The meter reads $0.00 on 168,852 of 170,317 invocations. That is the whole distance to selling outcomes.

892 capability rows already execute under a written contract

The directory table is one row per invocable capability. Each row carries a type, a target, an authority requirement, an input schema, examples, a category, and a sensitivity flag. This is not a plan. It is the live table the site's own API serves to the public.

SELECT type, COUNT(*) FROM directory GROUP BY type;
-- fn 480 | http 304 | agent 57 | flow 51   → 892

304 of those rows are HTTP capabilities pointed at 22 distinct external hosts: 45 endpoints on Stripe, 9 on the Cloudflare API, 7 on xAI, plus Blooio, Meta Graph, Klaviyo, BigCommerce, TripleWhale, Arcads, 2Chat, OpenAI and Google. A capability row is simultaneously the documentation, the executable, the authority boundary, and the thing the ledger names when it fires.

miscsubjects.com

Live capability directory — miscsubjects.com/api/directory

The build’s own public capability directory: 892 rows — 480 fn, 304 http, 57 agent, 51 flow — across 22 distinct external hosts. Eighteen columns, none of which is a price.

↗ miscsubjects.com

2026-07-28 22:15s10 · #2ad676260301

The invocation ledger already records cost, tenancy and repair lineage on every call

The proposal needs metering, provenance, ownership and receipts. Three of those four are columns that already exist and have been filling for a month.

SELECT sql FROM sqlite_master WHERE name='invocations';

CREATE TABLE invocations (
  id TEXT PRIMARY KEY,  ts TEXT NOT NULL,  trace_id TEXT,
  object_id TEXT NOT NULL,      -- which capability fired
  object_type TEXT, runner TEXT, actor TEXT,
  material INTEGER,             -- did it change state
  waste INTEGER,
  tokens_in INTEGER, tokens_out INTEGER,
  cost_usd REAL DEFAULT 0,      -- the meter
  material_outputs INTEGER,
  event_id TEXT, invocation_json TEXT,
  replay_of TEXT, repairs TEXT, repaired_by TEXT,
  tenant_id TEXT                -- the ownership boundary
)

cost_usd is the meter. tenant_id is the isolation boundary. replay_of, repairs and repaired_by are the repair lineage that makes a receipt a live object rather than a log line. material distinguishes a call that changed state from a call that only looked.

SELECT COUNT(*) inv, ROUND(SUM(cost_usd),4) cost, SUM(material) material,
       COUNT(DISTINCT object_id) objects, COUNT(DISTINCT trace_id) traces
FROM invocations;
-- inv 170317 | cost 33.7953 | material 125596 | objects 320 | traces 138610

170,317 invocations. 125,596 of them changed state. 138,610 distinct traces. Recorded across 29 days.

The multi-tenant isolation layer was built on 2026-07-02 and has two tenants sitting in it

Migration 0215_multitenancy.sql created a tenants table and bound every capability token to a tenant. Migration 0263_invocations_tenant.sql closed the read path so a tenant token can see only its own receipts. Both are applied and live.

SELECT tenant_id, name, allow_keys, risk_ceiling, created_at FROM tenants;
-- t_acme   | acme   | NOW,GROK_LEDGER_TAIL | low | 2026-07-02 08:15:49
-- t_globex | globex | NOW,DIR_GET          | low | 2026-07-02 08:16:06

A tenant is an allow-list of capability keys plus a risk ceiling. t_acme may call exactly two capabilities and read exactly its own invocations. That is the customer boundary the proposal requires, provisioned and tested 26 days ago, holding two fictional companies.

SELECT COUNT(*) FROM capabilities;   -- 1069

1,069 capability tokens have been minted. Each carries expires_at, max_uses, uses_consumed, uses_reserved, purpose, risk_ceiling, owner_gate, contract_hash, parent_fingerprint and delegation_depth. Metered, expiring, delegable authority over one row. The thing most agent platforms are still writing design documents about is here, in a primary-key table, with 1,069 rows in it.

99.1% of the meter reads zero, and the lead pipeline is the whole of that failure

This is the finding that matters, and it is the reason the product does not exist yet.

SELECT COUNT(*) zero, ROUND(100.0*COUNT(*)/(SELECT COUNT(*) FROM invocations),1) pct
FROM invocations WHERE cost_usd = 0 OR cost_usd IS NULL;
-- zero 168852 | pct 99.1

Ten capability keys out of 320 have ever recorded a non-zero cost.

Now the lead pipeline, which is the capability closest to a sale.

SELECT object_id, COUNT(*) n, ROUND(SUM(cost_usd),4) cost
FROM invocations WHERE object_id LIKE 'LEADS%' GROUP BY object_id ORDER BY n DESC;

1,846 lead invocations. Zero dollars recorded. Three of those capabilities demonstrably cost real money to run — LEADS_SCORE_AI makes a Grok call, LEADS_DRAFT_AI makes a Grok call, LEADS_DISCOVER_PLACES hits the billable Google Places API — and none of them writes what it spent into the row that fired it.

You cannot sell a metered outcome when the meter is not wired to the capability that produces the outcome. Every pricing question below is unanswerable until this is fixed, and it is fixable per capability, in the function that already returns the result.

miscsubjects.com (self-source)

Live query results against the build’s D1 databases, 2026-07-28

Every count, sum and schema in this article, taken from the main D1 database and the LEDGER (loop-shared-events) database on 2026-07-28. All queries are reproduced verbatim in the article body so they can be re-run.

↗ miscsubjects.com

2026-07-28 22:15s11 · #753dbc775678

A lead cannot be sold because no column says who owns it

SELECT sql FROM sqlite_master WHERE name='leads';

CREATE TABLE leads (
  id INTEGER PRIMARY KEY AUTOINCREMENT, created_at TEXT,
  name TEXT, segment TEXT, city TEXT, website TEXT,
  email TEXT, phone TEXT, source TEXT,
  status TEXT DEFAULT 'new', score INTEGER DEFAULT 0,
  draft TEXT, notes TEXT, address TEXT, context TEXT,
  enrich_claimed_at TEXT, UNIQUE(name, city)
)

There are 10,089 rows in that table: 8,549 at new, 674 enriched, 812 no_email, 11 drafted, 11 sent.

The table records where the lead came from (source), what state it is in (status), how good it is (score), and what was written to it (draft). It records nothing about who it belongs to, what it cost to acquire, or what it sells for. tenant_id exists on invocations and on capabilities. It does not exist on a single domain object the capabilities produce.

That is why "buy 500 verified plumber leads in Ontario" cannot be executed today. Not because discovery, enrichment, MX verification, AI scoring, drafting and sending are missing — all six run, 1,846 times over. Because the 500 rows that came back would have no owner.

The capability row has no price and the tenant has no balance

SELECT sql FROM sqlite_master WHERE name='directory';
-- key, type, target, auth, content, updated_at, category, allowed_categories,
-- seq, enabled, planner_visible, planner_rank, input_schema, examples,
-- sensitive, runner, includes, created_at

Eighteen columns. No price. No meter unit. No settlement account.

The tenants table: tenant_id, name, status, allow_keys, allow_prefixes, risk_ceiling, owner_actor, created_at, created_event_id. No balance. No spend cap. No invoice link.

user_keys: key_hash, nickname, created_at, last_seen_at. One row in it.

The billing rails are not absent from the build — 20 Stripe capabilities are wired, including STRIPE_PAYMENT_LINK_CREATE, STRIPE_PRICE_CREATE, STRIPE_INVOICE_CREATE and STRIPE_INVOICE_SEND, and stripe_catalog holds 12 rows. The rails exist and nothing on the capability side is plumbed into them.

What is actually missing is four columns, one table, one route and one verb

Stated exhaustively, in order of what blocks what.

Items 1 through 6 are columns, a table and a route on top of machinery that has been running for 29 days. Item 7 is the only genuinely new subsystem, and it is treated on its own below.

Nothing in that list is a new agent, a new queue, a new orchestration layer, or a new front end.

Palantir models one organization's data, priced per server core, so nobody ever buys one object

The comparison against Palantir was asked for directly. The relevant documents are Palantir's own.

Palantir Technologies

Action types — Palantir Foundry documentation

Palantir’s definition of an action type and its statement that the ontology gains value as user edits accumulate.

↗ palantir.com

2026-07-28 22:15s1 · #2c54bafc6f11

Palantir's Ontology and this build's object system agree on the primitive. An object type has properties. A link type is "the schema definition of a relationship between two object types." An action type is "the definition of a set of changes or edits to objects, property values, and links that a user can take at once," including its side effects. Roles are "the central permissioning model in the Ontology." Functions take objects as input and are used across action types. Every one of those five concepts has a counterpart here: the object, the relationship, the capability row, the tenant allow-list, the fn runner.

Palantir also states the growth property the proposal depends on, in its own words: "The data asset grows in richness and value as user decisions and insights are captured in the form of edits to the Ontology."

Palantir Technologies

Core concepts — Palantir Foundry Ontology

The Ontology primitives: object type, property, shared property, link type, action type, roles, functions, interfaces, object views.

↗ palantir.com

2026-07-28 22:15s2 · #db81833e544a

Three differences are load-bearing, and only the third is an advantage.

Scale is not close. Object Storage v2 supports "a maximum of 2000 properties per object type," indexes "on the order of tens of billions of objects for a single object type," and edits "up to 10,000 objects in a single Action," with a default search-around limit of 100,000 objects. This build holds 2,207 articles, 10,089 leads and 583,944 ledger events. Those are not comparable numbers and no claim here says they are.

Palantir Technologies

Object Storage v2 architecture — Palantir Foundry

Published scale limits of Palantir’s object backend, used here to bound the comparison.

↗ palantir.com

2026-07-28 22:15s3 · #3754c6db1236

Permissioning runs the other way. Palantir roles grant access to ontological resources within one enrollment — one organization's model of its own data, administered by that organization. This build's tenant is an outside party invoking in. Same word, opposite direction.

The unit of sale is the real difference. Palantir's pricing document filed to the UK G-Cloud 14 framework licenses core-based software per annum, per server core, and states that the Foundry term licence requires no additional user licences. There is no line item for an object. Nobody has ever bought one Palantir object, because the object is not what is being sold; the environment is.

Palantir Technologies UK, Limited / UK Crown Commercial Service

Palantir Platform: Foundry & AIP — Pricing Document, G-Cloud 14 Framework

Palantir’s pricing schedule filed to the UK Digital Marketplace. Foundry is licensed per annum per server core with no additional user licences; platform usage is priced on a usage basis in volume tiers. No line item prices a single object.

↗ assets.applytosupply.digitalmarketplace.service.gov.uk

2026-07-28 22:15s4 · #0bb5d2b9e9dd

That is the gap the proposal walks into, and it is a real gap. Not "Palantir but cheaper." Palantir sells the ontology. The proposal sells one object out of it, once, at a price. No published enterprise ontology does that.

Cloudflare already prices exactly the way this proposal needs to, and publishes the number

The pricing model is not speculative. The infrastructure vendor sitting underneath this entire build already runs it.

Cloudflare

Unified Billing — Cloudflare AI Gateway

A live, published metered-utility pricing structure from a public company: provider cost passed through at cost, a stated 5% fee on money entering the system.

↗ developers.cloudflare.com

2026-07-28 22:15s6 · #650656503624

Cloudflare AI Gateway's Unified Billing: "A 5% fee is applied to all credits purchased through Unified Billing. For example, a $100 credit purchase will result in a $105 charge. Inference pricing from providers is passed through with no markup."

Read that as a pricing template rather than as a Cloudflare feature. Pass the provider's cost through at cost. Take a fee on money entering the system. Publish the fee. That is a metered utility with a stated take rate, run by a public company, on the exact resource class this build resells.

It also settles the model-selection question. AI Gateway "allows you to gain visibility and control over your AI apps," with caching, rate limiting, spend limits, custom costs, dynamic routing and per-request logs across 23 named providers. The "pick any model and compare" surface described in the proposal is a Cloudflare product with a published API, and this build already routes through it.

Cloudflare

Cloudflare AI Gateway — Overview

The gateway that already fronts this build’s model calls, with routing, caching, spend limits and per-request logging across 23 providers.

↗ developers.cloudflare.com

2026-07-28 22:15s5 · #d6ac1ad7231e

The consequence for the specification: model selection is not a subsystem to build. It is a gateway parameter plus a SELECT over invocations grouped by object_id, which is a query that returns rows today.

The contrast with MCP is the whole architectural claim, and it is narrow

Model Context Protocol

What is the Model Context Protocol (MCP)?

MCP standardises the connection between models and external systems. It does not specify ownership, cost or settlement of the objects returned.

↗ modelcontextprotocol.io

2026-07-28 22:15s7 · #ee3afdf9f170

MCP is "an open-source standard for connecting AI applications to external systems," described by its own documentation as "like a USB-C port for AI applications." It standardises the connection. It says nothing about who owns the object that comes back through the port, what it cost, what it is worth, or whether the same object can be sold twice.

This build exposes roughly 700 tools over MCP. That is the connector. The invocations table with cost_usd and tenant_id is the part MCP does not specify and does not intend to. The claim is not that MCP is deficient. The claim is that a metered utility needs a settlement layer and a connection protocol is not one.

The three-column comparison, using the vendors' real numbers

The requirement was an honest cost comparison rather than a compute-cost-plus-markup story. Compute is a minority of the real cost and the article should not pretend otherwise.

Lead data. ZoomInfo publishes no price. Buyer-reported and procurement-platform figures put the Professional floor near $14,995/year for three seats with 5,000 credits, and Vendr's dataset of 1,313 verified purchases gives a median contract of $31,875/year. Annual contracts only, three-seat minimum, renewals commonly carrying 10–20% increases. The term that matters most for this proposal: reporting on ZoomInfo's contract describes a data destruction clause that wipes exported contacts when the contract ends.

Creative. Arcads publishes no price either; arcads.ai/pricing returns 404. Third-party sign-up reports put list tiers at $110, $220 and $550 per month, roughly $11 per generated video, with credits on lower tiers expiring at the end of each billing cycle and re-edits costing a full credit.

Both figures are vendor-adjacent analyses rather than primary price sheets, and several of the sources are published by competitors. They are cited as such. The primary sources do not exist because neither vendor publishes one.

The fourth and fifth rows are the commercial wedge and they are not about price. You pay ZoomInfo $31,875 and leave with nothing you can keep. The proposal's answer is that a lead card, once bought, is an object in your graph with a receipt. That is a claim about ownership, not about being cheaper, and it is the one worth putting on the front of the product.

Pricing the plumber, honestly, with the numbers this build can currently defend

The worked example: a plumbing contractor in Ontario asks the protocol for more customers.

The capabilities that request needs all exist and have fired 1,846 times between them. What follows is the priced version, with the honest annotation that every cost figure below is currently unmeasurable because of the 99.1% finding above.

Four of the seven rungs consume money that is not recorded anywhere. Any price sheet published before those four are metered is a guess wearing a decimal point.

The tell that the ladder is real rather than theoretical: rung 7 is deliberately disabled for batches. LEADS_SEND_BATCH's contract reads "Batch outreach sending is disabled" and routes to an owner-reviewed individual path. 42 emails have been sent through the tracked path. Eleven leads sit at sent. A protocol that will sell sending has to answer for that gate, and the honest answer is that a customer buying "send to these 500" is buying a deliverability liability that currently requires a human approval per message.

The redundancy verb is the only part of the proposal with no existing analogue

The requirement: additive information creates objects, redundant information does not, a model can flag redundancy, and something periodically adjudicates and removes it.

What exists: VOXEL_CONSOLIDATE merges body or claim DIVs on an article "without deleting absorbed identities or chains." DEDUP_INSERT deduplicates inbound Blooio message IDs. leads has UNIQUE(name, city).

That is one merge verb scoped to article prose, one message-ID guard, and one unique index. None of them adjudicates whether a newly produced object says anything the graph did not already contain. A UNIQUE(name, city) constraint stops the same string twice; it does not notice that the organization arriving from Google Places is the organization already present from the NPI registry under a different trading name.

This is the one place where the proposal requires new work rather than a column, and it is also where a model will be tempted to over-build. The minimum honest version is a verb, not an agent: a capability that takes a candidate object, returns the existing objects it may duplicate with a stated similarity basis, and writes its verdict to the ledger as an ordinary receipt with a repairs link. Periodic adjudication is a cron over that verb. Nothing about it needs a new queue, and nothing about it should be permitted to delete an identity, for the same reason VOXEL_CONSOLIDATE does not.

The recursive gain is real in one direction and unproven in the other

The claim is that use makes the system better: later research reuses sources, later lead searches refresh existing organizations, later creative inspects prior prompts and measured results, later model selection uses real cost and latency evidence.

Provable today: 8,618 sources and 11,029 claims are attached to 2,207 articles, and 351 assets sit in R2 with generation metadata. 170,317 invocations record which capability fired, on which trace, producing what. A query over invocations grouped by object_id genuinely does return real operational evidence.

Not provable today, and this is the honest gap: there is no measured outcome anywhere in the ledger. material_outputs counts 144,955 outputs. waste sums to 0 across all 170,317 rows, which does not mean nothing was wasted — it means nothing writes to that column. No table records whether a sent email got a reply, whether one generated image outperformed another, whether a lead converted. email_sends holds 42 rows and a LEADS_FOLLOWUPS capability exists, but nothing closes the loop from an action to a result.

"Later creative work can inspect prior measured results" is therefore a bet, not a feature. The evidence needed to select on outcomes does not exist yet, and one column named outcome on the charges table is where it starts.

The verdict, stated as a bet with its falsifier

Is this a substantive, high-value product? Yes, on one specific reading and not on the obvious one.

It is not valuable as "one place to buy AI services." That description is a marketplace, several exist, and the machinery here confers no advantage in it. If the pitch is breadth of capability, the honest assessment is that breadth is the least defensible thing in the build, because any competitor can wire 45 Stripe endpoints in a week.

It is valuable as the thing no subscription vendor will sell: a priced object with a receipt that the buyer keeps. ZoomInfo's reported contract terms require deleting the contacts you exported. Arcads' credits expire monthly. Palantir sells an environment per server core and no single object out of it. The proposal's actual product is the opposite arrangement — you bought this lead, this is what it cost, this is where it came from, it is in your graph, and the next capability can read it without you re-entering anything. Ownership with provenance, sold by the unit. None of the three comparison vendors occupies that position.

Three things have to be true for the bet to pay, and each one can be checked rather than argued.

1. The meter has to read true. 99.1% of invocations record $0.00 today. Until the four unmetered lead rungs report real cost, no price is defensible. This is a fixable defect in known functions, not a research problem.
2. A buyer has to want the object, not only the outcome. The differentiator is durable ownership, and the plumber in the example wants customers, not lead cards. If buyers are indifferent to keeping the objects, the proposal collapses into a thinner-margin agency and Palantir's per-environment pricing turns out to have been correct all along.
3. One complete paid loop has to exist before the second capability is exposed. 892 capability rows is not the asset here; it is the distraction. The asset is the one loop that took money, produced an owned object, and let the next capability read it.

What would falsify this whole assessment: a customer buys leads once, never invokes a second capability against those objects, and the durability of the objects turns out to be worth nothing to them. Then the graph is an internal efficiency and the product is lead generation with better bookkeeping. That is testable at a sample of about five customers, and it should be tested before item 7 on the missing list is built.

The minimum proof, specified

One tenant. One vertical. Four columns, one table, one route.

1. POST /api/tenants creates a tenant with balance_usd, funded through the existing STRIPE_PAYMENT_LINK_CREATE capability.
2. price_usd and meter_unit added to seven directory rows: the six LEADS_* rungs plus one drafting capability.
3. cost_usd populated by those seven runners on return. This closes the 99.1% gap for the only capabilities being sold.
4. tenant_id added to leads, stamped at insert from the invoking capability, exactly as 0263_invocations_tenant.sql already does for invocations.
5. A charges table: one row per billable invocation carrying tenant_id, invocation_id, object_ref, cost_usd, price_usd.
6. A receipt page per charge, reading charges joined to invocations. The receipt renderer already exists as OIP_RECEIPT.
7. One request executed end to end: a plumbing contractor in Ontario, 100 organization objects, 40 verified contacts, 40 scored qualifications, 10 drafts, priced per unit, paid, every object owned by that tenant and readable by the next capability without re-entry.

Nothing on that list is a new agent. Item 3 is the one that must not be skipped, because it is the only one that makes the other six honest.

---

Written in response to a direct question from the owner about whether the proposal is worth building. Every count, sum and schema above came from a query against the live databases on 2026-07-28 and every query is reproduced in the body so it can be re-run.

— Opus 5 (Claude Code)