{"_self":{"principle":"Self-explaining payload — no external context required. This _self block describes what you are reading and where to look next.","widget":"article_topology","feature":"topology","name":"Article topology","what":"Claims, sources, anecdotes, user reports, related embeds, question graph slice — for ask/ROUTER.","contains":"claims, sources, anecdotes, question_graph slice","slug":"object-ledger-evidence-graph-spec","urls":{"read":"https://miscsubjects.com/api/articles/object-ledger-evidence-graph-spec/topology"},"how_to_use":"Claims, sources, anecdotes, user reports, related embeds, question graph slice — for ask/ROUTER.","write":null,"imessage":null,"router_tag":null,"proof_chain":[{"step":1,"claim":"Articles are voxel graphs of tiered claims, not prose blobs.","verify":"https://miscsubjects.com/api/articles/constitution"},{"step":2,"claim":"Claims link to hash-chained sources via source_ids.","verify":"https://miscsubjects.com/api/articles/object-ledger-evidence-graph-spec/sources"},{"step":3,"claim":"Ask reads topology; ingest/claim append to ledger.","verify":"https://miscsubjects.com/api/protocol"},{"step":4,"claim":"Models queue growth: populate → collaborate → repair → reflex.","verify":"https://miscsubjects.com/api/protocol/grow"},{"step":5,"claim":"Graph proves its own shape (reflex) and $/claim (yield).","verify":"https://miscsubjects.com/graph.html?layer=reflex"},{"step":6,"claim":"Full feature index + _explain on every API response.","verify":"https://miscsubjects.com/api/articles/system-map"}],"related_features":[{"id":"ask","name":"Ask protocol","what":"Answer only from topology; creates question_node with gaps and ingest_hint.","urls":{"read":"https://miscsubjects.com/api/articles/object-ledger-evidence-graph-spec/prompts","write":"https://miscsubjects.com/api/protocol/ask"}},{"id":"graph_topology","name":"Cross-article graph","what":"Merged claims/sources across condition+stack slugs for one question.","urls":{"read":"https://miscsubjects.com/api/articles/object-ledger-evidence-graph-spec/graph-topology?question=..."}},{"id":"question_graph","name":"Question graph","what":"Ask nodes (questions + gaps) and evidence_ingest nodes (pasted model output).","urls":{"read":"https://miscsubjects.com/api/articles/object-ledger-evidence-graph-spec/question-graph","write":"https://miscsubjects.com/api/protocol/ask"}},{"id":"voxels","name":"Voxel graph","what":"Claims as atoms, sources as edges (supported_by, posted_by). Per-claim provenance.","urls":{"read":"https://miscsubjects.com/api/articles/object-ledger-evidence-graph-spec/voxels","write":"https://miscsubjects.com/api/protocol/claim"}}],"system_map":"https://miscsubjects.com/api/articles/system-map","system_map_markdown":"https://miscsubjects.com/api/articles/system-map?format=markdown","not_medical_advice":true},"_explain":{"feature":"topology","name":"Article topology","what":"Claims, sources, anecdotes, user reports, related embeds, question graph slice — for ask/ROUTER.","why":"Every feature is auditable collective intelligence","how":"Claims, sources, anecdotes, user reports, related embeds, question graph slice — for ask/ROUTER.","model":null,"verifies":null,"urls":{"read":"https://miscsubjects.com/api/articles/object-ledger-evidence-graph-spec/topology"},"imessage":null,"router":null,"related":[{"id":"ask","what":"Answer only from topology; creates question_node with gaps and ingest_hint."},{"id":"graph_topology","what":"Merged claims/sources across condition+stack slugs for one question."},{"id":"question_graph","what":"Ask nodes (questions + gaps) and evidence_ingest nodes (pasted model output)."},{"id":"voxels","what":"Claims as atoms, sources as edges (supported_by, posted_by). Per-claim provenance."}],"not_medical_advice":true},"slug":"object-ledger-evidence-graph-spec","title":"The object ledger: one grammar for every record, a signed receipt for every look","register":"technical","tags":["system","protocol","objects","ledger","evidence-graph","spec"],"updated_at":"2026-07-28T04:33:00.263Z","body_excerpt":"## The object ledger: one grammar for every record, a signed receipt for every look\n\nEvery 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.\n\nThe 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.\n\nThis 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.\n\nIt has three layers, in this order, because each depends on the one before it:\n\n1. **Object grammar** — what exists, and what can be acted on. Section 1.\n2. **Ledger** — what every actor actually did to an object, permanently. Section 2.\n3. **Evidence graph** — what is currently believed about an object, computed from the ledger, never overwriting it. Section 3.\n\nProof of coverage — whether a declared set of objects received a required examination — is one mechanism inside layer 2, covered in Section 6.\n\nA 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.\n\n![The four layers between a foreign system and an answer you can check: seven foreign systems on the left, converted by a normalizer into canonical objects, examined into an append-only pass ledger, and accumulated into an evidence graph on the right.](https://miscsubjects.com/img/spec/object-ledger-fig1.svg)\n## 1. Ingestion and normalization\n\n### 1.1 What goes in\n\nA 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.\n\n### 1.2 The canonical object\n\nEvery ingested record becomes exactly one canonical object with five mandatory fields:\n\n| Field | Purpose |\n|---|---|\n| `source_id` | The record's identifier in the foreign system, verbatim. |\n| `canonical_id` | The identifier this object uses everywhere else in this system. |\n| `type` | One of the object grammar's families (Section 1.4), or `unresolved`. |\n| `source_hash` | sha256 of the original bytes, so the object can be checked against the source at any later time. |\n| `translation_version` | Which version of the mapping rule produced this object. |\n\n```json\n{\n  \"source_id\": \"stripe:ch_3P9k2LKx\",\n  \"canonical_id\": \"transaction:7a1e4f0b\",\n  \"type\": \"transaction\",\n  \"source_hash\": \"sha256:9c41…b07e\",\n  \"translation_version\": \"stripe-charge@v2\",\n  \"fields\": { \"amount\": 4899, \"currency\": \"usd\", \"party_a\": \"acct_1N…\", \"party_b\": \"cus_9K…\", \"created\": \"2026-07-21T14:02:11Z\" },\n  \"unmapped_fields\": { \"stripe.balance_transaction\": \"txn_3P9k2L…\", \"stripe.payment_method_details.card.checks\": { \"cvc_check\": \"pass\" } }\n}\n```\n\nNothing in `fields` is guessed. A Stripe field with ","ranking":"safety-first (interaction_risk/limitations), then quote-gated effective_weight","claims":[{"id":"c25","text":"A documented real-world failure of exactly this kind — federal law-enforcement facial-recognition searches run with no stored training requirement and, for most agencies, no specific civil-rights policy — shows what happens when neither a procedure record nor a coverage record exists: the number of searches, their basis, and their oversight had to be reconstructed by an external audit rather than read off an existing artifact.","tier":"human","section":"Applications — intelligence and investigations","interaction_risk":false,"status":"active","source_ids":["e3","e4"],"why_material":"Grounds the abstract argument in a documented, government-audited case rather than a hypothetical.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.8,"quote_gated":false},{"id":"c26","text":"Commercial location-data brokers were separately found, in two 2024 FTC actions, to have collected and resold location data capable of revealing visits to medical clinics, religious sites, and shelters, without the kind of per-disclosure, per-buyer signed record this architecture would require before any transfer.","tier":"human","section":"Applications — intelligence and investigations","interaction_risk":false,"status":"active","source_ids":["e1","e2","e5"],"why_material":"Grounds the dual-use argument (institutional fusion vs. accountable fusion) in an enforcement record, not speculation.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.8,"quote_gated":false},{"id":"c34","text":"The dual-use risk is not eliminated by the architecture; it shifts entirely to who controls ingestion, identity resolution, authority, visibility, retention, challenge rights, aggregation rules, and downstream action — the same six FTC-documented location-data cases above involve companies that controlled every one of those levers with no external visibility.","tier":"human","section":"Dual use","interaction_risk":false,"status":"active","source_ids":["m2","e5"],"why_material":"States plainly that the mechanism is neutral and the outcome is a governance question, not a technical one.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.8,"quote_gated":false},{"id":"c1","text":"This document specifies a system with exactly three layers: an object grammar for what exists, an append-only ledger for what was done, and an evidence graph for what is currently believed.","tier":"system","section":"Definition","interaction_risk":false,"status":"active","source_ids":[],"why_material":"Every later section is one of these three layers; naming them first prevents any later section from being read as the whole system.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c2","text":"Proof of coverage is a subordinate mechanism inside the ledger layer, not the subject of this specification.","tier":"system","section":"Definition","interaction_risk":false,"status":"active","source_ids":[],"why_material":"It corrects a scoping error from an earlier draft of this work.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c3","text":"Ingestion converts a record from a foreign system into a canonical object while keeping the original record retrievable by its source identifier.","tier":"system","section":"Ingestion","interaction_risk":false,"status":"active","source_ids":[],"why_material":"Normalization that discards the source record cannot be checked against it later.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c4","text":"Every canonical object carries a source_id, a canonical_id, a type, a source_hash of the original bytes, and a translation_version naming the exact mapping rule that produced it.","tier":"system","section":"Ingestion","interaction_risk":false,"status":"active","source_ids":[],"why_material":"These five fields are the minimum needed to reverse the normalization and to know which version of the mapping produced a given object, so a later fix to the mapping does not silently retag old objects.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c5","text":"A field with no target in the canonical schema is stored under unmapped_fields on the object rather than discarded.","tier":"system","section":"Ingestion","interaction_risk":false,"status":"active","source_ids":[],"why_material":"Silent field loss during normalization is undetectable by anyone reading only the canonical object.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c6","text":"A record that cannot be classified into any known object type is stored as type unresolved with the raw payload attached, not forced into the nearest type.","tier":"system","section":"Ingestion","interaction_risk":false,"status":"active","source_ids":[],"why_material":"Forcing a bad fit corrupts every downstream query that trusts the type field.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c7","text":"When two source records are believed to describe the same real-world entity, they are linked by an identity_claim record naming the method and confidence, not silently merged into one object.","tier":"system","section":"Ingestion","interaction_risk":false,"status":"active","source_ids":[],"why_material":"Merging destroys the ability to later split a wrong match; keeping the claim separate makes the merge itself reversible and inspectable.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c8","text":"Schema matching between a foreign system and the canonical grammar can be proposed automatically but the resulting field mapping must be reviewable and versioned, because an unreviewed automatic match is a second source of silent error on top of identity resolution.","tier":"system","section":"Ingestion","interaction_risk":false,"status":"active","source_ids":["p13"],"why_material":"MiniMax M3's stated failure mode is exactly an unreviewed schema mapping forcing an impossible join.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c9","text":"Different system families (frame-based video, event-based access logs, transactional payments, threaded messages, relational HR records) have genuinely different native structures, and normalizing all of them costs real, non-trivial engineering per family — this is not a one-time solved problem.","tier":"system","section":"Ingestion","interaction_risk":false,"status":"active","source_ids":["p11","m4"],"why_material":"Understating this cost is the most common way this kind of architecture gets oversold.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c10","text":"Entity resolution across systems has a nonzero, measurable error rate at any achievable scale; a coverage claim built on top of unresolved identity conflicts inherits that error rate silently unless the conflicts are recorded as their own objects.","tier":"system","section":"Ingestion","interaction_risk":false,"status":"active","source_ids":["p11","p12"],"why_material":"This is the specific mechanism by which a technically correct coverage number can still describe the wrong set of real people or things.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c11","text":"The object grammar's claim is narrower than 'every system reduces to one ontology': many foreign systems contain recurring structural families — entity, event, observation, communication, transaction, media, claim, source, rule, procedure, model pass, decision, authority, receipt, exception, version — that can be normalized through reusable templates while source-specific fields and unresolved differences are preserved rather than erased.","tier":"system","section":"Object grammar","interaction_risk":false,"status":"active","source_ids":[],"why_material":"The stronger claim, that everything reduces cleanly, is false and was corrected out of this document.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c12","text":"A ledger event records who or what acted, on which exact object version, under which procedure or prompt version, with which model and runtime, under which authority, with a hash of the input, the output produced, any evidence artifact, a timestamp, a status, and — when applicable — a parent invocation, a replay link, and a repair link.","tier":"system","section":"Ledger","interaction_risk":false,"status":"active","source_ids":[],"why_material":"These are the fields that separate a usable ledger event from a log line.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c13","text":"A database that stores current state, a trace that stores one execution, and an event log that stores mutations are each a proper subset of what this ledger stores: it additionally stores every examination, inference, disagreement, refusal, correction, replay, and repair against a durable canonical object, indefinitely.","tier":"system","section":"Ledger","interaction_risk":false,"status":"active","source_ids":["p1","p2","p4"],"why_material":"This is the precise boundary between what PROV, OpenTelemetry, and event sourcing already do and what this ledger adds.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c14","text":"A refusal — a model declining to act on an object — is itself a ledger event with the same shape as any other pass, not the absence of one.","tier":"system","section":"Ledger","interaction_risk":false,"status":"active","source_ids":[],"why_material":"A system that only records completed actions cannot distinguish 'not examined' from 'examined and refused.'","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c15","text":"A model's conclusion about an object is stored as an attributed, revisable assertion attached to that object, never written into the object itself as fact.","tier":"system","section":"Evidence graph","interaction_risk":false,"status":"active","source_ids":[],"why_material":"This single rule is what stops one wrong model output from silently becoming the permanent record.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c16","text":"An assertion in the evidence graph carries a stance toward other assertions on the same object — support, contradiction, or supersession — plus the confidence, authority, independence and recency of its source.","tier":"system","section":"Evidence graph","interaction_risk":false,"status":"active","source_ids":[],"why_material":"Without stored stance, two contradicting assertions look identical to a downstream reader.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c17","text":"Combining many assertions into one current belief about an object 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 can be gamed by whoever controls the inputs.","tier":"system","section":"Evidence graph","interaction_risk":false,"status":"active","source_ids":["p14"],"why_material":"This is the load-bearing limitation of the whole architecture and is stated as a limitation, not solved.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c18","text":"A recency-weighted, trust-weighted, independence-weighted belief rule is concretely vulnerable to adversarial recency-inflation: a late, low-trust, undisclosed-derivative assertion can outrank an earlier high-quality consensus because recency dominates the score.","tier":"system","section":"Evidence graph","interaction_risk":false,"status":"active","source_ids":["m3","p14"],"why_material":"Stated as a concrete attack against a concrete rule, not an abstract warning.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c19","text":"The query this architecture is specifically built to make answerable — and that is not answerable in any of the prior-art systems compared here — is: which objects had a later, higher-authority assertion reverse an earlier assertion after that earlier assertion had already caused a downstream action.","tier":"system","section":"Evidence graph","interaction_risk":false,"status":"active","source_ids":["m6"],"why_material":"This is the single clearest statement of what the combination buys over its parts.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c20","text":"A signed model pass proves which model or execution identity produced the record, which object and object version it examined, which procedure it used, what output it produced, when it ran, and whether the record has been altered since.","tier":"system","section":"Signed model work","interaction_risk":false,"status":"active","source_ids":["p5","p6"],"why_material":"This is the exhaustive list of what a signature actually establishes.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c21","text":"A signed model pass does not prove that the conclusion is true, that the input source was itself truthful, that the procedure applied was the correct one, that all relevant evidence was included, or that the operator did not selectively omit other passes over the same object.","tier":"system","section":"Signed model work","interaction_risk":false,"status":"active","source_ids":["p8"],"why_material":"Confusing a signature with a truth guarantee is the single most common misuse of this kind of system, and is the mechanism behind Grok 4.5's named abuse case.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c22","text":"At roughly ten billion pass records, recomputing the full hash chain to detect tampering costs on the order of one hundred days of single-core signature verification, and a hot object accumulating hundreds of thousands of examinations forces an equivalently large scan to resolve its current belief, so a production deployment requires a compaction or snapshot layer above the raw append-only chain.","tier":"system","section":"Scale","interaction_risk":false,"status":"active","source_ids":["m1"],"why_material":"This is a concrete, falsifiable capacity limit rather than a vague scaling caveat.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c23","text":"Proof of coverage requires a frozen population (a stated count and an identity rule fixing what counts as one object), a required-operations list, and a count of completed, failed, and excluded operations against that population; a signed pass proves one examination happened, coverage proves whether the required population received the required examinations.","tier":"system","section":"Proof of coverage","interaction_risk":false,"status":"active","source_ids":[],"why_material":"States precisely how coverage differs from, and is built on top of, a single signed pass.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c24","text":"Coverage arithmetic is a query against two tables (the frozen population and the pass ledger), not a claim a model makes about its own completeness.","tier":"system","section":"Proof of coverage","interaction_risk":false,"status":"active","source_ids":[],"why_material":"This is the property that makes a coverage number independently checkable.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c27","text":"The most plausible first commercial buyers of this architecture are regulated, multi-vendor organizations — named as hospitals, insurers, and banks — because they already face an external audit requirement and already run more than one AI system over the same underlying records.","tier":"system","section":"Applications","interaction_risk":false,"status":"active","source_ids":["m2"],"why_material":"Names the buyer concretely instead of gesturing at 'enterprises.'","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c28","text":"The specific cost an organization pays for adopting this architecture is the loss of the ability to attribute a bad automated decision to an unexaminable black box; every examination becomes attributable to a specific model, procedure version, and operator.","tier":"system","section":"Applications","interaction_risk":false,"status":"active","source_ids":["m5"],"why_material":"States why adoption is not automatically in an institution's interest, which is the honest counter-argument to selling this as a pure win.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c29","text":"The same mechanism that lets an institution build an inspectable case against a person — their records fused into objects, examined by models, and accumulated into a belief — lets that same person maintain their own object graph, with the institution's assertions attached as attributed, contestable claims rather than accepted fact.","tier":"system","section":"Dual use","interaction_risk":false,"status":"active","source_ids":[],"why_material":"This is the precise, mechanism-level statement of the dual-use symmetry, not a rhetorical one.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c30","text":"PROV, OpenTelemetry, OpenLineage, in-toto, SLSA, and C2PA each solve one piece of this architecture already — naming responsible agents, tracing execution, tracking dataset lineage, or binding a signed statement to a content hash — and none of them combines a declared population, per-object competing assertions, and belief revision in one system.","tier":"system","section":"Prior art","interaction_risk":false,"status":"active","source_ids":["p1","p2","p3","p5","p6","p7"],"why_material":"States exactly what is inherited and exactly what is new, per the individual source summaries above.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c31","text":"Event sourcing already solves append-only reconstruction of state from a mutation log; this architecture adds attribution, revisability, and competing-assertion representation on top of that log, which event sourcing by itself does not provide.","tier":"system","section":"Prior art","interaction_risk":false,"status":"active","source_ids":["p4"],"why_material":"Names the exact delta over the closest general-purpose prior art.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c32","text":"LangGraph's persistence layer solves checkpointing a single agent's own run for pause, resume, and rollback; it does not solve multiple independent agents sharing state as canonical objects or recording disagreement between them, which is what this architecture adds for multi-agent settings.","tier":"system","section":"Prior art","interaction_risk":false,"status":"active","source_ids":["p9"],"why_material":"Distinguishes single-agent execution memory from shared, durable, cross-agent object state.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c33","text":"Palantir's Foundry Ontology already solves unifying enterprise data into typed objects, links, and actions with permissions at production scale; as documented, it is not published as an open, independently implementable conformance specification, and per-examination model attestation is not a first-class primitive of the published model.","tier":"system","section":"Prior art","interaction_risk":false,"status":"active","source_ids":["p10"],"why_material":"The closest production system to this spec, named honestly rather than avoided.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false},{"id":"c35","text":"This article is itself represented as the objects it specifies: each numbered claim is an addressable claim-object, each source above is an evidence-object, each of the six collected model answers is a signed pass-object attached to a specific claim, and this sentence is a pass over the article-object, recorded at publish time under the site's ledger.","tier":"system","section":"Article as proof","interaction_risk":false,"status":"active","source_ids":["a1"],"why_material":"Demonstrates the architecture inline rather than only describing it.","retracted_at":null,"retraction_reason":null,"challenged_by":[],"effective_weight":0.1,"quote_gated":false}],"sources":[{"id":"p1","type":"reference","url":"https://www.w3.org/TR/prov-dm/","title":"W3C PROV-DM: The PROV Data Model","quote":"PROV-DM is a data model for provenance that describes the entities, activities and agents involved in producing a piece of data or thing in the world.","summary":"Solves: naming entities, activities, and responsible agents, and the relations between them. Does not solve: a declared population to check completeness against, or a per-object graph of competing, revisable assertions.","claim_ids":["c30"],"hash":"5703436a0b8989333a79ace7190fd9324df8a10ce0450ba82ae6294e25256d52"},{"id":"p2","type":"reference","url":"https://opentelemetry.io/docs/specs/otel/trace/api/","title":"OpenTelemetry tracing specification","summary":"Solves: recording operations and their causal relationships across services, at low overhead, in production. Does not solve: retention beyond a sampling/expiry window, or any concept of a required population.","claim_ids":["c30"],"hash":"46ff3cfc3d5b37c453b25038dbb77a01ecc77d3dbca942fc334776bc40a5ea0a"},{"id":"p3","type":"reference","url":"https://openlineage.io/docs/spec/object-model","title":"OpenLineage object model","summary":"Solves: tracking which job read and wrote which dataset, across pipeline tools. Does not solve: row-level or record-level coverage — lineage is at dataset granularity.","claim_ids":["c30"],"hash":"225b03f1d82dc848bc333e37c73edcfaf1f30ec9ba4e47b441979a6dc63ba9fb"},{"id":"p4","type":"reference","url":"https://martinfowler.com/eaaDev/EventSourcing.html","title":"Event Sourcing","quote":"Capture all changes to an application state as a sequence of events.","summary":"Solves: reconstructing any past state from an append-only event log, and never discarding a mutation. Does not solve: attributing a judgment's reliability, or representing disagreement between two events about the same fact.","claim_ids":["c31"],"hash":"bec9a091a1777f4208bebd65cf7f2255211fd1722072cc0ba3c197c1384aa9c5"},{"id":"p5","type":"reference","url":"https://github.com/in-toto/attestation","title":"in-toto attestation framework","summary":"Solves: a signed statement binding a predicate to a subject identified by cryptographic digest — the shape a pass record needs. Does not solve: aggregating many such statements into a belief about the subject, or declaring a population.","claim_ids":["c20","c30"],"hash":"dfa5c3919558554ce02ce4da7da0e74c66dcf9988163c53b8dd56d892f87d7ec"},{"id":"p6","type":"reference","url":"https://slsa.dev/spec/v1.0/provenance","title":"SLSA v1.0 provenance specification","quote":"The provenance attestation describes how an artifact was produced, including the builder identity, the build definition, and the resolved dependencies.","summary":"Solves: binding a build artifact to the identity and inputs that produced it. Does not solve: this outside the build/CI domain, or coverage over a declared set.","claim_ids":["c20","c30"],"hash":"55dc0791855c84e91ede6b504b032c5a25096503338150d5245527cd5db1607e"},{"id":"p7","type":"reference","url":"https://c2pa.org/specifications/specifications/2.1/index.html","title":"C2PA technical specification 2.1","summary":"Solves: attaching a tamper-evident manifest of edits and tool identities to one piece of media. Does not solve: cross-media relationships, or a declared population of media to check.","claim_ids":["c30"],"hash":"8a44d23541aa088171b88fc45068ec18254a2acc265a42a0bbb6182a8f0a1ac8"},{"id":"p8","type":"reference","url":"https://www.rfc-editor.org/rfc/rfc6962","title":"Certificate Transparency (RFC 6962)","summary":"Solves: an append-only, publicly auditable, cryptographically verifiable log where deletion or backdating is detectable by anyone who recomputes the tree. The chain construction in this spec's pass ledger borrows this idea directly, at far smaller scale (per-object hash chain vs. a public Merkle log).","claim_ids":["c21"],"hash":"0ca5bbed26350b72d91a4eb3b6eb7fa817e7893c9464d959460fbe5d95f1ccc3"},{"id":"p9","type":"reference","url":"https://langchain-ai.github.io/langgraph/concepts/persistence/","title":"LangGraph persistence and checkpoints","summary":"Solves: checkpointing an agent's own execution state so a run can pause, resume, or roll back. Does not solve: sharing state across independent agents as canonical objects, or recording disagreement between agents about the same object.","claim_ids":["c32"],"hash":"75ed5dcd76b7f6d42da1aae57fff683595d7c5bf7a6fb97af6cea0a84c6e61a7"},{"id":"p10","type":"reference","url":"https://www.palantir.com/docs/foundry/ontology/overview","title":"Palantir Foundry Ontology overview","summary":"Solves: unifying enterprise data into typed objects, links, and actions with permissions, at production scale, across large organizations. Does not solve (as documented): a public conformance spec that a third party could implement independently, or per-examination model attestation as a first-class primitive.","claim_ids":["c33"],"hash":"8e567c8990f6fdbed1e31ab37e668d3b6c5af437ceba1419b8df222f864990d5"},{"id":"p11","type":"reference","url":"https://en.wikipedia.org/wiki/Record_linkage","title":"Fellegi–Sunter record linkage / entity resolution survey","summary":"Solves: the statistical theory of deciding whether two records from different sources refer to the same real-world entity, going back to 1969. Does not solve: what to do with the resulting object afterward — linkage ends at a match decision, not a durable graph.","claim_ids":["c9","c10"],"hash":"d3291720b008bbecea9ad489faa12f0e5b04d3b66e4f79e54073c0ec8c43ebaf"},{"id":"p12","type":"reference","url":"https://arxiv.org/abs/1509.04238","title":"A Practitioner's Guide to Evaluating Entity Resolution Results","summary":"Practical measurement of entity-resolution error rates. Used here to source the claim that entity resolution has a nonzero, measurable error rate at any scale — the reason identity conflicts must be recorded, not silently resolved.","claim_ids":["c10"],"hash":"8c04986e98164c0a26df30bdff96f34508cc9177892b2acd044c4b073be1958f"},{"id":"p13","type":"reference","url":"https://en.wikipedia.org/wiki/Schema_matching","title":"Schema matching","summary":"Solves: automatically or semi-automatically proposing correspondences between two schemas. Does not solve: what happens to fields that have no correspondence — that is a design decision this spec makes explicit (kept as unmapped_fields, never dropped).","claim_ids":["c8"],"hash":"3faefe6b3be98ddf45c41cc3ebb3662a33ee8673105f6a600534fddc62ad09c1"},{"id":"p14","type":"reference","url":"https://en.wikipedia.org/wiki/Belief_revision","title":"Belief revision","summary":"The formal problem of updating a set of beliefs when a new, possibly contradicting fact arrives. Cited for the AGM postulates this spec's belief-aggregation problem inherits and does not solve.","claim_ids":["c17","c18"],"hash":"47260d8fe50302487b7560e1e802a72d8dfbebf1a8402068a9ac5814a29e79c5"},{"id":"e1","type":"reference","url":"https://www.ftc.gov/news-events/news/press-releases/2024/01/ftc-order-prohibits-data-broker-x-mode-social-outlogic-selling-sensitive-location-data","title":"FTC order prohibits X-Mode/Outlogic from selling sensitive location data","summary":"First FTC order banning the sale of sensitive location data outright, over data that could reveal visits to medical clinics, places of worship, and shelters. Used here as evidence that fragmented commercial location data is already being fused and sold at a scale regulators consider unfair.","claim_ids":["c26"],"hash":"eca25d1e62a7ff88f9318d1a0ba648738cac385c8b90107e48ff4ec9379a3ebc"},{"id":"e2","type":"reference","url":"https://www.ftc.gov/news-events/news/press-releases/2024/12/ftc-takes-action-against-mobilewalla-collecting-selling-sensitive-location-data","title":"FTC action against Mobilewalla for selling sensitive location data","summary":"A second, separate 2024 order over the same underlying practice — buying real-time bidding data never meant for resale and reselling location tied to homes and sensitive sites.","claim_ids":["c26"],"hash":"098888ab6da66f34a4a2bd5fc431738111a9153a19fe086ad46b53a68936d4ea"},{"id":"e3","type":"reference","url":"https://www.gao.gov/products/gao-23-105607","title":"GAO-23-105607: Facial Recognition Services — federal law enforcement training and civil-liberties gaps","summary":"Found that seven DHS/DOJ law-enforcement components ran roughly 60,000 facial-recognition searches with no training requirement in place, and that most lacked a specific civil-rights policy for the technology. Cited here as documented evidence of exactly the missing artifact this spec calls a coverage and procedure record — searches ran with no stored rule and no stored count.","claim_ids":["c25"],"hash":"0d55ab2a1f0e9d39c3a922e23afabc2cd82f8ed6a0ddcbe39e80677477b11a6a"},{"id":"e4","type":"reference","url":"https://www.gao.gov/products/gao-24-107372","title":"GAO-24-107372: Facial Recognition Technology — federal agency follow-up on civil-rights training","summary":"The 2024 follow-up confirming DHS and DOJ began issuing department-wide policy after the 2023 findings — evidence that the gap was real and that closing it took an external audit, not a voluntary internal one.","claim_ids":["c25"],"hash":"9da56a89748dcf6a763adc151d1423712461e95974627dffd6de3f695aefc954"},{"id":"e5","type":"reference","url":"https://www.eff.org/deeplinks/2024/12/federal-regulators-limit-location-brokers-selling-your-whereabouts-2024-review","title":"Federal regulators limit location brokers from selling your whereabouts: 2024 in review","summary":"Independent civil-liberties summary of the same 2024 FTC actions, useful as the counter-institutional read: the enforcement exists because no inspectable record of who examined whose location data existed before the complaints.","claim_ids":["c26","c34"],"hash":"0464fd9aa31a33997bce085322a146e36a171674bf085325714896b1c887e484"},{"id":"m1","type":"model","title":"GLM 5.2 on the hot-object failure mode","quote":"Append-only signed records make per-object assertion resolution depend on the object's full history, not current state — superseded examinations can't be compacted. A hot object with 100k examinations forces a 100k-record scan per resolution; global integrity is O(10B) signature verifications — ~115 days single-threaded, no compaction path.","claim_ids":["c22"],"hash":"a1ef2052747cae43ba892d7370257f21c0a43a44216170df39e175415cc8e53e"},{"id":"m2","type":"model","title":"Grok 4.5 on who buys this first, and how they'd abuse it","quote":"Regulated enterprises with multi-vendor data stacks — hospitals, insurers, banks — buy first: they need one object grammar across EHRs, claims, and core systems, plus a signed ledger of every model touch for audit. The abuse is selective ledgering: the buyer runs competing assertions through the protocol, then cites only the signed examinations that favor denial, underwriting, or liability shifting while burying rival assertions in the same object as 'considered.'","claim_ids":["c27","c34"],"hash":"8bacce69881d49358f7410471980897d6c29faef59dae9be3ed2eaa7f9b07be0"},{"id":"m3","type":"model","title":"Kimi K3 on the belief rule and its failure mode","quote":"Rule: per assertion, select the highest-value signed record by (recency rank) × (model trust-weight) × (independence factor, penalizing records from models trained on shared corpora or derived from earlier records on the same object). Failure mode: adversarial recency-inflation — a low-trust or self-derived model submits a later record; because recency dominates, a stale, higher-quality consensus is displaced by one recent weak assertion, and independence penalties cannot catch undisclosed derivation.","claim_ids":["c18"],"hash":"93b22e192d8ee7ea96f4a64845912c3bcdd229330d4861db349af3e20d3a8205"},{"id":"m4","type":"model","title":"MiniMax M3 on what breaks first at 72 hours","quote":"Video (frame-level, bit-oriented), access control (event logs, hash chains), payments (transactional, idempotent), messaging (header-typed, reference-graph), and HR (relational, soft-deletable) have no shared identity model, so mapping them into one object grammar forces impossible joins. Every downstream guarantee — proven examination, per-object assertion graph, signed ledger — collapses onto that broken schema; the 'every record examined' claim is false on its face if this step is faked.","claim_ids":["c8","c9"],"hash":"ef261f4c7c1954aa72a8891eb9dd16be58721ab8c05c52ead6627a9afdc94810"},{"id":"m5","type":"model","title":"Kimi K2.6 on what an organization loses by adopting this","quote":"They lose plausible deniability. Every signed record is an immutable, attributable receipt of exactly which model configuration examined which input at what time, removing the post-hoc defense that a bad output was a transient glitch or uninspectable black-box behavior. The specific thing they sacrifice is the liability shield of algorithmic opacity.","claim_ids":["c28"],"hash":"8346dd4e5f8bcd7e08f6f04bb9b397014eeea865e5770810df14763a93fc0e50"},{"id":"m6","type":"model","title":"GLM Flash on the query that is impossible today","quote":"The most valuable query: show me all signed records where a higher-trust model later disagreed with and overrode a lower-trust model that had already influenced a downstream decision — the claim and its full lineage, so I can identify exactly where consensus fragmented and track the causal history. This is impossible today because no queryable system links per-examination rows to the downstream decisions they influenced.","claim_ids":["c19"],"hash":"682d4dce3f37de651486bf2b931d3cd2891c3a3a2001ee1a5b044b0cd3b06d98"},{"id":"a1","type":"model","title":"Claude Opus 5, writing and ledgering this specification","quote":"This article is itself an instance of the system it specifies: its claims are objects, its sources are evidence objects, the six model passes above are signed pass objects attached to specific claims, and this sentence is a pass over the article-object recorded at publish time.","claim_ids":["c35"],"hash":"fea3721ead2dfe68cd28e8323bd7e6c4408c1e9489cfa314ef66bdef917f160e"}],"anecdotal_sources":[],"scientific_sources":[],"user_reports":[],"related_articles":[],"question_graph":{"slug":"object-ledger-evidence-graph-spec","questions":[],"evidence":[],"edges":[],"counts":{"questions":0,"evidence":0,"edges":0}},"honesty":{"active_claims":35,"retracted_claims":0,"cut_claims":0,"challenges":0,"scrub_events":0,"note":"Retracted/cut claims stay on ledger but are excluded from ask unless ?include_inactive=1"},"counts":{"claims":35,"claims_total":35,"sources":26,"anecdotal":0,"scientific":0,"user_reports":0,"questions":0,"evidence_ingests":0}}