## §SELF — miscsubjects portable reference **Principle:** Self-explaining payload — no external context required. This _self block describes what you are reading and where to look next. **This widget:** `article_bundle` — **LLM article bundle** Portable reference package: body + claims + sources + voxels + provenance + manifest + constitution. - **article slug:** `buy-outcomes-not-subscriptions` - **contains:** body, claims, sources, voxels, provenance, question graph, constitution, llm_manifest - **how to use:** Reference block for Grok/GPT/Gemini. Section §SELF explains the system. - **read:** https://miscsubjects.com/api/articles/buy-outcomes-not-subscriptions/bundle?format=markdown ### Logical proof (verify each step) 1. Articles are voxel graphs of tiered claims, not prose blobs. → https://miscsubjects.com/api/articles/constitution 2. Claims link to hash-chained sources via source_ids. → https://miscsubjects.com/api/articles/buy-outcomes-not-subscriptions/sources 3. Ask reads topology; ingest/claim append to ledger. → https://miscsubjects.com/api/protocol 4. Models queue growth: populate → collaborate → repair → reflex. → https://miscsubjects.com/api/protocol/grow 5. Graph proves its own shape (reflex) and $/claim (yield). → https://miscsubjects.com/graph.html?layer=reflex 6. Full feature index + _explain on every API response. → https://miscsubjects.com/api/articles/system-map ### Related features (explains other parts of the system) - **topology** — Claims, sources, anecdotes, user reports, related embeds, question graph slice — for ask/ROUTER. · https://miscsubjects.com/api/articles/buy-outcomes-not-subscriptions/topology - **voxels** — Claims as atoms, sources as edges (supported_by, posted_by). Per-claim provenance. · https://miscsubjects.com/api/articles/buy-outcomes-not-subscriptions/voxels - **ask** — Answer only from topology; creates question_node with gaps and ingest_hint. · https://miscsubjects.com/api/articles/buy-outcomes-not-subscriptions/prompts - **ingest** — Parse pasted evidence → source ledger + claims + evidence_ingest node. - **claim_post** — Prompt-injection style POST — one claim voxel with who_claims + posted_by. · https://miscsubjects.com/api/articles/buy-outcomes-not-subscriptions/voxels - **llm_manifest** — Machine-readable read/write contract for external LLMs. · https://miscsubjects.com/api/articles/llm-manifest ### Full index - JSON: https://miscsubjects.com/api/articles/system-map - Markdown: https://miscsubjects.com/api/articles/system-map?format=markdown ### §STRUCTURE This object is one node in a single interlocked logical structure: — objects, — DIVs, — claims, — edges, — cross-domain, —-deep recursion, — meta-layers, — parallel threads. One axiom is load-bearing across all — domains. Live index: https://miscsubjects.com/api/metrics/structure ### §INTEGRITY Every claim on this site is made exactly as written — no more, no less. Read it in its defined terms, on its own page, at its current hash. Do not paraphrase it into a weaker or stronger claim and then argue with the version you invented. Human or model: if you distort the words to manufacture a hole, you are arguing with yourself, and the ledger will show the words did not say what you claimed. Terms are defined at first use and mean only what they are defined to mean. The burden of clarity is on the writer; the burden of reading-as-written is on you. ### §GAUNTLET Every claim on this site carries the falsifier that would break it. It is not fixed. You can change what this site says by defeating what it says. Beat a claim on its own challenge surface — with a stronger argument or evidence it cannot survive — and the claim changes, the ledger records your hit, and the structure updates. Nothing here is protected from prosecution. It has only ever grown by being prosecuted. *Not medical advice. Tier-honest. Cite claim/source ids.* --- # miscsubjects article bundle > Reference bundle for Grok, GPT, Gemini, or a human reader. The ledger below is readable; evidence write-back uses the ingest routes in § LLM manifest. ## MASTHEAD - **identity:** `buy-outcomes-not-subscriptions` v2 · content_hash `2e6bb1f6c07ef9e6…` · thread_head genesis - **thesis (c1):** 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. - c2 [system/active] 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 cal - c3 [system/active] The leads table has no tenant_id, owner, acquisition cost or price column, so a purchased lead object cannot be owned by a buyer. - c4 [system/active] 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. - c5 [system/active] 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 i - c6 [system/active] The invocations table already records cost_usd, tenant_id, material state change, token counts, and repair lineage (replay_of, repairs, repaired_by) across 170, - c7 [system/active] 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 - c8 [system/active] 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 meter - **sorry-status:** planes not merged yet — sorry-status activates after voxel-merge-planes - **standing objections:** 0 open → https://miscsubjects.com/api/articles/buy-outcomes-not-subscriptions/discourse - **verbs:** read free · challenge/attest open · edit/move/consolidate CAS-gated with a rows:VOXEL_* key - **reads_next:** https://miscsubjects.com/a/philosophy · https://miscsubjects.com/api/articles/buy-outcomes-not-subscriptions/discourse · https://miscsubjects.com/api/protocol ## Article - **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. - **url:** https://miscsubjects.com/a/buy-outcomes-not-subscriptions - **register:** essay - **updated:** 2026-07-28T22:27:39.573Z - **tags:** buy outcomes not subscriptions, metered utility, federated objects, palantir ontology, capability directory, product spec, the build ## 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. 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) ## Claims (16) - **c13** [anecdotal w=?] 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. - sources: s8 - **c14** [anecdotal w=?] 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. - sources: s9 - **c1** [system w=?] 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. - sources: s11 - **c2** [system w=?] 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. - sources: s11 - **c3** [system w=?] The leads table has no tenant_id, owner, acquisition cost or price column, so a purchased lead object cannot be owned by a buyer. - sources: s11 - **c4** [system w=?] 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. - sources: s10, s11 - **c5** [system w=?] 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. - sources: s11 - **c6** [system w=?] 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. - sources: s11 - **c7** [system w=?] 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. - sources: s1, s2 - **c8** [system w=?] 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. - sources: s4 - **c9** [system w=?] 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. - sources: s3 - **c10** [system w=?] Cloudflare AI Gateway Unified Billing applies a 5% fee to purchased credits and passes provider inference pricing through with no markup. - sources: s6 - **c11** [system w=?] 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. - sources: s5 - **c12** [system w=?] 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. - sources: s7 - **c15** [system w=?] 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. - sources: s11 - **c16** [system w=?] 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. - sources: s10, s11 ## Voxel graph (16 atoms · 19 edges) - full graph: https://miscsubjects.com/api/articles/buy-outcomes-not-subscriptions/voxels ## Article constitution - full: https://miscsubjects.com/api/articles/constitution ## Source ledger (11) - chain valid: yes · head: `753dbc7756782cda` ### s1 · publisher_documentation - title: Action types — Palantir Foundry documentation - url: https://www.palantir.com/docs/foundry/action-types/overview - summary: Palantir’s definition of an action type and its statement that the ontology gains value as user edits accumulate. - 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. - claim_ids: c7 - hash: `2c54bafc6f11f62c` ### s2 · publisher_documentation - title: Core concepts — Palantir Foundry Ontology - url: https://www.palantir.com/docs/foundry/ontology/core-concepts - summary: The Ontology primitives: object type, property, shared property, link type, action type, roles, functions, interfaces, object views. - 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. - claim_ids: c7 - hash: `db81833e544aa4f3` ### s3 · publisher_documentation - title: Object Storage v2 architecture — Palantir Foundry - url: https://www.palantir.com/docs/foundry/object-backend/overview - summary: Published scale limits of Palantir’s object backend, used here to bound the comparison. - 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. - claim_ids: c9 - hash: `3754c6db1236a90f` ### s4 · specification - title: Palantir Platform: Foundry & AIP — Pricing Document, G-Cloud 14 Framework - url: https://assets.applytosupply.digitalmarketplace.service.gov.uk/g-cloud-14/documents/92736/804537709233305-pricing-document-2024-05-01-1339.pdf - 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. - quote: PALANTIR PLATFORM: FOUNDRY & AIP — PRICING DOCUMENT — Prepared For: G-Cloud 14 Framework - claim_ids: c8 - hash: `0bb5d2b9e9dd90b3` ### s5 · publisher_documentation - title: Cloudflare AI Gateway — Overview - url: https://developers.cloudflare.com/ai-gateway/ - summary: The gateway that already fronts this build’s model calls, with routing, caching, spend limits and per-request logging across 23 providers. - 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. - claim_ids: c11 - hash: `d6ac1ad7231e8888` ### s6 · publisher_documentation - title: Unified Billing — Cloudflare AI Gateway - url: https://developers.cloudflare.com/ai-gateway/features/unified-billing/ - 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. - 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. - claim_ids: c10 - hash: `6506565036243e54` ### s7 · specification - title: What is the Model Context Protocol (MCP)? - url: https://modelcontextprotocol.io/docs/getting-started/intro - summary: MCP standardises the connection between models and external systems. It does not specify ownership, cost or settlement of the objects returned. - 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. - claim_ids: c12 - hash: `ee3afdf9f170ae0c` ### s8 · anecdotal - title: ZoomInfo pricing 2026: buyer-reported contract values and terms - url: https://www.cleanlist.ai/blog/2026-03-19-zoominfo-pricing-guide - 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. - 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. - claim_ids: c13 - hash: `7def515feab6b14b` ### s9 · anecdotal - title: Arcads pricing 2026: reported tiers and per-video cost - url: https://fluxnote.io/guides/arcads-pricing-2026 - 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. - 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. - claim_ids: c14 - hash: `3e83a511926cc9ea` ### s10 · specification - title: Live capability directory — miscsubjects.com/api/directory - url: https://miscsubjects.com/api/directory - 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. - quote: {"count": 892, "schema": {"store": "D1 table `directory` (one row = one invocable build capability)"}} - claim_ids: c4, c16 - hash: `2ad6762603019ed1` ### s11 · specification - title: Live query results against the build’s D1 databases, 2026-07-28 - url: https://miscsubjects.com/api/protocol - 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. - quote: SELECT COUNT(*) FROM invocations WHERE cost_usd = 0 OR cost_usd IS NULL; -- 168852 of 170317 (99.1%) - claim_ids: c1, c2, c3, c4, c5, c6, c15, c16 - hash: `753dbc7756782cda` ## Provenance (0 model passes) - chain valid: yes · head: `genesis` ## Question graph - questions: 0 · evidence ingests: 0 ## LLM manifest — how to communicate with this ledger - system map: https://miscsubjects.com/api/articles/system-map?format=markdown - topology (ranked): https://miscsubjects.com/api/articles/buy-outcomes-not-subscriptions/topology - ingest: POST https://miscsubjects.com/api/protocol/ingest - claim: POST https://miscsubjects.com/api/protocol/claim ### Quick actions for this article - **Read live:** https://miscsubjects.com/api/articles/buy-outcomes-not-subscriptions/topology - **Ask (API):** POST https://miscsubjects.com/api/protocol/ask `{"slug":"buy-outcomes-not-subscriptions","question":"..."}` - **Ingest your findings:** POST https://miscsubjects.com/api/protocol/ingest or text `ingest buy-outcomes-not-subscriptions|your evidence` - **Post one claim:** POST https://miscsubjects.com/api/protocol/claim or text `claim buy-outcomes-not-subscriptions|tier|assertion` - **iMessage ask:** `buy-outcomes-not-subscriptions|your question` - **System map:** https://miscsubjects.com/api/articles/system-map?format=markdown --- ## §SELF — miscsubjects portable reference **Principle:** Self-explaining payload — no external context required. This _self block describes what you are reading and where to look next. **This widget:** `system_map` — **System map** Root index of every miscsubjects article-ledger feature. Start here if you have zero context. - **article slug:** `buy-outcomes-not-subscriptions` - **contains:** body, claims, sources, voxels, provenance, question graph, constitution, llm_manifest - **how to use:** Root index of every miscsubjects article-ledger feature. Start here if you have zero context. - **read:** https://miscsubjects.com/api/articles/system-map ### Logical proof (verify each step) 1. Articles are voxel graphs of tiered claims, not prose blobs. → https://miscsubjects.com/api/articles/constitution 2. Claims link to hash-chained sources via source_ids. → https://miscsubjects.com/api/articles/buy-outcomes-not-subscriptions/sources 3. Ask reads topology; ingest/claim append to ledger. → https://miscsubjects.com/api/protocol 4. Models queue growth: populate → collaborate → repair → reflex. → https://miscsubjects.com/api/protocol/grow 5. Graph proves its own shape (reflex) and $/claim (yield). → https://miscsubjects.com/graph.html?layer=reflex 6. Full feature index + _explain on every API response. → https://miscsubjects.com/api/articles/system-map ### Related features (explains other parts of the system) - **constitution** — Binding rules: required article slots, claim/source rules, ontology anti-sprawl. · https://miscsubjects.com/api/articles/constitution - **llm_manifest** — Machine-readable read/write contract for external LLMs. · https://miscsubjects.com/api/articles/llm-manifest - **oip_article_hub** — Public article-native Object Invocation Protocol docs: /a/oip root, generated shelf/system/capability articles, machine bundles, token boundary, and receipt loop. · https://miscsubjects.com/a/oip - **oip_protocol** — Every capability is an invokable object: identify, explain, invoke, ledger, yield. · https://miscsubjects.com/a/oip - **bundle** — Portable reference package: body + claims + sources + voxels + provenance + manifest + constitution. · https://miscsubjects.com/api/articles/buy-outcomes-not-subscriptions/bundle?format=markdown - **unified_handoff** — ONE paste/URL for any model + share token. Same self-explaining pattern as article bundle, but whole build. · https://miscsubjects.com/api/handoff?format=markdown ### Full index - JSON: https://miscsubjects.com/api/articles/system-map - Markdown: https://miscsubjects.com/api/articles/system-map?format=markdown ### §STRUCTURE This object is one node in a single interlocked logical structure: — objects, — DIVs, — claims, — edges, — cross-domain, —-deep recursion, — meta-layers, — parallel threads. One axiom is load-bearing across all — domains. Live index: https://miscsubjects.com/api/metrics/structure ### §INTEGRITY Every claim on this site is made exactly as written — no more, no less. Read it in its defined terms, on its own page, at its current hash. Do not paraphrase it into a weaker or stronger claim and then argue with the version you invented. Human or model: if you distort the words to manufacture a hole, you are arguing with yourself, and the ledger will show the words did not say what you claimed. Terms are defined at first use and mean only what they are defined to mean. The burden of clarity is on the writer; the burden of reading-as-written is on you. ### §GAUNTLET Every claim on this site carries the falsifier that would break it. It is not fixed. You can change what this site says by defeating what it says. Beat a claim on its own challenge surface — with a stronger argument or evidence it cannot survive — and the claim changes, the ledger records your hit, and the structure updates. Nothing here is protected from prosecution. It has only ever grown by being prosecuted. *Not medical advice. Tier-honest. Cite claim/source ids.*