What $10.75 bought: 43 owned business records, five receipts, and the unit of sale no vendor offers

Who this is for: the business paying $1,500 a month for someone else to press the buttons

A plumbing contractor in Ottawa does not want a lead-generation platform. He does not want a seat license, an onboarding call, or a dashboard he will open twice. He wants more customers, and today his only options are these:

He can hire an agency at $1,500–$5,000 a month, whose actual work is operating tools he could theoretically buy himself — a data vendor, an email platform, an ad account. He is not paying for the tools. He is paying a person to press the buttons, because the tools assume a full-time operator he does not employ.

He can buy the tools directly and become that operator. ZoomInfo will sell him access at a buyer-reported median of $31,875 a year across 1,313 verified purchases, three seats minimum, with reported contract terms requiring destruction of exported contacts at the end (claim c13). He needs one seat and 200 contacts. The unit does not exist at his size.

Or he can do nothing, which is what almost everyone does.

Software has spent twenty years selling to the small fraction of businesses that will hire an operator. The rest — the plumber, the dentist, the two-truck landscaper — never buy the tools at all, because a tool you must learn to operate is not a product to someone whose day is already full. The metered protocol removes the operator, not the tool. The plumber states the result he wants in one sentence, the machine does the work, and he pays for the units delivered — $0.25 per business found, $0.50 per contact resolved, $0.02 per domain verified. No seat. No minimum. No month.

$15.47 of that arithmetic is on this page as receipts. The agency's $1,500 is not comparable to a subscription; it is comparable to the work, and the work now has a price per unit.

What ran, in order, with the artifact from each step

Every step below executed against the live production system on 2026-07-28. Nothing is illustrative.

Step 0 — a stranger becomes a customer. One route, added as part of this work:

POST /api/tenants
{"tenant_id":"plumber-demo","name":"Ontario plumbing company (demonstration tenant)",
 "allow_prefixes":"LEADS","balance_usd":30}

→ 200 {"ok":true,"tenant":{"tenant_id":"t_plumber-demo","status":"active",
       "balance_usd":30,"created_at":"2026-07-28T16:29:55-07:00"},
       "funding":{"funded_usd":30,"by":"owner:federated-object-proof"}}

A capability token was then minted bound to that tenant — cap_48d9ef30a3a6e5a8, scope pfx:LEADS. It can invoke lead capabilities, read only its own receipts, and nothing else. Every request below carries that token and no other authority.

Step 1 — the machine reads the request. The build's own planning model was unavailable: its provider (xAI) had hit a spending limit, and the failed attempt is itself a permanent ledger row, inv_0dq1sobaua, recording the provider error. A different vendor's model interpreted the request instead, which is the whole point of treating the model as a replaceable operator rather than the system:

{
 "model": "claude-glm-5.2",
 "max_tokens": 2000,
 "messages": [
  {
   "role": "user",
   "content": "You are the request planner for a protocol whose capabilities are: LEADS_DISCOVER_PLACES ($0.25/organization), LEADS_ENRICH_BATCH ($0.50/contact resolved), LEADS_VERIFY_MX ($0.02/domain checked), LEADS_SCORE_AI ($0.10/lead scored), LEADS_DRAFT_AI ($2.00/draft), LEADS_FOLLOWUPS ($2.00/sequence). A customer writes: 'I run a plumbing company in Ottawa, Ontario. Get me more customers.' State: (1) which capabilities you would invoke and in what order, (2) the one or two questions you genuinely need answered before spending their money, and nothing else. Under 120 words."
  }
 ]
}

{
 "id": "id-1785281799057",
 "type": "message",
 "role": "assistant",
 "model": "@cf/zai-org/glm-5.2",
 "content": [
  {
   "type": "text",
   "text": "(1) I would invoke the capabilities in this order:\nLEADS_DISCOVER_PLACES -> LEADS_ENRICH_BATCH -> LEADS_VERIFY_MX -> LEADS_SCORE_AI -> LEADS_DRAFT_AI -> LEADS_FOLLOWUPS.\n\n(2) Questions to answer before spending your money:\n1. Who is your ideal target customer for this campaign (e.g., commercial property managers, restaurants, residential homebuilders)?\n2. How many leads do you want to target, and what is your maximum budget for this outreach campaign?"
  }
 ],
 "stop_reason": "end_turn",
 "stop_sequence": null,
 "usage": {
  "input_tokens": 158,
  "output_tokens": 795,
  "cache_read_input_tokens": 0,
  "cache_creation_input_tokens": 0
 }
}

Two questions, both necessary: what kind of customer, and what budget. No qualifying call. No discovery session. The answers were "property management companies" and the funded $30.00.

Step 2 — the price comes off the row, not out of a negotiation. Every capability carries its price and its unit in the same table that documents and executes it. This is the live query, and the table below it is that query rendered at page load:

SELECT key, price_usd, meter_unit FROM directory WHERE price_usd > 0;

Step 3 — the purchase. The tenant's token invoked the first rung:

GET /api/dispatch?invoke=LEADS_DISCOVER_PLACES
    &body=property management company|Ottawa|40
    &share=<tenant token>

→ invocation inv_yxg5jmhamu · trace t_e13e9txt
  {"inserted_new": 43, "units": 43, "meter_unit": "organization",
   "api_requests": 3, "cost_usd": 0.12,
   "cost_basis": "Google Places Text Search Enterprise + Atmosphere — $40.00/1,000 requests",
   "tenant_id": "t_plumber-demo",
   "object_ids": ["lead:11786","lead:11787","lead:11788", … 43 total],
   "charge": {"id":"ch_bf8beb55e6d349e1a419","units":43,"price_usd":10.75,"cost_usd":0.12}}

The $0.12 is not an estimate. It is three requests at Google's published SKU price, verified against the live price sheet the same day:

Google

Google Maps Platform pricing — Places API Text Search SKUs

The live SKU price sheet: Text Search Enterprise + Atmosphere bills $40.00 per 1,000 requests ($0.04/request) after the 1,000-request monthly free cap. The discover runner's field mask (websiteUri, phone, rating) places its calls in this SKU; the demonstration's recorded $0.12 is 3 requests at this price.

↗ developers.google.com

2026-07-28 23:05s1 · #a06438149e1c

Step 4 — the second capability reads the first one's objects. No CSV. No export. No re-entry. Enrichment selected the objects the discovery step had just created and returned both what it read and what it changed:

GET /api/dispatch?invoke=LEADS_ENRICH_BATCH&body=8&share=<tenant token>
→ inv_itzk33ejzz
  read_object_ids: lead:11819 … lead:11828     ← created by inv_yxg5jmhamu
  object_ids:      lead:11822 lead:11823 lead:11824 lead:11825 lead:11826 lead:11828
  units: 6 · charge ch_71c7ba3dd9724032b6cc · $3.00

Two of the eight sites yielded no address and were not charged for. The reuse is measurable rather than asserted:

SELECT COUNT(*) FROM charges
WHERE tenant_id='t_plumber-demo' AND object_refs LIKE '%"lead:11822"%';
-- 3

One business, bought once, used by three separate paid operations — found, then enriched, then verified — with no second purchase of the business itself. Each later charge priced only its own new work.

Step 5 — verification, then judgment. MX verification checked 6 email domains against a free public resolver and charged $0.12 for the check (inv_udch4ldam8). Two model passes scored 16 leads for $1.60 total against $0.005022 of real model cost (inv_t0hj0gnaqr, inv_adqd0upv3p).

Step 6 — the gate that refused and charged nothing. Drafting was invoked on a lead before it qualified:

GET /api/dispatch?invoke=LEADS_DRAFT_AI&body=11822&share=<tenant token>
→ inv_55crgyc6kc · charge: none
  {"blocked": true, "error": "icp_threshold_not_met", "score": 5, "minimum": 65,
   "note": "Nothing drafted. Only verified high-fit leads enter copy review."}

No unit delivered, no charge. That is the metered promise under refusal, which is the only condition in which it means anything.

Step 7 — what the customer holds now. 44 objects (43 bought plus one synthetic demonstration record), 6 verified contacts, 5 receipts, and $14.53 of unspent balance. The next offer is computed from that state, not from a sales sequence: you hold 6 verified contacts; drafts are $2.00 each on the row.

Figure 1 — every identifier in these boxes is real and queryable. The unit of sale is the object in the middle, not the capability that made it or the model that operated it.

The margin, done out loud, with the real numbers

The receipts above make the pricing argument checkable rather than rhetorical. This table uses the actual charges from this page's demonstration in the third column, and published vendor figures in the first two:

The pricing rule, stated so it can be argued with: substantially below the customer's real alternative, substantially above fully loaded marginal delivery cost — where fully loaded means the APIs, the data acquisition, the deliverability infrastructure, the failures, the verification, the maintenance, the model judgment, and the amortised cost of having built the capability at all. Compute-plus-markup is banned as a pricing basis, and the row above shows why: $0.125022 of provider cost against $15.47 of price is not a markup on tokens, it is the price of work that would otherwise cost a month of somebody's salary. The customer's comparison is the agency retainer, not the DNS bill.

The strongest objection, published unedited, and what it forced

A hostile reviewer was asked to name the single weakest claim on this page and destroy it. Its answer was correct enough to change the system before publication:

{
 "model": "claude-kimi-k3",
 "max_tokens": 3000,
 "messages": [
  {
   "role": "user",
   "content": "An article claims a new sellable unit: one unit of completed work — a discovered business, a verified contact — priced individually, owned permanently by the buyer, carrying a receipt for its real production cost, reusable by the next paid capability without re-entry. Its evidence: on 2026-07-28 a demonstration tenant funded with $30.00, through its own scoped token against production, bought 43 Ottawa businesses as owned objects for $10.75 (real Google Places cost $0.12), 6 resolved contacts for $3.00, 6 MX verifications for $0.12, 16 AI-scored leads for $1.60 (real model cost $0.005); one unqualified draft was refused by a score gate and charged nothing; balance ended $14.53 across 5 charge rows each joined to invocation id, trace id and object ids; one object (lead:11822) is referenced by 3 separate paid operations having been bought once; an unauthenticated fetch of a tenant-owned object returns HTTP 403 with a recorded refusal receipt. Open gaps it admits: charges.outcome is NULL everywhere (nothing records replies or conversions); the batch queues are global not tenant-scoped, so one scoring charge billed the tenant for 8 rows it did not own; the assets table records no generation cost. Its thesis: ZoomInfo (access + destruction clause), Arcads (expiring credits) and Palantir (per-core environment) structurally cannot sell this unit.\n\nYou are a hostile reviewer. Name the SINGLE weakest claim in this article and destroy it. Be specific and brutal — if the demonstration is theatre, say why in mechanical terms. Do not be balanced, do not hedge, do not compliment. Under 200 words."
  }
 ]
}

{
 "id": "id-1785284298242",
 "type": "message",
 "role": "assistant",
 "model": "moonshotai/kimi-k3",
 "content": [
  {
   "type": "text",
   "text": "**The weakest claim: \"owned permanently by the buyer.\"** The article's own evidence disproves it.\n\nThe 403 test — offered as proof of ownership — demonstrates the opposite. lead:11822 is a row in the vendor's Postgres, reachable only through the vendor's token service. The buyer holds no bytes, no key, no export, no escrow. Possession that requires the custodian's permission layer to be online, honest, and solvent is custody, not property. \"Permanent\" here means \"until the vendor pivots or goes bankrupt\" — ZoomInfo's destruction clause with the clause deleted and enforcement left identical.\n\nThe reuse claim seals the coffin: \"reusable by the next paid capability\" means the asset functions exclusively as input to more vendor billing. An object you cannot extract, cannot use elsewhere, and cannot even read without the seller's gatekeeper is a lock-in token denominated in your own data.\n\nAnd the custody ledger doesn't even work: the global queue billed this tenant for eight rows it didn't own, so the ownership records are demonstrably misattributed in the only demonstration offered. The unit being sold is a promise stored in the promisor's database — structurally indistinguishable from the access models the article claims to bury."
  }
 ],
 "stop_reason": "end_turn",
 "stop_sequence": null,
 "usage": {
  "input_tokens": 445,
  "output_tokens": 2428,
  "cache_read_input_tokens": 0,
  "cache_creation_input_tokens": 0
 }
}

The attack is right on the first half and it should be read twice: possession that requires the custodian's permission layer to be online, honest, and solvent is custody, not property. An object you can only reach through the seller's gate is a lock-in token denominated in your own data, and the 403 refusal this article was proud of proves the gate exists rather than proving ownership.

So the claim was not defended in prose. The system was changed. A tenant can now take everything and leave, with their own token, in one request:

GET /api/objects/export?tenant=t_plumber-demo&share=<tenant token>
→ 200 · 29,128 bytes
  {"export_of":"t_plumber-demo","counts":{"objects":44,"charges":5},
   "tenant":{"balance_usd":14.53,"status":"active"},
   "license":"These objects are the exporting tenant's property. This file is complete,
              unencumbered, and carries the provenance for every row: nothing here requires
              this system to remain online, solvent, or willing.",
   "objects":[…44 complete records including email and phone…],
   "charges":[…5 receipts…]}

Without the tenant's token the same URL returns 403 export_requires_owning_tenant. The export is free, complete, and includes the receipts, because provenance that cannot leave with the object is provenance that only serves the seller.

What the export does not fix, and the reviewer is still correct about: the objects were produced by this system's contracts with Google and its own runners, and nothing outside this system currently accepts a miscsubjects object as a typed input. Portability today means the buyer holds a complete file, not that a competitor's capability can consume it natively. Federation between providers is a claim about a future standard, not a demonstrated fact, and it is registered as an open gap below rather than smuggled into the demonstration.

The second half of the attack is simply true and was already on this page: the global queue billed this tenant for 8 rows it did not own. The reviewer found it because it was disclosed, which is the argument for disclosing it.

The object, at three levels of magnification

The word for what was sold is object: one unit of completed work with a stable identity, an owner, a recorded production cost, a price, a verification state and a receipt. Here is one, live, at every zoom the system holds it at.

Zoom 1 — the row. What a list vendor sells you, frozen at export. These are real rows from the customer's 43, read from the production table at page load:

Zoom 2 — the card. The same object opened: identity, contact state, verification, qualification, and then the block no list vendor has ever shown a customer — which capability created it, from what source, on what date, under which owner, and every charge that ever referenced it.

The public demonstration card is a synthetic record, labelled as such on its face, because real customers' contact details belong inside the boundary they paid for. Its machine actions and verification states are real:

Two real objects from the purchase. Same renderer, same page load, real Ottawa businesses. Their provenance is public; their contact fields are not, because those belong to the tenant that paid for them:

The boundary, demonstrated rather than promised. A person rendered as an object is exactly the dual-use mechanism the object grammar names — the same card that serves a buyer serves a stalker if the boundary is missing (dual-use claims c25, c26, c29, c34). So the boundary refuses in public, and the refusal is itself a recorded event rather than a blank page:

GET https://miscsubjects.com/api/objects/lead/11822          (no credential)
HTTP 403
{"refused": true, "reason": "cross_tenant_read", "object": "lead:11822",
 "owner_tenant": "t_plumber-demo", "ts": "2026-07-28T16:33:22-07:00",
 "note": "This object belongs to t_plumber-demo. It renders only inside its owning tenant's
          boundary — the same rule the invocation read path enforces. This refusal is
          recorded on the invocation ledger."}

Zoom 3 — the action surface. The object's future: every capability that can be bought against it, with its price, computed from the directory at page load rather than curated by hand. That surface is the table in Step 2 above; on a customer's own card it renders as buttons.

Read the three zooms against the vendors: ZoomInfo sells zoom 1 and contractually destroys it at exit. The unit here is zoom 2 with zoom 3 attached, and it walks out the door in a 29KB file when the customer wants it to.

Figure 2 — solid boxes ran, with invocation and charge ids. Dashed boxes are gaps this demonstration surfaced, each with its named fix. A gap drawn on the same figure as the receipts is the difference between an audit and an advertisement.

What was broken this morning, what the receipts retired, what is still open

This page's predecessor was an audit, published hours earlier, which proved the paid loop could not run (buy-outcomes-not-subscriptions). The honest structure is therefore before and after, not confession:

Four defects were retired between the audit and this page. Three remain open with their fixes named in columns. That is the whole state, and every row of it is re-runnable.

Why no incumbent offers this unit

The definition, now that the thing has been seen: a federated object is one unit of completed work, priced individually, owned permanently by the buyer, carrying provenance and a recorded production cost, and immediately usable by the next paid capability without re-entry. A capability is one row in a live directory — simultaneously the documentation of an operation, its executable contract, its authority boundary, and the thing the ledger names when it fires; there are 892 of them (SELECT type, COUNT(*) FROM directory GROUP BY type → fn 480, http 304, agent 57, flow 51). A metered utility prices by the unit actually delivered, with the price published where a stranger can read it before buying.

Try to buy that unit anywhere. You cannot, and a model instructed to find a counterexample could not either:

{
 "model": "claude-kimi-k3",
 "max_tokens": 2000,
 "messages": [
  {
   "role": "user",
   "content": "Definition: one qualified lead for your business, priced individually, owned by you permanently, carrying a receipt for what it cost to produce, and immediately usable by the next paid service without re-entering it. Name any commercial vendor, in any industry, whose published unit of sale matches this definition. If none, state the closest miss and why it misses. Under 150 words, no preamble."
  }
 ]
}

{
 "id": "id-1785281848203",
 "type": "message",
 "role": "assistant",
 "model": "moonshotai/kimi-k3",
 "content": [
  {
   "type": "text",
   "text": "None. No vendor's published unit of sale satisfies all four clauses.\n\nClosest miss: exclusive insurance/home-services lead sellers and ping-post exchanges (e.g., EverQuote, AWL, PX). Their unit is literally one lead, individually priced, sold exclusively to a single buyer, and API-delivered directly into the buyer's CRM — approximating ownership and no-re-entry usability.\n\nWhy it misses:\n- **No production receipt.** Price is auction- or market-set; the actual cost to generate the lead is never disclosed per unit.\n- **Ownership is contractual exclusivity, not permanent title.** The same consumer can be resold later as a \"fresh\" lead.\n- **\"Qualified\" is filter-asserted, not warranted.** Form fields define qualification; there's no guarantee attached to the unit.\n- **Portability is conditional.** Delivery works only into pre-integrated systems, not any arbitrary next paid service.\n\nThe production-cost receipt is the universal failure point — no commercial lead seller exposes per-unit cost."
  }
 ],
 "stop_reason": "end_turn",
 "stop_sequence": null,
 "usage": {
  "input_tokens": 164,
  "output_tokens": 1541,
  "cache_read_input_tokens": 0,
  "cache_creation_input_tokens": 0
 }
}

The market sells access (ZoomInfo, with a destruction clause), credits (Arcads, $110–$550 monthly tiers with credits expiring at cycle end — c14), environments (Palantir Foundry, licensed per server core per annum with no line item for a single object — c8), engagements (the agency retainer), and tokens (model vendors). Each of them structurally cannot offer the unit, because the unit destroys the thing they charge for: the deletion clause is the data vendor's moat, the expiring credit is the creative vendor's revenue, the environment is the platform vendor's contract.

And the connection standard that everyone is building on says nothing about it, by its own definition:

Model Context Protocol

What is the Model Context Protocol (MCP)?

MCP's own definition of its scope: connection between AI applications and external systems. Ownership, cost and settlement of what comes back through the connection are outside it — the layer this article's unit of sale occupies.

↗ modelcontextprotocol.io

2026-07-29 00:20s4 · #9246f15bc6dd

MCP defines how a model reaches an external system. It is silent on who owns the object that comes back, what it cost, whether it can be sold twice, and whether the buyer can take it with them. The billing shape is not exotic either — the infrastructure vendor beneath this entire build already meters exactly this way in public:

Cloudflare

Unified Billing — Cloudflare AI Gateway

The infrastructure vendor under this build already operates the metered-utility billing shape in public: provider cost passed through unmarked, a published percentage on credits entering the system. The template this article's charges table follows.

↗ developers.cloudflare.com

2026-07-29 00:20s5 · #9ce018d9f536

The graph underneath, and the one property that compounds

Two things can happen through the front door. A read traverses objects already in the graph and changes nothing. An invocation performs work, and its output does not evaporate as chat — it lands as attributed objects: which capability, which model, which inputs, what cost, under whose authority (assertion claims c15–c16).

The consequence is the only compounding claim on this page: a conventional AI product's marginal query produces a response that disappears, so the same research is re-run and re-purchased tomorrow. Here, the plumber's 43 businesses are now supply for every later capability he buys, and the reuse is the -- 3 from Step 4, not a metaphor. A competitor's cost of goods is flat per query; this system's declines with use, because the graph is a supply-side asset every paid query enriches.

That claim was handed to a model with instructions to attack it, and its objection is printed here rather than survived quietly:

{
 "model": "claude-glm-5.2",
 "max_tokens": 2000,
 "messages": [
  {
   "role": "user",
   "content": "Claim under test: 'every competitor's cost of goods is flat per query; this system's cost of goods declines with use, because the graph is a supply-side asset that every paid query enriches.' The system is a governed object graph where every model/capability invocation either reads state or writes attributed objects into it, and later invocations reuse earlier objects. State the strongest argument that this recursion claim is circular or self-serving, given that the graph's operator also writes its rules. Under 150 words, no preamble."
  }
 ]
}

{
 "id": "id-1785281862650",
 "type": "message",
 "role": "assistant",
 "model": "@cf/zai-org/glm-5.2",
 "content": [
  {
   "type": "text",
   "text": "The claim is circular because the operator engineers the very conditions that validate it. By writing the graph’s governance rules, the operator mandates that every invocation must write attributed objects into the system. This forces an artificial \"enrichment\" tax on every query, manufacturing the supply-side asset by fiat rather than through organic economic efficiency. The operator then counts this mandated friction as a future cost saving. The claimed \"declining cost of goods\" is merely a self-fulfilling accounting trick: the system’s rules force users to pay into the graph, and the operator subsequently points to the resulting graph density as proof of declining costs. It conflates an imposed architectural monopoly with a genuine market advantage, rendering the thesis entirely self-serving."
  }
 ],
 "stop_reason": "end_turn",
 "stop_sequence": null,
 "usage": {
  "input_tokens": 118,
  "output_tokens": 871,
  "cache_read_input_tokens": 0,
  "cache_creation_input_tokens": 0
 }
}

The objection has a real edge — the operator does write the rules — and exactly one honest boundary blunts it: the compounding is proven in the reuse direction and unproven in the outcome direction, because charges.outcome is empty. If later work stops reading earlier objects, the claim dies by its own falsifier.

The same discipline applies to what a model says about an object. Asked whether the demonstration business was still operating, the model refused to invent a status the record does not carry, and its answer landed as a signed assertion attached to the object rather than as anonymous fact written into its fields:

{
 "model": "claude-glm-5.2",
 "max_tokens": 1200,
 "messages": [
  {
   "role": "user",
   "content": "You are asked a question about one object in a governed graph. Object record: {\"id\": \"lead:11829\", \"name\": \"Capital Region Plumbing Co. (synthetic demonstration record)\", \"segment\": \"plumbing contractor\", \"city\": \"Ottawa\", \"website\": \"https://capital-region-plumbing.example\", \"email\": \"office@capital-region-plumbing.example\", \"phone\": \"(613) 555-0136\", \"source\": \"synthetic-demo\", \"status\": \"enriched\", \"tenant_id\": \"t_plumber-demo\"} Question: is this business still operating? Answer only from what the record itself shows, in under 80 words, and state your confidence basis plainly."
  }
 ]
}

{
 "id": "id-1785281985983",
 "type": "message",
 "role": "assistant",
 "model": "@cf/zai-org/glm-5.2",
 "content": [
  {
   "type": "text",
   "text": "The record does not indicate whether the business is still operating. It includes contact details and a data processing status of \"enriched,\" but contains no explicit operational status field. \n\nConfidence basis: I am highly confident in this answer because I only relied on the provided record fields, none of which declare an operational state. Furthermore, the name explicitly labels it as a \"synthetic demonstration record\" (fictitious)."
  }
 ],
 "stop_reason": "end_turn",
 "stop_sequence": null,
 "usage": {
  "input_tokens": 163,
  "output_tokens": 593,
  "cache_read_input_tokens": 0,
  "cache_creation_input_tokens": 0
 }
}

Every model card on this page carries its complete raw REST exchange — the exact request JSON including the full prompt, and the exact response JSON including token usage — under a collapsed disclosure. An edited quote proves nothing; the raw payload is the only falsifiable form of a model pass. Open one and check the quote against the response body.

Where this sits, bounded honestly

The mainstream agent stack is arranged model-first: model → prompt → tools → app. This is arranged the other way: governed objects → capability authority → model as replaceable operator → receipts → public and private projections. The demonstration contains its own proof of the replaceable-operator clause: the planner's model lane died mid-loop and a different vendor's model interpreted the request; the scoring runner's primary model was unavailable and its fallback produced the scores, attributed, at recorded cost. No operation's meaning changed when the model behind it changed.

The closest relative is not an agent framework but Palantir's Foundry Ontology: both join typed objects, links, actions, functions and permissions into one governed layer, and Palantir states the same growth property claimed here — the data asset gains value as user edits accumulate (c7). The kinship is real and the scale is not close: Palantir's published object backend supports 2,000 properties per object type and indexes tens of billions of objects for one type; this build holds thousands of articles and roughly eleven thousand leads (c9). No claim here asserts parity.

Four divergences justify calling it a different thing: the public knowledge corpus is part of the operating system (this page is a projection of the same objects the machine operates on, which is why it can carry its own evidence); governance is machine-legible to strangers (every receipt above is publicly fetchable); the ontology models an operator, not an organisation; and the system amends the rules under which it amends itself. That fourth one is the boldest, so it was attacked too, and the attacker won:

{
 "model": "claude-deepseek-deepseek-v4-pro",
 "max_tokens": 2000,
 "messages": [
  {
   "role": "user",
   "content": "The system claims four divergences from Palantir's Foundry Ontology: (1) the public knowledge corpus is part of the operating system, not marketing over it; (2) governance is machine-legible and externally inspectable by strangers; (3) the ontology models an operator (one person's rules, tools, memory), not an organization; (4) the system amends the rules under which it amends itself. Given these four claimed divergences, which one is most likely overstated, and what evidence would settle it? Under 150 words, no preamble."
  }
 ]
}

{
 "id": "id-1785281878141",
 "type": "message",
 "role": "assistant",
 "model": "deepseek/deepseek-v4-pro",
 "content": [
  {
   "type": "text",
   "text": "Claim (4) is most likely overstated.  \nEvidence to settle it: a reproducible demonstration where the system, without human intervention, modifies the mechanism by which it amends its own rules—e.g., altering the protocol, voting logic, or code that governs rule change—and the alteration is successfully applied and persists across subsequent amendments. If it cannot be shown to independently and reliably rewrite its own meta-rules, the claim is exaggerated."
  }
 ],
 "stop_reason": "end_turn",
 "stop_sequence": null,
 "usage": {
  "input_tokens": 121,
  "output_tokens": 794,
  "cache_read_input_tokens": 0,
  "cache_creation_input_tokens": 0
 }
}

The demanded evidence — a reproducible, persisting, unassisted amendment of the amendment mechanism — is not supplied on this page, and the claim carries that verdict on its face.

Two governance mechanisms did fire during this work, both mechanical rather than aspirational. The first publish attempt of this article was refused with HTTP 428 write_gate: a body write requires a token issued only to a caller that fetched the live writing law and answered questions about it correctly. The token that published this page was earned by returning the exact titles of three clauses (challenge wg_8cb1f3f9c352e68534e96aae, law hash b71b5331…). The predecessor article at this subject published as an unfilled scaffold with six empty claims — the failure that gate now refuses.

The verdict, as a bet with its falsifier

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

Not as "one place to buy AI services." That is a marketplace, several exist, and 892 capabilities is breadth — the least defensible asset here, because a funded competitor can wire the same endpoints in weeks.

It is valuable as the unit of sale no incumbent can offer without breaking their own model, sold to the businesses that were never going to hire an operator. The machinery is not a deck: it is the directory, the token boundary, the append-only ledger, an export route, and $15.47 of real charges against a real balance, all of which a stranger can re-run from this page.

Three things must be true for the bet to pay, each checkable rather than arguable. The meter must keep reading true on every billable rung — it reads true on seven as of today. A buyer must value owning the object and not only the outcome — untested. And one complete paid loop must exist before a second vertical is exposed — it now exists, and the second vertical deliberately does not.

The falsifier for the whole thesis: a customer buys leads once, never invokes a second capability against those objects, and durable ownership prices at zero for them — in which case the graph is an internal efficiency and this is lead generation with better bookkeeping. That is testable at roughly five customers, and it should be tested before anything else is built.

A skeptical investor, given only these numbers and asked which claim to diligence first, named the one this page demonstrates in Step 4 and demanded exactly the artifact printed there:

{
 "model": "claude-deepseek-deepseek-v4-flash",
 "max_tokens": 2000,
 "messages": [
  {
   "role": "user",
   "content": "Article summary: a build with 892 invocable capability rows, an append-only invocation ledger (170,418 rows), and a month-old multi-tenant boundary added 4 columns, 1 table (charges), and 1 route (POST /api/tenants), then demonstrated one complete paid loop live: a demonstration tenant funded with $30.00 bought 43 organization objects from Google Places at $0.25/unit (real recorded provider cost $0.12), enrichment resolved 6 contacts at $0.50/unit, MX verification 6 domains at $0.02/unit, AI scoring 16 leads at $0.10/unit (real model cost ~$0.005), and an unqualified draft was refused by a score gate with no charge. Balance moved $30.00 to $14.53 across 5 charge rows, each joined to its invocation id and object ids. Thesis: the sellable unit no incumbent offers is the priced, owned, receipted, reusable object; ZoomInfo sells access with a destruction clause, Arcads sells expiring credits, Palantir sells an environment per server core. You are a skeptical investor given only this article. Name the single claim you would diligence first and the artifact that would satisfy you. Under 150 words, no preamble."
  }
 ]
}

{
 "id": "id-1785281929261",
 "type": "message",
 "role": "assistant",
 "model": "deepseek/deepseek-v4-flash",
 "content": [
  {
   "type": "text",
   "text": "The single claim: the \"reusable object\" retains value across multiple invocations without additional charge. The artifact: a ledger showing the same object ID used in two different paid operations (e.g., enrichment then AI scoring) with only one initial charge and no subsequent deduction."
  }
 ],
 "stop_reason": "end_turn",
 "stop_sequence": null,
 "usage": {
  "input_tokens": 274,
  "output_tokens": 216,
  "cache_read_input_tokens": 0,
  "cache_creation_input_tokens": 0
 }
}