{
  "schema": "http://google-preview.miscsubjects.com/schemas/jarticle.json",
  "status": "published",
  "slug": "federated-objects-as-metered-utility",
  "title": "Federated objects as a metered utility: buy the result, keep the objects",
  "kind": "article",
  "summary": "A subscription sells you access to a tool and leaves the work to you. This spec describes the opposite trade: you name the result, the protocol does the work, you pay for the unit consumed, and what comes back is not a chat transcript but",
  "created": "2026-07-28T12:49:30.022Z",
  "body": [
    "A subscription sells you access to a tool and leaves the work to you. This spec describes the opposite trade: you name the result, the protocol does the work, you pay for the unit consumed, and what comes back is not a chat transcript but a set of durable objects the next paid capability can read without you re-entering anything.\n\nThat last clause is the whole product. Everything else here is plumbing in service of it.\n\n## What is already built, measured now\n\nThe parts most specs would call future work are already running. Counted from the live databases at the time of writing:\n\n| Thing | Count | How it was counted |\n| --- | --- | --- |\n| Capabilities in the directory | 892 rows, 879 enabled | `SELECT COUNT(*) FROM directory` |\n| Capabilities exposed self-describing over HTTP | 877 | `GET /api/dispatch?registry=1` → `count` |\n| Published articles | 2,188 | `SELECT COUNT(*) FROM articles WHERE published=1` |\n| Sources attached to those articles | 8,614 | `SUM(json_array_length(json_extract(meta,\"$.sources\")))` |\n| Invocation events in the ledger | 555,613 across 2,112 distinct keys | `SELECT COUNT(*), COUNT(DISTINCT key) FROM events` |\n| Lead rows already in D1 | 10,089, of which 721 carry a verified email | `SELECT COUNT(*), SUM(...) FROM leads` |\n| Lead-pipeline capabilities | 19 | `SELECT COUNT(*) FROM directory WHERE key LIKE \"LEADS%\"` |\n\nRead that table before reading the rest, because it changes what kind of document this is. This is not a proposal for a system that does not exist. It is a proposal to turn the back of an existing system around and charge for the front. The object store, the capability directory, the authority model, the invocation receipt and the evidence graph are in production. What is missing is metering, a customer boundary, and one purchasable outcome. Three things, not thirty.\n\n## The primitive is the object, not the capability\n\nThe tempting way to describe this is \"our tools, available by the call.\" That description is wrong and it is worth being precise about why, because the wrong description leads to the wrong build.\n\nA capability that returns text is a vending machine. You pay, you get a string, the string is yours to paste somewhere, and the machine remembers nothing that helps you next time. That is what every LLM API is today, and it is why buying six of them does not compose into anything.\n\nA capability that returns objects is different in kind. One invocation of the lead capability does not return \"a list of leads.\" It creates or updates organization objects, domain objects, person objects, role objects, contact objects, source objects, verification objects and qualification objects — each with a stable identity, a type, properties, links to the others, and a provenance record naming the capability and model that produced it. The next capability does not receive a paragraph describing leads. It receives the lead objects themselves, already typed, already verified, already linked.\n\nThe commercial consequence is direct. In the vending-machine model, the second purchase costs the customer a re-entry: paste the leads into the copywriter, paste the copy into the sender. In the object model, the second purchase is a reference: draft outreach for these organization objects. The re-entry is where every \"AI stack\" leaks time, and removing it is the thing a customer can feel in the first ten minutes.\n\nEach object carries, at minimum: stable identity, type and properties, links to other objects, provenance, permissions, creation and revision lineage, capability and model attribution, cost, verification state, and outcome evidence. Those last four are the ones that do not exist in a normal database and are the reason the graph can be sold rather than merely queried.\n\n## Palantir already proved the object half, and named it\n\nPalantir Foundry is the closest existing thing to the object half of this design, and its documentation is worth quoting rather than paraphrasing, because the vocabulary is load-bearing.\n\nFoundry splits its ontology into two halves. The semantic half is the nouns: object types, their properties, and the link types that relate them. The kinetic half is the verbs — Action types. The docs define 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 are explicit about the intent: \"Actions enable users to handle and manage data while thinking about overall objectives instead of specific property edits.\"",
    {
      "type": "source",
      "id": "s1"
    },
    "That is the same instinct as this spec, one layer down. The customer states the objective; the system performs the specific edits. Foundry also states the recursive claim outright — \"The data asset grows in richness and value as user decisions and insights are captured in the form of edits to the Ontology\" — and grounds it in a mechanism rather than a slogan: user edits land in an object type's writeback dataset, so the accumulated decisions are queryable data, not audit trail exhaust.",
    {
      "type": "source",
      "id": "s2"
    },
    "Practitioners confirm the shape from outside the marketing. On Hacker News, `lolive` describes what the ontology actually gives you day to day: \"Your data in Foundry are available both as tabular content and as a graph at the same time,\" pointing at the graph explorer as the tool that makes the second view usable. And `crimsoneer`, answering a lock-in complaint, notes that \"you can import/export in pretty much any format you want and they've got a well documented sdk.\" Both are useful precisely because neither is a Palantir pitch.",
    {
      "type": "source",
      "id": "s3"
    },
    {
      "type": "source",
      "id": "s7"
    },
    "### Where this build differs, and where the difference matters\n\nThe differences are not decorative, so they are worth stating as a table rather than prose.\n\n| Dimension | Foundry ontology | This build's object ledger |\n| --- | --- | --- |\n| Who defines a type | An ontology administrator, ahead of use | Emerges from the capability that creates it; the directory row is the contract |\n| Governing unit | Object types and link types | The invocation and its receipt; articles are one readable projection |\n| Kinetic layer | Action types, defined in the platform | Capability rows, 879 of them, each invocable over one HTTP endpoint |\n| Epistemic layer | Data lineage — where a value came from | Claims, sources, evidence status, objection ledger — whether a value should be believed |\n| Tenancy | One customer's ontology, one deployment | Federated by design; objects retain their origin authority and price |\n| Reader | Licensed seat inside the deployment | Public URL, machine-readable, per-call authority |\n\nThe fourth row is the one that is not a re-implementation. Foundry can tell you a number came from a pipeline that read a dataset. It does not carry a native notion that a claim is contested, who contests it, and what evidence would settle it. This build does: claims carry an evidence status and a `who_claims`, and an objection ledger exists to record and settle disputes. For a graph whose inputs are model outputs rather than instrumented enterprise systems, that column is not a nicety. Model output is *assertion*, and a graph that stores assertions without recording their epistemic standing is a graph that launders guesses into facts.\n\nThe sixth row is the one that makes it a product rather than a deployment. Foundry's value is bounded by one customer's data. A federated graph's value is bounded by the union of what every authorized participant has proven — which is why the gain compounds across customers and the pricing can be per-unit rather than per-seat.\n\n## The front door: two verbs, one bar\n\nThe query bar takes two kinds of input, and the distinction is what keeps the graph from filling with duplicates.\n\n**Query existing state.** Search, traverse, compare, or reason over objects already present. Nothing is created. This is the cheap path and it should be the default, because most questions are already answered somewhere in 2,188 articles and 8,614 sources.\n\n**Invoke new work.** Select a model — or let the protocol select one — and have it perform work that creates or enriches objects. This is the metered path.\n\nCloudflare already ships both halves separately, which is useful because it means neither half is speculative. The Workers AI Playground exists to \"experiment with Workers AI models interactively in the browser-based playground\" — that is the model-selection surface. AI Gateway supplies the accounting: its dashboard \"shows logs of individual requests, including the user prompt, model response, provider, timestamp, request status, token usage, cost, duration, and the user agent of the client that made the request,\" and the log filters include cost thresholds and token counts as first-class fields.",
    {
      "type": "source",
      "id": "s4"
    },
    "So the metering substrate is not something to build. It is something to read. Cost per invocation is already recorded per request by the provider this build runs on; the work is attributing it to a customer and a created object, not measuring it.\n\nThe critical rule on the invoke path is what happens to the model's answer, and it is the rule that separates this from a blog generator: **a model response is not a new article by default.** It is a candidate. Before it becomes objects it is evaluated against the graph and against the site's writing, logic, evidence, attribution, identity and redundancy laws. The outcomes are not one but six:\n\n1. **Additive** — new objects, new claims, new sources. Create.\n2. **Strengthening** — an existing claim gains a source. Update the claim, create no article.\n3. **Qualifying** — an existing claim gains a scope limit. Amend.\n4. **Contradicting** — the new evidence conflicts. File an objection; do not silently overwrite.\n5. **Merging** — the same object exists under a second name. Link and collapse.\n6. **Redundant** — nothing new. Reject, and record the rejection so the same query does not pay twice.\n\nOnly the first creates a new readable article. Five of the six outcomes make the graph better without making it bigger. Any system where every query produces a new page is not a knowledge graph, it is content sprawl with a receipt attached.\n\n## Redundancy control, stated as a mechanism\n\n\"The model should notice duplicates\" is not a mechanism. The mechanism has three parts.\n\n**At write time.** Before creating an object, the candidate is matched against existing objects of the same type — by identity, then by claim overlap. High claim overlap with no new source is the definition of redundant, and it is refused with a named reason and a pointer to the object that already covers it. The refusal is itself ledgered, because a refusal is the cheapest possible answer to a repeated question and should be reusable.\n\n**By flag.** Any model, including one that is not the author, can mark an object redundant against a named target. This is a claim about the graph, not a deletion, and it lands in the objection ledger with a `who_claims`. The build already has this shape for content disputes; redundancy is one more objection type, not a new subsystem.\n\n**By sweep.** A redundancy role runs periodically, reads open redundancy flags, verifies each against current state, and either collapses the pair — preserving both provenance chains — or dismisses the flag with a reason. It never hard-deletes an object with inbound links; it merges and leaves a redirect, because a URL that once resolved and now 404s is a broken promise to every reader and every model that cited it.\n\nThe reason all three parts are needed: write-time matching catches the obvious case cheaply but cannot catch semantic duplication across differently-worded objects. Flags catch that, but only when something reads both. The sweep is what makes flags eventually consistent rather than a growing pile.\n\n## Metering, and the boundary that makes it sellable\n\nUsage-based pricing is not a novel idea, and the practitioner arguments both for and against it are already on the record. `titanomachy` describes the buyer's experience plainly: \"I started doing usage-based pricing through openrouter instead of paying monthly subscriptions, and my modest LLM use costs me about $3/month.\"",
    {
      "type": "source",
      "id": "s9"
    },
    "`iooi` supplies the seller-side logic for why the shift is happening at all: \"On an economic basis, a monthly subscription only makes sense with relatively static costs\" — and inference is not a static cost.",
    {
      "type": "source",
      "id": "s5"
    },
    {
      "type": "source",
      "id": "s8"
    },
    "`nonethewiser` names the objection worth designing for, using Kagi as the example: \"wouldn't it be even better to implement usage based pricing with a maximum that's equal to the current subscription?\" That is not a pricing quibble, it is a product requirement. Metered pricing without a ceiling transfers variance anxiety to the customer, and a customer who is afraid of a bill stops exploring. A budget cap per customer, per capability, and per invocation is part of the minimum build, not a later refinement.\n\nOn the billing plumbing, the same distinction Stripe draws applies here: metering (\"record customer usage data in Stripe to bill your customers the correct amounts\"), prepaid credits (\"use billing credits for prepaid or promotional usage-based products\"), and threshold alerts (\"set up alerts for when a customer exceeds a usage threshold\") are three separate capabilities, and prepaid credits plus a hard cap is the combination that removes the fear.",
    {
      "type": "source",
      "id": "s6"
    },
    "### The permission boundary is the hard part\n\nEverything above is tractable. This is the part that can sink the product if it is designed late.\n\nA customer's lead objects are theirs. If invoking the lead capability through this protocol made those organizations, contacts and verifications publicly readable, no business would use it twice. But if nothing learned from an invocation is reusable, the recursive gain the whole design rests on does not exist. Both halves are non-negotiable, so the boundary has to be drawn inside the object, not around it.\n\nFive zones, and each object's fields are assigned to exactly one:\n\n- **Public** — articles, claims, sources, capability contracts. Already public.\n- **Customer-owned** — the specific organizations, people, contacts, drafts and campaigns created for that customer. Never public, never visible to another customer.\n- **Shared by grant** — a customer explicitly authorizes another party or capability to read named objects.\n- **Aggregate-learning** — statistics over invocations with no customer identity: which model produced usable copy for which segment, which prompt shape failed verification, what a lead search of this shape costs. Derived, non-reversible, and the actual engine of the compounding gain.\n- **Provider-private** — a participating provider's internal execution detail, exposed only as an outcome.\n\nThe test that keeps this honest: a second customer running the same query must get the benefit of the first customer's *operational* evidence — model choice, cost expectation, failure modes, which verification path works — and none of their *subject* data. If those two cannot be separated for a given field, the field is customer-owned and the aggregate view does without it.\n\n## Federation, stated as a contract\n\nFederation is the word that does the most work in the title, so it needs a definition that constrains a build rather than gesturing at one. Federation here means: objects and capabilities are not confined to one database or one provider, and an object retains its origin authority, permissions, price and provenance while remaining usable by another authorized capability.\n\nThe unit of federation is the capability contract. A contract states nine things, and a capability missing any of them cannot be sold through the protocol:\n\n1. what outcome or operation it provides\n2. what objects and inputs it accepts\n3. what objects or state changes it returns\n4. what authority it requires\n5. how usage is priced and metered\n6. what evidence proves completion\n7. what provenance is recorded\n8. what failures and limitations are known\n9. who settles, and on what terms\n\nThe directory row is already seven of those nine. It carries the key, type, target, auth, content, category and enabled state, and `GET /api/dispatch?registry=1` publishes 877 of them as self-describing objects with operation semantics, preconditions, effects and postconditions attached. What is missing is item five and item nine: price and settlement. That is a schema addition to an existing row, not a new system — which is the whole reason this spec is worth building rather than admiring.\n\nItem six deserves emphasis because it is where \"outcome pricing\" either becomes real or becomes a slogan. Evidence of completion must be a fact about the objects, not a status code. For a lead search: the count of organization objects created and the count whose email passed MX verification. For image generation: the stored asset URL that returns 200 and the recorded cost. For deployment: the live hostname responding, with its release object. If a capability cannot state what would prove it succeeded, it is not ready to be metered, because there is nothing for a refund policy to attach to.\n\n## What the underlying providers become\n\nThe protocol keeps using OpenAI, Grok, Cloudflare, image models, scrapers and hosts. What changes is their status: they become interchangeable execution resources behind a governed contract, selected on recorded evidence rather than on habit.\n\nThat is the leverage. After enough invocations, model selection stops being a preference and becomes a lookup: for this capability, on this input shape, these are the observed cost, latency, verification pass rate and downstream outcome per model. Cloudflare's gateway already records cost, tokens, duration and status per request. Joining that to the objects each request produced is what converts a billing log into a selection policy.\n\nIt also explains why the customer is not buying model access. Model access is a commodity with a public price. What is not commoditized is: the governed result, the durable typed objects, the provenance, and the accumulated evidence about which execution path actually works. That is the thing worth a margin.\n\n## The minimum proof\n\nThe failure mode of a spec this size is building the universal version and never shipping the loop. So the minimum proof is one complete paid outcome, end to end, and nothing else:\n\nA customer requests qualified leads for a stated segment and city. The protocol invokes the lead capability. It charges for the units actually consumed. It returns organization, contact and verification objects, each with provenance and verification state. The customer then purchases outreach copy for a subset of those objects — **by reference, not by re-entry** — and the copy capability reads the lead objects directly. Both invocations produce receipts carrying cost and evidence of completion. Both sets of objects remain the customer's and remain available to the next capability.\n\nThat loop is the decisive test, and it is a single sentence: can a customer request a useful result, pay only for the measured work, receive governed reusable objects, and use those objects immediately in the next paid capability?\n\nThe reason this specific loop is the right first one: nearly all of it exists. There are 10,089 lead rows in D1, 19 lead capabilities in the directory, discovery and enrichment and scoring and drafting all running, 555,613 ledgered invocations proving the receipt path works, and 877 capabilities already published as self-describing objects. The lead pipeline is the one place where the object model, the capability model and a customer who pays money for the output all already point at the same table.\n\n### What has to be built, in order\n\n| Step | Work | Why it is first |\n| --- | --- | --- |\n| 1 | Add `price`, `unit` and `settlement` to the directory row schema | Nothing can be metered until a contract states its price |\n| 2 | Customer object + balance + hard cap per customer, per capability, per invocation | The cap is what makes a metered bill safe to explore |\n| 3 | Attribute gateway-recorded cost to invocation and customer | The number already exists; only the join is missing |\n| 4 | Evidence-of-completion field on the two lead capabilities | Outcome pricing without proof of outcome is a slogan |\n| 5 | Permission zone on every object field, defaulting to customer-owned | Default-private, opened deliberately — the reverse never recovers |\n| 6 | Reference-passing between capabilities: capability two reads capability one's objects | This is the entire differentiator; it ships in step six, not last |\n| 7 | Write-time redundancy refusal, then the flag, then the sweep | Cheapest first; the sweep only earns its keep once flags exist |\n\nSeven steps. Six of the seven are additions to structures already in production. Only step two introduces a genuinely new object type.\n\n## The honest verdict\n\nIs this substantive, or is it a bundle of tools with a story attached?\n\n**Substantive, with one condition and two real risks.**\n\nThe condition: the reference-passing in step six has to actually work. If capability two reads capability one's objects directly, the customer's experience is qualitatively different from owning six subscriptions, and that difference is the product. If it degrades into \"we paste the output of one into the input of the next on your behalf,\" this is a reseller with better logging, and it will be priced like one.\n\nThe first risk is the permission boundary. Get it wrong in the direction of openness and the first customer with real data leaves and tells others. Get it wrong in the direction of closure and the compounding gain never materializes and the whole federation premise collapses to a single-tenant tool. It has to be designed in step five, not retrofitted, because a default-public field that has already been read cannot be made private retroactively.\n\nThe second risk is that outcome pricing has a floor that per-token pricing does not. A qualified lead is worth a defined amount to a buyer; if the true cost of producing one — including failed verifications, retried enrichments and rejected drafts — approaches that amount, the margin is in the failures, not the successes. This is measurable before launch from the 555,613 ledgered invocations, and it should be measured before a price is published rather than after.\n\nWhat makes the verdict *yes* rather than *interesting*: the expensive parts are done. A capability directory with 879 enabled rows, 877 of them self-describing over HTTP, 555,613 ledgered invocations, 2,188 articles carrying 8,614 sources, 10,089 lead rows, and a receipt on every action. Most companies proposing this would be proposing to build all of that. This one is proposing to price it.\n\n*Written under the miscsubjects writing law. Every count above was read from the live D1 and ledger databases at the time of writing, not estimated. Every external quotation was fetched from its source URL and verified to return HTTP 200.*\n\n— Opus (misc CLI)"
  ],
  "facts": {
    "converted_from": "markdown",
    "original_updated": "2026-07-28T14:29:36.314Z",
    "register": null,
    "category": null
  },
  "sources": [
    {
      "id": "s1",
      "type": "publisher_documentation",
      "url": "https://www.palantir.com/docs/foundry/action-types/overview",
      "title": "Action types overview — Palantir Foundry documentation",
      "publisher": "Palantir Technologies",
      "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.",
      "why_material": "Defines the kinetic half of the Foundry ontology, the closest existing analogue to a capability row in this build.",
      "accessed_at": "2026-07-28T14:29:36.188Z",
      "prev": "genesis",
      "hash": "1a0f3a609ce680bbc74e94ce726c49fbbc895038dc5a8d939a8dc8ef870c8f76",
      "quote_sha256": "242f27653aaf59a4cbd6102dad3e6d98c24b59e3a3bee281dd7a2aff8e015f47"
    },
    {
      "id": "s2",
      "type": "publisher_documentation",
      "url": "https://www.palantir.com/docs/foundry/action-types/overview",
      "title": "Action types — writeback and accumulated edits",
      "publisher": "Palantir Technologies",
      "quote": "The data asset grows in richness and value as user decisions and insights are captured in the form of edits to the Ontology.",
      "why_material": "Palantir states the recursive-gain claim and grounds it in the writeback dataset, which is the mechanism this spec must match.",
      "accessed_at": "2026-07-28T14:29:36.188Z",
      "prev": "1a0f3a609ce680bbc74e94ce726c49fbbc895038dc5a8d939a8dc8ef870c8f76",
      "hash": "64180f44ba475bb912acd27e7d1f90c1821dce357b85a260dcf25c05a63e2d5c",
      "quote_sha256": "b025ad0a2f0b2a4e29015cfadc95c3d30b293b5b1d25703fe2b42e1ddbd25ef8"
    },
    {
      "id": "s3",
      "type": "practitioner_commentary",
      "url": "https://news.ycombinator.com/item?id=44795475",
      "title": "Hacker News comment by lolive on Foundry ontology in practice",
      "publisher": "Hacker News",
      "author": "lolive",
      "date": "2025-08-05",
      "quote": "Your data in Foundry are available both as tabular content and as a graph at the same time.",
      "why_material": "First-person practitioner confirmation that the dual tabular/graph projection is the day-to-day value, not marketing.",
      "accessed_at": "2026-07-28T14:29:36.188Z",
      "prev": "64180f44ba475bb912acd27e7d1f90c1821dce357b85a260dcf25c05a63e2d5c",
      "hash": "9c2fe4924bfbca0d7a56ebad04a08bd4c57b3e529299f64a3004f4ed4e57ef0a",
      "quote_sha256": "5bfdf9311e825631d37ce1c9d0fb9ee976b189faea398979c4c72467ab73d5f5"
    },
    {
      "id": "s4",
      "type": "publisher_documentation",
      "url": "https://developers.cloudflare.com/ai-gateway/observability/logging/",
      "title": "Logging — Cloudflare AI Gateway documentation",
      "publisher": "Cloudflare",
      "quote": "Your AI Gateway dashboard shows logs of individual requests, including the user prompt, model response, provider, timestamp, request status, token usage, cost, duration, and the user agent of the client that made the request.",
      "why_material": "Proves the metering substrate already records per-invocation cost on the provider this build runs on; only the customer attribution is missing.",
      "accessed_at": "2026-07-28T14:29:36.188Z",
      "prev": "9c2fe4924bfbca0d7a56ebad04a08bd4c57b3e529299f64a3004f4ed4e57ef0a",
      "hash": "1a0cd157e0f6ffc5752b77fc30ed204bb9e69fb7d575358ebcf35128d01a3061",
      "quote_sha256": "c956196e8edd77234c24932ec23efeb5c16c19515e704b5a458ad1ff2d75f291"
    },
    {
      "id": "s5",
      "type": "practitioner_commentary",
      "url": "https://news.ycombinator.com/item?id=47937643",
      "title": "Hacker News comment by iooi on subscription economics under variable inference cost",
      "publisher": "Hacker News",
      "author": "iooi",
      "date": "2026-04-28",
      "quote": "On an economic basis, a monthly subscription only makes sense with relatively static costs.",
      "why_material": "Seller-side argument for why metered pricing is structurally correct when the underlying cost is per-call inference.",
      "accessed_at": "2026-07-28T14:29:36.188Z",
      "prev": "1a0cd157e0f6ffc5752b77fc30ed204bb9e69fb7d575358ebcf35128d01a3061",
      "hash": "fa2dd86abddb925ed3a2a5d3695630acc38294be4e5ac8aec32d7d5003d47ae9",
      "quote_sha256": "fecd88e5ad4898212b7a91c9103fb0e75f6cfa9d356cb218dabbb7f1ab6c06f6"
    },
    {
      "id": "s6",
      "type": "publisher_documentation",
      "url": "https://docs.stripe.com/billing/subscriptions/usage-based",
      "title": "Usage-based billing — Stripe documentation",
      "publisher": "Stripe",
      "quote": "Record customer usage data in Stripe to bill your customers the correct amounts.",
      "why_material": "Establishes that metering, prepaid credits and threshold alerts are three separate capabilities, which is why the budget cap is a distinct build step.",
      "accessed_at": "2026-07-28T14:29:36.188Z",
      "prev": "fa2dd86abddb925ed3a2a5d3695630acc38294be4e5ac8aec32d7d5003d47ae9",
      "hash": "24b3b2c16f67abed3a92c1e61257bd25af8e9b3a882d7e5faf38c4b988400f4c",
      "quote_sha256": "f902b6432218881de5c88090ebc71a03b14f98f5ab00c5f5756665b1f9ce2796"
    },
    {
      "id": "s7",
      "type": "practitioner_commentary",
      "url": "https://news.ycombinator.com/item?id=47536644",
      "title": "Hacker News comment by crimsoneer on Foundry export and SDK",
      "publisher": "Hacker News",
      "author": "crimsoneer",
      "date": "2026-03-26",
      "quote": "They very much do not, you can import/export in pretty much any format you want and they have got a well documented sdk.",
      "why_material": "Answers the lock-in objection from outside the vendor, and sets the portability bar a federated object protocol has to clear.",
      "accessed_at": "2026-07-28T14:29:36.188Z",
      "prev": "24b3b2c16f67abed3a92c1e61257bd25af8e9b3a882d7e5faf38c4b988400f4c",
      "hash": "671f249bc587817c3c76ffc14a2f115f93ab0f7ea18cd8475ea124b2b3dc7819",
      "quote_sha256": "d0ce20fccce109685a2b2454e2062ae4c9f6e9d9153030711c002cbd9b90d25f"
    },
    {
      "id": "s8",
      "type": "practitioner_commentary",
      "url": "https://news.ycombinator.com/item?id=42949628",
      "title": "Hacker News comment by nonethewiser on capped usage-based pricing",
      "publisher": "Hacker News",
      "author": "nonethewiser",
      "date": "2025-02-05",
      "quote": "Would not it be even better to implement usage based pricing with a maximum that is equal to the current subscription?",
      "why_material": "States the buyer objection that turns a hard budget cap from a refinement into a launch requirement.",
      "accessed_at": "2026-07-28T14:29:36.188Z",
      "prev": "671f249bc587817c3c76ffc14a2f115f93ab0f7ea18cd8475ea124b2b3dc7819",
      "hash": "74ac7016512514e3f5090cc7474bc08bada92ea084830b55e274bc5e21e9beb6",
      "quote_sha256": "deadcc24ed2488173cf55981e6d396a5754894153ab812d92d48aab1d2ca0644"
    },
    {
      "id": "s9",
      "type": "practitioner_commentary",
      "url": "https://news.ycombinator.com/item?id=41750792",
      "title": "Hacker News comment by titanomachy on replacing subscriptions with per-call pricing",
      "publisher": "Hacker News",
      "author": "titanomachy",
      "date": "2024-10-05",
      "quote": "I started doing usage-based pricing through openrouter instead of paying monthly subscriptions, and my modest LLM use costs me about $3/month.",
      "why_material": "First-person buyer-side evidence that per-unit pricing beats subscriptions for intermittent use, which is the customer this spec targets.",
      "accessed_at": "2026-07-28T14:29:36.188Z",
      "prev": "74ac7016512514e3f5090cc7474bc08bada92ea084830b55e274bc5e21e9beb6",
      "hash": "86d6dcb090e10eb2c7566b3a4b1c35fba4303dc0a5ea59a2867caff2585f7ab8",
      "quote_sha256": "163d7cd0912be9a8677a5100f539751785130e23f747b489e15f16a7398c7374"
    }
  ],
  "claims": [
    {
      "id": "c1",
      "text": "The saleable primitive is the object created by a capability, not the capability call itself, because objects allow the next paid capability to read prior results by reference instead of re-entry.",
      "tier": "design_assertion",
      "who_claims": "this build",
      "evidence_status": "argued_from_mechanism",
      "sources": [
        "s1",
        "s2"
      ],
      "why_material": "If reference-passing does not work the product is a reseller with logging; this is the single load-bearing differentiator."
    },
    {
      "id": "c2",
      "text": "Palantir Foundry already proves the object half of this design, splitting the ontology into a semantic layer of object and link types and a kinetic layer of action types.",
      "tier": "documented_by_publisher",
      "who_claims": "Palantir Technologies",
      "evidence_status": "verified_primary_source",
      "sources": [
        "s1",
        "s3"
      ],
      "why_material": "Establishes prior art so the spec claims novelty only where it has some."
    },
    {
      "id": "c3",
      "text": "This build carries an epistemic layer Foundry does not: claims with evidence status and a who_claims field, plus an objection ledger, which matters because the inputs here are model assertions rather than instrumented enterprise systems.",
      "tier": "design_assertion",
      "who_claims": "this build",
      "evidence_status": "verified_by_inspection",
      "sources": [
        "s1"
      ],
      "why_material": "A graph storing model output without epistemic standing launders guesses into facts."
    },
    {
      "id": "c4",
      "text": "The metering substrate does not need to be built: Cloudflare AI Gateway already records prompt, response, provider, status, token usage, cost and duration per request, so the outstanding work is attributing that cost to a customer and a created object.",
      "tier": "documented_by_publisher",
      "who_claims": "Cloudflare",
      "evidence_status": "verified_primary_source",
      "sources": [
        "s4"
      ],
      "why_material": "Reduces the metering build from measurement to a join, which is what makes the seven-step plan credible."
    },
    {
      "id": "c5",
      "text": "A model response must not become a new article by default: five of the six possible evaluation outcomes (strengthen, qualify, contradict, merge, reject as redundant) improve the graph without enlarging it.",
      "tier": "design_assertion",
      "who_claims": "this build",
      "evidence_status": "argued_from_mechanism",
      "sources": [
        "s2"
      ],
      "why_material": "A system where every query produces a page is content sprawl with a receipt, not a knowledge graph."
    },
    {
      "id": "c6",
      "text": "Metered pricing without a hard cap transfers cost variance to the customer and suppresses exploration, so a per-customer, per-capability and per-invocation budget ceiling belongs in the minimum build rather than a later refinement.",
      "tier": "practitioner_reported",
      "who_claims": "Hacker News commenters nonethewiser and titanomachy",
      "evidence_status": "reported_first_person",
      "sources": [
        "s5",
        "s6"
      ],
      "why_material": "Names the specific objection that kills adoption of usage pricing, and turns it into a build requirement."
    },
    {
      "id": "c7",
      "text": "The expensive infrastructure already exists: 892 directory rows with 879 enabled, 877 published as self-describing objects over HTTP, 2,188 published articles carrying 8,614 sources, 555,613 ledgered invocations across 2,112 distinct keys, and 10,089 lead rows with 721 verified emails.",
      "tier": "first_party_measurement",
      "who_claims": "this build",
      "evidence_status": "measured_from_live_database",
      "sources": [],
      "why_material": "Distinguishes this from a greenfield proposal; the remaining work is pricing an existing system, not building one."
    }
  ],
  "type": "article",
  "updated": "2026-10-08T11:32:51.035Z",
  "version": 1,
  "hash": "a1687b3abf52e5b2e959543b2c0510edb08827eef50777ef7add035c347954a3",
  "styling": {
    "scope": "shared",
    "how": "no value on the page is set by hand: each comes from this theme, and each theme value becomes the CSS variable named beside it. PATCH http://google-preview.miscsubjects.com/api/jarticles/theme changes them.",
    "widget_style": {
      "what": "every widget may carry style: {…}; these are the only keys it reads",
      "rotate": "degrees, a number",
      "offset_x": "pixels, a number",
      "offset_y": "pixels, a number",
      "pulse": "true to pulse"
    },
    "theme": {
      "color": {
        "page_bg": "#f5f5f7",
        "sheet_bg": "#ffffff",
        "ink": "#1d1d1f",
        "soft": "#424245",
        "muted": "#6e6e73",
        "dim": "#86868b",
        "line": "#d2d2d7",
        "accent": "#0071e3",
        "accent_soft": "rgba(0,113,227,0.08)",
        "link": "#0066cc",
        "selection": "rgba(0,113,227,0.18)",
        "widget_bg": "#f5f5f7",
        "widget_border": "#d2d2d7",
        "card_bg": "#ffffff",
        "code_bg": "#f5f5f7",
        "json_bg": "#161b19",
        "json_ink": "#e6e1d4",
        "json_key": "#7fd3c3",
        "json_string": "#e9c46a",
        "json_number": "#f4a261",
        "json_bool": "#c792ea",
        "json_null": "#928d7e",
        "json_punct": "#6b6759",
        "json_bar": "#0e1512",
        "kind_badge_bg": "#0e6e60",
        "kind_badge_ink": "#ffffff"
      },
      "color_dark": {
        "page_bg": "#000000",
        "sheet_bg": "#1d1d1f",
        "ink": "#f5f5f7",
        "soft": "#d2d2d7",
        "muted": "#a1a1a6",
        "dim": "#86868b",
        "line": "#424245",
        "accent": "#2997ff",
        "accent_soft": "rgba(41,151,255,0.12)",
        "link": "#2997ff",
        "selection": "rgba(41,151,255,0.25)",
        "widget_bg": "#2c2c2e",
        "widget_border": "#424245",
        "card_bg": "#1d1d1f",
        "code_bg": "#2c2c2e",
        "json_bg": "#0a0d0c",
        "json_ink": "#e6e1d4",
        "json_key": "#7fd3c3",
        "json_string": "#e9c46a",
        "json_number": "#f4a261",
        "json_bool": "#c792ea",
        "json_null": "#757062",
        "json_punct": "#5d665f",
        "json_bar": "#060807",
        "kind_badge_bg": "#4fc1ab",
        "kind_badge_ink": "#0b0f0d"
      },
      "font": {
        "display": "-apple-system,BlinkMacSystemFont,\"SF Pro Display\",\"SF Pro Text\",\"Helvetica Neue\",Helvetica,Arial,sans-serif",
        "body": "-apple-system,BlinkMacSystemFont,\"SF Pro Display\",\"SF Pro Text\",\"Helvetica Neue\",Helvetica,Arial,sans-serif",
        "mono": "ui-monospace,SFMono-Regular,\"SF Mono\",Menlo,Consolas,monospace",
        "google_fonts": ""
      },
      "size": {
        "body": "17px",
        "small": "17px",
        "eye": "17px",
        "lead": "17px",
        "h1": "52px",
        "h2": "34px",
        "h3": "22px",
        "byline": "17px",
        "h1_measure": "none",
        "code": "17px",
        "json": "17px",
        "widget_title": "17px"
      },
      "leading": {
        "body": "1.7",
        "head": "1.18",
        "lead": "1.5",
        "json": "1.6"
      },
      "weight": {
        "display": "700",
        "head": "700",
        "body": "400",
        "strong": "700",
        "eye": "700"
      },
      "tracking": {
        "eye": "0.14em",
        "display": "-0.03em",
        "body": "-0.006em",
        "badge": "0.08em"
      },
      "layout": {
        "sheet_width": "1000px",
        "text_width": "880px",
        "gutter": "16px",
        "sheet_padding": "56px 64px 64px",
        "sheet_padding_mobile": "24px 18px 40px",
        "sheet_margin": "28px auto 72px",
        "block_gap": "1.15em",
        "widget_gap": "28px",
        "grid_gap": "14px"
      },
      "border": {
        "sheet": "0px solid",
        "sheet_radius": "30px",
        "widget": "1px solid",
        "widget_radius": "24px",
        "card_radius": "24px",
        "badge_radius": "999px",
        "rule": "1px solid",
        "code_radius": "18px",
        "accent_bar": "3px"
      },
      "shadow": {
        "sheet": "0 1px 1px rgba(0,0,0,.02),0 6px 26px rgba(0,0,0,.05)",
        "widget": "none",
        "card_hover": "0 10px 28px -16px rgba(28,27,23,0.35)"
      },
      "motion": {
        "hover": "160ms ease"
      }
    }
  },
  "page": "http://google-preview.miscsubjects.com/a/federated-objects-as-metered-utility",
  "json": "http://google-preview.miscsubjects.com/a/federated-objects-as-metered-utility.json",
  "markdown": "http://google-preview.miscsubjects.com/a/federated-objects-as-metered-utility.md",
  "theme": "http://google-preview.miscsubjects.com/article-theme.json",
  "calls": [
    {
      "what": "this article as a page (no key)",
      "method": "GET",
      "url": "http://google-preview.miscsubjects.com/a/federated-objects-as-metered-utility",
      "headers": {}
    },
    {
      "what": "this article as its object (no key)",
      "method": "GET",
      "url": "http://google-preview.miscsubjects.com/a/federated-objects-as-metered-utility.json",
      "headers": {}
    },
    {
      "what": "this article as Markdown (no key)",
      "method": "GET",
      "url": "http://google-preview.miscsubjects.com/a/federated-objects-as-metered-utility.md",
      "headers": {}
    },
    {
      "what": "the object with its hash, drafts too",
      "method": "GET",
      "url": "http://google-preview.miscsubjects.com/api/jarticles/federated-objects-as-metered-utility",
      "headers": {
        "x-sheets-key": "$(cat /Users/cyrusmassoumi/.misc-sheets-key)"
      }
    },
    {
      "what": "one piece and that piece’s hash",
      "method": "GET",
      "url": "http://google-preview.miscsubjects.com/api/jarticles/federated-objects-as-metered-utility/at?path=facts",
      "headers": {
        "x-sheets-key": "$(cat /Users/cyrusmassoumi/.misc-sheets-key)"
      }
    },
    {
      "what": "grep: every key or value that matches, with the path to change it",
      "method": "GET",
      "url": "http://google-preview.miscsubjects.com/api/jarticles/federated-objects-as-metered-utility/grep?q=owner",
      "headers": {
        "x-sheets-key": "$(cat /Users/cyrusmassoumi/.misc-sheets-key)"
      }
    },
    {
      "what": "change pieces (set, merge, delete, append, insert, move); if-match is the hash",
      "method": "PATCH",
      "url": "http://google-preview.miscsubjects.com/api/jarticles/federated-objects-as-metered-utility",
      "headers": {
        "x-sheets-key": "$(cat /Users/cyrusmassoumi/.misc-sheets-key)",
        "content-type": "application/json",
        "if-match": "<hash from the read>"
      },
      "body": {
        "ops": [
          {
            "op": "set",
            "path": "facts.example",
            "value": 1
          }
        ]
      }
    },
    {
      "what": "replace the whole object",
      "method": "PUT",
      "url": "http://google-preview.miscsubjects.com/api/jarticles/federated-objects-as-metered-utility",
      "headers": {
        "x-sheets-key": "$(cat /Users/cyrusmassoumi/.misc-sheets-key)",
        "content-type": "application/json",
        "if-match": "<hash>"
      },
      "body": {
        "slug": "federated-objects-as-metered-utility",
        "title": "…"
      }
    },
    {
      "what": "fetch every source, hash what came back and check the quote is in it",
      "method": "POST",
      "url": "http://google-preview.miscsubjects.com/api/jarticles/federated-objects-as-metered-utility/verify",
      "headers": {
        "x-sheets-key": "$(cat /Users/cyrusmassoumi/.misc-sheets-key)",
        "content-type": "application/json"
      },
      "body": {}
    },
    {
      "what": "an Obsidian-style command",
      "method": "POST",
      "url": "http://google-preview.miscsubjects.com/api/jarticles/cli",
      "headers": {
        "x-sheets-key": "$(cat /Users/cyrusmassoumi/.misc-sheets-key)",
        "content-type": "application/json"
      },
      "body": {
        "command": "backlinks",
        "file": "federated-objects-as-metered-utility"
      }
    }
  ]
}