Offline Verification for Evidence Bundles

• ■Enables audit without trusting network infrastructure
• ■Produces deterministic PASS/FAIL verdicts with reason codes
• ■Validates policy enforcement, receipt chains, and bundle integrity

What is offline verification?

Offline verification is the process of validating an evidence bundle's authenticity and integrity using only the contents of the bundle itself. No external API calls, no database lookups, no timestamp authority connections. The verifier reads the bundle, checks signatures, validates the receipt chain, and emits a verdict.

This matters because it removes trust dependencies. If an auditor can verify on their own hardware, they don't need to trust your servers, your uptime, or your access controls. The cryptography speaks for itself.

Why does offline verification beat online-only trust?

Online verification systems require the verifier to contact an external service. This introduces failure modes: network outages, API deprecation, vendor lock-in, and the fundamental question of whether the service is lying. Offline verification eliminates these by embedding all necessary proof in the bundle.

What is the structure of an evidence bundle?

An evidence bundle is a portable package containing everything needed for verification: the policy artifact, signed receipts, continuity chain state, and a manifest that binds them together. The bundle format must be deterministic so that identical inputs always produce identical bundle bytes.

evidence-bundle/
├── manifest.json          # Bundle metadata + file checksums
├── policy/
│   └── policy_artifact.json
├── receipts/
│   ├── 0001.json
│   ├── 0002.json
│   └── chain_head.json
└── verifier/
    └── verify.js          # Embedded verifier (optional)

What are the determinism requirements?

Deterministic verification requires canonical serialization at every step. JSON must be canonicalized (sorted keys, no whitespace). Hashes must be computed over canonical bytes. Signatures must be computed over the same canonical bytes. Any deviation means two verifiers might produce different results.

• ■Canonicalization: UTF-8, sorted keys, no insignificant whitespace, arrays preserve order
• ■Hashing: SHA-256 over canonical bytes
• ■Signing: Ed25519 over canonical bytes with signature field omitted

What is the verification workflow?

The verifier follows a strict sequence: unpack the bundle, validate the manifest checksums, verify the policy signature, validate each receipt signature and hash chain, confirm continuity, and emit a verdict with reason codes.

1. 1.Unpack bundle and validate manifest checksums
2. 2.Recompute policy_id and verify policy signature
3. 3.Validate each receipt: schema, receipt_id, this_receipt_hash, signature
4. 4.Check chain continuity: counter gaps, prev_hash linkage
5. 5.Confirm required events present (POLICY_LOADED, ENFORCED, etc.)
6. 6.Emit verdict: PASS / PASS_WITH_CAVEATS / FAIL with reason codes

Frequently asked questions

Deep dive topics