Execution Chains
When continuity evidence is present, what it can establish, and why it is not a universal field in current WitnessOps receipts.
When is continuity evidence available, and what should I verify before treating a sequence as intact?
Execution continuity is an optional proof layer across multiple events or receipts. It is not a universal field group in every current WitnessOps receipt.
1. Current legacy receipt-profile boundary
The canonical public_exposure_review receipt uses witnessops.receipt.v0 with witnessops.verification_context.v1. It binds one proof run to a manifest digest and real manifest artifact IDs. The profile does not define ledger.stream, ledger.seq, ledger.prev_hash, or ledger.entry_hash fields.
Do not add or infer those fields when evaluating this profile. The public /verify adapter validates the exact profiled envelope and rejects unsupported top-level fields.
2. Compatibility and design continuity formats
Some compatibility receipts, retained packages, or design documents use predecessor digests, sequence numbers, hash-chained records, Merkle roots, log checkpoints, or inclusion proofs. Those mechanisms are meaningful only when the specific receipt or package contract declares them and the verifier checks the matching bytes.
An older documented ledger.* Receipt v2 model is not the canonical public_exposure_review envelope and is not accepted as a standalone current /verify format.
3. Checks for a declared chain
When a supported package declares continuity, a verifier should:
- identify the exact stream or segment boundary
- recompute each record digest under the declared canonicalization rules
- check predecessor links and sequence rules
- detect gaps, duplicates, reordering, and link mismatches within the declared segment
- verify any checkpoint, inclusion proof, or external anchor with independently obtained trust material
A receipt-only result cannot establish a chain when predecessor records and continuity artifacts were not supplied.
4. What continuity can and cannot support
| Continuity evidence can support | Continuity evidence cannot prove |
|---|---|
| Presented records link and order consistently under the declared contract | No records were omitted outside the declared segment |
| Presented bytes have no detected link or digest break | The underlying real-world actions happened exactly as described |
| A checkpoint or anchor covers the supplied segment when independently verified | Tool correctness, host integrity, or human judgment |
| Declared approval and execution records appear in a tested order | The original authority source was truthful |
5. Public result boundary
valid is appropriate only when every continuity check required by the selected mode and contract was independently completed and passed. If chain material, package bytes, or required anchors are unavailable, the overall result remains incomplete or indeterminate; passing checks over a presented subset do not establish completeness.
6. Next-page handoff
Read Receipt Specification for the current legacy-profile contract and Evidence Bundles for reconstructable package references.