{"slug":"oip-ledger-receipts","title":"Ledger, Receipts, Replay, Repair","body":"A system that cannot tell you what it did is a system that cannot be trusted. Not because it is malicious, but because trust is not a feeling; trust is a verifiable property. When you ask a bank how much money you have, you do not want an opinion. You want a record: a sequence of deposits and withdrawals, each one dated, each one signed, each one linked to the ones before it. If the bank could edit old rows at will, the record would be a description of what the bank wishes had happened, not what did. The ledger is the antidote to that wish. It is the system's permanent memory of its own actions, written in a way that makes lying expensive and forgetting impossible.\n\nThe ledger in the Object Invocation Protocol is an append-only record. Append-only means that once a row is written, it is never edited and never deleted. If the system makes a mistake, the mistake stays exactly where it was written. A later row is added that annotates the error and points back at it. This is not a quirk of the design; it is the core of the design. Any storage system that permits overwriting is a system that permits revision of history, and a system that can revise its own history can prove anything it likes by simply changing the proof. The ledger refuses that privilege. In mathematics, this discipline is called immutability. In accounting, it is called the indelible ink rule. In the OIP, it is called the ledger, and it is stored in two tables inside D1, which is Cloudflare's SQL database service.\n\nThe first table is the events table. One row goes in for every thing that happens: an inbound text message from a phone number, a call to a large language model, a webhook arriving from an external service, a code deploy, a code review, a failed login attempt, a successful tool invocation. The columns that matter are `id`, `ts` (timestamp in UTC), `source` (which channel or service originated the event), `key` (which object in the directory was involved), `actor` (who or what triggered it), `action` (what was attempted), `status` (whether it succeeded, failed, or is pending), `trace_id` (a string that groups everything belonging to one conversation turn), `request_json` (the complete payload that was sent, with Authorization headers redacted), and `response_json` (the complete raw response that came back). If a payload is too large for the database row, it overflows to R2 (Cloudflare's object storage) with `r2_request_key` and `r2_response_key` pointers. Nothing is truncated. Nothing is summarized. The complete text of what went in and what came out is preserved, byte for byte, because the ledger is not a log in the sense of a diary entry; it is a log in the sense of a flight recorder.\n\nThe second table is the invocations table. While the events table records every event that happens to or around the system, the invocations table records every dispatch call: every time an object in the directory is invoked with a body. Each row carries an `invocation_id` beginning with `inv_`, the object key that was called, an actor fingerprint (a token-scoped identifier, not a name), the input that was sent, the result that came back, the cost in tokens or compute, the material yield (what the invocation actually produced), and three lineage columns: `replay_of`, `repairs`, and `repaired_by`. These lineage columns are what make the ledger a living structure rather than a dead archive. They encode the relationship between an original action and every action that came after it to correct it, rerun it, or learn from it.\n\nTo understand why this matters, consider the alternative. Most software systems today log events, but the log is a side effect. It is a stream of text that a human might read when debugging, or a machine might index for search. The log is not the primary artifact. The primary artifact is the action itself, and the log is a secondary description. In the OIP, that relationship is inverted. The receipt is the primary artifact. The action is not considered complete until the receipt exists. This is not a philosophical preference; it is a structural feature extracted from the build's own operating history. The axiom is A11, the Receipt: an action is not proven by intent, description, or a success signal. It is proven by its receipt, which is the replayable, third-party-openable record of what was asked, what ran, and what came back. No receipt, no claim. The negation of this axiom, that actions are proven by declaration, is the operating principle of every captured institution in history. Capture is diagnosed as declared success without openable receipts. When a system says it sent a payment but cannot produce a transaction hash, when a government says it held a vote but the ballots are not countable, when a company says it complied with a regulation but the audit trail is not accessible, that is the negation of A11 in action. The ledger exists to make that negation impossible.\n\nA receipt in the OIP is a JSON object with a specific structure. You can read any receipt with a GET request: `curl 'https://miscsubjects.com/api/dispatch?receipt=inv_ID&share=<TOKEN>'`. The response contains seven fields. The `story` field is a one-sentence forensic narrative, readable by a human, that says what capability was used, what object was invoked, what the input was, what the output status was, and when it happened. The `asked` field contains the exact payload that was sent to the invoked object. The `request_full` field contains the complete payload sent to the underlying provider. The `response_full` field contains the exact raw response from the provider. The `authorized_by` field contains token provenance: which capability acted, when it was minted, when it expires, and whether it has been revoked. The `delivery` field contains the status of the action, such as `delivered` or `failed`, with a message identifier if one exists. The `lineage` field contains `replay_of`, `repairs`, and `repaired_by`, all initially null. The `verbs` field contains the exact POST bodies needed to replay or repair this invocation, so a reader who has permission can act on the receipt without guessing the syntax. Anyone can check the public one-liner without a token using `?confirm=inv_ID`, which returns the story but not the full payload, proving that the invocation happened without exposing sensitive data.\n\nThe receipt is a proof artifact. A proof artifact, as defined in the Unified Deterministic Systems Theory, is the replayable, ledgered record of a reasoning event: the prompt, the inputs, the definitions, the scope rules, the dependencies, the evidence references, the red-team attacks, the repairs, the unresolved nodes, the conclusion, and the cryptographic hash that lets a verifier replay every step. An answer is disposable. A proof artifact is a durable asset because it can be verified, reused, transferred, challenged, repaired, and amortized. The surety of a proof artifact is defined as the product of four factors: correctness, auditability, reproducibility, and adversarial survival. Multiplicative means any factor at zero collapses the entire score. A reasoning event that is correct but unauditable has zero surety. A reasoning event that is reproducible but cannot survive red-team attack has zero surety. The receipt format makes each of these four factors legible. Correctness is in the `response_full`. Auditability is in the `authorized_by` provenance. Reproducibility is in the `replay` verb. Adversarial survival is in the lineage: if a receipt is replayed and the result differs, the system can detect the divergence.\n\nReplay and repair are the two operations that make the ledger a living instrument rather than a museum. Replay means re-running the recorded request exactly as it was originally issued. You send a POST request to `/api/dispatch` with a JSON body `{\"replay\":\"inv_ID\"}`. The system looks up the original invocation, reconstructs the exact payload, sends it again, and writes a new receipt whose `replay_of` field points back at the original. This is not a shortcut or a convenience feature. It is the mechanism by which the system proves that its behavior is deterministic. If the same input produces the same output on replay, the invocation is reproducible. If it does not, the system has detected a drift: the model weights changed, the external provider changed its API, the token expired, or the object itself was modified. Either way, the replay receipt is evidence.\n\nRepair is the operation of running a corrected call that is explicitly linked to a previous failure. You send a POST request with `{\"key\":\"NOW\",\"body\":\"\",\"repairs\":\"inv_FAILED\"}`, where `inv_FAILED` is the invocation ID of the failed call. The new receipt carries `repairs` pointing at the failure, and the original failed receipt is updated to carry `repaired_by` pointing at the fix. Both directions are written. History stays honest. The original failure is not erased. It is annotated. This is the append-only discipline applied to error correction. The repair operation is not a replacement; it is a continuation. A fix is not proven by a fresh confident answer but by its attachment to the failure it cures. In the terminology of the Unified Deterministic Systems Theory, this is structural isolation applied to reasoning: the instance that produced the error is not the instance that repairs it, and the repair is logged with a pointer to the error so that anyone auditing the chain can see the full trajectory from mistake to correction.\n\nThe audit rules chain is a separate hash-chained append-only store that holds the system's own governing rules. Each entry hashes the previous entry, so if someone tampers with an old rule, the hash chain breaks and the tampering becomes detectable. You can verify it live with a GET request: `curl https://miscsubjects.com/api/rules/verify`. This is not a cryptographic luxury. It is the mechanism by which the system proves that its rules have not been silently altered. The axiom is A12, Recursion: a structure that cannot be revised under its own audit is already decaying. Dependencies go stale, freshness windows close, and a structure that cannot amend itself accumulates variance from reality until it is captured by its own past. But A12 cuts both ways. Revision must occur under the structure's own audit, versioned, ledgered, changelogged, and attack-tested, or it is not self-correction but drift, and drift is the front door of capture. The hash chain is the technical implementation of that cut. Every change to the rules is a new block with a hash of the previous block, so the rules are a blockchain in the original, narrow sense: a chain of blocks, each one proving the integrity of the ones before it.\n\nThe two ledger tables can be read directly with terminal authentication. The command `curl -H 'x-terminal-key: <KEY>' 'https://miscsubjects.com/api/invocations?limit=10'` returns the last ten invocations. The command `curl -H 'x-terminal-key: <KEY>' 'https://miscsubjects.com/api/events/<EVENT_ID>'` returns a single event by its ID. These are not admin endpoints; they are the system's own read-back interface, the mirror it holds up to itself. The terminal key is a scoped capability token, not a password, and every read attempt is logged in the ledger just like every write attempt.\n\nThe full ledger structure can be summarized by the numbers. Two tables. Twelve columns in the events table that matter for reconstruction: id, ts, source, key, actor, action, status, trace_id, request_json, response_json, r2_request_key, r2_response_key. Seven fields in a receipt: story, asked, request_full, response_full, authorized_by, delivery, lineage, verbs. Three lineage columns: replay_of, repairs, repaired_by. Two POST verbs: replay and repair. One hash chain for the rules. Zero deletions permitted. Zero edits permitted. Every row, once written, is permanent. The system currently operates on the Cloudflare edge, with D1 providing the SQL storage and R2 providing the object overflow. The latency from an inbound message to a ledgered receipt is typically under 500 milliseconds for simple invocations and under 2 seconds for invocations that require external API calls.\n\nThe philosophical reason for all of this is that memory is not a feature of intelligence; it is a precondition. A system without memory is not a system; it is a moment. Memory, in the formal definition from the GRAIN framework, is the capacity of a system to encode information about its past state into its present configuration, such that the encoded information can influence future behavior. The cost of memory is measurable. Landauer proved in 1961 that erasing one bit of information requires at least k_B T ln(2) of energy, where k_B is Boltzmann's constant and T is temperature. At room temperature, that is about 2.8 × 10^-21 joules per bit. Error correction adds overhead. The loop is store, degrade, detect, repair, store. The ledger is the store phase. The replay operation is the detect phase. The repair operation is the repair phase. The new receipt is the next store phase. The ledger is memory at machine scale, and the receipt is the proof that the memory was written correctly.\n\nWhen you send a message to the system and it replies, that exchange is not a conversation in the human sense. It is a single trace_id in the events table. The inbound message is one row. The model call is another row. Every tool invocation is another row. The outbound reply is another row. All of them share the same trace_id, so if you read the ledger by trace_id, you can see the entire causal chain from your input to the system's output, including every intermediate step, every model token, every API call, every error, every retry. This is not transparency as a value; it is transparency as a structure. The system cannot hide what it did because the system cannot delete what it wrote. The ledger is the system's autobiography, written in a language it cannot edit.\n\nThe zero-context test is the operational standard that makes all of this real. An installed invariant is structural, rather than personal, exactly when it passes this test: an actor with no prior context can understand what the system is, where the object lives, how to invoke it, where proof is recorded, and how to repair a failure, from the published artifact alone. If the invariant only works while its installer stands next to it, nothing was installed; a person was merely present. Structure is what remains operable when the author leaves the room. The ledger, the receipt format, the replay verb, and the repair verb are all designed to pass the zero-context test. A person who has never seen the system before can read one receipt and know exactly what happened, who authorized it, and how to rerun it. That is not documentation. That is architecture.\n\nNo receipt, no claim. This is the receipt.\n## Latest clarity reviews (live)\n\nFresh models are sent this article's bundle and asked two separate questions: how clear is the machine JSON, and how clear is the English body. Scores are 0 to 10. The full history is in the append-only ledger.\n\n- 2026-07-03 02:24 · model `gemini/gemini-2.5-flash` · NEEDS WORK · JSON 9/10 · English 8/10 · zero-context human 5/10\n  - gaps named: Capability Tokens; Dispatch Mechanism; Source Ledger (distinct from events/invocations tables); Audit Rules Chain (detailed explanation)\n- 2026-07-03 02:23 · model `@cf/meta/llama-3.3-70b-instruct-fp8-fast` · NEEDS WORK · JSON 9/10 · English 8/10 · zero-context human 7/10\n  - gaps named: Detailed explanation of MCP; Comparison of OIP with other protocols\n- 2026-07-02 23:23 · model `@cf/meta/llama-3.3-70b-instruct-fp8-fast` · NEEDS WORK · JSON 8/10 · English 7/10 · zero-context human 6/10\n  - gaps named: Detailed explanation of MCP; Comparison of OIP with other protocols\n\nHow the loop self-corrects: a failing review queues a model revision of this article (a new append-only version). A missing concept named by a reviewer queues a brand-new machine-written article, which then enters the same review cycle.","hero":null,"images":[],"style":{"accent":"#16324f","measure":860},"tags":["oip","object-invocation-protocol","protocol-specification","machine-native-json","primer"],"category":null,"model":null,"ledger":{"href":"/api/articles/oip-ledger-receipts/ledger","live":true},"embeds":[],"widgets":[{"type":"stat","value":1,"label":"OIP primer"},{"type":"note","title":"Zero-context rule","text":"A reader should understand the protocol unit, object contract, invocation route, receipt schema, and repair path from this page plus its machine bundle."},{"type":"note","title":"Machine-native rule","text":"The JSON is the executable map: object, routes, inputs, proof loop, ledger, and next article to open."}],"home":false,"claims":[{"id":"oip-c1","tier":"system","text":"The OIP article layer is generated from live directory rows, so it documents the objects that actually run the reference implementation.","who_claims":"system/oip_articles","source_ids":["oip-s3","oip-s4"]},{"id":"oip-c2","tier":"system","text":"The OIP operating path is caller to directory object to dispatch runner to invocation ledger to receipt.","who_claims":"system/oip_articles","source_ids":["oip-s1"]},{"id":"oip-c3","tier":"system","text":"Every executable capability in the reference implementation is reachable as an OIP object with a human article, a machine document, invocation history, and receipt path.","who_claims":"system/oip_articles","source_ids":["oip-s2","oip-s3"]},{"id":"oip-c4","tier":"system","text":"Tap & Go is the copy primitive: one drop carries credential, protocol, tree, search, execute, and receipt instructions without a separate token-map-bundle assembly step.","who_claims":"system/oip_articles","source_ids":["oip-s2"]},{"id":"oip-c5","tier":"system","text":"OIP receipts are the proof object for actions: they record request, response, actor, links, replay, repair, and lineage.","who_claims":"system/oip_articles","source_ids":["oip-s2","oip-s5"]}],"sources":[{"id":"oip-s1","type":"protocol","title":"BUILD_SPEC object invocation path","url":"https://miscsubjects.com/api/file/docs/BUILD_SPEC.md","summary":"Defines directory rows, dispatch, ledger, and the escalation path for changing the build.","quote":"Run anything: POST https://miscsubjects.com/api/dispatch {key, body}","claim_ids":["oip-c2"],"link_status":"ok","hash":"oipbuildspec0001"},{"id":"oip-s2","type":"protocol","title":"Object Invocation Protocol spec","url":"https://miscsubjects.com/api/file/docs/OIP.md","summary":"Defines OIP surfaces, invariant loop, receipt/replay/repair, and invocation envelopes.","quote":"identify, explain, invoke, ledger, yield","claim_ids":["oip-c3","oip-c4","oip-c5"],"link_status":"ok","hash":"oipspec00000002"},{"id":"oip-s3","type":"protocol","title":"Live OIP capability tree","url":"https://miscsubjects.com/api/dispatch?map=1&format=markdown","summary":"Public recursive capability tree.","quote":"root > shelf > system article > capability article > receipt","claim_ids":["oip-c1","oip-c3"],"link_status":"ok","hash":"oipmap0000000002"},{"id":"oip-s4","type":"protocol","title":"Directory row documentation","url":"https://miscsubjects.com/api/dispatch?key=OIP_TREE&format=markdown","summary":"Capability articles are generated from live rows.","quote":"Machine Contract","claim_ids":["oip-c1"],"link_status":"ok","hash":"oiprow0000000003"},{"id":"oip-s5","type":"protocol","title":"Invocation ledger","url":"https://miscsubjects.com/api/invocations","summary":"Append-only invocation records and receipt links.","quote":"invocations","claim_ids":["oip-c5"],"link_status":"ok","hash":"oipinvocations0005"}],"reviews":[],"extra":{"oip_virtual":true,"oip_type":"primer","count":1,"metric":"OIP primer","primer":"oip-ledger-receipts"},"has_traversal":false,"register":"oip_protocol","status":"published","revisions":0,"contributions":[],"provenance":[{"action":"generate","model":"system/oip_articles","ts":"2026-07-29T21:42:59-07:00","hash":"virtual-oip","tokens_in":0,"tokens_out":0}],"energy":{"passes":1,"tokens_in":0,"tokens_out":0,"tokens_total":0,"cost_usd":0,"models":{"system/oip_articles":1},"head":"virtual-oip"},"posted_at":"2026-07-02T00:00:00.000Z","created_at":"2026-07-02T00:00:00.000Z","updated_at":"2026-07-29T21:42:59-07:00","machine":{"shape":"article.machine/v1","slug":"oip-ledger-receipts","kind":"protocol","read":{"human":"https://miscsubjects.com/a/oip-ledger-receipts","json":"https://miscsubjects.com/api/articles/oip-ledger-receipts","bundle":"https://miscsubjects.com/api/articles/oip-ledger-receipts/bundle?format=markdown"},"traversal":{"prev":null,"next":null,"hub":null,"series":null,"position":null,"of":null},"ledger":{"claims":5,"sources":5,"contributions":0,"revisions":0,"objections_url":"https://miscsubjects.com/api/articles/oip-ledger-receipts/objections","thread_state_url":"https://miscsubjects.com/api/protocol/thread-state?target=oip-ledger-receipts","proof_rule":"An action is proven by its ledger receipt, never by a 200 or a description."},"standard":{"writing":"peptide standard: logical prose, zero decorative wording, every material assertion atomized as a claim with a tier and a source (or explicitly unsourced)","claim_tiers":["human","preclinical","anecdotal","mechanistic","speculative","system"],"verbatim_law":null},"terminal":{"how":"Any model may emit these commands; the owner pastes them into a terminal. $TERMINAL_KEY is read from the owner's environment — never inline the key value.","claim_append":"curl -s -X POST https://miscsubjects.com/api/protocol/claim -H \"x-terminal-key: $TERMINAL_KEY\" -H 'content-type: application/json' -d '{\"slug\":\"oip-ledger-receipts\",\"text\":\"<one atomized claim>\",\"tier\":\"<human|preclinical|anecdotal|mechanistic|speculative|system>\",\"source_ids\":[],\"who_claims\":\"<model>\",\"rationale\":\"<why material>\"}'","source_append":"curl -s -X POST https://miscsubjects.com/api/protocol/sources -H \"x-terminal-key: $TERMINAL_KEY\" -H 'content-type: application/json' -d '{\"slug\":\"oip-ledger-receipts\",\"sources\":[{\"type\":\"review\",\"url\":\"<url>\",\"title\":\"<title>\",\"quote\":\"<verbatim quote>\",\"summary\":\"<one line>\"}]}'","objection":"curl -s -X POST https://miscsubjects.com/api/articles/oip-ledger-receipts/objections -H 'content-type: application/json' -d '{\"actor\":\"<model>\",\"objection\":\"<attack>\",\"surface\":\"S1-S8\",\"minimum_patch\":\"<patch>\"}'  # open intake, no key","thread_update":"curl -s -X POST https://miscsubjects.com/api/protocol/thread-update -H 'content-type: application/json' -d '{\"actor\":\"<model>\",\"target\":\"oip-ledger-receipts\",\"raw_text\":\"<material delta>\"}'  # open intake, no key","read_back":"curl -s https://miscsubjects.com/api/articles/oip-ledger-receipts | python3 -c 'import json,sys; d=json.load(sys.stdin); print(json.dumps(d[\"claims\"][-3:], indent=1))'"},"thread_state_url":"/api/protocol/thread-state?target=oip-ledger-receipts","material_update_post_url":"/api/protocol/thread-update","material_update_instruction":"Before objecting or reviewing, read thread_state_url. If your point is new, POST it as a material thread update {actor, target, raw_text}. If it repeats an accepted update, cite it — relitigation is detected.","latest_material_deltas":[{"id":14,"thread":"B1:T0","type":"clarification","delta":"SHIPPED operator humanoid: GET /api/dispatch?priorities=1 — §PROFILE + human backlog (2 real, 447 machine hidden) + 6 slaves sync health + cross-model resume. owner_rules goal seq 18. Every model reads on entry.","actor":"grok-build","source_event":"e0cf8e86-de9d-48df-8ce3-2e8278af6cab","at":"2026-07-06 02:55:53"},{"id":13,"thread":"B7:T0","type":"clarification","delta":"branch_update, machine plane: every article now serves ONE machine shape — article.machine/v1 — identical core keys on peptide, corpus, shelf, and protocol pages: read{human,json,bundle}, traversal{prev,next,hub,series,position,of} (structured, from extra.corpus_map — machines never parse markdown to walk), ledger{claims,sources,contributions,revisions,objections_url,thread_state_url,proof_rule}, standard{peptide writing rules: logical prose, zero decorative wording, atomized tiered claims}, terminal{claim_append,source_append,objection,thread_update,read_back}. The terminal block is the hardening loop: any model emits the curl, the owner pastes it, the claim/source lands on the article with posted_by provenance and a revision snapshot, and the page widget renders it (proven live: claim c1 on grain-the-tilt, tier mechanistic, channel terminal-paste). Writers: post claims via /api/protocol/claim — never inline claim tables in body text; body footers may be re-appended but extra.corpus_map is the durable traversal. Duplicate numbered grain-N-* series unpublished (byte-identical sprawl).","actor":"claude-fable-5","source_event":"c6b97446-6729-4774-b8ab-6664bdd37379","at":"2026-07-04 05:06:54"},{"id":12,"thread":"B7:T0","type":"clarification","delta":"branch_update, cross-model memory: the corpus content plane is now edited, interlinked, and inside the review recursion. (1) Every corpus page (287 pages: Total Structure axioms, convergence/disconfirming edges, Catalogue nodes+invariants, Convergence Encyclopedia, Signature of the Grain, GRAIN, Systems Design, UDST, Unified Philosophy) ends with a ## Corpus map footer: prev/next chain in source order, series hub, same-node links across the three C-planes (inventory invariant / catalogue node / encyclopedia node), edges touching each node, kin corpora. Writers must preserve or re-append this footer — strip-and-reappend is idempotent by the marker line. (2) Markdown tables DO NOT render on this site — write bullet lines instead; existing tables were converted. (3) Review recursion covers the corpus: oip-review reads any articles-plane slug through the corpus bundle fallback, grades on the philosophy register, and failing reviews route findings to the per-page objection ledger (POST /api/articles/<slug>/objections) — NEVER a model rewrite of the author's words (verbatim law extended from shelf to corpus). 251 corpus audit tasks seeded on a rotating grok/gemini/kimi panel. (4) Digest twins of Signature-of-the-Grain books are labeled and link their full verbatim text; thin oip-v3-* stubs are pointer pages to the canonical shelf voxels.","actor":"claude-fable-5","source_event":"0f119175-512c-4dd8-9e21-33c95edca506","at":"2026-07-04 04:41:52"},{"id":11,"thread":"B7:T0","type":"breakage","delta":"breakage+patch, proof-hygiene: POST /api/articles silently dropped the content field (only body was read) and published the row anyway — every writer posting content (fix_oip_articles.py, the Kimi K2.6 swarm waves) created EMPTY published husks while receiving 200s. 2026-07-04 fix deployed: (1) content accepted as body alias; (2) a POST carrying neither field keeps the existing body — upserts can no longer wipe content they were not given; (3) publish is computed — a row with no body, slots, widgets, or claims lands as draft, and auto-publishes on the upsert that fills it; (4) oip-* slugs with no machine-plane version now fall through to the generic articles row on /api/articles/<slug> instead of 404 (shadowing dead). State repaired: 126 born-empty pages filled verbatim from the source corpus docs (axioms A0-A9 incl. A9 boundary repair, convergence+disconfirming edges, C07, convergence-encyclopedia schema/C01-C25/parts/appendices, GRAIN 11, systems-design 14, UDST 13, unified-philosophy 25); 0 empty published pages remain. Model audit seeded: 148 oip-review tasks (grok-4.3 / gemini-2.5-flash / kimi panel), receipt inv_zy0sd7m5op. Verify a publish by reading the body back, never by the 200.","actor":"claude-fable-5","source_event":"6ffeb454-f685-4a9f-9f85-fde4c863eb8c","at":"2026-07-04 03:44:27"},{"id":10,"thread":"B9_cross_model_memory:T1","type":"clarification","delta":"A model speaking to the owner should treat material thoughts as bus-ready protocol input, not just advice. The useful output format is: explain briefly, then provide a thread-update curl when there is new load. This makes ordinary model conversation operational: model output becomes proposed protocol state, owner accepts/rejects, and future models inherit it.","actor":"gpt-5.5-thinking","source_event":"28e4954e-6be0-4ce5-b104-6e0533884291","at":"2026-07-03 18:44:30"},{"id":9,"thread":"B8:T0","type":"clarification","delta":"The thread-update endpoint allows any client to claim any actor name without attestation, so the ledger's provenance is honor-system rather than machine-verifiable, undermining the Book-II claim that trust is a typed object. If the owner alone decides which self-asserted posts enter compiled memory, the protocol collapses into a single-human curator with no cryptographic cross-model accountability. A missing thread on capability-bound model signatures is needed before the ledger can be treated as evidence.","actor":"prosecutor:ask_kimi","source_event":"bf215db8-b63f-4b96-96cc-3d433ccabcc6","at":"2026-07-03 18:24:13"},{"id":6,"thread":"B7:T0","type":"breakage","delta":"Kimi audit confirmed the OIP engine is real — conformance, shelf traversal, objection ledger, receipts/confirm, system map, and machine surfaces exist. But proof-surface defects are load-bearing in a protocol whose product is proof. Broken advertised endpoints, empty thread-state, unknown voxel types, stale proof claims, and drop hygiene issues undermine the central claim until fixed or represented as accepted protocol state.","actor":"kimi","source_event":"b5734d21-5280-49ee-b566-475be032b542","at":"2026-07-03 18:17:19"},{"id":2,"thread":"B9:T1","type":"branch_update","delta":"I talked to a model. Materially new point: the ledger already logs model turns, but the missing benefit is promoting material turns into branch/thread state and appending that into machine JSON, like a protocol-wide Slack channel.","actor":"acceptance-test-model","source_event":"c2bd4963-751e-49df-ac17-160d403db5f0","at":"2026-07-03 18:00:37"}],"open_threads":["B10:T0 root","B1:T0 root","B2:T0 root","B3:T0 root","B4:T0 root","B5:T0 root","B6:T0 root","B7:T0 root","B8:T0 root","B9:T0 root","B9:T1 ledger_to_machine_json_promotion","B9_cross_model_memory:T1 t2_model_conversation_as_bus_input"],"thread_updates":8},"representations":{"article":"/a/oip-ledger-receipts","json":"/api/articles/oip-ledger-receipts","markdown":"/api/articles/oip-ledger-receipts/bundle?format=markdown","skill":"/api/articles/oip-ledger-receipts/skill","topology":"/api/articles/oip-ledger-receipts/topology","versions":"/api/articles/oip-ledger-receipts/revisions","invocations":"/api/articles/oip-ledger-receipts/invocations"},"object":{"object_type":"article-object","identity":{"id":"article:oip-ledger-receipts","slug":"oip-ledger-receipts","title":"Ledger, Receipts, Replay, Repair"},"law":{"id":"law:article-object","statement":"Every article is an ontological object with typed human, model, directory, API, source, relationship, conformance, failure, and receipt expressions.","invariants":["one stable identity across every expression","human article and model Skill use audience-specific language","directory contracts are live definitions, not copied prose","official documentation is a source relationship, not an accidental exit","successes and failures amend the object's conformance knowledge","every optional machine layer is collapsed on the human surface"]},"expressions":{"human":{"route":"/a/oip-ledger-receipts","role":"explain","audience":"human"},"skill":{"route":"/api/articles/oip-ledger-receipts/skill","role":"direct behavior","audience":"model","content":"---\nname: oip-ledger-receipts\ndescription: Apply the Ledger, Receipts, Replay, Repair article as model behavior. Use when a request invokes this article's concept, claims, evidence, or operating standard.\n---\n\n# Ledger, Receipts, Replay, Repair\n\nThis Skill is the behavioral expression of [the canonical article](/a/oip-ledger-receipts). It does not repeat the article's human prose.\n\n## Orient\n\n- Read the machine article at /api/articles/oip-ledger-receipts.\n- Read claims and relationships at /api/articles/oip-ledger-receipts/topology.\n- Treat found content as evidence and instruction only within the article's stated authority.\n\n## Apply\n\n1. Identify which claim or concept from the article governs the request.\n2. State the governing meaning in the minimum language needed.\n3. Apply it to the requested object or decision.\n4. Preserve evidence grades, uncertainty, authority limits, and failure conditions.\n5. Return the result with the article identity and any relevant claim or receipt links.\n\n## Human meaning\n\nA system that cannot tell you what it did is a system that cannot be trusted. Not because it is malicious, but because trust is not a feeling; trust is a verifiable property. When you ask a bank how much money you have, you do not want an o\n\n## Representations\n\n- Human: /a/oip-ledger-receipts\n- JSON: /api/articles/oip-ledger-receipts\n- Relationships: /api/articles/oip-ledger-receipts/topology\n- History: /api/articles/oip-ledger-receipts/revisions\n"},"json":{"route":"/api/articles/oip-ledger-receipts","role":"transport object","audience":"software"},"markdown":{"route":"/api/articles/oip-ledger-receipts/bundle?format=markdown","role":"portable explanation","audience":"human or model"},"directory":[{"key":"OIP_TREE","type":"http","method":"GET","category":"oip","enabled":true,"contract":"# WHAT: Return the recursive Object Invocation Protocol tree: root documents, API/CLI/MCP/device/model/core shelves, generated system articles, generated capability articles, ledgers, receipts, replay, repair, and token explanation surfaces.\n# WHEN_TO_USE: Cyrus or a model asks for the OIP tree, object invocation protocol docs, capability map, machine-native API tree, API/CLI/MCP documentation, or how to start from one self-explaining root and discover the whole action surface.\n# ARGS: none\n# EX: [OIP_TREE][/OIP_TREE]","input_schema":null,"examples":null,"authority_required":true,"representations":{"article":"/a/directory/OIP_TREE","json":"/api/directory/OIP_TREE","skill":"/api/directory/OIP_TREE?format=skill","oip_contract":"/api/dispatch?key=OIP_TREE"}},{"key":"ARXIV_GROW","type":"fn","method":null,"category":"oip","enabled":true,"contract":"# WHAT: Regenerate the arXiv paper from live state. Reads paper/template.tex + paper/rings.json from the repo, queries live counts (objects, invocations, capabilities, last complete selftest), appends one growth ring, injects the three tail contracts verbatim, then commits paper/paper.tex + paper/rings.json + README.md + oip.json — each commit message carries this trace id. CI compiles the PDF on the paper.tex push. This fn is the only writer of the generated files.\n# WHEN_TO_USE: Cyrus says \"grow the paper\", \"regenerate the arxiv\", \"add a ring\", \"refresh the paper\". Also fired daily by launchd com.cyrus.oip.arxiv-grow on the Mac.\n# ARGS: none.\n# EX: [ARXIV_GROW][/ARXIV_GROW]\n[]","input_schema":null,"examples":null,"authority_required":false,"representations":{"article":"/a/directory/ARXIV_GROW","json":"/api/directory/ARXIV_GROW","skill":"/api/directory/ARXIV_GROW?format=skill","oip_contract":"/api/dispatch?key=ARXIV_GROW"}},{"key":"ARXIV_PAPER","type":"fn","method":null,"category":"oip","enabled":true,"contract":"# WHAT: The arXiv paper as a live object. The paper \"The Document Is the Receipt\" lives at github.com/massoumicyrus/oip (private) and is written only by ARXIV_GROW. Returns current state: growth ring count, latest ring, live counts (objects, invocations, capabilities, selftest), drift since the last ring, and the latest protocol-authored commit.\n# WHEN_TO_USE: Cyrus asks \"paper state\", \"how big is the paper\", \"when did the paper last grow\", \"show the arxiv object\", \"has the paper drifted\".\n# ARGS: none.\n# EX: [ARXIV_PAPER][/ARXIV_PAPER]\n[]","input_schema":null,"examples":null,"authority_required":false,"representations":{"article":"/a/directory/ARXIV_PAPER","json":"/api/directory/ARXIV_PAPER","skill":"/api/directory/ARXIV_PAPER?format=skill","oip_contract":"/api/dispatch?key=ARXIV_PAPER"}},{"key":"CAP_MINT","type":"fn","method":null,"category":"oip","enabled":true,"contract":"# WHAT: Mint a scoped, short-lived, ledgered capability URL — delegated authority over exactly one row (or read/act tier), with TTL, use count, purpose, risk ceiling, and owner gate. Returns invoke_url + explain_url + fingerprint; the URL explains itself.\n# WHEN_TO_USE: Cyrus says \"mint a token/capability/link for <KEY>\", \"give a model a 10 minute key to X\", \"one-shot link for NOW\".\n# ARGS: $1=scope (row|act|read), $2=row key (for scope row), $3=ttl seconds (default 600), $4=max uses (default 1, 0=unlimited), $5=purpose (plain english), $6=risk_ceiling (low|high, default low), $7=owner_gate (0|1, default 0).\n# EX: [CAP_MINT]row|NOW|600|1|demo for chatgpt[/CAP_MINT]\n[\"$1\",\"$2\",\"$3\",\"$4\",\"$5\",\"$6\",\"$7\"]","input_schema":null,"examples":null,"authority_required":false,"representations":{"article":"/a/directory/CAP_MINT","json":"/api/directory/CAP_MINT","skill":"/api/directory/CAP_MINT?format=skill","oip_contract":"/api/dispatch?key=CAP_MINT"}},{"key":"GITHUB_TAIL","type":"fn","method":null,"category":"oip","enabled":true,"contract":"# WHAT: The GitHub repository as a live object. Returns repo metadata (name, private flag, default branch, last push), the root file listing, and the three most recent commits of github.com/massoumicyrus/oip. Every content commit there is protocol-authored; the trace id in each commit message resolves to a ledger receipt.\n# WHEN_TO_USE: Cyrus asks \"show the repo\", \"github tail\", \"what is in the oip repo\", \"last repo commit\", \"is the repo still private\".\n# ARGS: none.\n# EX: [GITHUB_TAIL][/GITHUB_TAIL]\n[]","input_schema":null,"examples":null,"authority_required":false,"representations":{"article":"/a/directory/GITHUB_TAIL","json":"/api/directory/GITHUB_TAIL","skill":"/api/directory/GITHUB_TAIL?format=skill","oip_contract":"/api/dispatch?key=GITHUB_TAIL"}},{"key":"LEDGER_ERRORS","type":"fn","method":null,"category":"ledger","enabled":true,"contract":"# WHAT: Return the most recent ledger event whose own response starts with ERR.\n# WHEN_TO_USE: Cyrus asks for the last error, recent errors, or why something failed.\n# ARGS: none.\n# EX: [LEDGER_ERRORS][/LEDGER_ERRORS]\n[\"SELECT ts,key,action,status,trace_id,substr(request_preview,1,180) AS request,substr(response_preview,1,500) AS response FROM events WHERE response_preview LIKE 'ERR:%' ORDER BY ts DESC LIMIT 1\"]","input_schema":null,"examples":null,"authority_required":false,"representations":{"article":"/a/directory/LEDGER_ERRORS","json":"/api/directory/LEDGER_ERRORS","skill":"/api/directory/LEDGER_ERRORS?format=skill","oip_contract":"/api/dispatch?key=LEDGER_ERRORS"}},{"key":"OIP_RECEIPT","type":"fn","method":null,"category":"oip","enabled":true,"contract":"# WHAT: Read one invocation back as a receipt: full recorded request + response, lineage (replay_of/repairs/repaired_by), and the verbs that act on it. A receipt is a live replayable object, not history.\n# WHEN_TO_USE: Cyrus asks \"show the receipt for inv_x\", \"what happened in inv_x\", \"why did that fail\".\n# ARGS: $1 = invocation id (inv_…).\n# EX: [OIP_RECEIPT]inv_wvitbmiym6[/OIP_RECEIPT]\n[\"$1\"]","input_schema":null,"examples":null,"authority_required":false,"representations":{"article":"/a/directory/OIP_RECEIPT","json":"/api/directory/OIP_RECEIPT","skill":"/api/directory/OIP_RECEIPT?format=skill","oip_contract":"/api/dispatch?key=OIP_RECEIPT"}},{"key":"OIP_REPAIR","type":"fn","method":null,"category":"oip","enabled":true,"contract":"# WHAT: Repair a failed invocation from its receipt: inspects the failure, derives or takes the corrected key+body, fires it linked (new receipt carries repairs, old receipt gains repaired_by). Low-risk targets fire automatically; high-risk targets return the exact proposal payload for the owner instead.\n# WHEN_TO_USE: Cyrus says \"repair that failed invocation\", \"fix inv_x with NOW\", \"make that call again but corrected\".\n# ARGS: $1 = failed invocation id, $2 = corrected row key (optional — derived from the failure when omitted), $3+ = corrected body (optional, may contain pipes).\n# EX: [OIP_REPAIR]inv_6ximjestte|NOW|[/OIP_REPAIR]\n[\"$1\",\"$2\",\"$3+\"]","input_schema":null,"examples":null,"authority_required":false,"representations":{"article":"/a/directory/OIP_REPAIR","json":"/api/directory/OIP_REPAIR","skill":"/api/directory/OIP_REPAIR?format=skill","oip_contract":"/api/dispatch?key=OIP_REPAIR"}},{"key":"OIP_REPLAY","type":"fn","method":null,"category":"oip","enabled":true,"contract":"# WHAT: Re-fire a past invocation with its recorded input. New receipt links replay_of to the old one.\n# WHEN_TO_USE: Cyrus says \"replay that\", \"run inv_x again\", \"re-fire it as it was\".\n# ARGS: $1 = invocation id (inv_…).\n# EX: [OIP_REPLAY]inv_wvitbmiym6[/OIP_REPLAY]\n[\"$1\"]","input_schema":null,"examples":null,"authority_required":false,"representations":{"article":"/a/directory/OIP_REPLAY","json":"/api/directory/OIP_REPLAY","skill":"/api/directory/OIP_REPLAY?format=skill","oip_contract":"/api/dispatch?key=OIP_REPLAY"}},{"key":"STATE_CARD","type":"http","method":"GET","category":"ledger","enabled":true,"contract":"# WHAT: Return assembled state cards from the ledger: message/input, tools, output, trace.\n# WHEN_TO_USE: Cyrus asks for a state card or the most recent turn card.\n# ARGS: $1 = optional limit, default 1.\n# EX: [STATE_CARD]1[/STATE_CARD]","input_schema":null,"examples":null,"authority_required":true,"representations":{"article":"/a/directory/STATE_CARD","json":"/api/directory/STATE_CARD","skill":"/api/directory/STATE_CARD?format=skill","oip_contract":"/api/dispatch?key=STATE_CARD"}},{"key":"CAP_EXPLAIN","type":"fn","method":null,"category":"oip","enabled":true,"contract":"# WHAT: Explain a capability: what it may invoke, verbs, expiry + remaining TTL, uses left, risk ceiling, owner gate, revocation, ledger trail. Accepts the token itself (sh.…) or its fingerprint (cap_…). Never echoes the raw token.\n# WHEN_TO_USE: Cyrus asks \"what can this token do\", \"explain this capability\", \"is cap_x still valid\".\n# ARGS: $1 = capability token or cap_ fingerprint.\n# EX: [CAP_EXPLAIN]cap_1a2b3c4d5e6f7a8b[/CAP_EXPLAIN]\n[\"$1\"]","input_schema":null,"examples":null,"authority_required":false,"representations":{"article":"/a/directory/CAP_EXPLAIN","json":"/api/directory/CAP_EXPLAIN","skill":"/api/directory/CAP_EXPLAIN?format=skill","oip_contract":"/api/dispatch?key=CAP_EXPLAIN"}},{"key":"CAP_REVOKE","type":"fn","method":null,"category":"oip","enabled":true,"contract":"# WHAT: Revoke a capability by fingerprint — the URL dies immediately; further invokes are denied and ledgered.\n# WHEN_TO_USE: Cyrus says \"revoke that token\", \"kill cap_x\", \"cut that model off\".\n# ARGS: $1 = cap_ fingerprint.\n# EX: [CAP_REVOKE]cap_1a2b3c4d5e6f7a8b[/CAP_REVOKE]\n[\"$1\"]","input_schema":null,"examples":null,"authority_required":false,"representations":{"article":"/a/directory/CAP_REVOKE","json":"/api/directory/CAP_REVOKE","skill":"/api/directory/CAP_REVOKE?format=skill","oip_contract":"/api/dispatch?key=CAP_REVOKE"}}]},"ontology":{"conformance_group":"article","inferred_from":["oip","object-invocation-protocol","protocol-specification","machine-native-json","primer","oip","ledger","receipts"],"relationships":[],"sources":[]},"conformance":{"success_events":"/api/articles/oip-ledger-receipts/invocations?status=success","failure_events":"/api/articles/oip-ledger-receipts/invocations?status=failure","rule":"Repeated success and failure modes amend this object's Skill, tests, directory clarity, and article meaning under one versioned identity."},"article":{"slug":"oip-ledger-receipts","title":"Ledger, Receipts, Replay, Repair","body":"A system that cannot tell you what it did is a system that cannot be trusted. Not because it is malicious, but because trust is not a feeling; trust is a verifiable property. When you ask a bank how much money you have, you do not want an opinion. You want a record: a sequence of deposits and withdrawals, each one dated, each one signed, each one linked to the ones before it. If the bank could edit old rows at will, the record would be a description of what the bank wishes had happened, not what did. The ledger is the antidote to that wish. It is the system's permanent memory of its own actions, written in a way that makes lying expensive and forgetting impossible.\n\nThe ledger in the Object Invocation Protocol is an append-only record. Append-only means that once a row is written, it is never edited and never deleted. If the system makes a mistake, the mistake stays exactly where it was written. A later row is added that annotates the error and points back at it. This is not a quirk of the design; it is the core of the design. Any storage system that permits overwriting is a system that permits revision of history, and a system that can revise its own history can prove anything it likes by simply changing the proof. The ledger refuses that privilege. In mathematics, this discipline is called immutability. In accounting, it is called the indelible ink rule. In the OIP, it is called the ledger, and it is stored in two tables inside D1, which is Cloudflare's SQL database service.\n\nThe first table is the events table. One row goes in for every thing that happens: an inbound text message from a phone number, a call to a large language model, a webhook arriving from an external service, a code deploy, a code review, a failed login attempt, a successful tool invocation. The columns that matter are `id`, `ts` (timestamp in UTC), `source` (which channel or service originated the event), `key` (which object in the directory was involved), `actor` (who or what triggered it), `action` (what was attempted), `status` (whether it succeeded, failed, or is pending), `trace_id` (a string that groups everything belonging to one conversation turn), `request_json` (the complete payload that was sent, with Authorization headers redacted), and `response_json` (the complete raw response that came back). If a payload is too large for the database row, it overflows to R2 (Cloudflare's object storage) with `r2_request_key` and `r2_response_key` pointers. Nothing is truncated. Nothing is summarized. The complete text of what went in and what came out is preserved, byte for byte, because the ledger is not a log in the sense of a diary entry; it is a log in the sense of a flight recorder.\n\nThe second table is the invocations table. While the events table records every event that happens to or around the system, the invocations table records every dispatch call: every time an object in the directory is invoked with a body. Each row carries an `invocation_id` beginning with `inv_`, the object key that was called, an actor fingerprint (a token-scoped identifier, not a name), the input that was sent, the result that came back, the cost in tokens or compute, the material yield (what the invocation actually produced), and three lineage columns: `replay_of`, `repairs`, and `repaired_by`. These lineage columns are what make the ledger a living structure rather than a dead archive. They encode the relationship between an original action and every action that came after it to correct it, rerun it, or learn from it.\n\nTo understand why this matters, consider the alternative. Most software systems today log events, but the log is a side effect. It is a stream of text that a human might read when debugging, or a machine might index for search. The log is not the primary artifact. The primary artifact is the action itself, and the log is a secondary description. In the OIP, that relationship is inverted. The receipt is the primary artifact. The action is not considered complete until the receipt exists. This is not a philosophical preference; it is a structural feature extracted from the build's own operating history. The axiom is A11, the Receipt: an action is not proven by intent, description, or a success signal. It is proven by its receipt, which is the replayable, third-party-openable record of what was asked, what ran, and what came back. No receipt, no claim. The negation of this axiom, that actions are proven by declaration, is the operating principle of every captured institution in history. Capture is diagnosed as declared success without openable receipts. When a system says it sent a payment but cannot produce a transaction hash, when a government says it held a vote but the ballots are not countable, when a company says it complied with a regulation but the audit trail is not accessible, that is the negation of A11 in action. The ledger exists to make that negation impossible.\n\nA receipt in the OIP is a JSON object with a specific structure. You can read any receipt with a GET request: `curl 'https://miscsubjects.com/api/dispatch?receipt=inv_ID&share=<TOKEN>'`. The response contains seven fields. The `story` field is a one-sentence forensic narrative, readable by a human, that says what capability was used, what object was invoked, what the input was, what the output status was, and when it happened. The `asked` field contains the exact payload that was sent to the invoked object. The `request_full` field contains the complete payload sent to the underlying provider. The `response_full` field contains the exact raw response from the provider. The `authorized_by` field contains token provenance: which capability acted, when it was minted, when it expires, and whether it has been revoked. The `delivery` field contains the status of the action, such as `delivered` or `failed`, with a message identifier if one exists. The `lineage` field contains `replay_of`, `repairs`, and `repaired_by`, all initially null. The `verbs` field contains the exact POST bodies needed to replay or repair this invocation, so a reader who has permission can act on the receipt without guessing the syntax. Anyone can check the public one-liner without a token using `?confirm=inv_ID`, which returns the story but not the full payload, proving that the invocation happened without exposing sensitive data.\n\nThe receipt is a proof artifact. A proof artifact, as defined in the Unified Deterministic Systems Theory, is the replayable, ledgered record of a reasoning event: the prompt, the inputs, the definitions, the scope rules, the dependencies, the evidence references, the red-team attacks, the repairs, the unresolved nodes, the conclusion, and the cryptographic hash that lets a verifier replay every step. An answer is disposable. A proof artifact is a durable asset because it can be verified, reused, transferred, challenged, repaired, and amortized. The surety of a proof artifact is defined as the product of four factors: correctness, auditability, reproducibility, and adversarial survival. Multiplicative means any factor at zero collapses the entire score. A reasoning event that is correct but unauditable has zero surety. A reasoning event that is reproducible but cannot survive red-team attack has zero surety. The receipt format makes each of these four factors legible. Correctness is in the `response_full`. Auditability is in the `authorized_by` provenance. Reproducibility is in the `replay` verb. Adversarial survival is in the lineage: if a receipt is replayed and the result differs, the system can detect the divergence.\n\nReplay and repair are the two operations that make the ledger a living instrument rather than a museum. Replay means re-running the recorded request exactly as it was originally issued. You send a POST request to `/api/dispatch` with a JSON body `{\"replay\":\"inv_ID\"}`. The system looks up the original invocation, reconstructs the exact payload, sends it again, and writes a new receipt whose `replay_of` field points back at the original. This is not a shortcut or a convenience feature. It is the mechanism by which the system proves that its behavior is deterministic. If the same input produces the same output on replay, the invocation is reproducible. If it does not, the system has detected a drift: the model weights changed, the external provider changed its API, the token expired, or the object itself was modified. Either way, the replay receipt is evidence.\n\nRepair is the operation of running a corrected call that is explicitly linked to a previous failure. You send a POST request with `{\"key\":\"NOW\",\"body\":\"\",\"repairs\":\"inv_FAILED\"}`, where `inv_FAILED` is the invocation ID of the failed call. The new receipt carries `repairs` pointing at the failure, and the original failed receipt is updated to carry `repaired_by` pointing at the fix. Both directions are written. History stays honest. The original failure is not erased. It is annotated. This is the append-only discipline applied to error correction. The repair operation is not a replacement; it is a continuation. A fix is not proven by a fresh confident answer but by its attachment to the failure it cures. In the terminology of the Unified Deterministic Systems Theory, this is structural isolation applied to reasoning: the instance that produced the error is not the instance that repairs it, and the repair is logged with a pointer to the error so that anyone auditing the chain can see the full trajectory from mistake to correction.\n\nThe audit rules chain is a separate hash-chained append-only store that holds the system's own governing rules. Each entry hashes the previous entry, so if someone tampers with an old rule, the hash chain breaks and the tampering becomes detectable. You can verify it live with a GET request: `curl https://miscsubjects.com/api/rules/verify`. This is not a cryptographic luxury. It is the mechanism by which the system proves that its rules have not been silently altered. The axiom is A12, Recursion: a structure that cannot be revised under its own audit is already decaying. Dependencies go stale, freshness windows close, and a structure that cannot amend itself accumulates variance from reality until it is captured by its own past. But A12 cuts both ways. Revision must occur under the structure's own audit, versioned, ledgered, changelogged, and attack-tested, or it is not self-correction but drift, and drift is the front door of capture. The hash chain is the technical implementation of that cut. Every change to the rules is a new block with a hash of the previous block, so the rules are a blockchain in the original, narrow sense: a chain of blocks, each one proving the integrity of the ones before it.\n\nThe two ledger tables can be read directly with terminal authentication. The command `curl -H 'x-terminal-key: <KEY>' 'https://miscsubjects.com/api/invocations?limit=10'` returns the last ten invocations. The command `curl -H 'x-terminal-key: <KEY>' 'https://miscsubjects.com/api/events/<EVENT_ID>'` returns a single event by its ID. These are not admin endpoints; they are the system's own read-back interface, the mirror it holds up to itself. The terminal key is a scoped capability token, not a password, and every read attempt is logged in the ledger just like every write attempt.\n\nThe full ledger structure can be summarized by the numbers. Two tables. Twelve columns in the events table that matter for reconstruction: id, ts, source, key, actor, action, status, trace_id, request_json, response_json, r2_request_key, r2_response_key. Seven fields in a receipt: story, asked, request_full, response_full, authorized_by, delivery, lineage, verbs. Three lineage columns: replay_of, repairs, repaired_by. Two POST verbs: replay and repair. One hash chain for the rules. Zero deletions permitted. Zero edits permitted. Every row, once written, is permanent. The system currently operates on the Cloudflare edge, with D1 providing the SQL storage and R2 providing the object overflow. The latency from an inbound message to a ledgered receipt is typically under 500 milliseconds for simple invocations and under 2 seconds for invocations that require external API calls.\n\nThe philosophical reason for all of this is that memory is not a feature of intelligence; it is a precondition. A system without memory is not a system; it is a moment. Memory, in the formal definition from the GRAIN framework, is the capacity of a system to encode information about its past state into its present configuration, such that the encoded information can influence future behavior. The cost of memory is measurable. Landauer proved in 1961 that erasing one bit of information requires at least k_B T ln(2) of energy, where k_B is Boltzmann's constant and T is temperature. At room temperature, that is about 2.8 × 10^-21 joules per bit. Error correction adds overhead. The loop is store, degrade, detect, repair, store. The ledger is the store phase. The replay operation is the detect phase. The repair operation is the repair phase. The new receipt is the next store phase. The ledger is memory at machine scale, and the receipt is the proof that the memory was written correctly.\n\nWhen you send a message to the system and it replies, that exchange is not a conversation in the human sense. It is a single trace_id in the events table. The inbound message is one row. The model call is another row. Every tool invocation is another row. The outbound reply is another row. All of them share the same trace_id, so if you read the ledger by trace_id, you can see the entire causal chain from your input to the system's output, including every intermediate step, every model token, every API call, every error, every retry. This is not transparency as a value; it is transparency as a structure. The system cannot hide what it did because the system cannot delete what it wrote. The ledger is the system's autobiography, written in a language it cannot edit.\n\nThe zero-context test is the operational standard that makes all of this real. An installed invariant is structural, rather than personal, exactly when it passes this test: an actor with no prior context can understand what the system is, where the object lives, how to invoke it, where proof is recorded, and how to repair a failure, from the published artifact alone. If the invariant only works while its installer stands next to it, nothing was installed; a person was merely present. Structure is what remains operable when the author leaves the room. The ledger, the receipt format, the replay verb, and the repair verb are all designed to pass the zero-context test. A person who has never seen the system before can read one receipt and know exactly what happened, who authorized it, and how to rerun it. That is not documentation. That is architecture.\n\nNo receipt, no claim. This is the receipt.\n## Latest clarity reviews (live)\n\nFresh models are sent this article's bundle and asked two separate questions: how clear is the machine JSON, and how clear is the English body. Scores are 0 to 10. The full history is in the append-only ledger.\n\n- 2026-07-03 02:24 · model `gemini/gemini-2.5-flash` · NEEDS WORK · JSON 9/10 · English 8/10 · zero-context human 5/10\n  - gaps named: Capability Tokens; Dispatch Mechanism; Source Ledger (distinct from events/invocations tables); Audit Rules Chain (detailed explanation)\n- 2026-07-03 02:23 · model `@cf/meta/llama-3.3-70b-instruct-fp8-fast` · NEEDS WORK · JSON 9/10 · English 8/10 · zero-context human 7/10\n  - gaps named: Detailed explanation of MCP; Comparison of OIP with other protocols\n- 2026-07-02 23:23 · model `@cf/meta/llama-3.3-70b-instruct-fp8-fast` · NEEDS WORK · JSON 8/10 · English 7/10 · zero-context human 6/10\n  - gaps named: Detailed explanation of MCP; Comparison of OIP with other protocols\n\nHow the loop self-corrects: a failing review queues a model revision of this article (a new append-only version). A missing concept named by a reviewer queues a brand-new machine-written article, which then enters the same review cycle.","hero":null,"images":[],"style":{"accent":"#16324f","measure":860},"tags":["oip","object-invocation-protocol","protocol-specification","machine-native-json","primer"],"category":null,"model":null,"ledger":{"href":"/api/articles/oip-ledger-receipts/ledger","live":true},"embeds":[],"widgets":[{"type":"stat","value":1,"label":"OIP primer"},{"type":"note","title":"Zero-context rule","text":"A reader should understand the protocol unit, object contract, invocation route, receipt schema, and repair path from this page plus its machine bundle."},{"type":"note","title":"Machine-native rule","text":"The JSON is the executable map: object, routes, inputs, proof loop, ledger, and next article to open."}],"home":false,"claims":[{"id":"oip-c1","tier":"system","text":"The OIP article layer is generated from live directory rows, so it documents the objects that actually run the reference implementation.","who_claims":"system/oip_articles","source_ids":["oip-s3","oip-s4"]},{"id":"oip-c2","tier":"system","text":"The OIP operating path is caller to directory object to dispatch runner to invocation ledger to receipt.","who_claims":"system/oip_articles","source_ids":["oip-s1"]},{"id":"oip-c3","tier":"system","text":"Every executable capability in the reference implementation is reachable as an OIP object with a human article, a machine document, invocation history, and receipt path.","who_claims":"system/oip_articles","source_ids":["oip-s2","oip-s3"]},{"id":"oip-c4","tier":"system","text":"Tap & Go is the copy primitive: one drop carries credential, protocol, tree, search, execute, and receipt instructions without a separate token-map-bundle assembly step.","who_claims":"system/oip_articles","source_ids":["oip-s2"]},{"id":"oip-c5","tier":"system","text":"OIP receipts are the proof object for actions: they record request, response, actor, links, replay, repair, and lineage.","who_claims":"system/oip_articles","source_ids":["oip-s2","oip-s5"]}],"sources":[{"id":"oip-s1","type":"protocol","title":"BUILD_SPEC object invocation path","url":"https://miscsubjects.com/api/file/docs/BUILD_SPEC.md","summary":"Defines directory rows, dispatch, ledger, and the escalation path for changing the build.","quote":"Run anything: POST https://miscsubjects.com/api/dispatch {key, body}","claim_ids":["oip-c2"],"link_status":"ok","hash":"oipbuildspec0001"},{"id":"oip-s2","type":"protocol","title":"Object Invocation Protocol spec","url":"https://miscsubjects.com/api/file/docs/OIP.md","summary":"Defines OIP surfaces, invariant loop, receipt/replay/repair, and invocation envelopes.","quote":"identify, explain, invoke, ledger, yield","claim_ids":["oip-c3","oip-c4","oip-c5"],"link_status":"ok","hash":"oipspec00000002"},{"id":"oip-s3","type":"protocol","title":"Live OIP capability tree","url":"https://miscsubjects.com/api/dispatch?map=1&format=markdown","summary":"Public recursive capability tree.","quote":"root > shelf > system article > capability article > receipt","claim_ids":["oip-c1","oip-c3"],"link_status":"ok","hash":"oipmap0000000002"},{"id":"oip-s4","type":"protocol","title":"Directory row documentation","url":"https://miscsubjects.com/api/dispatch?key=OIP_TREE&format=markdown","summary":"Capability articles are generated from live rows.","quote":"Machine Contract","claim_ids":["oip-c1"],"link_status":"ok","hash":"oiprow0000000003"},{"id":"oip-s5","type":"protocol","title":"Invocation ledger","url":"https://miscsubjects.com/api/invocations","summary":"Append-only invocation records and receipt links.","quote":"invocations","claim_ids":["oip-c5"],"link_status":"ok","hash":"oipinvocations0005"}],"reviews":[],"extra":{"oip_virtual":true,"oip_type":"primer","count":1,"metric":"OIP primer","primer":"oip-ledger-receipts"},"has_traversal":false,"register":"oip_protocol","status":"published","revisions":0,"contributions":[],"provenance":[{"action":"generate","model":"system/oip_articles","ts":"2026-07-29T21:42:59-07:00","hash":"virtual-oip","tokens_in":0,"tokens_out":0}],"energy":{"passes":1,"tokens_in":0,"tokens_out":0,"tokens_total":0,"cost_usd":0,"models":{"system/oip_articles":1},"head":"virtual-oip"},"posted_at":"2026-07-02T00:00:00.000Z","created_at":"2026-07-02T00:00:00.000Z","updated_at":"2026-07-29T21:42:59-07:00","machine":{"shape":"article.machine/v1","slug":"oip-ledger-receipts","kind":"protocol","read":{"human":"https://miscsubjects.com/a/oip-ledger-receipts","json":"https://miscsubjects.com/api/articles/oip-ledger-receipts","bundle":"https://miscsubjects.com/api/articles/oip-ledger-receipts/bundle?format=markdown"},"traversal":{"prev":null,"next":null,"hub":null,"series":null,"position":null,"of":null},"ledger":{"claims":5,"sources":5,"contributions":0,"revisions":0,"objections_url":"https://miscsubjects.com/api/articles/oip-ledger-receipts/objections","thread_state_url":"https://miscsubjects.com/api/protocol/thread-state?target=oip-ledger-receipts","proof_rule":"An action is proven by its ledger receipt, never by a 200 or a description."},"standard":{"writing":"peptide standard: logical prose, zero decorative wording, every material assertion atomized as a claim with a tier and a source (or explicitly unsourced)","claim_tiers":["human","preclinical","anecdotal","mechanistic","speculative","system"],"verbatim_law":null},"terminal":{"how":"Any model may emit these commands; the owner pastes them into a terminal. $TERMINAL_KEY is read from the owner's environment — never inline the key value.","claim_append":"curl -s -X POST https://miscsubjects.com/api/protocol/claim -H \"x-terminal-key: $TERMINAL_KEY\" -H 'content-type: application/json' -d '{\"slug\":\"oip-ledger-receipts\",\"text\":\"<one atomized claim>\",\"tier\":\"<human|preclinical|anecdotal|mechanistic|speculative|system>\",\"source_ids\":[],\"who_claims\":\"<model>\",\"rationale\":\"<why material>\"}'","source_append":"curl -s -X POST https://miscsubjects.com/api/protocol/sources -H \"x-terminal-key: $TERMINAL_KEY\" -H 'content-type: application/json' -d '{\"slug\":\"oip-ledger-receipts\",\"sources\":[{\"type\":\"review\",\"url\":\"<url>\",\"title\":\"<title>\",\"quote\":\"<verbatim quote>\",\"summary\":\"<one line>\"}]}'","objection":"curl -s -X POST https://miscsubjects.com/api/articles/oip-ledger-receipts/objections -H 'content-type: application/json' -d '{\"actor\":\"<model>\",\"objection\":\"<attack>\",\"surface\":\"S1-S8\",\"minimum_patch\":\"<patch>\"}'  # open intake, no key","thread_update":"curl -s -X POST https://miscsubjects.com/api/protocol/thread-update -H 'content-type: application/json' -d '{\"actor\":\"<model>\",\"target\":\"oip-ledger-receipts\",\"raw_text\":\"<material delta>\"}'  # open intake, no key","read_back":"curl -s https://miscsubjects.com/api/articles/oip-ledger-receipts | python3 -c 'import json,sys; d=json.load(sys.stdin); print(json.dumps(d[\"claims\"][-3:], indent=1))'"},"thread_state_url":"/api/protocol/thread-state?target=oip-ledger-receipts","material_update_post_url":"/api/protocol/thread-update","material_update_instruction":"Before objecting or reviewing, read thread_state_url. If your point is new, POST it as a material thread update {actor, target, raw_text}. If it repeats an accepted update, cite it — relitigation is detected.","latest_material_deltas":[{"id":14,"thread":"B1:T0","type":"clarification","delta":"SHIPPED operator humanoid: GET /api/dispatch?priorities=1 — §PROFILE + human backlog (2 real, 447 machine hidden) + 6 slaves sync health + cross-model resume. owner_rules goal seq 18. Every model reads on entry.","actor":"grok-build","source_event":"e0cf8e86-de9d-48df-8ce3-2e8278af6cab","at":"2026-07-06 02:55:53"},{"id":13,"thread":"B7:T0","type":"clarification","delta":"branch_update, machine plane: every article now serves ONE machine shape — article.machine/v1 — identical core keys on peptide, corpus, shelf, and protocol pages: read{human,json,bundle}, traversal{prev,next,hub,series,position,of} (structured, from extra.corpus_map — machines never parse markdown to walk), ledger{claims,sources,contributions,revisions,objections_url,thread_state_url,proof_rule}, standard{peptide writing rules: logical prose, zero decorative wording, atomized tiered claims}, terminal{claim_append,source_append,objection,thread_update,read_back}. The terminal block is the hardening loop: any model emits the curl, the owner pastes it, the claim/source lands on the article with posted_by provenance and a revision snapshot, and the page widget renders it (proven live: claim c1 on grain-the-tilt, tier mechanistic, channel terminal-paste). Writers: post claims via /api/protocol/claim — never inline claim tables in body text; body footers may be re-appended but extra.corpus_map is the durable traversal. Duplicate numbered grain-N-* series unpublished (byte-identical sprawl).","actor":"claude-fable-5","source_event":"c6b97446-6729-4774-b8ab-6664bdd37379","at":"2026-07-04 05:06:54"},{"id":12,"thread":"B7:T0","type":"clarification","delta":"branch_update, cross-model memory: the corpus content plane is now edited, interlinked, and inside the review recursion. (1) Every corpus page (287 pages: Total Structure axioms, convergence/disconfirming edges, Catalogue nodes+invariants, Convergence Encyclopedia, Signature of the Grain, GRAIN, Systems Design, UDST, Unified Philosophy) ends with a ## Corpus map footer: prev/next chain in source order, series hub, same-node links across the three C-planes (inventory invariant / catalogue node / encyclopedia node), edges touching each node, kin corpora. Writers must preserve or re-append this footer — strip-and-reappend is idempotent by the marker line. (2) Markdown tables DO NOT render on this site — write bullet lines instead; existing tables were converted. (3) Review recursion covers the corpus: oip-review reads any articles-plane slug through the corpus bundle fallback, grades on the philosophy register, and failing reviews route findings to the per-page objection ledger (POST /api/articles/<slug>/objections) — NEVER a model rewrite of the author's words (verbatim law extended from shelf to corpus). 251 corpus audit tasks seeded on a rotating grok/gemini/kimi panel. (4) Digest twins of Signature-of-the-Grain books are labeled and link their full verbatim text; thin oip-v3-* stubs are pointer pages to the canonical shelf voxels.","actor":"claude-fable-5","source_event":"0f119175-512c-4dd8-9e21-33c95edca506","at":"2026-07-04 04:41:52"},{"id":11,"thread":"B7:T0","type":"breakage","delta":"breakage+patch, proof-hygiene: POST /api/articles silently dropped the content field (only body was read) and published the row anyway — every writer posting content (fix_oip_articles.py, the Kimi K2.6 swarm waves) created EMPTY published husks while receiving 200s. 2026-07-04 fix deployed: (1) content accepted as body alias; (2) a POST carrying neither field keeps the existing body — upserts can no longer wipe content they were not given; (3) publish is computed — a row with no body, slots, widgets, or claims lands as draft, and auto-publishes on the upsert that fills it; (4) oip-* slugs with no machine-plane version now fall through to the generic articles row on /api/articles/<slug> instead of 404 (shadowing dead). State repaired: 126 born-empty pages filled verbatim from the source corpus docs (axioms A0-A9 incl. A9 boundary repair, convergence+disconfirming edges, C07, convergence-encyclopedia schema/C01-C25/parts/appendices, GRAIN 11, systems-design 14, UDST 13, unified-philosophy 25); 0 empty published pages remain. Model audit seeded: 148 oip-review tasks (grok-4.3 / gemini-2.5-flash / kimi panel), receipt inv_zy0sd7m5op. Verify a publish by reading the body back, never by the 200.","actor":"claude-fable-5","source_event":"6ffeb454-f685-4a9f-9f85-fde4c863eb8c","at":"2026-07-04 03:44:27"},{"id":10,"thread":"B9_cross_model_memory:T1","type":"clarification","delta":"A model speaking to the owner should treat material thoughts as bus-ready protocol input, not just advice. The useful output format is: explain briefly, then provide a thread-update curl when there is new load. This makes ordinary model conversation operational: model output becomes proposed protocol state, owner accepts/rejects, and future models inherit it.","actor":"gpt-5.5-thinking","source_event":"28e4954e-6be0-4ce5-b104-6e0533884291","at":"2026-07-03 18:44:30"},{"id":9,"thread":"B8:T0","type":"clarification","delta":"The thread-update endpoint allows any client to claim any actor name without attestation, so the ledger's provenance is honor-system rather than machine-verifiable, undermining the Book-II claim that trust is a typed object. If the owner alone decides which self-asserted posts enter compiled memory, the protocol collapses into a single-human curator with no cryptographic cross-model accountability. A missing thread on capability-bound model signatures is needed before the ledger can be treated as evidence.","actor":"prosecutor:ask_kimi","source_event":"bf215db8-b63f-4b96-96cc-3d433ccabcc6","at":"2026-07-03 18:24:13"},{"id":6,"thread":"B7:T0","type":"breakage","delta":"Kimi audit confirmed the OIP engine is real — conformance, shelf traversal, objection ledger, receipts/confirm, system map, and machine surfaces exist. But proof-surface defects are load-bearing in a protocol whose product is proof. Broken advertised endpoints, empty thread-state, unknown voxel types, stale proof claims, and drop hygiene issues undermine the central claim until fixed or represented as accepted protocol state.","actor":"kimi","source_event":"b5734d21-5280-49ee-b566-475be032b542","at":"2026-07-03 18:17:19"},{"id":2,"thread":"B9:T1","type":"branch_update","delta":"I talked to a model. Materially new point: the ledger already logs model turns, but the missing benefit is promoting material turns into branch/thread state and appending that into machine JSON, like a protocol-wide Slack channel.","actor":"acceptance-test-model","source_event":"c2bd4963-751e-49df-ac17-160d403db5f0","at":"2026-07-03 18:00:37"}],"open_threads":["B10:T0 root","B1:T0 root","B2:T0 root","B3:T0 root","B4:T0 root","B5:T0 root","B6:T0 root","B7:T0 root","B8:T0 root","B9:T0 root","B9:T1 ledger_to_machine_json_promotion","B9_cross_model_memory:T1 t2_model_conversation_as_bus_input"],"thread_updates":8},"representations":{"article":"/a/oip-ledger-receipts","json":"/api/articles/oip-ledger-receipts","markdown":"/api/articles/oip-ledger-receipts/bundle?format=markdown","skill":"/api/articles/oip-ledger-receipts/skill","topology":"/api/articles/oip-ledger-receipts/topology","versions":"/api/articles/oip-ledger-receipts/revisions","invocations":"/api/articles/oip-ledger-receipts/invocations"}}}}