Provenance and custody · written for counsel
What the hash proves, and what it does not.
This page is for the person who has to put an exhibit in front of a tribunal. It states the fields we record, the procedure receiving counsel runs without us, and the limits of what a hash can establish.
What a hash is
One paragraph, plainly
A hash is a short, fixed-length value computed from a file. Change one pixel of a tally-sheet image and the value changes completely; leave the file untouched and the value recomputes identically on any machine, in any year, with no contact with us. A hash therefore establishes that a file is the same file that was hashed. It does not establish who created the file, when they created it, or that what the file depicts is true — those come from the custody ledger, the certification, and the underlying record.
Hashed at capture
What is hashed, at the moment of capture
- The tally-sheet image bytes, exactly as captured, before any processing.
- The capture metadata record: aggregate unit key, capturing role, device class, captured-at timestamp in UTC.
- Both hashes together, so the image and its circumstances cannot be separated later.
- No individual identity is hashed, because none is collected. The record names a role, not a person.
Chain to a root
How records chain to a root
Each verification record carries two hashes: the hash of the artifact it verifies, and the hash of the record immediately before it. The records therefore form an ordered chain, and a single value — the chain root — is computed over the ordered part hashes and written into the manifest.
- Alter a record and its own hash changes, so the next record no longer matches.
- Remove or reorder a record and the chain root changes.
- The root is therefore a single value counsel can read into the record, and any later change contradicts it.
The manifest
What the manifest lists
- Standard
- The bundle standard and version, erm_evidence/1, so the index is fixed and testable.
- Parts
- Every part of the bundle, in order, each with its SHA-256. A part that could not be produced is listed with the reason it is absent.
- Chain root
- The single value computed over the ordered part hashes.
- Certifier
- A hashed generator reference. Integrity is checked by the delivery hash — a SHA-256 over items, chain_root and bundle_id — recorded in the custody record.
- Generated at
- The generation timestamp, in UTC, with the zone stated rather than implied.
Custody ledger
The columns a certification needs
These are the fields an FRE 902(13) or 902(14) certification rests on, and the fields SWGDE recommends for handling digital evidence. The ledger is delivered as part 08 of the bundle. The row below is a labelled sample from a CI fixture.
Sample · CI fixture · not live
| Item id | Transferor | Transferee | Date / time UTC | Purpose | Acquisition hash | Verification hash | Certifier |
|---|---|---|---|---|---|---|---|
ITEM-0412-A | Field capture role 04 | Verification role 02 | 24 Jun 2026 08:12 UTC | Human confirmation | sha256:7b31… | sha256:2d90… | Certifying role 01 |
Sample row from a CI fixture. It corresponds to no contest, no station, and no person.
Offline verification · 5 steps
How receiving counsel verifies, without us
- Recompute the delivery hash (SHA-256 over items, chain_root, bundle_id) and compare it with the custody record.
- Recompute the SHA-256 of every part and compare each with the manifest.
- Recompute the chain root from the part hashes and compare it with the manifest root.
- Re-fetch the official-record snapshot URL and compare its content hash.
- Replay the reconciliation report against the capture set and the N/A log.
Every step uses standard tools on the delivered files. No Veridian service, account, or network call to us is required at any point.
Step 02, run here Sample · CI fixture · not live
Compare a value with the manifest entry for part 01
This panel compares text you paste with one manifest entry from a synthetic CI fixture. It hashes nothing, reads no file, and corresponds to no engagement. It exists so the procedure on this page can be seen once before it matters.
Manifest value, part 01 (sample · CI fixture · not live)
sha256:9f2c04ae7b312d90e417aa0631f86c2b5d418ac37e90b214cf05d6a1938be47c
What tampering looks like
Three cases, and the step that catches each
Case 01 · step 02
A page was altered
One tally-sheet image is edited after capture. Its recomputed SHA-256 no longer matches the manifest entry, and the part is identified by name.
Case 02 · step 03
An entry was removed or reordered
A capture entry is deleted or moved. Each part hash still matches, but the recomputed chain root does not match the manifest root.
Case 03 · step 04
The official snapshot was substituted
The official-record snapshot is swapped for another document. The re-fetched content hash does not match the hash recorded at fetch time.
These three cases are constructed and detected on every CI run against a synthetic bundle. Detection beyond these three cases is not claimed.
Due diligence
How would this stand up?
- Is the exhibit the same file that was delivered? What the manifest lists →
- Can we check it without relying on Veridian? Offline verification, five steps →
- Who handled the artifact, and when? The custody ledger columns →
- What happens if a page was swapped? What tampering looks like →
- What does the hash not prove? What a hash is →
- Why is a figure missing from the report? Refusal rules and reason codes →
Request an engagement
Tell us the contest, the date, and the artifact you need. We reply with scope, refusal conditions, and a price against the published floor.