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

slug: buy-outcomes-not-subscriptions · https://miscsubjects.com/a/buy-outcomes-not-subscriptions · tags: buy outcomes not subscriptions, metered utility, federated objects, palantir ontology, capability directory, product spec, the build · updated 2026-07-28T22:27:39.573Z

On 2026-07-28 this build recorded its 170,317th capability invocation. 168,852 of them — 99.1% — recorded a cost of $0.00.

That 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.

The 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.

Every figure below ships with the query that produced it. Run them and the article either holds or it does not.

## 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.

```sql
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.

[[embed:source:s10]]

## 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.

```sql
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.

```sql
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.

```sql
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.

```sql
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.

```sql
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.

| Capability | Invocations | Recorded cost |
| --- | --- | --- |
| PROTOCOL_WRITE | 1,182 | $29.2067 |
| XAI_CHAT | 103 | $4.0475 |
| OIP_ARTICLE_REVIEW | 144 | $0.3693 |
| OPS | 11 | $0.0795 |
| GITHUB | 6 | $0.0289 |
| ARCADS | 9 | $0.0258 |
| COMPUTER | 3 | $0.0216 |
| VOICE | 4 | $0.0107 |
| CF_EXPERT | 1 | $0.0042 |
| ARTICLE_ASK | 3 | $0.0011 |
| **All other 310 keys** | **168,852** | **$0.0000** |

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

```sql
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;
```

| Capability | Invocations | Recorded cost |
| --- | --- | --- |
| LEADS_ENRICH_BATCH | 713 | $0.0000 |
| LEADS_VERIFY_MX | 405 | $0.0000 |
| LEADS_SCORE_AI | 233 | $0.0000 |
| LEADS_DISCOVER_PLACES | 186 | $0.0000 |
| LEADS_DRAFT_AI | 178 | $0.0000 |
| LEADS_LIST | 41 | $0.0000 |
| LEADS_DISCOVER_NPI | 36 | $0.0000 |
| LEADS_SEND | 16 | $0.0000 |
| 11 further LEADS_* keys | 38 | $0.0000 |

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.

[[embed:source:s11]]

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

```sql
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

```sql
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.

| # | Missing | Where | Blocks |
| --- | --- | --- | --- |
| 1 | `cost_usd` populated on every billable capability | each `fn` runner's return path | all pricing; 99.1% of the meter |
| 2 | `price_usd` + `meter_unit` | `directory` row | quoting a capability at all |
| 3 | `tenant_id` | every produced domain object (`leads`, `assets`, `pages`, `email_sends`) | selling the object, transferring it, reusing it |
| 4 | `balance_usd` + `spend_cap_usd` | `tenants` row | pre-paid metering, refusal on empty |
| 5 | A ledger of charges | new table `charges(tenant_id, invocation_id, object_ref, price_usd, cost_usd, ts)` | receipts a buyer can audit |
| 6 | Self-serve tenant creation | one route, `POST /api/tenants` | a stranger becoming a customer without owner intervention |
| 7 | Redundancy adjudication over domain objects | new capability | the graph gaining instead of bloating |

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.

[[embed:source:s1]]

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."

[[embed:source:s2]]

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.

[[embed:source:s3]]

**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.

[[embed:source:s4]]

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.

[[embed:source:s6]]

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.

[[embed:source:s5]]

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

[[embed:source:s7]]

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.

[[embed:source:s8]]

**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.

[[embed:source:s9]]

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.

| | Agency / contractor | Subscription stack | Metered protocol |
| --- | --- | --- | --- |
| Commitment | Retainer, statement of work | 12-month minimum, 3-seat minimum | Per unit consumed |
| Price visibility | Quoted per engagement | Not published; negotiated | Published per capability row |
| Who operates it | The agency | The customer | The protocol |
| What you hold at the end | Deliverables, if the contract says so | Access, which stops | The objects, with provenance |
| Exit | Notice period | Data destruction clause | Objects already yours |
| Marginal cost of one more unit | Renegotiation | Credit burn, then overage | The recorded `cost_usd` plus fee |

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.

| Rung | Capability | Object created | Meter unit | Cost basis today |
| --- | --- | --- | --- | --- |
| 1 | LEADS_DISCOVER_NPI / LEADS_DISCOVER | organization | per organization | Free federal registry + OpenStreetMap |
| 2 | LEADS_DISCOVER_PLACES | organization + address + phone | per organization | Billable Google Places call, **unmetered** |
| 3 | LEADS_ENRICH_BATCH | contact + email | per contact resolved | Crawl compute, **unmetered** |
| 4 | LEADS_VERIFY_MX | verification | per domain checked | DNS-over-HTTPS, negligible |
| 5 | LEADS_SCORE_AI | qualification score | per lead scored | Grok call, **unmetered** |
| 6 | LEADS_DRAFT_AI | outreach draft | per draft | Grok call, **unmetered** |
| 7 | LEADS_SEND | send action + receipt | per message sent | Cloudflare email, owner-gated |

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)


## Sources

1. Action types — Palantir Foundry documentation — https://www.palantir.com/docs/foundry/action-types/overview
2. Core concepts — Palantir Foundry Ontology — https://www.palantir.com/docs/foundry/ontology/core-concepts
3. Object Storage v2 architecture — Palantir Foundry — https://www.palantir.com/docs/foundry/object-backend/overview
4. Palantir Platform: Foundry & AIP — Pricing Document, G-Cloud 14 Framework — https://assets.applytosupply.digitalmarketplace.service.gov.uk/g-cloud-14/documents/92736/804537709233305-pricing-document-2024-05-01-1339.pdf
5. Cloudflare AI Gateway — Overview — https://developers.cloudflare.com/ai-gateway/
6. Unified Billing — Cloudflare AI Gateway — https://developers.cloudflare.com/ai-gateway/features/unified-billing/
7. What is the Model Context Protocol (MCP)? — https://modelcontextprotocol.io/docs/getting-started/intro
8. ZoomInfo pricing 2026: buyer-reported contract values and terms — https://www.cleanlist.ai/blog/2026-03-19-zoominfo-pricing-guide
9. Arcads pricing 2026: reported tiers and per-video cost — https://fluxnote.io/guides/arcads-pricing-2026
10. Live capability directory — miscsubjects.com/api/directory — https://miscsubjects.com/api/directory
11. Live query results against the build’s D1 databases, 2026-07-28 — https://miscsubjects.com/api/protocol


---

# Federated objects as a metered utility: the product spec

slug: federated-objects-as-metered-utility · https://miscsubjects.com/a/federated-objects-as-metered-utility · tags: federated objects, metered utility, object graph, palantir ontology, capability contract, usage-based pricing, provenance · updated 2026-07-28T22:09:18.498Z

## The idea, stated for zero context

The build already runs 876 capabilities as invocable objects with stable IDs, receipts, and provenance. A lead-scraping call creates organization, contact, and draft objects. An image call creates image, prompt, model, and cost objects. A deployment creates domain, build, and release objects. Each object carries its origin, its authority, its price, and its lineage.

The product is this: let anyone invoke those capabilities, pay only for the measured work or proven outcome, and receive governed reusable objects that persist, compose, and improve with every use. The customer does not buy a subscription to a tool. The customer states the result they want and pays for the proven outcome.

"I am a plumber in Ontario. Get me more leads for my plumbing business." The protocol invokes the lead capability, charges for usage, returns useful lead objects, records provenance and verification, allows the customer to purchase outreach copy for selected leads, and makes the authorized objects available to the next capability without rebuilding or re-entering the data.

The primitive is not the capability. The primitive is the object created or changed by the capability.

## What already exists

The build already operates 876+ capabilities as invocable objects with stable IDs, receipts, and provenance [1][2]. The lead pipeline (LEADS_DISCOVER → LEADS_ENRICH → LEADS_DRAFT → LEADS_SEND) creates organization, contact, draft, and receipt objects as a byproduct of invocation [1]. Every model call through the build's AI Gateway is logged with cost, tokens, and model name, enabling per-query pricing and outcome attribution [3]. The object ledger records every invocation with input, output, lineage, and evidence links [1]. The capability directory lists every invocable object with its contract, its cost, and its provenance [2].

What is missing is the metered front door. The capabilities exist. The objects exist. The provenance exists. The pricing does not. The customer interface does not. The public access does not.

## The primitive

A lead-scraping invocation creates organization, domain, person, role, contact, source, verification, and qualification objects. An image-generation invocation creates image, prompt, model, cost, campaign, variant, approval, and performance objects. A deployment invocation creates domain, repository, build, account, environment, release, receipt, and status objects.

Objects carry:

- stable identity
- type and properties
- relationships to other objects
- provenance
- permissions
- creation and revision lineage
- capability and model attribution
- cost
- verification state
- outcome evidence

The graph contains articles, claims, sources, people, organizations, domains, models, skills, capabilities, invocations, generated media, campaigns, infrastructure, contacts, deployments, results, and any other useful object type. Articles are one readable projection of the graph, not the graph's governing unit.

## The two forms of inquiry

The same front door supports two forms of inquiry.

Query existing state: search, traverse, compare, summarize, or reason over objects and relationships already present. The plumber asks "what do you know about plumbing businesses in Ontario" and the protocol traverses the graph and returns what exists.

Invoke new work: select or allow the protocol to select a model or capability that performs work and creates or enriches objects. The plumber asks "get me more leads" and the protocol invokes the lead capability, creates new objects, and returns them with provenance and cost.

A model response is not automatically added as repeated prose. It is evaluated against the existing graph and the site's writing, logic, evidence, attribution, identity, and redundancy laws. Only additive information or state changes create or modify objects. Existing knowledge is referenced, strengthened, qualified, contradicted, merged, or left unchanged rather than duplicated.

## The recursive gain

The system gains recursively from use.

Later research reuses prior sources and findings. Later lead searches reuse and refresh existing organization and contact objects. Later creative work inspects prior prompts, models, media, approvals, and measured results. Later deployments reuse proven execution paths. Later model selection uses real cost, quality, latency, and outcome evidence. Failures update the capability contract and prevent repeated waste.

The gain is governed and permissioned. Private customer objects must not become publicly accessible merely because they were created through the protocol. The specification needs explicit public, private, customer-owned, shared, and aggregate-learning boundaries. Reusable operational evidence may improve the system without exposing protected customer data.

## The comparison

Palantir's Foundry ontology defines object types, link types, action types, and interfaces as the governance layer over a data graph [4]. The build's articles, capabilities, and receipts map to the same categories. Palantir sells the ontology to enterprises. The build sells the outcome to anyone.

Cloudflare's AI Playground allows browser-based model invocation with per-request metering [5]. The playground proves the query-interface pattern works at scale. The build extends it: the query does not just invoke a model, it invokes a capability that creates typed objects with provenance, cost, and reusability.

The difference is the object. Palantir's ontology is a governance layer over enterprise data. Cloudflare's playground is a metering layer over model calls. The build's protocol is a governance layer over outcomes. The customer buys the result, not the tool.

## The commercial proposition

Don't buy more subscriptions. Buy the result. Pay per proven outcome.

A customer should not need separate subscriptions for lead scraping, enrichment, copy, image generation, video, model access, infrastructure, hosting, domain management, deployment, and outreach when the useful capabilities can be purchased by the unit through one governed protocol.

The protocol may still use OpenAI, Grok, Cloudflare, image models, scraping systems, hosting providers, and other external infrastructure underneath. Those providers become interchangeable execution resources. The customer buys the governed result and durable object state, not access to a black-box model interface.

## The hard parts

Grounding quality is the first hard part. The model must find the right articles, claims, and objects in the graph. If the retrieval misses the relevant knowledge, the new article is a wild goose chase with a receipt. The build's claim-aware retrieval (matching claims by keyword overlap against the query) is the current approach. It works for direct matches. It fails for semantic similarity — "plumber in Ontario" and "plumbing businesses in Ontario" share no keywords. A vector index over claims would solve this. Cloudflare Vectorize is the obvious candidate.

Contract enforcement is the second hard part. The model must adhere to the writing law, the logic law, the evidence law, the attribution law, the identity law, and the redundancy law. A model that ignores the contract produces an article that violates the site's standards. The current approach is a system prompt with the laws inlined. A better approach is a validation pass after generation: check every claim for a source, check every source for a URL, check every URL for a 200, check the body for banned terms, check the structure for required sections. The validation pass rejects the article if any check fails. The model retries with the rejection reason as feedback.

Cost is the third hard part. Every query through the playground costs tokens. The build's AI Gateway logs every call with cost, tokens, and model name [3]. The playground must price the query before invoking the model, not after. The price is the sum of the retrieval cost, the generation cost, the validation cost, and the storage cost. The customer sees the price before confirming. The customer pays only if the outcome is proven.

Redundancy is the fourth hard part. The graph grows with every query. If two queries produce the same article, the second is redundant. The redundancy law requires a way to flag redundancy, a way to verify the flag, and a way to merge or remove the redundant object. The current approach is a model that compares the new article against the existing graph and flags overlap. A better approach is a hash of the article's claims: if the claim set is identical to an existing article, the article is redundant. The redundancy agent periodically scans the graph for claim-set collisions and proposes merges.

## The minimum proof

The minimum product proof demonstrates one complete paid outcome rather than an abstract universal system.

A user requests qualified leads. The protocol invokes the lead capability, charges for usage, returns useful lead objects, records provenance and verification, allows the user to purchase outreach copy for selected leads, and makes the authorized objects available to the next capability without rebuilding or re-entering the data.

The decisive test is simple: can a customer request a useful result, pay only for the measured work or proven outcome, receive governed reusable objects, and use those objects immediately in the next paid capability?

## The playground

The proof is a public query interface on the homepage. The visitor types a query. The protocol selects a model, invokes the relevant capability, creates or enriches objects, and returns the result with provenance, cost, and a receipt. The visitor sees the object created, the cost incurred, and the lineage recorded.

The playground is not a demo. It is the product. The first query is free. The second query costs. The objects persist. The graph grows. The customer pays for the outcome, not the subscription.

## Sources

1. [The Object Ledger](https://miscsubjects.com/a/the-object-ledger). Every article, capability, invocation, and receipt is one addressable object with a stable ID and a history.
2. [The Unified Loop](https://miscsubjects.com/a/the-unified-loop). The full cycle from input to ledgered object to reusable knowledge. The protocol the playground extends.
3. [Cloudflare AI Gateway](https://miscsubjects.com/a/cloudflare-ai-gateway). The build already routes model calls through a gateway with cost logging, rate limiting, and per-model attribution.
4. [Palantir Foundry Ontology — Models](https://www.palantir.com/docs/foundry/ontology/models). Object types, link types, action types, interfaces. The reference architecture for governed object graphs.
5. [Cloudflare Workers AI — Model Playground](https://developers.cloudflare.com/workers-ai/playground/). Browser-based model invocation with per-request metering. The closest existing analog to the query interface described here.


## Sources

1. Action types overview — Palantir Foundry documentation — https://www.palantir.com/docs/foundry/action-types/overview
2. Action types — writeback and accumulated edits — https://www.palantir.com/docs/foundry/action-types/overview
3. Hacker News comment by lolive on Foundry ontology in practice — https://news.ycombinator.com/item?id=44795475
4. Logging — Cloudflare AI Gateway documentation — https://developers.cloudflare.com/ai-gateway/observability/logging/
5. Hacker News comment by iooi on subscription economics under variable inference cost — https://news.ycombinator.com/item?id=47937643
6. Usage-based billing — Stripe documentation — https://docs.stripe.com/billing/subscriptions/usage-based
7. Hacker News comment by crimsoneer on Foundry export and SDK — https://news.ycombinator.com/item?id=47536644
8. Hacker News comment by nonethewiser on capped usage-based pricing — https://news.ycombinator.com/item?id=42949628
9. Hacker News comment by titanomachy on replacing subscriptions with per-call pricing — https://news.ycombinator.com/item?id=41750792