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:
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:
receipt:
id: CR-0042
version: 0.1
Recommended form:
receipt:
id: CR-20260922-0042
spec_version: "0.1"
4. Required Fields
A valid Continuity Receipt contains:
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:
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.
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.
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.
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:
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:
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
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:
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.
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:
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.
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:
- receipt identity exists
- predecessor is identified
- successor is identified
- transition is identified
- authority is current and scoped
- mandatory invariants are preserved or legitimately modified
- observed effects are recorded
- sufficient evidence exists for required claims
- acceptance is explicit
- acceptance authority is valid
- continuity scope is explicit
- 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.
