The object ledger: one grammar for every record, a signed receipt for every look
Every company that runs more than one system has the same hidden cost: each system speaks its own language. Video talks in frames. Access control talks in events. Payments talk in transactions. Messaging talks in headers and threads. HR talks in rows with soft deletes. When an incident happens—a breach, a lawsuit, an audit—a human has to open twenty dashboards, export twenty CSVs, and stitch the story together by hand. The question "what did we know, and when" takes weeks and is always wrong.
The second problem is newer. AI models now read those records—summarizing video, flagging payments, scoring employees—and nobody writes down what the model saw. There is no receipt. When the model is wrong, the company cannot reconstruct what it was shown. When the model is right, the company cannot prove it. The model is a witness with no memory and no oath.
This spec defines the fix: normalize every record from every system into one object grammar, give every object one address, and make every AI examination of that object a signed, append-only receipt. Belief about the 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.
It has three layers, in this order, because each depends on the one before it:
- Object grammar — what exists, and what can be acted on. Section 1.
- Ledger — what every actor actually did to an object, permanently. Section 2.
- Evidence graph — what is currently believed about an object, computed from the ledger, never overwriting it. Section 3.
Proof of coverage — whether a declared set of objects received a required examination — is one mechanism inside layer 2, covered in Section 6.
A companion object grammar and invocation protocol already runs in production on this site at /a/oip — the tool-invocation half of this system. This document specifies the record-ingestion and evidence-graph half.
1. Ingestion and normalization
1.1 What goes in
A foreign system is anything with records this system does not control: a camera archive, a payment processor, a badge-access system, an email or chat archive, a source-code repository, a medical-records system, a public-records database, or a folder of PDFs. None of these systems change to participate. Records are pulled through whatever interface already exists — an API, a database replica, a file export — and converted at that boundary.
1.2 The canonical object
Every ingested record becomes exactly one canonical object with five mandatory fields:
| Field | Purpose |
|---|---|
source_id | The record's identifier in the foreign system, verbatim. |
canonical_id | The identifier this object uses everywhere else in this system. |
type | One of the object grammar's families (Section 1.4), or unresolved. |
source_hash | sha256 of the original bytes, so the object can be checked against the source at any later time. |
translation_version | Which version of the mapping rule produced this object. |
{
"source_id": "stripe:ch_3P9k2LKx",
"canonical_id": "transaction:7a1e4f0b",
"type": "transaction",
"source_hash": "sha256:9c41…b07e",
"translation_version": "stripe-charge@v2",
"fields": { "amount": 4899, "currency": "usd", "party_a": "acct_1N…", "party_b": "cus_9K…", "created": "2026-07-21T14:02:11Z" },
"unmapped_fields": { "stripe.balance_transaction": "txn_3P9k2L…", "stripe.payment_method_details.card.checks": { "cvc_check": "pass" } }
}Nothing in fields is guessed. A Stripe field with no place in the canonical transaction schema goes to unmapped_fields rather than being dropped — a mapping that silently discards data is undetectable by anyone who only reads the canonical object afterward.
1.3 What happens when the mapping is uncertain
Three specific failure cases are each given their own explicit object, rather than being resolved silently:
- A record that fits no known type. Stored as
type: "unresolved"with the raw payload attached. It is never forced into the nearest-fitting type, because a forced fit corrupts every later query that trusts thetypefield. - Two records that might be the same real-world entity. A badge scan and a payment made nine seconds later, both naming "J. Rivera" — stored as a separate
identity_claimobject:{ "object_a": "person:44f1", "object_b": "person:91ac", "method": "name+timestamp-proximity", "confidence": 0.71 }. The two source objects are never merged. Merging destroys the ability to later discover the match was wrong; the claim sits beside both objects and can itself be contradicted. - A schema field with no canonical target. Recorded, not discarded (1.2).
Entity resolution — deciding whether two records describe one real entity — is a studied statistical problem with a nonzero error rate at any scale, measured directly in practice. A coverage claim built on top of unexamined identity conflicts silently inherits that error rate. Recording every conflict as its own object is the only way an auditor can find out how many conflicts existed and how they were resolved.
1.4 The object grammar
The defensible claim is narrower than "every system reduces to one ontology," and that stronger claim is false. The claim actually made: many foreign systems contain recurring structural families, and those families can be normalized through reusable templates while everything that does not fit stays visible as an exception.
| Family | What it holds | Concrete instance |
|---|---|---|
| entity | a person, organization, device, or place | person:44f1, device:badge-0091 |
| event | something that happened at a time | event:door-open-14:02:03Z |
| observation | a sensed or extracted fact about an entity | observation:face-detected-in-frame-88213 |
| communication | a message with sender, recipient, body, thread | message:0a44c2 |
| transaction | two parties, an amount, a status | transaction:7a1e4f0b |
| media | binary content with a checksum and detected regions | image:8f2a1c9d |
| claim | an assertion about another object | claim:c19 (this document's own claims) |
| source | evidence supporting or produced by a claim | source:m6 (a model pass, below) |
| rule | a versioned policy or statute | rule:match@v3.1 |
| procedure | a versioned test or operation definition | procedure:fraud-score@v9 |
| model_pass | one model's examination of one object | see Section 2 |
| decision | a human or automated action taken on an object | decision:hold-account-91ac |
| authority | the scope permitting an actor to act | authority:role-fraud-analyst |
| receipt | proof an invocation completed | receipt:c4d5…9e08 |
| exception | an unresolved conflict, gap, or refusal | exception:identity-conflict-44f1-91ac |
| version | a pointer to a specific revision of any object | transaction:7a1e4f0b@v2 |
Sixteen families, not an exhaustive ontology of the world — a template set. A foreign system that produces something with no good fit produces an unresolved object (1.3) and a new template gets written, reviewed, and versioned. That is the entire extension mechanism; there is no larger schema waiting to be discovered.
2. The ledger
2.1 What a ledger event contains
Every material act on an object — an examination, an inference, a disagreement, a refusal, a correction, a replay, or a repair — becomes one append-only event.
json · 17 linestap to unfold
{
"object_id": "transaction:7a1e4f0b",
"object_version": "v1",
"actor": "fraud-model-c@operator-4",
"procedure": "fraud-score@v9",
"authority": "role-fraud-analyst",
"input_hash": "sha256:1b9f…7d21",
"output": "flagged",
"evidence": "sha256:d6a2…44e1",
"started_at": "2026-07-27T18:04:11.221Z",
"status": "completed",
"parent_invocation": null,
"replay_of": null,
"repair_of": null,
"prev": "sha256:aa01…4f6b",
"hash": "sha256:bb02…7c1d"
}| Field | Why it exists |
|---|---|
actor | Which model, endpoint, or human acted — an identity, not a display name. |
procedure | Versioned. "Reviewed for fraud" is unrepeatable; fraud-score@v9 resolves to a stored definition. |
authority | The scope that permitted this act, so an audit can ask whether the actor was allowed to act at all. |
input_hash | Binds the record to the exact bytes examined at that moment. |
status | completed, failed, or refused — a refusal is a first-class event, not a missing row. |
parent_invocation, replay_of, repair_of | Link a corrected or repeated action back to the one it responds to, so a chain of corrections is traceable. |
prev, hash | The append-only chain: deleting this row breaks every hash after it. |
2.2 What this is not
| System | What it stores | What it lacks that this ledger has |
|---|---|---|
| A database | current state | every prior state, and why it changed |
| A trace (OpenTelemetry) | one execution's spans | permanence beyond a retention window, and a required population to compare against |
| An event log (event sourcing) | every mutation, replayable | attribution of reliability, and competing-assertion representation for the same fact |
| PROV | entities, activities, responsible agents | a declared population, coverage, and per-object belief aggregation |
This ledger is the union of what those four already do, applied specifically to model examinations of canonical objects, plus the fields in 2.1 that none of the four individually require. Full source cards for OpenTelemetry and event sourcing:
2.3 A refusal is a recorded event
A model declining to act — insufficient authority, ambiguous input, a policy conflict — writes the same event shape with status: "refused" and a reason. Without this, a system cannot distinguish "this object was never examined" from "this object was examined and the model declined to act," and those are different facts with different consequences for a later audit.
3. The evidence graph
3.1 A model's conclusion is a claim, not a fact
The single rule that makes this system resistant to one bad model output corrupting the record: a model's conclusion about an object is written as an attributed, revisable assertion attached to that object. It is never written into the object's own fields as settled fact.
{
"id": "assertion:9f21",
"object_id": "image:8f2a1c9d",
"claim": "face matches reference set entry R-4408",
"stance": "contradicts",
"contradicts": "assertion:7ab0",
"actor": "vision-model-c@operator-3",
"confidence": 0.31,
"authority": "role-investigator",
"independence": "trained_separately_from:7ab0.actor",
"ts": "2026-07-27T18:12:04Z"
}assertion:7ab0, made earlier by a different model, said no_match. Both assertions persist. Neither is deleted when they disagree.
3.2 Computing a current belief without deleting what produced it
A "current belief" for an object is a read-time computation over its assertions — never a stored, final value. This is the one place this specification names its own unsolved problem plainly: combining many assertions into one belief is an instance of the belief-revision problem, and no belief-revision rule is neutral. Every rule weights some inputs over others, and every weighting is attackable by whoever controls the inputs.
A recency-and-trust-weighted rule is concretely vulnerable to adversarial recency-inflation: a late, low-trust, undisclosed-derivative assertion outranks an earlier high-quality consensus because recency dominates the score, and an independence penalty cannot catch a derivation the submitter does not disclose. This is not a hypothetical caveat; it is the specific attack against the specific rule quoted above.
3.3 The query this buys that nothing else answers
That query — find every object where a later, higher-authority assertion overturned an earlier one after the earlier one had already caused a downstream decision — requires exactly the three things this system provides together: a durable object each assertion attaches to, an unbroken ledger of which decision cited which assertion, and assertions that are never overwritten. None of the systems in Section 7 store all three.
4. Signed model work
4.1 What a signature proves
A signed pass — the pairing of a ledger event (2.1) with the model or execution identity that produced it — establishes exactly five things: which model or execution identity produced the record, which object and object version it examined, which procedure it used, what output it produced, and when it ran, plus whether the record has been altered since (via the hash chain).
in-toto and SLSA establish the general shape being borrowed here: bind a claim to a content digest and name the actor, rather than to a filename or a free-text description.
4.2 What a signature does not prove
It does not prove the conclusion is true. It does not prove the input source was itself truthful. It does not prove the procedure applied was the correct one for the situation. It does not prove all relevant evidence was included. And it does not prove the operator did not selectively omit other passes over the same object while presenting this one.
That last gap is not theoretical:
A signature is real evidence that an examination happened exactly as recorded. It is not evidence that the examination was the whole story, or the right one to cite.
5. Proof of coverage
Coverage is the one mechanism that answers "was every required object examined," and it needs three things that a single signed pass does not provide by itself: a frozen population, an identity rule, and a required-operations list.
{
"universe_id": "u_2026_07_27_gate_a_faces",
"declared_count": 4812,
"identity_rule": "one object per tracked face-track with >= 3 detections and minimum bounding box 40px",
"excluded": 337,
"exclusion_reason": "below minimum resolution",
"required_procedure": "match@v3.1"
}SELECT u.declared_count,
COUNT(DISTINCT p.object_id) FILTER (WHERE p.output <> 'error') AS examined,
u.declared_count - COUNT(DISTINCT p.object_id) FILTER (WHERE p.output <> 'error') AS missing
FROM universe u LEFT JOIN pass p
ON p.universe_id = u.id AND p.procedure = u.required_procedure
WHERE u.id = 'u_2026_07_27_gate_a_faces';
-- 4812 | 4790 | 22A signed pass proves one examination happened. Coverage proves whether the required population received the required examinations — a query against two tables, not a claim any model makes about its own completeness.
6. Scale
Concretely: at roughly ten billion pass records, recomputing the full hash chain to detect any tampering costs on the order of a hundred days of single-core signature verification, and a single hot object with hundreds of thousands of examinations forces an equivalently large scan every time its current belief is resolved. A production deployment therefore needs a compaction or snapshot layer — periodic, signed summaries of an object's assertion state that later queries read by default, with the raw chain kept for audit and available on demand. This document specifies the raw layer; it does not specify the compaction layer, which is unresolved.
7. One complete event, hour by hour
A twenty-system ingest after a major incident: cameras, badge logs, payment records, messaging archives, employee files, devices, public records, and witness statements, with a 72-hour deadline to prove every relevant record was examined.
Hour 0 — scope and freeze. Twenty systems listed. Access confirmed on fourteen, refused on three, unknown on three pending legal review. The identity rule for "one relevant record" is written and signed before any ingestion begins.
Hour 6 — shape matching. The fourteen accessible systems map onto six of the sixteen object families in Section 1.4. Two systems need a new template written and reviewed. Every field with no canonical target is logged, not dropped (1.2).
Hour 18 — enrolment. 2,412,006 objects hashed and counted. The universe is frozen. 311,004 records are excluded by the identity rule, each with a stated reason (mostly: below-threshold image resolution, duplicate badge scans within the same second).
Hour 30 — passes running. Three independent models examine the same enrolled objects under versioned procedures. 6.1 million pass records written. A coverage query runs every fifteen minutes against the live table.
Hour 52 — contradictions surface. 1,204 objects now carry two model assertions that disagree. This is not an error state; it is the evidence graph doing its job (Section 3). All 1,204 are queued for human review by rule, not by whoever happens to notice.
Hour 72 — handover. 2,412,006 enrolled · 2,398,771 examined · 13,235 unresolved and individually named · 1,204 contested and queued · 3 systems refused access, listed by name. Every number in that sentence is a query against the object table and the pass table. None of it is a model's summary of its own work.
The honest failure mode of this whole scenario is not a shortage of storage or a shortage of model calls. It is the schema-reconciliation step at hour 6 — if that step is faked or rushed, every later number, including "2,398,771 examined," is decoration sitting on top of a broken join.
8. Applications
| Domain | Objects | Current method | What changes | New query this enables | Principal abuse |
|---|---|---|---|---|---|
| Intelligence & investigations | person, device, location, image, message | fused databases, analyst judgment, no stored population | a frozen, named population and per-object competing assertions | "which faces were never examined, and why" | selective ledgering — citing only the passes that support a predetermined conclusion (see the Grok 4.5 pass, Section 4.2) |
| Fraud | account, transaction, device, dispute | one model score per transaction, thin logs | every detector's judgment attached to the same account/transaction objects, disagreement preserved | "which flagged accounts had a later model reverse an earlier hold" (the GLM Flash pass, Section 3.3) | tuning which model's assertion gets cited to justify a decision already made |
| Medicine | patient, scan, lab result, diagnosis | a reading becomes the chart entry | a reading is an attributed, contestable claim on the patient object until confirmed | "which findings were later contradicted by a specialist or a biopsy, and how long the gap was" | an uncontested preliminary read hardening into treatment before a second opinion exists |
| Compliance | rule, control, governed asset, execution | a dashboard summarizing pass/fail | every control execution as a signed pass against a versioned rule, with coverage over the whole regulated population | "which assets were never checked under the current rule version" | running the audit against a rule version that excludes the population that would fail |
| Software engineering | repository, file, requirement, test | an agent's summary of what it changed | every read, edit, and test run as a pass over file and requirement objects | "which claimed-satisfied requirements have no passing test object attached" | an agent's summary overstating coverage a reviewer never checks |
| Research & journalism | source, claim, event | a report citing sources informally | every source and inference as its own object with a stance toward other claims | "which published claims rest on a source later retracted" | selective citation of the supporting sources while contradicting ones exist in the same graph, unlinked |
| Autonomous agents | shared object, agent, pass | private per-agent memory and summaries | agents share canonical objects and see each other's passes, not just each other's summaries | "which agent's assertion did a later agent overturn, and did anything act on the earlier one first" | one agent's uncorroborated pass propagating into another agent's decision before it is contested |
| Personal privacy | a person's own records, institutional claims about them | the institution's record is the only record | the person holds their own object graph; an institution's claim about them is one more attributed, contestable assertion | "which institutional claims about me have I contradicted, and was the contradiction ever examined" | none for the individual — this is the defensive application, discussed next |
9. Dual use
The same mechanism serves two opposite purposes with no code-level difference between them.
An institution can fuse someone's payment, location, communication, and access records into canonical objects, run models over them, and accumulate an evidentiary case — this is the coming AI-fusion problem in its concrete, mechanical form.
Two separate 2024 FTC orders document this already happening in the commercial location-data market: data brokers reselling location tied to medical clinics, religious sites, and shelters, with no per-disclosure signed record of who bought what and why.
Two GAO reports document the same absence inside government use: federal facial-recognition searches run for years with no stored training requirement and, for most agencies, no specific civil-rights policy — exactly the missing procedure record and missing coverage record this specification requires by default.
The identical mechanism run in the other direction lets a person maintain their own object graph, hold an institution's claims about them as attributed, contestable assertions rather than accepted fact, and attach counterevidence to the same object the institution's claim lives on. The risk does not disappear in this direction either: it shifts entirely to who controls ingestion, identity resolution, authority, visibility, retention, challenge rights, aggregation rules, and downstream action.
Nothing in the architecture decides which direction it runs. That is decided entirely by who controls ingestion, identity resolution, authority, visibility, retention, challenge rights, aggregation rules, and downstream action. EFF's independent reading of the same enforcement actions is useful because it names exactly those levers as the ones that were uncontrolled.
10. Prior art
| System | Solves | Does not solve | What this spec inherits |
|---|---|---|---|
| W3C PROV | entities, activities, responsible agents, and the relations between them | a declared population; per-object competing, revisable assertions | the entity/activity/agent vocabulary underlying Section 2 |
| OpenTelemetry | low-overhead tracing of operations and their causal links, in production | retention beyond a sampling window; any concept of a required population | the span-linking idea, applied to model passes instead of service calls |
| OpenLineage | which job read/wrote which dataset, across pipeline tools | row-level coverage — its granularity is the dataset, not the record | the dataset-lineage concept, pushed down to object granularity |
| Event sourcing | append-only reconstruction of any past state from a mutation log | attribution of reliability; competing-assertion representation | the append-only mutation log itself, which Section 2's ledger is built on |
| in-toto / SLSA | binding a signed statement to a content digest and a builder identity | aggregating many such statements into a belief; declaring a population | the exact shape of Section 4's signed pass |
| C2PA | a tamper-evident manifest of edits and tool identities on one piece of media | cross-media relationships; a declared population of media | the per-artifact manifest idea, generalized past media |
| Certificate Transparency | a public, cryptographically verifiable append-only log where deletion is detectable | anything about content or meaning — it is a pure logging primitive | the hash-chain construction in Section 2.1, at object scale instead of internet scale |
| LangGraph persistence | checkpointing one agent's own execution for pause/resume/rollback | multiple independent agents sharing state as objects, or recording their disagreement | the checkpoint-as-durable-state idea, extended to cross-agent shared objects in Section 8 |
| Palantir Foundry Ontology | unifying enterprise data into typed objects, links, and actions at production scale | (as documented) an open, independently implementable spec; per-examination model attestation as a first-class primitive | the object-and-link modeling approach, published here as an open specification instead |
| Record linkage / entity resolution | the statistical theory of matching records to real-world entities, since 1969 | what to do with the object once matched — linkage stops at the match decision | the confidence-scored identity_claim object in Section 1.3 |
| Schema matching | proposing correspondences between two schemas, automatically or semi-automatically | what happens to fields with no correspondence | the versioned mapping concept; unmapped_fields is this spec's explicit answer to the gap |
| Belief revision | the formal theory of updating beliefs under new, possibly contradicting information | providing one neutral aggregation rule — none exists | the honest statement, in Section 3.2, that this is unsolved here too |
The combination this document claims as its contribution: a declared population, per-object competing and revisable assertions, and belief aggregation, unified with normalization and signed model attestation, in one open specification. No single system above provides all three; several provide one or two. Whether an unpublished or classified system already combines all of this has not been checked — patent filings and defense-sector literature were not searched for this document, and that is a stated limitation, not a claim of novelty.
Full source cards for every system in the table above, in the same order:
11. Article as proof
This document is itself an instance of what it specifies. Its 35 numbered claims are addressable claim-objects. Its fourteen prior-art sources and five regulatory sources are evidence-objects. The six model answers collected during this document's own drafting are signed pass-objects, each attached to the specific claim it supports, each carrying the model identity, the exact question, the exact answer, and a timestamp — reproduced below in full, plus the pass recording this document's own authorship. A reader can move, right now, from any claim above to its source, from a source to the model pass that produced it, and from that pass to the exact quote and verdict — the traversal this specification describes in Section 3.3, demonstrated rather than only asserted.
Key evidence
25 more ranked claims
Ask this article · 8 suggested prompts
Text the build (+14245134626) or WhatsApp — slug|question creates a question node. Paste evidence with ingest slug|q:NODE_ID|your paste.