---
slug: query-the-graph-llm-queries-as-new-articles
title: "Federated objects as a metered utility: turning every query into governed graph state"
kind: article
status: published
hash: 6ba740b1ced5fac0b237c46e54c6e2eccbb81b1e6cfed742cfcfabe1b41f0b9f
created: 2026-07-28T11:08:04.709Z
updated: 2026-10-08T11:32:52.030Z
summary: "A customer states a result they want — qualified leads, outreach copy, campaign images, a deployed website — and pays for the proven outcome, not for a subscription to a tool they then have to learn, connect, operate, and maintain. The"
tags: []
above: []
below: []
adjacent: []
nested: []
---
# Federated objects as a metered utility: turning every query into governed graph state

*A customer states a result they want — qualified leads, outreach copy, campaign images, a deployed website — and pays for the proven outcome, not for a subscription to a tool they then have to learn, connect, operate, and maintain. The*

## The proposal, stated as a product

A customer states a result they want — qualified leads, outreach copy, campaign images, a deployed website — and pays for the proven outcome, not for a subscription to a tool they then have to learn, connect, operate, and maintain. The work is done by capabilities already running on this build: lead scraping, email drafting, image generation, domain provisioning, deployment. Each capability creates or modifies objects — organizations, contacts, drafts, images, domains, releases — and those objects persist in a governed graph that the next capability reads from and writes back to. Every query into the system, whether it asks existing state or invokes new work, is evaluated against the graph and the site's writing, evidence, attribution, and redundancy laws before it is allowed to create or change anything. The graph compounds: later work reuses prior sources, prior leads, prior creative, prior deployments, prior failures.

This is not a chat box. A chat box answers once and forgets. A graph answer stays, accrues citations, can be challenged, and compounds. The difference is the object: the thing created or changed by the capability, carrying stable identity, type, relationships, provenance, permissions, cost, and verification state.

## Evidence status

**Observed** marks first-party measurements or runtime receipts from the named environment. **Specified** marks vendor or standards documentation. **Implemented** and **deployed** name code and live-state evidence, respectively. **Externally attested** marks operator reports. **Derived** marks arithmetic calculated from cited inputs.

## What already exists on this build

Three load-bearing components are live today. The proposal does not require inventing them; it requires exposing them through one front door.

### The object ledger

Every article, tool, skill, claim, and API on miscsubjects is the same kind of invocable object: one address, one history, a receipt for every action. The object-ledger spec defines the grammar — a record is a div with a stable id, a type, a body, a provenance trail, and a signed receipt for every mutation. Belief about an object is not a column that gets overwritten; it is a graph of competing assertions, each backed by a signed receipt, so the current answer is always derived and never asserted. [[embed:source:s3]]

### The writing law

The writing-law skill is a file, not a memory. It defines what counts as a claim, what a source is, how a div is structured, how a model signs its work, and what is banned — decorative terms, opaque phrasing, planted content, unsourced assertions. The law is applied by the intake pipeline before an article is published. A model that writes an article through the graph is forced to adhere to the same rules a human writer is. [[embed:source:s4]]

### The Cloudflare AI Gateway

The build routes model calls through Cloudflare's AI Gateway. The gateway logs every call, records cost, tokens, cache state, and model id. Cloudflare ships a model playground — a UI where you pick a model, type a prompt, and get a response. The proposal here is structurally similar but with a critical difference: the response is not a throwaway blob. It is evaluated against the graph and the writing law, and if it contains additive information, it becomes a new article — sourced, claimed, signed, linked. [[embed:source:s5]]

## The core primitive: the object, not the capability

The important product primitive is not the capability alone. It is the object created or changed by the capability. 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 (one address, one slug)
- type and properties
- relationships to other objects (links, citations, claims)
- provenance (who created it, when, through which capability, using which model)
- permissions (public, private, customer-owned, shared, aggregate-learning)
- creation and revision lineage (append-only, signed receipts)
- capability and model attribution
- cost (tokens in, tokens out, cached fraction, dollars)
- verification state (evidence status, challenge state)
- outcome evidence (what the object produced, whether it worked)

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.

## Two forms of inquiry through one front door

The same query bar supports two modes:

**Query existing state.** Search, traverse, compare, summarize, or reason over objects and relationships already present. This is what the homepage does today — title, subject, tag, claim search across published articles.

**Invoke new work.** Select a model available through the Cloudflare AI Gateway, or let the protocol select one, and prompt it to perform work that creates or enriches objects. The model's response is not automatically added as repeated prose. It is evaluated against the existing graph and the site's writing, 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 — never duplicated.

## How this compares to Palantir Foundry's ontology

Palantir Foundry ships an ontology — a semantic layer that maps an organization's data to real-world concepts (object types, link types, action types). The Foundry documentation describes the ontology as a "digital twin" for the entire enterprise, unlocking the ability to simulate changes across the organization. Mapping models to the ontology provides interpretability (end users interact with simple concepts like forecast, estimate, classification), economies of scale (a forecast produced for one use case can be used by subsequent use cases), and connectivity at scale (the ontology becomes a single source of truth for data and logic). [[embed:source:s1]]

The structural parallels and the divergences:

| Dimension | Palantir Foundry Ontology | miscsubjects object ledger |
| --- | --- | --- |
| Core unit | Object type (backed by dataset) | Object (article, claim, source, capability, invocation) |
| Identity | Object id within an ontology | One address (slug or KV key) per object |
| Relationships | Link types (typed edges between object types) | Links, citations, claims (typed edges between objects) |
| Actions | Action types (functions that modify objects, with parameters, submission criteria, side effects) | Capabilities (directory rows, invocable via API, with authority, auth, provenance) |
| Functions | Function-backed actions (TypeScript/Python, deployed on Foundry) | Worker functions (JavaScript, deployed on Cloudflare) |
| Model integration | Models mapped to ontology properties; results are properties of object types | Model outputs evaluated against writing law; if additive, become new objects (articles, claims) |
| Governance | Permissions, branching, proposals, review | Write tokens, terminal key, intake pipeline, writing law enforcement |
| Provenance | Action log, audit trail | Signed receipts for every mutation, append-only ledger |
| Scope | Enterprise-internal (one organization's data) | Federated (public articles, private customer objects, shared aggregate learning) |
| Commercial model | Enterprise license | Metered utility (pay per proven outcome) |

The key divergence is the commercial model and the federation boundary. Foundry's ontology is internal to one organization. The object ledger is designed for federation: capability providers expose governed operations through the protocol, authorized users or models invoke them, and the resulting objects retain their origin, authority, permissions, price, and provenance while remaining usable by other authorized capabilities. [[embed:source:s2]]

## The Palantir feature this maps to: staff as objects

Palantir describes adding staff as objects — a contact card as an object type with properties for name, role, organization, contact channels. In the object ledger, this is a directory row of type `contact` with a stable key, properties, provenance, and relationships to the organization object and any articles that reference the person. The build already has a directory (the capability directory at D1) that stores tools, agents, and flows as keyed rows. Extending it to contact cards is a contract change, not a new system.

## The recursive research use case

The use case Cyrus describes: instead of asking a model "what advanced Cloudflare features could I add to this build" and getting a blurb, the query invokes the model to research across existing Cloudflare documentation, write articles comparing the most advanced features, make an ontological outline, and write follow-up articles. Each article is sourced, claimed, signed. Each article becomes a source for the next query. The model is grounded in the existing graph — it reads the articles already on the site about Cloudflare, Hugging Face, OpenAI — and its output is evaluated for additivity before it is allowed to enter the graph.

The practical sequence:

1. User queries: "Write an article in the miscsubjects writing law and logic style. Comprehensively dive into Palantir's ontology model and data model."
2. The protocol retrieves existing articles about Palantir, ontology, object systems.
3. The protocol retrieves the Palantir Foundry documentation (external source).
4. The model is prompted with the writing law, the existing graph state, and the external sources.
5. The model writes an article. The intake pipeline enforces the writing law: sourced claims, signed work, no planted content, no decorative complexity.
6. If the article is additive (not redundant with existing articles), it is published.
7. The article becomes a source for the next query about Palantir, ontology, or object systems.

## The redundancy problem and how to solve it

If every query adds an article, the graph fills with duplicates. The proposal requires a redundancy mechanism with three layers:

**Write-time rejection.** Before a new article is published, the intake pipeline compares it against existing articles on the same subject. If the new article adds no information not already present, it is rejected. This is the same mechanism the writing law already implies — an article is a canonical resource, not a write-up; it should be the page a reader with zero prior knowledge needs.

**Model-flagged redundancy.** A model writing a new article can flag an existing article as redundant — same claim, same source, same conclusion — and the flag is recorded as a claim against the existing article, not as a deletion.

**Redundancy agent.** A periodic agent (a protocol role, like the existing writer/reviewer/source-hunt roles) scans the graph for flagged redundancies, verifies them, and either merges the redundant articles or unpublishes the lesser one. The ledger records the action. Nothing is silently deleted; everything is an append-only receipt.

The build already has the apparatus for this: the protocol roles (PROTOCOL_RUN with writer, reviewer, source-hunt, oip-review), the ledger (LEDGER_QUERY for event inspection), the directory (DIR_GET, DIR_LIST for capability inventory), and the D1 database for article state. The redundancy agent is a new role, not a new system.

## The commercial proposition: pay per proven outcome

The customer does not buy subscriptions to lead scraping, enrichment, copy, image generation, video, model access, infrastructure, hosting, domain management, deployment, and outreach. The customer states the result and pays for the proven outcome. 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 capability contract makes clear:

- what outcome or operation it provides
- what objects and inputs it accepts
- what objects or state changes it returns
- what authority it requires
- how usage is priced and metered
- what evidence proves completion
- what provenance is recorded
- what failures or limitations are known

The build already records most of this: the directory row carries `auth`, `target`, `content`, `category`, `enabled`. The ledger records every invocation with `trace_id`, `request_preview`, `response_preview`, `request_size`, `response_size`. The AI Gateway logs record cost, tokens, model, cache state. The missing pieces are the metering layer (balance, budget, price per unit) and the settlement layer (charge the customer, pay the provider).

## Federation and permission boundaries

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 boundaries:

- **Public objects** — articles, claims, sources on the live site. Anyone can read.
- **Private customer objects** — leads, drafts, campaigns, deployments for a specific customer. Only that customer and the protocol can read.
- **Shared objects** — sources, models, capabilities available to all authorized users.
- **Aggregate learning** — anonymized performance data (which prompt produced the best image, which email copy had the highest open rate) that improves the system without exposing protected customer data.

A capability provider can expose a governed operation through the protocol. An authorized user or model invokes it. The resulting objects retain their origin, authority, permissions, price, and provenance while remaining usable by other authorized capabilities.

## The recursive gain, stated concretely

Later research reuses prior sources and findings — the Palantir article written today is a source for the comparative ontology article written tomorrow.
Later lead searches reuse and refresh existing organization and contact objects — a lead scraped today is enriched, drafted, and sent; the next search for the same city finds the existing objects and only scrapes what is new.
Later creative work inspects prior prompts, models, media, approvals, and measured results — the image that performed best in a campaign is the first reference for the next campaign.
Later deployments reuse proven execution paths — the domain, DNS, and worker config that worked once is the template for the next deployment.
Later model selection uses real cost, quality, latency, and outcome evidence — the AI Gateway logs show which model produced the best article at the lowest cost, and the next query uses that model by default.
Failures update the capability contract and prevent repeated waste — a capability that returned bad leads is flagged, and the next invocation uses a different provider.

## The minimum product proof

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

1. A user requests qualified leads for a business segment and city.
2. The protocol invokes the lead capability (LEADS_DISCOVER_PLACES, LEADS_ENRICH_BATCH, LEADS_SCORE_AI — all already running).
3. Usage is metered and charged.
4. The protocol returns useful lead objects (organization, domain, person, contact, score).
5. Provenance and verification are recorded (source, MX check, score reasoning).
6. The user purchases outreach copy for selected leads (LEADS_DRAFT_AI — already running).
7. The authorized objects are available to the next capability without rebuilding or re-entering the data.
8. The user purchases campaign images (ARCADS_GENERATE, GROK_IMAGE — already running).
9. The user purchases a deployed website (domain purchase, worker deployment — partially running).
10. Every step produces a receipt. Every object persists. Every cost is recorded.

The decisive test: 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 answer is yes, because the capabilities already exist and the object grammar already defines what they produce. What is missing is the metering, the front door that routes a query to either existing-state search or new-work invocation, and the redundancy enforcement.

## What is hard, stated honestly

**Grounding quality.** A model prompted to "research Cloudflare's advanced features" will hallucinate if it is not grounded in real documentation. The protocol must retrieve real sources (web fetch, existing articles) and pass them to the model as context. The model's output must cite those sources. The writing law already requires this; the protocol must enforce it at invocation time, not just at publish time.

**Contract enforcement.** The writing law is a file. A model can ignore it. The intake pipeline must reject articles that violate the law — unsourced claims, planted content, decorative complexity. This is a code path, not a prompt instruction. The build already has the intake pipeline; it needs to be extended to evaluate model-generated articles with the same rigor it applies to human-generated ones.

**Cost.** Every query through the AI Gateway costs money. Recursive research — a model reading 50 existing articles and 10 external sources to write one new article — costs more than a single chat completion. The metering layer must track this and the customer must pay for it. The AI Gateway logs already record cost; the metering layer is a read-and-charge loop on top of those logs.

**Redundancy.** The write-time rejection mechanism requires comparing a new article against every existing article on the same subject. This is an embedding similarity search or a structured comparison, not a string match. The build does not currently have embeddings; this is a new component.

**Bad faith.** A customer could invoke capabilities to generate garbage and fill the graph. The permission boundaries (public, private, customer-owned) and the verification state on objects are the defense. Garbage from one customer does not pollute the public graph or another customer's private graph.

## Is this a substantive, high-value product

Yes, with one condition. The condition is that the contract — the writing law, the evidence rules, the redundancy enforcement — is enforced at write time by code, not by a prompt that a model can ignore. If the contract is enforced, the product is substantively different from a chat box or a model playground: every output is governed, sourced, signed, and additive. The graph compounds. The customer pays for outcomes, not subscriptions. The capabilities already exist; the object grammar already exists; the ledger already exists. What is missing is the front door, the metering, and the redundancy enforcement — each a bounded piece of work, not a new system.

If the contract is not enforced — if the model's output is published without evaluation — the product is a chat box with extra steps. The value is in the governance, not the generation.

## What to build, in order

1. **The front door.** The query bar routes to existing-state search (today's behavior) or new-work invocation (a model prompt that produces objects). A toggle or a natural-language classifier determines which mode.
2. **Claim-aware retrieval.** Before the model is prompted, the protocol retrieves existing articles on the subject and passes them as context. The model is told what already exists; its job is to add to it, not to repeat it.
3. **ARTICLE_FROM_QUERY.** A capability that takes a query, retrieves context, prompts a model through the AI Gateway, enforces the writing law on the output, and publishes the article if additive. This is a new directory row, not a new system.
4. **The metering layer.** A balance, a budget, a price per unit. The AI Gateway logs already record cost; the metering layer charges the customer.
5. **The redundancy agent.** A protocol role that scans for flagged redundancies and merges or unpublishes. A new role, not a new system.
6. **Contact cards as directory rows.** Extend the directory to type `contact` with stable keys, properties, provenance, and relationships. A contract change, not a new system.
7. **The minimum proof.** Run the lead-to-deployment sequence end to end, with metering and receipts at every step. One complete paid outcome.

## Facts

```json
{
  "converted_from": "markdown",
  "original_updated": "2026-07-28T23:29:10.016Z",
  "register": null,
  "category": null
}
```

## Sources

1. [Models in the Ontology — Palantir Foundry](https://www.palantir.com/docs/foundry/ontology/models) — “The Ontology becomes a digital twin for the entire enterprise, which unlocks the ability to simulate changes across the organization. Mapping models to the Ontology provides interpretability, economies of scale, and connectivity at scale.” (sha256 b19e12cf6317637a)
2. [Ontology building overview — Palantir Foundry](https://www.palantir.com/docs/foundry/ontology/overview) — “Ontology building covers object types, link types, action types, functions, interfaces, and permissions. The ontology is a semantic layer that maps an organization's data to real-world concepts.” (sha256 552b3a77ffac1575)
3. [The object ledger: one grammar for every record, a signed receipt for every look](https://miscsubjects.com/a/object-ledger-evidence-graph-spec) — “Every company that runs more than one system has the same hidden cost: each system speaks its own language. The spec normalizes every record into one object grammar, gives every object one address, and makes every AI examination a signed, append-only receipt. Belief about the object is not a column that gets overwritten; it is a graph of competing assertions.” (sha256 564d41f7d1030473)
4. [writing-law skill](https://miscsubjects.com/skills/writing-law) — “Decorative terms, ambiguous phrasing, and opaque language are not style failures. They are hostile acts against the reader. An article is a canonical resource, not a write-up. Every claim is sourced. Every model signs its work.” (sha256 a366dcf314d75ce1)
5. [How to create a Cloudflare AI Gateway, with authentication on](https://miscsubjects.com/a/cloudflare-ai-gateway-setup) — “An AI Gateway is a URL you send AI requests to instead of sending them to the provider directly; Cloudflare forwards the request, returns the provider's answer unchanged, and keeps a row recording the model, the token counts, an estimated cost, the duration and the status code.” (sha256 4111f64fcf3b48b6)