Federated objects as a metered utility: the product spec

The idea, stated for zero context

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

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

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

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

What already exists

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

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

The primitive

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

Objects carry:

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

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

The two forms of inquiry

The same front door supports two forms of inquiry.

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

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

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

The recursive gain

The system gains recursively from use.

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

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

The comparison

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

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

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

The commercial proposition

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

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

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

The hard parts

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

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

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

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

The minimum proof

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

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

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

The playground

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

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

Sources

1. The Object Ledger. Every article, capability, invocation, and receipt is one addressable object with a stable ID and a history.
2. The Unified Loop. The full cycle from input to ledgered object to reusable knowledge. The protocol the playground extends.
3. Cloudflare AI Gateway. The build already routes model calls through a gateway with cost logging, rate limiting, and per-model attribution.
4. Palantir Foundry Ontology — Models. Object types, link types, action types, interfaces. The reference architecture for governed object graphs.
5. Cloudflare Workers AI — Model Playground. Browser-based model invocation with per-request metering. The closest existing analog to the query interface described here.