# Continuity Receipt Specification v0.1 **Sean Manouge** **22 September 2026** ## 1. Purpose A **Continuity Receipt** is a portable record that proves how one accepted state became the legitimate successor of another. It exists to answer a specific question: > **Why is this successor entitled to govern after this predecessor?** The receipt does not replace the full state, transition history, evidence corpus, or governing sources. It references them. Its purpose is to provide a compact, inspectable continuity object containing enough information to establish: - the predecessor - the successor - the transition between them - the authority under which the transition occurred - the invariants that constrained it - the effects that were observed - the evidence supporting those effects - the acceptance decision - the resulting continuity status A receipt therefore records **legitimate succession**, not merely activity. --- # 2. Core Principle A receipt is issued only when a transition reaches an explicit continuity outcome. For an accepted transition: ```text PREDECESSOR ↓ TRANSITION ↓ OBSERVED EFFECTS ↓ EVIDENCE ↓ ACCEPTANCE ↓ SUCCESSOR ↓ CONTINUITY RECEIPT ``` The receipt does not make the transition legitimate by existing. It records why the transition was determined to be legitimate. A malformed process cannot manufacture continuity simply by generating a receipt afterward. --- # 3. Receipt Identity Every receipt must have a unique identifier. Minimum form: ```yaml receipt: id: CR-0042 version: 0.1 ``` Recommended form: ```yaml receipt: id: CR-20260922-0042 spec_version: "0.1" ``` --- # 4. Required Fields A valid Continuity Receipt contains: ```text receipt predecessor successor transition authority invariants effects evidence acceptance continuity ``` These sections collectively establish the continuity claim. --- # 5. Receipt The `receipt` section identifies the receipt itself. Required fields: ```yaml receipt: id: CR-0042 spec_version: "0.1" issued_at: 2026-09-22T19:42:00+09:30 ``` Optional fields may include issuer, environment and scope. --- # 6. Predecessor The `predecessor` identifies the accepted state from which the transition began. ```yaml predecessor: id: STATE-0041 scope: production-runtime state_ref: runtime://states/0041 digest: sha256:... ``` The predecessor must refer to the state recognised as governing immediately before the transition within the relevant scope. If the predecessor cannot be established, a valid succession receipt cannot be issued. --- # 7. Successor The `successor` identifies the resulting state. ```yaml successor: id: STATE-0042 scope: production-runtime state_ref: runtime://states/0042 digest: sha256:... ``` The successor becomes governing only when acceptance authorises promotion within the specified scope. --- # 8. Transition The `transition` identifies and summarises the change that connects predecessor and successor. ```yaml transition: id: T-0042 actor: operator-17 intent: deploy build 8.4.1 scope: production-runtime proposed_at: 2026-09-22T19:31:00+09:30 executed_at: 2026-09-22T19:34:00+09:30 transition_ref: runtime://transitions/0042 ``` The receipt should summarise intent, not replicate every operation performed. --- # 9. Authority The `authority` section establishes why the transition was permitted. Authority references must establish current applicability. Historical authority is insufficient. Authority must be attributable, scoped, and current. --- # 10. Invariants The `invariants` section records continuity conditions that were required to survive the transition. An accepted receipt must not conceal violated mandatory invariants. If an invariant was legitimately modified, the receipt should record that explicitly. --- # 11. Effects The `effects` section records what the transition was expected to produce and what was actually observed. The distinction between expected and observed effects must remain explicit. The receipt must not collapse intention into outcome. --- # 12. Evidence The `evidence` section identifies what supports the receipt's claims. Each evidence item should identify: - the claim - the source - the verification method - the reference to the underlying evidence - optionally, an integrity digest Evidence should be matched to claims. --- # 13. Acceptance The `acceptance` section records the decision that promotes the successor into governing state. Suggested statuses: ```text accepted accepted_with_conditions provisional rejected revoked superseded unresolved ``` Acceptance must be explicit. --- # 14. Continuity The `continuity` section records the resulting determination. Suggested continuity states: ```text valid invalid provisional unresolved revoked ``` Where continuity is not valid, the receipt should identify the failure mode. Receipts are useful for failed and unresolved transitions as well as successful ones. A receipt may prove that continuity **was not established**. --- # 15. Minimal Valid Receipt ```yaml continuity_receipt: receipt: id: CR-0042 spec_version: "0.1" issued_at: 2026-09-22T19:42:00+09:30 predecessor: id: STATE-0041 successor: id: STATE-0042 transition: id: T-0042 intent: deploy build 8.4.1 authority: source: release-policy-v3 actor: operator-17 scope: production-deployment status: current invariants: preserved: - service_identity - audit_lineage effects: expected: - production build becomes 8.4.1 observed: - production build is 8.4.1 evidence: - ref: evidence://runtime-query/0042 acceptance: status: accepted accepted_at: 2026-09-22T19:41:00+09:30 continuity: status: valid ``` --- # 16. Canonical Full Form A fuller representation should retain all of the same semantics while adding explicit source references, digests, actor roles, verification methods, acceptance authority, scope, warnings and failure fields. --- # 17. Integrity A receipt should be capable of having its own integrity verified. Recommended mechanisms include: ```text cryptographic digest digital signature append-only storage signed ledger entry trusted timestamp ``` Integrity protection establishes that the receipt has not been altered since issuance. It does not establish that the receipt was correct when issued. Cryptography can prove that nonsense has remained faithfully unchanged. --- # 18. Evidence Binding A receipt may reference external evidence rather than embedding it. Where evidence is external, the receipt should bind to it through a stable identifier or digest. This enables the system to verify that the referenced evidence remains the evidence originally used during acceptance. --- # 19. Scope Every receipt must identify the scope in which its continuity claim applies. The receipt asserts: > This successor is a legitimate continuation of this predecessor **within this specified scope**. This prevents continuity from becoming an unjustified global boolean. --- # 20. Conditional Acceptance Some successors may be accepted subject to explicit conditions. Conditions must have operational meaning. --- # 21. Revocation A previously issued receipt may later cease to support current governance. Revocation does not erase the receipt. Instead, a later continuity event records that its acceptance status has changed. The original receipt remains part of history. Its status changes. This preserves lineage without pretending earlier acceptance never occurred. --- # 22. Supersession A valid receipt may also be superseded normally by later accepted succession. ```text CR-0041 ↓ CR-0042 ↓ CR-0043 ``` Each receipt proves one step. Together they form a continuity chain. A receipt remains historically valid after supersession unless later revoked. Therefore: ```text superseded ≠ invalid ``` --- # 23. Failure Receipts A receipt may also record failed continuity. This receipt does not establish legitimate succession. It establishes why legitimate succession failed. That distinction makes failed transitions auditable without allowing them into governing lineage. --- # 24. Receipt Chain A continuity chain may be represented as a sequence of linked receipts. ```text STATE-0001 │ CR-0002 │ STATE-0002 │ CR-0003 │ STATE-0003 ``` Each receipt links exactly one accepted predecessor-successor relationship within a defined scope. --- # 25. Forks Where branching is legitimate, multiple receipts may reference the same predecessor. This does not necessarily indicate conflicting succession. The receipts must state their scopes or branch status. Conflicting succession arises only when incompatible successors claim authority over the same exclusive scope. --- # 26. Merge Where multiple valid branches merge into a new accepted state, the successor may require multiple continuity antecedents. The base v0.1 model assumes one primary predecessor per receipt. A merge may identify a primary predecessor plus additional antecedents, or use a future multi-predecessor extension. --- # 27. Human-Readable Form A receipt should also be expressible in plain language. For example: > **CR-0042** records that **STATE-0042** legitimately succeeded **STATE-0041** in the production runtime. The deployment of build 8.4.1 was authorised under Release Policy v3, preserved the required service identity and audit lineage invariants, produced the expected deployment and health effects, was independently verified, and was accepted by the release controller on 22 September 2026. Human readability is useful because continuity should remain intelligible outside the machinery that generated it. --- # 28. Validation Rules A receipt claiming `continuity.status: valid` must satisfy at least: 1. receipt identity exists 2. predecessor is identified 3. successor is identified 4. transition is identified 5. authority is current and scoped 6. mandatory invariants are preserved or legitimately modified 7. observed effects are recorded 8. sufficient evidence exists for required claims 9. acceptance is explicit 10. acceptance authority is valid 11. continuity scope is explicit 12. no unresolved governing failure remains --- # 29. Receipt Invariants ## No receipt without a predecessor Except for genesis records. ## No authority without scope Authority claims must identify what they govern. ## No outcome without observation Expected effects must not masquerade as observed effects. ## No proof without a claim Evidence should identify what it supports. ## No acceptance by implication Acceptance must be explicit. ## No global continuity by default Continuity must specify scope. ## No erasure by supersession Historical receipts remain part of lineage. ## No correction by overwrite Corrections should create new records rather than silently mutate history. --- # 30. Genesis Receipt A genesis state has no predecessor. It requires a specialised receipt establishing state, identity, constituting authority, initial invariants, evidence, acceptance and continuity status. Genesis establishes the first accepted state. It does not pretend a predecessor existed where none did. --- # 31. Interoperability The Continuity Receipt should remain implementation-independent. A receipt may be represented as YAML, JSON, CBOR, a database record, a signed envelope, an event record, an API object, or a document. The representation may vary. The semantics must not. The goal is not to standardise punctuation. The goal is to standardise the **continuity claim**. --- # 32. The Receipt Rule The specification can be reduced to one rule: > **Every accepted successor should be able to produce a receipt explaining why it legitimately follows from its predecessor.** That receipt should identify: > what came before, what changed, under whose authority, what had to remain true, what actually happened, what proves it, and why the result was accepted. If a system cannot produce that explanation, then its continuity may still be real. But it is not yet established. The Continuity Receipt turns legitimate succession into something a system can carry, inspect, exchange, verify, and challenge. It gives continuity a proof object. And once continuity has a proof object, it stops being merely a story a system tells about itself.