Verify First Sample: Evidence Export Audit Package
Mechanism-first walkthrough for verifying an evidence export audit package with explicit integrity, custody, lineage, and redaction semantics.
This sample models one bounded evidence-export operation and keeps the Verify First contract intact: validate mechanism and artifacts first, then form conclusions.
Scenario
An operator exports a scoped audit package for an incident review. The package must preserve export integrity, custody traceability, artifact lineage, and explicit redaction semantics so an independent reviewer can verify what is present, what was transformed, and what was intentionally withheld.
Operation claim
The operation claim is: produce an audit package for the declared scope where artifact membership, hashes, custody events, lineage links, and redaction declarations are independently verifiable.
Execution claim
- assemble export scope in
export-scope.json - collect selected evidence references in
source-artifact-index.json - produce package payload and manifest entries
- apply redaction rules from
redaction-policy.jsonand record outcomes inredaction-map.json - emit custody events during packaging into
custody-log.ndjson
Execution answers: what action ran.
Proof claim
receipt.jsonbinds operation claim fields, scope digest, and output package digestverification.jsonrecords verifier checks over signatures, timestamps, and digest matchingchain.jsoncarries predecessor/continuity fields for lineage and replay checksredaction-proof.jsonbinds redaction declarations to redacted artifacts by digest
Proof answers: what can be verified cryptographically.
Evidence claim
bundle-manifest.jsondefines required package members and their digestscustody-log.ndjsonsupplies custody event sequence for handoff traceabilitylineage-map.jsonlinks exported artifacts to source identifiers and predecessor hashesexport-integrity-report.jsonrecords hash and completeness checks at export time
Evidence answers: what independent inputs are available to verify.
Interpretation claim
- analysts decide whether export scope is fit for the audit question
- analysts assess whether declared redactions are acceptable for the review objective
- analysts determine operational impact not encoded in signed package fields
Interpretation answers: what humans conclude from verified evidence.
Included custody artifacts
Required artifact list for audit package verification:
receipt.jsonverification.jsonbundle-manifest.jsonchain.jsonexport-scope.jsonsource-artifact-index.jsonexport-integrity-report.jsoncustody-log.ndjsonlineage-map.jsonredaction-policy.jsonredaction-map.jsonredaction-proof.jsonREADME.md
Verify now
- Run artifact verification at Verify.
- Follow verifier mechanics in How verification works.
- Validate receipt handling in Receipts and Receipt specification.
What this proves
This sample proves the exported audit package can be independently checked for digest integrity, custody event inclusion, lineage continuity fields, and declared redaction semantics using the required artifact set.
What this does not prove
This sample does not prove the original incident narrative is complete, that all possible evidence was exported, or that redaction policy choices were optimal for every downstream use case.
Trust assumptions
Trust still depends on signer key custody, timestamp and verifier runtime integrity, accurate custody event capture, and governance controls described in the Threat model.
Canonical verifier flow
This sequence is rendered from the shared verifier-flow contract used across verify-first surfaces.
1. inspect operation claim
Read the claimed operation fields (actor, target, scope, action, and policy identifiers) and confirm they match the event under review.
2. inspect raw receipt
Inspect the unmodified receipt payload, including proof stage, schema version, and signed body bytes before any normalization.
3. verify signature and timestamp
Verify receipt signature material and validate timestamp token binding, issuer chain, and accepted time window.
4. verify manifest/bundle completeness
Check that every manifest or bundle entry referenced by the receipt is present, hash-matching, and not silently omitted.
5. inspect chain continuity
Follow predecessor links across receipts to confirm continuity, expected ordering, and absence of chain breaks.
6. review remaining trust assumptions
List unresolved assumptions (key custody, timestamp authority trust, host/tool integrity, identity binding) before relying on the result.
What this proves
- The receipt can be inspected as claimed input, including raw fields used by the verifier.
- Signature, timestamp, manifest/bundle completeness, and continuity checks passed under the configured verification policy.
What this does not prove
- It does not prove the operation was correct, safe, or authorized beyond evidence represented in the receipt and referenced artifacts.
- It does not prove external organizations, identity providers, or infrastructure are trustworthy.
Remaining trust assumptions
- Signing key custody, rotation, and revocation handling remain trusted.
- Timestamp authority operation and certificate trust remain trusted.
- Verifier implementation, hash/signature primitives, and runtime integrity remain trusted.
- Identity-to-subject mapping and policy configuration remain trusted.