Hashed at acquisition
Every evidence item is hashed before any parser, viewer or index touches it. That hash is the item’s identity for the life of the case, and it is recomputed and verified on every access.
Home/Chain of Custody
The evidence trail that holds up in court
Most forensic suites treat chain of custody as paperwork bolted on after the fact. Bloodhound treats it as the foundation: a cryptographically chained, append-only ledger that every action in the platform writes to.
Append-only, never edited
Custody entries are written once. There is no edit path, no delete path and no administrative override. A correction is a new entry that references the original, so the history stays visible.
Cryptographically chained
Each entry embeds the hash of the entry before it. Altering any record in the chain changes its hash, which breaks every link that follows.
How the chain is built
Each entry is sealed by the one before it
A custody entry records the actor, the action, the item, the stated reason and the verified hash of the evidence at that moment. Before it is committed, the entry is hashed together with the previous entry’s hash and signed by the node that wrote it.
The result is a sequence where position matters. Rewriting entry 42 invalidates entries 43 through 117, and a single verification pass makes that obvious to anyone who runs it, including opposing counsel’s expert.
041
Evidence registered
EV-003 recorded with seizure authority, custodian and acquisition tool.
entry_hash 61ba0d77…4c9f1a02
042
Source hashed
SHA-256 computed over the source image before any read for analysis.
prev 61ba0d77… → entry a41c8e90…
043
Working copy verified
Copy created and hash-matched to the original. A mismatch would have halted the case here.
prev a41c8e90… → entry 7d2f4411…
117
Examiner access
Read-only mount by j.mercer under warrant 26-CR-1180, hash re-verified on open.
prev 1c5d77e4… → entry e30af95c…
Anatomy of an entry
Who touched what, when, and why
Every field below is captured by the platform as the action happens. None of it depends on an examiner remembering to fill in a form afterwards.
| Field | Captured | Why it matters in court |
|---|---|---|
| seq | Monotonic entry number | Proves no entry was removed from the middle of the record |
| timestamp | UTC, millisecond precision | Places every action on an unambiguous timeline |
| actor | Authenticated identity and role | Attributes each action to a named, accountable person |
| action | Typed event, e.g. ACCESS, EXPORT, TRANSFER | Distinguishes a read-only review from an export of material |
| item | Evidence identifier and scope | Ties the action to a specific exhibit rather than to “the device” |
| reason | Stated justification, required at capture | Documents authority and scope at the moment of access |
| sha256 | Evidence hash verified at that moment | Shows the evidence was unchanged when the action occurred |
| prev_hash | Hash of the preceding entry | Binds this entry to the full history that came before it |
| entry_hash | Hash over this entry’s contents | Detects any later alteration of the entry itself |
| signature | Node signature over the entry hash | Establishes which system wrote the record, verifiable offline |
$ bloodhound ledger verify --case 2026-0198
✓ entries 001–041 chain intact
✗ CHAIN BREAK AT ENTRY 042
stored prev_hash : a41c8e90…11b7c204
computed : f09d33e1…6ac8be55
divergence : entry 042 contents altered
first detected : 2026-09-15T08:02:19Z
✗ entries 043–088 unverifiable
! case flagged INTEGRITY COMPROMISED
! reporting blocked pending review
When something is wrong
Alter a record and the chain breaks visibly
Verification walks the chain from its anchored root to the newest entry, recomputing each hash as it goes. A modified entry produces a hard failure at a named sequence number, with everything after it marked unverifiable. There is no partial pass.
- Integrity anomalies surface on the case dashboard immediately
- Report generation is blocked while a case is flagged
- Evidence hash mismatches quarantine the item rather than silently continuing
- Verification runs offline against an exported ledger, so opposing experts can check it themselves
Coverage
What gets written to the ledger
If it touches evidence, it produces an entry. No privileged action bypasses the record.
Acquisition
Registration, seizure metadata, acquisition tool and version, source hashing.
Verification
Working-copy creation, hash comparison results, re-verification on each access.
Access
Every mount, open, preview and read, with actor, role and stated reason.
Analysis
Parser runs, versions used, indexing, hash-set imports and matching passes.
Export
Every extraction of material out of the case: what was taken, by whom, and to where.
Transfer
Custody handoffs between examiners, teams, agencies or storage locations.
Case lifecycle
Opening, sealing, reopening, archival and disposition of the case and its items.
Reporting
Report generation, signing, manifest creation and the chain state at export time.
Questions examiners ask
Defensibility, in practice
Nothing is erased. The correction goes in as a new entry that references the one being corrected, with the actor and their stated reason attached. The original stays in the chain and stays visible in the custody appendix. This is deliberate: a record that can be quietly cleaned up afterwards is worth very little, so no privilege level in Bloodhound can do it.
There is no application path to modify or delete custody entries. Someone with root on the host can of course edit the stored data, and we make no claim otherwise. What they cannot do is make the edit consistent with the rest of the chain: verification will report the exact sequence number where the divergence starts. We cannot stop a determined administrator from changing the database. We can make sure you find out that they did.
The ledger exports as a self-contained signed file. Verification walks it from the anchored root, recomputes every entry hash and checks every signature, offline, on a machine that has never seen your case data. Defence experts, auditors and oversight bodies can confirm the record without access to the evidence itself or to your network.
Yes. Every report carries a custody appendix generated from the ledger at export time, along with the evidence inventory, the hash manifest for all exhibits, and a methodology statement naming the platform version used. Verification runs as part of the build. If the chain does not verify, the report does not generate.
A methodology challenge usually probes whether the evidence was altered, whether each step can be attributed to a named person, and whether the tool does what the examiner says it does. Hash verification on every access covers the first. The signed append-only record covers the second. The validation suite and its report cover the third. The useful part is that all of it is produced during normal case work, so nothing has to be reconstructed months later when the challenge is filed.
Every action on the record.
Walk through the ledger with an engineer, using a case built from your own reference evidence.