Continuity Chains & Enforcement Receipts

• ■Creates tamper-evident audit trail for governance actions
• ■Enables offline chain-of-custody validation
• ■Supports forensic reconstruction after incidents

What is a continuity chain?

A continuity chain is an append-only sequence of receipts where each receipt contains the hash of the previous receipt. This creates a cryptographic link that makes tampering detectable. If anyone modifies a receipt in the middle, all subsequent hashes break.

Receipt #1          Receipt #2          Receipt #3
┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│ prev: 0000  │───▶│ prev: abc1  │───▶│ prev: def2  │
│ hash: abc1  │    │ hash: def2  │    │ hash: ghi3  │
│ sig: ...    │    │ sig: ...    │    │ sig: ...    │
└─────────────┘    └─────────────┘    └─────────────┘

The first receipt has a null previous hash (often represented as zeros). Each subsequent receipt computes prev_hash from the previous receipt's this_receipt_hash. A verifier walks the chain and confirms every link.

What is an enforcement receipt?

An enforcement receipt is a signed record documenting a governance decision. It contains the policy artifact reference, the action taken, a reason code explaining why, timestamps, and the chain linkage. The receipt is signed by the enforcement boundary's key.

{
  "receipt_v": "1",
  "receipt_id": "sha256:...",
  "run_id": "run_abc123",
  "counter": 42,
  "timestamp": "2024-01-15T10:30:00Z",
  "event_type": "ENFORCED",
  "decision": {
    "action": "BLOCK_EXECUTION",
    "reason_code": "DRIFT_DETECTED",
    "details": "Config hash mismatch"
  },
  "policy": { "policy_id": "sha256:..." },
  "chain": {
    "prev_receipt_hash": "sha256:def2...",
    "this_receipt_hash": "sha256:ghi3..."
  },
  "signer": {
    "key_id": "abc123",
    "signature": "Ed25519:..."
  }
}

How do receipts form chain-of-custody?

Each receipt proves what the governance boundary observed and decided at a specific point. The chain links prove the sequence. Together, they form an audit trail that an auditor can verify independently. The chain proves custody of the governance state.

• ■Integrity: Signatures prevent receipt tampering
• ■Ordering: Hash links prove sequence
• ■Completeness: Monotonic counters detect gaps
• ■Non-repudiation: Signer key binds receipts to the boundary

How does offline validation work?

The evidence bundle contains the full receipt chain. A verifier loads the bundle, iterates through receipts in order, validates each signature, confirms each prev_hash link, checks for counter gaps, and emits a verdict. No network calls required.

1. 1.Load receipts from bundle in counter order
2. 2.For each receipt: validate schema, recompute hashes, verify signature
3. 3.Confirm prev_receipt_hash matches previous receipt's this_receipt_hash
4. 4.Check counter is monotonically increasing with no gaps
5. 5.Validate chain_head matches last receipt
6. 6.Emit PASS if all checks succeed; FAIL with specific error otherwise

Frequently asked questions

Deep dive topics