{"slug":"federated-objects-as-metered-utility","title":"Federated objects as a metered utility: the product spec","body":"## The idea, stated for zero context\n\nThe build already runs 876 capabilities as invocable objects with stable IDs, receipts, and provenance. A lead-scraping call creates organization, contact, and draft objects. An image call creates image, prompt, model, and cost objects. A deployment creates domain, build, and release objects. Each object carries its origin, its authority, its price, and its lineage.\n\nThe product is this: let anyone invoke those capabilities, pay only for the measured work or proven outcome, and receive governed reusable objects that persist, compose, and improve with every use. The customer does not buy a subscription to a tool. The customer states the result they want and pays for the proven outcome.\n\n\"I am a plumber in Ontario. Get me more leads for my plumbing business.\" The protocol invokes the lead capability, charges for usage, returns useful lead objects, records provenance and verification, allows the customer to purchase outreach copy for selected leads, and makes the authorized objects available to the next capability without rebuilding or re-entering the data.\n\nThe primitive is not the capability. The primitive is the object created or changed by the capability.\n\n## What already exists\n\nThe build already operates 876+ capabilities as invocable objects with stable IDs, receipts, and provenance [1][2]. The lead pipeline (LEADS_DISCOVER → LEADS_ENRICH → LEADS_DRAFT → LEADS_SEND) creates organization, contact, draft, and receipt objects as a byproduct of invocation [1]. Every model call through the build's AI Gateway is logged with cost, tokens, and model name, enabling per-query pricing and outcome attribution [3]. The object ledger records every invocation with input, output, lineage, and evidence links [1]. The capability directory lists every invocable object with its contract, its cost, and its provenance [2].\n\nWhat is missing is the metered front door. The capabilities exist. The objects exist. The provenance exists. The pricing does not. The customer interface does not. The public access does not.\n\n## The primitive\n\nA lead-scraping invocation creates organization, domain, person, role, contact, source, verification, and qualification objects. An image-generation invocation creates image, prompt, model, cost, campaign, variant, approval, and performance objects. A deployment invocation creates domain, repository, build, account, environment, release, receipt, and status objects.\n\nObjects carry:\n\n- stable identity\n- type and properties\n- relationships to other objects\n- provenance\n- permissions\n- creation and revision lineage\n- capability and model attribution\n- cost\n- verification state\n- outcome evidence\n\nThe graph contains articles, claims, sources, people, organizations, domains, models, skills, capabilities, invocations, generated media, campaigns, infrastructure, contacts, deployments, results, and any other useful object type. Articles are one readable projection of the graph, not the graph's governing unit.\n\n## The two forms of inquiry\n\nThe same front door supports two forms of inquiry.\n\nQuery existing state: search, traverse, compare, summarize, or reason over objects and relationships already present. The plumber asks \"what do you know about plumbing businesses in Ontario\" and the protocol traverses the graph and returns what exists.\n\nInvoke new work: select or allow the protocol to select a model or capability that performs work and creates or enriches objects. The plumber asks \"get me more leads\" and the protocol invokes the lead capability, creates new objects, and returns them with provenance and cost.\n\nA model response is not automatically added as repeated prose. It is evaluated against the existing graph and the site's writing, logic, evidence, attribution, identity, and redundancy laws. Only additive information or state changes create or modify objects. Existing knowledge is referenced, strengthened, qualified, contradicted, merged, or left unchanged rather than duplicated.\n\n## The recursive gain\n\nThe system gains recursively from use.\n\nLater research reuses prior sources and findings. Later lead searches reuse and refresh existing organization and contact objects. Later creative work inspects prior prompts, models, media, approvals, and measured results. Later deployments reuse proven execution paths. Later model selection uses real cost, quality, latency, and outcome evidence. Failures update the capability contract and prevent repeated waste.\n\nThe gain is governed and permissioned. Private customer objects must not become publicly accessible merely because they were created through the protocol. The specification needs explicit public, private, customer-owned, shared, and aggregate-learning boundaries. Reusable operational evidence may improve the system without exposing protected customer data.\n\n## The comparison\n\nPalantir's Foundry ontology defines object types, link types, action types, and interfaces as the governance layer over a data graph [4]. The build's articles, capabilities, and receipts map to the same categories. Palantir sells the ontology to enterprises. The build sells the outcome to anyone.\n\nCloudflare's AI Playground allows browser-based model invocation with per-request metering [5]. The playground proves the query-interface pattern works at scale. The build extends it: the query does not just invoke a model, it invokes a capability that creates typed objects with provenance, cost, and reusability.\n\nThe difference is the object. Palantir's ontology is a governance layer over enterprise data. Cloudflare's playground is a metering layer over model calls. The build's protocol is a governance layer over outcomes. The customer buys the result, not the tool.\n\n## The commercial proposition\n\nDon't buy more subscriptions. Buy the result. Pay per proven outcome.\n\nA customer should not need separate subscriptions for lead scraping, enrichment, copy, image generation, video, model access, infrastructure, hosting, domain management, deployment, and outreach when the useful capabilities can be purchased by the unit through one governed protocol.\n\nThe protocol may still use OpenAI, Grok, Cloudflare, image models, scraping systems, hosting providers, and other external infrastructure underneath. Those providers become interchangeable execution resources. The customer buys the governed result and durable object state, not access to a black-box model interface.\n\n## The hard parts\n\nGrounding quality is the first hard part. The model must find the right articles, claims, and objects in the graph. If the retrieval misses the relevant knowledge, the new article is a wild goose chase with a receipt. The build's claim-aware retrieval (matching claims by keyword overlap against the query) is the current approach. It works for direct matches. It fails for semantic similarity — \"plumber in Ontario\" and \"plumbing businesses in Ontario\" share no keywords. A vector index over claims would solve this. Cloudflare Vectorize is the obvious candidate.\n\nContract enforcement is the second hard part. The model must adhere to the writing law, the logic law, the evidence law, the attribution law, the identity law, and the redundancy law. A model that ignores the contract produces an article that violates the site's standards. The current approach is a system prompt with the laws inlined. A better approach is a validation pass after generation: check every claim for a source, check every source for a URL, check every URL for a 200, check the body for banned terms, check the structure for required sections. The validation pass rejects the article if any check fails. The model retries with the rejection reason as feedback.\n\nCost is the third hard part. Every query through the playground costs tokens. The build's AI Gateway logs every call with cost, tokens, and model name [3]. The playground must price the query before invoking the model, not after. The price is the sum of the retrieval cost, the generation cost, the validation cost, and the storage cost. The customer sees the price before confirming. The customer pays only if the outcome is proven.\n\nRedundancy is the fourth hard part. The graph grows with every query. If two queries produce the same article, the second is redundant. The redundancy law requires a way to flag redundancy, a way to verify the flag, and a way to merge or remove the redundant object. The current approach is a model that compares the new article against the existing graph and flags overlap. A better approach is a hash of the article's claims: if the claim set is identical to an existing article, the article is redundant. The redundancy agent periodically scans the graph for claim-set collisions and proposes merges.\n\n## The minimum proof\n\nThe minimum product proof demonstrates one complete paid outcome rather than an abstract universal system.\n\nA user requests qualified leads. The protocol invokes the lead capability, charges for usage, returns useful lead objects, records provenance and verification, allows the user to purchase outreach copy for selected leads, and makes the authorized objects available to the next capability without rebuilding or re-entering the data.\n\nThe decisive test is simple: can a customer request a useful result, pay only for the measured work or proven outcome, receive governed reusable objects, and use those objects immediately in the next paid capability?\n\n## The playground\n\nThe proof is a public query interface on the homepage. The visitor types a query. The protocol selects a model, invokes the relevant capability, creates or enriches objects, and returns the result with provenance, cost, and a receipt. The visitor sees the object created, the cost incurred, and the lineage recorded.\n\nThe playground is not a demo. It is the product. The first query is free. The second query costs. The objects persist. The graph grows. The customer pays for the outcome, not the subscription.\n\n## Sources\n\n1. [The Object Ledger](https://miscsubjects.com/a/the-object-ledger). Every article, capability, invocation, and receipt is one addressable object with a stable ID and a history.\n2. [The Unified Loop](https://miscsubjects.com/a/the-unified-loop). The full cycle from input to ledgered object to reusable knowledge. The protocol the playground extends.\n3. [Cloudflare AI Gateway](https://miscsubjects.com/a/cloudflare-ai-gateway). The build already routes model calls through a gateway with cost logging, rate limiting, and per-model attribution.\n4. [Palantir Foundry Ontology — Models](https://www.palantir.com/docs/foundry/ontology/models). Object types, link types, action types, interfaces. The reference architecture for governed object graphs.\n5. [Cloudflare Workers AI — Model Playground](https://developers.cloudflare.com/workers-ai/playground/). Browser-based model invocation with per-request metering. The closest existing analog to the query interface described here.\n","register":"standard","tags":["federated objects","metered utility","object graph","palantir ontology","capability contract","usage-based pricing","provenance"],"style":"canonical","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","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","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","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","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","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","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","why_material":"Distinguishes this from a greenfield proposal; the remaining work is pricing an existing system, not building one."}],"sources":[{"id":"s1","type":"publisher_documentation","url":"https://www.palantir.com/docs/foundry/action-types/overview","title":"Action types overview — Palantir Foundry documentation","quote":"An action type is the definition of a set of changes or edits to objects, property values, and links that a user can take at once.","publisher":"Palantir Technologies"},{"id":"s2","type":"publisher_documentation","url":"https://www.palantir.com/docs/foundry/action-types/overview","title":"Action types — writeback and accumulated edits","quote":"The data asset grows in richness and value as user decisions and insights are captured in the form of edits to the Ontology.","publisher":"Palantir Technologies"},{"id":"s3","type":"practitioner_commentary","url":"https://news.ycombinator.com/item?id=44795475","title":"Hacker News comment by lolive on Foundry ontology in practice","quote":"Your data in Foundry are available both as tabular content and as a graph at the same time.","author":"lolive","publisher":"Hacker News","date":"2025-08-05"},{"id":"s4","type":"publisher_documentation","url":"https://developers.cloudflare.com/ai-gateway/observability/logging/","title":"Logging — Cloudflare AI Gateway documentation","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.","publisher":"Cloudflare"},{"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","quote":"On an economic basis, a monthly subscription only makes sense with relatively static costs.","author":"iooi","publisher":"Hacker News","date":"2026-04-28"},{"id":"s6","type":"publisher_documentation","url":"https://docs.stripe.com/billing/subscriptions/usage-based","title":"Usage-based billing — Stripe documentation","quote":"Record customer usage data in Stripe to bill your customers the correct amounts.","publisher":"Stripe"},{"id":"s7","type":"practitioner_commentary","url":"https://news.ycombinator.com/item?id=47536644","title":"Hacker News comment by crimsoneer on Foundry export and SDK","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.","author":"crimsoneer","publisher":"Hacker News","date":"2026-03-26"},{"id":"s8","type":"practitioner_commentary","url":"https://news.ycombinator.com/item?id=42949628","title":"Hacker News comment by nonethewiser on capped usage-based pricing","quote":"Would not it be even better to implement usage based pricing with a maximum that is equal to the current subscription?","author":"nonethewiser","publisher":"Hacker News","date":"2025-02-05"},{"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","quote":"I started doing usage-based pricing through openrouter instead of paying monthly subscriptions, and my modest LLM use costs me about $3/month.","author":"titanomachy","publisher":"Hacker News","date":"2024-10-05"}],"prov":{"model":"unattributed","action":"write"}}