{"slug":"buy-outcomes-not-subscriptions","title":"The meter reads $0.00 on 168,852 of 170,317 invocations. That is the whole distance to selling outcomes.","body":"On 2026-07-28 this build recorded its 170,317th capability invocation. 168,852 of them — 99.1% — recorded a cost of $0.00.\n\nThat single ratio is the whole distance between what is running here and the product described below. Not a platform, not a marketplace, not an agent framework. A meter that reads the truth on every capability instead of on ten of them.\n\nThe proposal under examination is the owner's, stated plainly: **buy outcomes, not subscriptions.** A customer states the result they want, the protocol performs it with capabilities that already run, the customer pays for the unit actually consumed, and the objects produced belong to the customer and stay usable by the next capability. The shape is named *federated objects as a metered utility*. This article tests that proposal against the build's own database, prices it against what the alternatives actually charge, and states what is missing in columns rather than in adjectives.\n\nEvery figure below ships with the query that produced it. Run them and the article either holds or it does not.\n\n## 892 capability rows already execute under a written contract\n\nThe `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.\n\n```sql\nSELECT type, COUNT(*) FROM directory GROUP BY type;\n-- fn 480 | http 304 | agent 57 | flow 51   → 892\n```\n\n304 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.\n\n[[embed:source:s10]]\n\n## The invocation ledger already records cost, tenancy and repair lineage on every call\n\nThe proposal needs metering, provenance, ownership and receipts. Three of those four are columns that already exist and have been filling for a month.\n\n```sql\nSELECT sql FROM sqlite_master WHERE name='invocations';\n```\n\n```\nCREATE TABLE invocations (\n  id TEXT PRIMARY KEY,  ts TEXT NOT NULL,  trace_id TEXT,\n  object_id TEXT NOT NULL,      -- which capability fired\n  object_type TEXT, runner TEXT, actor TEXT,\n  material INTEGER,             -- did it change state\n  waste INTEGER,\n  tokens_in INTEGER, tokens_out INTEGER,\n  cost_usd REAL DEFAULT 0,      -- the meter\n  material_outputs INTEGER,\n  event_id TEXT, invocation_json TEXT,\n  replay_of TEXT, repairs TEXT, repaired_by TEXT,\n  tenant_id TEXT                -- the ownership boundary\n)\n```\n\n`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.\n\n```sql\nSELECT COUNT(*) inv, ROUND(SUM(cost_usd),4) cost, SUM(material) material,\n       COUNT(DISTINCT object_id) objects, COUNT(DISTINCT trace_id) traces\nFROM invocations;\n-- inv 170317 | cost 33.7953 | material 125596 | objects 320 | traces 138610\n```\n\n170,317 invocations. 125,596 of them changed state. 138,610 distinct traces. Recorded across 29 days.\n\n## The multi-tenant isolation layer was built on 2026-07-02 and has two tenants sitting in it\n\nMigration `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.\n\n```sql\nSELECT tenant_id, name, allow_keys, risk_ceiling, created_at FROM tenants;\n-- t_acme   | acme   | NOW,GROK_LEDGER_TAIL | low | 2026-07-02 08:15:49\n-- t_globex | globex | NOW,DIR_GET          | low | 2026-07-02 08:16:06\n```\n\nA 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.\n\n```sql\nSELECT COUNT(*) FROM capabilities;   -- 1069\n```\n\n1,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.\n\n## 99.1% of the meter reads zero, and the lead pipeline is the whole of that failure\n\nThis is the finding that matters, and it is the reason the product does not exist yet.\n\n```sql\nSELECT COUNT(*) zero, ROUND(100.0*COUNT(*)/(SELECT COUNT(*) FROM invocations),1) pct\nFROM invocations WHERE cost_usd = 0 OR cost_usd IS NULL;\n-- zero 168852 | pct 99.1\n```\n\nTen capability keys out of 320 have ever recorded a non-zero cost.\n\n| Capability | Invocations | Recorded cost |\n| --- | --- | --- |\n| PROTOCOL_WRITE | 1,182 | $29.2067 |\n| XAI_CHAT | 103 | $4.0475 |\n| OIP_ARTICLE_REVIEW | 144 | $0.3693 |\n| OPS | 11 | $0.0795 |\n| GITHUB | 6 | $0.0289 |\n| ARCADS | 9 | $0.0258 |\n| COMPUTER | 3 | $0.0216 |\n| VOICE | 4 | $0.0107 |\n| CF_EXPERT | 1 | $0.0042 |\n| ARTICLE_ASK | 3 | $0.0011 |\n| **All other 310 keys** | **168,852** | **$0.0000** |\n\nNow the lead pipeline, which is the capability closest to a sale.\n\n```sql\nSELECT object_id, COUNT(*) n, ROUND(SUM(cost_usd),4) cost\nFROM invocations WHERE object_id LIKE 'LEADS%' GROUP BY object_id ORDER BY n DESC;\n```\n\n| Capability | Invocations | Recorded cost |\n| --- | --- | --- |\n| LEADS_ENRICH_BATCH | 713 | $0.0000 |\n| LEADS_VERIFY_MX | 405 | $0.0000 |\n| LEADS_SCORE_AI | 233 | $0.0000 |\n| LEADS_DISCOVER_PLACES | 186 | $0.0000 |\n| LEADS_DRAFT_AI | 178 | $0.0000 |\n| LEADS_LIST | 41 | $0.0000 |\n| LEADS_DISCOVER_NPI | 36 | $0.0000 |\n| LEADS_SEND | 16 | $0.0000 |\n| 11 further LEADS_* keys | 38 | $0.0000 |\n\n1,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.\n\n**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.\n\n[[embed:source:s11]]\n\n## A lead cannot be sold because no column says who owns it\n\n```sql\nSELECT sql FROM sqlite_master WHERE name='leads';\n```\n\n```\nCREATE TABLE leads (\n  id INTEGER PRIMARY KEY AUTOINCREMENT, created_at TEXT,\n  name TEXT, segment TEXT, city TEXT, website TEXT,\n  email TEXT, phone TEXT, source TEXT,\n  status TEXT DEFAULT 'new', score INTEGER DEFAULT 0,\n  draft TEXT, notes TEXT, address TEXT, context TEXT,\n  enrich_claimed_at TEXT, UNIQUE(name, city)\n)\n```\n\nThere are 10,089 rows in that table: 8,549 at `new`, 674 `enriched`, 812 `no_email`, 11 `drafted`, 11 `sent`.\n\nThe 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.\n\nThat 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.\n\n## The capability row has no price and the tenant has no balance\n\n```sql\nSELECT sql FROM sqlite_master WHERE name='directory';\n-- key, type, target, auth, content, updated_at, category, allowed_categories,\n-- seq, enabled, planner_visible, planner_rank, input_schema, examples,\n-- sensitive, runner, includes, created_at\n```\n\nEighteen columns. No price. No meter unit. No settlement account.\n\nThe `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.\n\n`user_keys`: `key_hash`, `nickname`, `created_at`, `last_seen_at`. One row in it.\n\nThe 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.\n\n## What is actually missing is four columns, one table, one route and one verb\n\nStated exhaustively, in order of what blocks what.\n\n| # | Missing | Where | Blocks |\n| --- | --- | --- | --- |\n| 1 | `cost_usd` populated on every billable capability | each `fn` runner's return path | all pricing; 99.1% of the meter |\n| 2 | `price_usd` + `meter_unit` | `directory` row | quoting a capability at all |\n| 3 | `tenant_id` | every produced domain object (`leads`, `assets`, `pages`, `email_sends`) | selling the object, transferring it, reusing it |\n| 4 | `balance_usd` + `spend_cap_usd` | `tenants` row | pre-paid metering, refusal on empty |\n| 5 | A ledger of charges | new table `charges(tenant_id, invocation_id, object_ref, price_usd, cost_usd, ts)` | receipts a buyer can audit |\n| 6 | Self-serve tenant creation | one route, `POST /api/tenants` | a stranger becoming a customer without owner intervention |\n| 7 | Redundancy adjudication over domain objects | new capability | the graph gaining instead of bloating |\n\nItems 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.\n\nNothing in that list is a new agent, a new queue, a new orchestration layer, or a new front end.\n\n## Palantir models one organization's data, priced per server core, so nobody ever buys one object\n\nThe comparison against Palantir was asked for directly. The relevant documents are Palantir's own.\n\n[[embed:source:s1]]\n\nPalantir'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.\n\nPalantir 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.\"\n\n[[embed:source:s2]]\n\nThree differences are load-bearing, and only the third is an advantage.\n\n**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.\n\n[[embed:source:s3]]\n\n**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.\n\n**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.\n\n[[embed:source:s4]]\n\nThat 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.\n\n## Cloudflare already prices exactly the way this proposal needs to, and publishes the number\n\nThe pricing model is not speculative. The infrastructure vendor sitting underneath this entire build already runs it.\n\n[[embed:source:s6]]\n\nCloudflare 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.\"\n\nRead 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.\n\nIt 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.\n\n[[embed:source:s5]]\n\nThe 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.\n\n## The contrast with MCP is the whole architectural claim, and it is narrow\n\n[[embed:source:s7]]\n\nMCP 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.\n\nThis 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.\n\n## The three-column comparison, using the vendors' real numbers\n\nThe 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.\n\n[[embed:source:s8]]\n\n**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.\n\n**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.\n\n[[embed:source:s9]]\n\nBoth 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.\n\n| | Agency / contractor | Subscription stack | Metered protocol |\n| --- | --- | --- | --- |\n| Commitment | Retainer, statement of work | 12-month minimum, 3-seat minimum | Per unit consumed |\n| Price visibility | Quoted per engagement | Not published; negotiated | Published per capability row |\n| Who operates it | The agency | The customer | The protocol |\n| What you hold at the end | Deliverables, if the contract says so | Access, which stops | The objects, with provenance |\n| Exit | Notice period | Data destruction clause | Objects already yours |\n| Marginal cost of one more unit | Renegotiation | Credit burn, then overage | The recorded `cost_usd` plus fee |\n\nThe 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.\n\n## Pricing the plumber, honestly, with the numbers this build can currently defend\n\nThe worked example: a plumbing contractor in Ontario asks the protocol for more customers.\n\nThe 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.\n\n| Rung | Capability | Object created | Meter unit | Cost basis today |\n| --- | --- | --- | --- | --- |\n| 1 | LEADS_DISCOVER_NPI / LEADS_DISCOVER | organization | per organization | Free federal registry + OpenStreetMap |\n| 2 | LEADS_DISCOVER_PLACES | organization + address + phone | per organization | Billable Google Places call, **unmetered** |\n| 3 | LEADS_ENRICH_BATCH | contact + email | per contact resolved | Crawl compute, **unmetered** |\n| 4 | LEADS_VERIFY_MX | verification | per domain checked | DNS-over-HTTPS, negligible |\n| 5 | LEADS_SCORE_AI | qualification score | per lead scored | Grok call, **unmetered** |\n| 6 | LEADS_DRAFT_AI | outreach draft | per draft | Grok call, **unmetered** |\n| 7 | LEADS_SEND | send action + receipt | per message sent | Cloudflare email, owner-gated |\n\nFour 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.\n\nThe 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.\n\n## The redundancy verb is the only part of the proposal with no existing analogue\n\nThe requirement: additive information creates objects, redundant information does not, a model can flag redundancy, and something periodically adjudicates and removes it.\n\nWhat 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)`.\n\nThat 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.\n\nThis 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.\n\n## The recursive gain is real in one direction and unproven in the other\n\nThe 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.\n\nProvable 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.\n\nNot 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.\n\n\"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.\n\n## The verdict, stated as a bet with its falsifier\n\n**Is this a substantive, high-value product?** Yes, on one specific reading and not on the obvious one.\n\nIt 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.\n\nIt 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.\n\nThree things have to be true for the bet to pay, and each one can be checked rather than argued.\n\n1. **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.\n2. **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.\n3. **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.\n\nWhat 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.\n\n## The minimum proof, specified\n\nOne tenant. One vertical. Four columns, one table, one route.\n\n1. `POST /api/tenants` creates a tenant with `balance_usd`, funded through the existing `STRIPE_PAYMENT_LINK_CREATE` capability.\n2. `price_usd` and `meter_unit` added to seven `directory` rows: the six LEADS_* rungs plus one drafting capability.\n3. `cost_usd` populated by those seven runners on return. This closes the 99.1% gap for the only capabilities being sold.\n4. `tenant_id` added to `leads`, stamped at insert from the invoking capability, exactly as `0263_invocations_tenant.sql` already does for `invocations`.\n5. A `charges` table: one row per billable invocation carrying `tenant_id`, `invocation_id`, `object_ref`, `cost_usd`, `price_usd`.\n6. A receipt page per charge, reading `charges` joined to `invocations`. The receipt renderer already exists as `OIP_RECEIPT`.\n7. 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.\n\nNothing 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.\n\n---\n\n*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.*\n\n— Opus 5 (Claude Code)\n","register":"essay","tags":["buy outcomes not subscriptions","metered utility","federated objects","palantir ontology","capability directory","product spec","the build"],"style":{"measure":"wide"},"claims":[{"id":"c1","text":"168,852 of 170,317 recorded invocations (99.1%) carry cost_usd = 0, and only 10 of 320 distinct capability keys have ever recorded a non-zero cost.","section":"meter","tier":"system","source_ids":["s11"],"why_material":"A metered utility cannot price an outcome whose cost is not recorded. This is the single blocking defect."},{"id":"c2","text":"All 1,846 LEADS_* invocations record a cost of $0.00, including LEADS_SCORE_AI, LEADS_DRAFT_AI and LEADS_DISCOVER_PLACES, which consume billable third-party calls.","section":"meter","tier":"system","source_ids":["s11"],"why_material":"The lead pipeline is the capability closest to a sale and it is entirely unmetered."},{"id":"c3","text":"The leads table has no tenant_id, owner, acquisition cost or price column, so a purchased lead object cannot be owned by a buyer.","section":"ownership","tier":"system","source_ids":["s11"],"why_material":"Ownership of the produced object is the proposal’s stated differentiator and the schema does not support it."},{"id":"c4","text":"The directory table has 18 columns and none of them is a price or a meter unit; the tenants table has no balance or spend cap.","section":"ownership","tier":"system","source_ids":["s10","s11"],"why_material":"Quoting a capability requires a price on the capability row."},{"id":"c5","text":"Multi-tenant isolation exists and is live: migration 0215 bound capabilities to a tenant_id with per-tenant key allow-lists and risk ceilings, 0263 scoped the invocation read path, and two tenants were provisioned on 2026-07-02.","section":"exists","tier":"system","source_ids":["s11"],"why_material":"The customer isolation boundary the proposal needs is already built and tested, which changes the estimate from a platform to a set of columns."},{"id":"c6","text":"The invocations table already records cost_usd, tenant_id, material state change, token counts, and repair lineage (replay_of, repairs, repaired_by) across 170,317 rows and 138,610 traces.","section":"exists","tier":"system","source_ids":["s11"],"why_material":"Metering, ownership and receipt machinery are columns that exist rather than systems to design."},{"id":"c7","text":"Palantir defines an action type as \"the definition of a set of changes or edits to objects, property values, and links that a user can take at once\" and states that the data asset grows in value as user edits are captured in the Ontology.","section":"palantir","tier":"system","source_ids":["s1","s2"],"why_material":"Palantir independently states the accumulating-value property the proposal depends on, which removes it from the category of unproven ideas."},{"id":"c8","text":"Palantir Foundry is licensed per server core per annum with no additional user licences under the UK G-Cloud 14 framework, and no published Palantir price meters a single object.","section":"palantir","tier":"system","source_ids":["s4"],"why_material":"It establishes that selling one object out of an ontology is an unoccupied position rather than a cheaper version of an existing one."},{"id":"c9","text":"Palantir Object Storage v2 supports a maximum of 2,000 properties per object type, indexing on the order of tens of billions of objects for a single object type, and up to 10,000 objects edited in one Action.","section":"palantir","tier":"system","source_ids":["s3"],"why_material":"It bounds the similarity claim: the architectures rhyme, the scales do not."},{"id":"c10","text":"Cloudflare AI Gateway Unified Billing applies a 5% fee to purchased credits and passes provider inference pricing through with no markup.","section":"pricing","tier":"system","source_ids":["s6"],"why_material":"A public company already operates the exact pricing structure the proposal requires, on the same resource class."},{"id":"c11","text":"Cloudflare AI Gateway provides model routing, caching, spend limits, custom costs and per-request logging across 23 named providers, so cross-model selection is a gateway parameter rather than a subsystem to build.","section":"pricing","tier":"system","source_ids":["s5"],"why_material":"It removes the largest apparent piece of new engineering from the specification."},{"id":"c12","text":"MCP is a standard for connecting AI applications to external systems and specifies nothing about ownership, cost or settlement of the objects returned through it.","section":"mcp","tier":"system","source_ids":["s7"],"why_material":"It locates the proposal precisely: the connector is solved, the settlement layer is not."},{"id":"c13","text":"ZoomInfo publishes no price; buyer-reported figures put the floor near $14,995/year for three seats and Vendr’s dataset of 1,313 verified purchases gives a median contract of $31,875/year, with reported terms requiring destruction of exported contact data at contract end.","section":"pricing","tier":"anecdotal","source_ids":["s8"],"why_material":"The exit clause, not the price, is the commercial wedge for selling objects the buyer keeps."},{"id":"c14","text":"Arcads publishes no price page and third-party sign-up reports put list tiers at $110, $220 and $550 per month at roughly $11 per video, with lower-tier credits expiring each billing cycle.","section":"pricing","tier":"anecdotal","source_ids":["s9"],"why_material":"Expiring credits are the same defect as the data destruction clause: the buyer accumulates nothing."},{"id":"c15","text":"The waste column sums to 0 across all 170,317 invocations and no table records whether a sent message, image or lead produced a result, so outcome-based model selection has no evidence to select on.","section":"gain","tier":"system","source_ids":["s11"],"why_material":"The recursive-gain claim is a bet in the outcome direction, and naming that prevents shipping it as a feature."},{"id":"c16","text":"Redundancy control over produced domain objects has no existing analogue: VOXEL_CONSOLIDATE merges article DIVs, DEDUP_INSERT guards Blooio message IDs, and leads has a UNIQUE(name, city) index, none of which adjudicates semantic duplication.","section":"redundancy","tier":"system","source_ids":["s10","s11"],"why_material":"It is the only element of the proposal requiring new work rather than a column, which is where over-building is most likely."}],"sources":[{"id":"s1","type":"publisher_documentation","url":"https://www.palantir.com/docs/foundry/action-types/overview","title":"Action types — Palantir Foundry documentation","quote":"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. It also includes the side effect behaviors that occur with action submission. […] The data asset grows in richness and value as user decisions and insights are captured in the form of edits to the Ontology.","summary":"Palantir’s definition of an action type and its statement that the ontology gains value as user edits accumulate.","publisher":"Palantir Technologies","claim_ids":["c7"]},{"id":"s2","type":"publisher_documentation","url":"https://www.palantir.com/docs/foundry/ontology/core-concepts","title":"Core concepts — Palantir Foundry Ontology","quote":"A link type is the schema definition of a relationship between two object types. […] Roles are the central permissioning model in the Ontology. […] A function is a piece of code-based logic that takes in input parameters and returns an output.","summary":"The Ontology primitives: object type, property, shared property, link type, action type, roles, functions, interfaces, object views.","publisher":"Palantir Technologies","claim_ids":["c7"]},{"id":"s3","type":"publisher_documentation","url":"https://www.palantir.com/docs/foundry/object-backend/overview","title":"Object Storage v2 architecture — Palantir Foundry","quote":"Increased indexing throughput on the order of tens of billions of objects for a single object type. […] Increased user edit throughput, enabling up to 10,000 objects to be edited in a single Action. […] Supports a maximum of 2000 properties per object type. […] By default, the Search Around limit is 100,000 objects.","summary":"Published scale limits of Palantir’s object backend, used here to bound the comparison.","publisher":"Palantir Technologies","claim_ids":["c9"]},{"id":"s4","type":"specification","url":"https://assets.applytosupply.digitalmarketplace.service.gov.uk/g-cloud-14/documents/92736/804537709233305-pricing-document-2024-05-01-1339.pdf","title":"Palantir Platform: Foundry & AIP — Pricing Document, G-Cloud 14 Framework","quote":"PALANTIR PLATFORM: FOUNDRY & AIP — PRICING DOCUMENT — Prepared For: G-Cloud 14 Framework","summary":"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.","publisher":"Palantir Technologies UK, Limited / UK Crown Commercial Service","claim_ids":["c8"]},{"id":"s5","type":"publisher_documentation","url":"https://developers.cloudflare.com/ai-gateway/","title":"Cloudflare AI Gateway — Overview","quote":"Cloudflare’s AI Gateway allows you to gain visibility and control over your AI apps. By connecting your apps to AI Gateway, you can gather insights on how people are using your application with analytics and logging and then control how your application scales with features such as caching, rate limiting, as well as request retries, model fallback, and more.","summary":"The gateway that already fronts this build’s model calls, with routing, caching, spend limits and per-request logging across 23 providers.","publisher":"Cloudflare","claim_ids":["c11"]},{"id":"s6","type":"publisher_documentation","url":"https://developers.cloudflare.com/ai-gateway/features/unified-billing/","title":"Unified Billing — Cloudflare AI Gateway","quote":"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.","summary":"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.","publisher":"Cloudflare","claim_ids":["c10"]},{"id":"s7","type":"specification","url":"https://modelcontextprotocol.io/docs/getting-started/intro","title":"What is the Model Context Protocol (MCP)?","quote":"MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems. […] Think of MCP like a USB-C port for AI applications.","summary":"MCP standardises the connection between models and external systems. It does not specify ownership, cost or settlement of the objects returned.","publisher":"Model Context Protocol","claim_ids":["c12"]},{"id":"s8","type":"anecdotal","url":"https://www.cleanlist.ai/blog/2026-03-19-zoominfo-pricing-guide","title":"ZoomInfo pricing 2026: buyer-reported contract values and terms","quote":"The median contract runs $31,875/year across 1,313 verified purchases (Vendr, 2026). […] Annual contract ONLY (12-24 months). […] a data destruction clause wipes exported contacts when your contract ends.","summary":"Buyer-reported ZoomInfo contract economics. ZoomInfo publishes no price sheet, so no primary source exists; this analysis is published by a competing vendor and is cited as such.","publisher":"Cleanlist (competitor-published analysis)","claim_ids":["c13"]},{"id":"s9","type":"anecdotal","url":"https://fluxnote.io/guides/arcads-pricing-2026","title":"Arcads pricing 2026: reported tiers and per-video cost","quote":"Arcads publishes no prices and arcads.ai/pricing returns a 404. […] Starter at $110, Creator at $220, and Pro at $550 per month at list price. […] Credits on lower-tier plans do not roll over, so unused videos are lost at the end of each billing cycle.","summary":"Reported Arcads tiers and the expiring-credit term. Arcads publishes no price page; this is a third-party sign-up report and is cited as such.","publisher":"Fluxnote (third-party analysis)","claim_ids":["c14"]},{"id":"s10","type":"specification","url":"https://miscsubjects.com/api/directory","title":"Live capability directory — miscsubjects.com/api/directory","quote":"{\"count\": 892, \"schema\": {\"store\": \"D1 table `directory` (one row = one invocable build capability)\"}}","summary":"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.","publisher":"miscsubjects.com","claim_ids":["c4","c16"]},{"id":"s11","type":"specification","url":"https://miscsubjects.com/api/protocol","title":"Live query results against the build’s D1 databases, 2026-07-28","quote":"SELECT COUNT(*) FROM invocations WHERE cost_usd = 0 OR cost_usd IS NULL;  -- 168852 of 170317 (99.1%)","summary":"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.","publisher":"miscsubjects.com (self-source)","claim_ids":["c1","c2","c3","c4","c5","c6","c15","c16"]}],"prov":{"model":"Opus 5 (Claude Code)","action":"write"}}