Receipts
What a WitnessOps receipt is, what it proves, and how it connects to proof bundles, signatures, timestamps, and chain continuity.
A receipt is the atomic proof statement in WitnessOps. It is the smallest portable statement about a governed event that another person can check independently given trusted verification keys or anchors.
1. Problem this page solves
Security teams often share logs and screenshots, but those are hard to verify outside the team that created them.
Receipts solve a narrower and stronger problem:
- make a governed event portable
- bind that event to issuer-authenticated cryptographic material
- make tampering and continuity breaks detectable
2. What you should understand after reading
After this page, you should understand:
- what a receipt contains at a high level
- what a receipt proves and what it does not prove
- how receipts connect to proof bundles, timestamps, and chain continuity
- why receipt strength is layered rather than all-or-nothing
3. Receipt mechanism
A receipt combines four elements:
- a statement about a governed action, decision, or result
- issuer-bound signature material
- continuity linkage to the surrounding receipt stream
- references to supporting proof artifacts in the proof bundle
In practice, it tells a reviewer what happened, under whose recorded authority, and where the event sits in sequence.
4. What a receipt proves
When verification succeeds for the available layers, a receipt can prove:
- the issuer-bound statement has not been modified
- the statement exists at a specific place in continuity history
- referenced proof layers such as timestamp, inclusion, or witness checks are satisfied when present and valid
This is stronger than ordinary logging and narrower than a claim of full operational truth.
5. What remains outside receipt proof
A receipt does not prove:
- underlying tool correctness
- perfect operator or approver judgment
- uncompromised host state on its own
- the complete story if surrounding artifacts are missing
Receipt proof is about governed issuance integrity, not total knowledge.
6. Strength ladder (layered assurance)
| Level | Meaning |
|---|---|
| Signed receipt | The issuer claim can be checked |
| Timestamped receipt | The signed object is bound to trusted time |
| Receipt in a proof bundle | Surrounding integrity material is available for offline checks |
| Witnessed receipt | Declared witness or trust-policy checks also succeed |
Each level adds something. Missing higher layers means the receipt proves less, not that it proves nothing.
7. Common interpretation and failure signals
Verification focuses on concrete checks: required fields, hashes, signatures, digest relationships, and policy-declared trust layers.
Typical failure signals:
- hash mismatch → bytes changed
- signature failure → issuer authenticity not established
- digest mismatch → proof references do not line up
indeterminate→ a required outside trust condition could not be established locally
Report by layer instead of collapsing everything into one vague score.
8. Next-page handoff
Next, read Receipt Specification for the field-level technical contract.
Then continue to Execution Chains for continuity and ordering across multiple receipts.