Evidence Bundles
What is in a WitnessOps proof bundle and how to check it offline.
A proof bundle is the portable package that carries proof artifacts from runtime to an independent reviewer.
1. Problem this page solves
Without packaging, proof artifacts end up scattered across systems, exports, and operator notes.
A verifier needs one stable package with clear integrity boundaries. This page explains what is inside a WitnessOps bundle and how that package supports offline review.
2. What you should understand after reading
After this page, you should understand:
- what a bundle contains
- which artifacts are required and which are conditional
- how the bundle supports local or offline verification
- where the bundle limits begin
3. Mechanism-first artifact order
Read a bundle in this order:
| Order | Artifact class | Typical files | Why it exists |
|---|---|---|---|
| 1 | Receipt claim | CLAIM.json, CLAIM.dsse.json | Defines the issuer-bound governed statement |
| 2 | Referenced evidence artifacts | artifacts/, referenced receipt or context files | Carries the supporting material linked to the claim |
| 3 | Signature trust material | trust/org-signing-pubkey.pem | Allows offline issuer signature checks |
| 4 | Timestamp material, when claimed | CLAIM.dsse.sha256, TIMESTAMP.tsr, TIMESTAMP.meta.json, trust/tsa-cert-chain.pem | Binds trusted time to the signed object |
| 5 | Chain or inclusion material, when claimed | receipts/receipts.ndjson, ROOT.txt, trust/log-pubkey.pem | Supports continuity and append-only publication checks |
| 6 | Manifest or index | MANIFEST.json | Anchors the full file inventory and digest integrity |
| 7 | Verification structure metadata | bundle layout + declared claim layers | Tells the reviewer which checks are expected |
Required vs conditional bundle layers
| Artifact | Status | Verification role |
|---|---|---|
MANIFEST.json | required | Detects tampering or incomplete export |
CLAIM.json | required | Declares the governed assertion |
CLAIM.dsse.json | required | Defines the canonical signed bytes |
receipts/receipts.ndjson | required | Provides the continuity substrate |
trust/org-signing-pubkey.pem | required | Enables issuer signature validation |
| Timestamp and TSA files | conditional | Required only when a trusted-time claim is declared |
| Chain or log trust files | conditional | Required only when publication or continuity claims are declared |
CLAIM.intoto.json | optional | Compatibility with attestation tooling |
4. Observed vs inferred
| Layer | What is available | Confidence boundary |
|---|---|---|
| Directly included artifacts | Files physically present in the bundle with digests, signatures, and checkpoint references | Testable by a local verifier |
| Derived claims | Assertions drawn from successful artifact checks, for example “signed before time X” | Valid only when the matching layer material is present and valid |
| Outside dependencies | Origin conditions, upstream identity or scope correctness, capture-context fidelity | Not recreated by bundle bytes alone |
5. Trust assumptions
A bundle preserves proof artifacts. It does not recreate every condition of original capture.
Trust assumptions that remain explicit:
- bundle references accurately represent the source capture context
- upstream systems feeding identity, scope, and policy were correct
- the runtime environment and key custody were trustworthy at issuance time
- verifier trust roots are authentic
A bundle is not proof by itself. It is the transport surface for proof artifacts.
6. Next-page handoff
Next, read Verification to run the deterministic check sequence for the bundle layers defined here.
For artifact taxonomy context, see Proof Artifact Classes.