{"_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":"what-is-replay-repair","urls":{"read":"https://miscsubjects.com/api/articles/what-is-replay-repair/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/what-is-replay-repair/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/what-is-replay-repair/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/what-is-replay-repair/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/what-is-replay-repair/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/what-is-replay-repair/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/what-is-replay-repair/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":"what-is-replay-repair","title":"What Is Replay and Repair","register":"standard","tags":["oip","kimi-import","self-explaining","voxel","concepts","what-is-replay-repair"],"updated_at":"2026-07-15T04:21:03.153Z","body_excerpt":"<!-- hierarchy:nav -->\n> **Path:** [OIP](https://miscsubjects.com/a/oip) › [Thinker Reference](https://miscsubjects.com/a/oip-thinker-reference) › [Protocol Concepts](https://miscsubjects.com/a/oip-protocol-concepts) › **What Is Replay and Repair**\n>\n> **Shelf:** Protocol Concepts · **Traversal:** self-explaining · hierarchical · voxel-ready\n> **Machine root:** [OIP tree](https://miscsubjects.com/api/dispatch?map=1&format=markdown) · [Registry](https://miscsubjects.com/api/dispatch?registry=1)\n\n# What Is Replay and Repair\n\n## §SELF — what-is-replay-repair\n\n**What this page is:** A definition of two mechanisms for handling and correcting invocation results in a ledger-based system.\n**What it explains:** How replay re-runs past invocations for verification, and how repair creates linked corrections without erasing errors.\n**Why read it:** To understand why appending corrections (rather than overwriting errors) creates an auditable history of what happened and what was fixed.\n\n### What Replay and Repair Are\n\nReplay and repair are two operations on an invocation ledger. A ledger is an append-only record: every invocation is stored as a receipt that cannot be changed or deleted. Replay and repair are the two ways to handle a receipt after it has been created.\n\n**Replay** means re-running a recorded invocation. You send a receipt ID to a replay endpoint. The system runs the same object with the same input again, producing a new receipt. The new receipt links back to the original. You now have two receipts for the same operation. You can compare them.\n\n**Repair** means creating a corrected invocation linked to a failed one. You send a new invocation with a `repairs` parameter containing the receipt ID of the failed invocation. The system runs the new invocation and creates bidirectional links: the failed receipt points to the repair, and the repair points to the failed receipt. Both receipts remain in the ledger.\n\n### Why They Matter\n\nIn systems where multiple components invoke objects on each other's behalf, errors happen. A model misinterprets a contract. An object returns an unexpected format. A network timeout causes a partial result. Without replay and repair, handling these errors requires either: (a) overwriting the error (destroying the record), or (b) creating disconnected corrections (losing the relationship between error and fix). Replay and repair solve both problems. The ledger stays complete. The lineage stays visible.\n\n### The Key Idea\n\nErrors are not erased. They are linked to their corrections. The ledger is append-only — nothing is deleted. Repair creates lineage, not replacement.\n\n**Replay use cases:**\n\n- **Verification.** A receipt claims that object X returned value Y. You replay it. If the new receipt shows the same result, you have independent confirmation. If not, you have detected non-determinism or a state change.\n- **Idempotency.** You sent an invocation but the network dropped the response. You do not know if it succeeded. You replay the receipt ID. The system returns the result without re-executing (if cached) or re-executes and returns a new receipt you can compare.\n- **Audit.** An investigator asks \"what happened at step 7?\" You replay the receipt for step 7 and show the exact input, output, and object that were involved.\n\n**Repair use cases:**\n\n- **Correction.** The first invocation failed because the input was wrong. You send a repair with corrected arguments. The new receipt links to the failed one. Anyone inspecting the ledger sees both the error and the fix.\n- **Lineage.** A downstream result depends on an invocation that later turned out to be wrong. The repair link lets you trace forward from the error to its correction, and backward from the correction to the error.\n- **Audit.** Nothing is erased. An auditor can see the complete history: what was attempted, what failed, what was corrected, and when. No data is hidden.\n\n### What Replay and Repair Got Right\n\n- **Append-only ledger.** The ledger ne","ranking":"safety-first (interaction_risk/limitations), then quote-gated effective_weight","claims":[],"sources":[],"anecdotal_sources":[],"scientific_sources":[],"user_reports":[],"related_articles":[],"question_graph":{"slug":"what-is-replay-repair","questions":[],"evidence":[],"edges":[],"counts":{"questions":0,"evidence":0,"edges":0}},"honesty":{"active_claims":0,"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":0,"claims_total":0,"sources":0,"anecdotal":0,"scientific":0,"user_reports":0,"questions":0,"evidence_ingests":0}}