Public audit of our chain of custody records
Every custody event on every CustodyTrack record — the moment a form is created, and each transfer after it — appends one entry to a single global chain of hash values. Each entry incorporates the one before it, so the entries only hold together in the order they were written. This page has that entire chain recomputed, from its first entry to its last, for anyone who asks: no account, no code, and no relationship with any party whose records are in it.
The recomputation reads hash values and timestamps. It does not read case numbers, item descriptions, party names, or anything else written on a form, and it returns three figures — how many entries there are, whether every link held, and when the most recent entry was written.
What the audit computes
1. It starts from a fixed genesis value
The chain has to hang from something. The first entry chains from the SHA-256 digest of one constant string, identical on every run and on every deployment, so there is no privileged starting point that only we can supply.
2. It walks every entry, in the order they were written
Each custody event — a record being created, a transfer being initiated, accepted, or cancelled — appended exactly one entry when it happened. The audit reads all of them, oldest first, with no sampling and no window.
3. It re-derives each entry's seal and compares
For every entry it checks two things: that the previous-hash the entry stored is the hash the entry before it actually carries, and that the entry's own hash is the SHA-256 digest of that event's hash joined to that previous hash. A mismatch of either kind marks the whole run as not intact.
4. It reports three figures and nothing else
How many entries it walked, whether every link held, and when the most recent entry was written. Entry count is not record count: a form created and then transferred twice contributes three entries, because three things happened to it.
What a passing result establishes — and what it does not
A cryptographic check is worth exactly what it is claimed to be worth and no more. Both halves are below, at the same size.
It establishes
- That the sequence of sealed values held today is the sequence produced when they were written. No entry has been edited, dropped, or slipped in between two others without the recomputation failing.
- That the answer is arithmetic rather than an assurance from us — SHA-256, concatenation, comparison — run against live data at the moment you ask for it, and never served from a cache.
- That anyone can ask again. There is no report to accept and no auditor to believe: a party who distrusts today's result can produce tomorrow's without our help or our permission.
It does not establish
- That anything written on a form is true. A collection time typed in wrongly is sealed as faithfully as a correct one. The chain preserves what was entered; it does not check it against the world.
- That one particular record still matches its own seal. That is a separate computation, run per record from the code printed on the form.
- That every relevant event was recorded at all. The chain can only speak about entries that exist — an event nobody entered leaves no gap for it to find.
- That alteration is prevented. Our records are tamper-evident: alteration is detectable, not prevented. The event and ledger tables reject updates and deletes outright, and the chain is what makes an alteration that got past that visible.
- Anything about admissibility. Whether a court receives a record, and on what basis, is a question for the court and the applicable rules of evidence.
How this differs from checking one record
Both checks are free and public, and they answer different questions. Running this audit does not check the document in your hand.
| This audit | Single-record check | |
|---|---|---|
| What it covers | Every entry in the one global chain, across every record on the service. | One record: its content hash, and the chain of custody events belonging to it. |
| What you need | Nothing. No code, no account, no relationship with anyone involved. | The verification code printed on the form, usually beside a QR code. |
| What is recomputed | The links between entries, from the genesis value forward to the newest one. | That record's content hash, re-derived from its stored values, then each event chained after it. |
| The question it answers | Is the whole sequence internally consistent, right now? | Is this form, the one in front of me, still what was sealed? |
To check one record instead — the form in front of you, from the code printed on it — verify a single chain of custody record.
What a failure would look like
The result panel turns red and reads that the ledger chain is not intact. It still reports the entry count and the most recent timestamp, and it does not name the entry that broke: the function returns one global answer rather than a row-by-row report, so that a failure discloses no more about any individual record than a pass does.
A red panel means at least one entry no longer matches the value computed from the entry before it. Data corruption, a partial restore from a backup, and a deliberate alteration all look the same from here. It is a reason to ask questions and to check the particular record you care about with its own verification code — not, on its own, a finding about anybody's conduct.
Two other outcomes are not failures of the chain at all. An amber notice means the audit could not run — the service was unreachable, or the request was rate-limited after ten runs a minute from one network. Neither result says anything about the entries.
Common questions
- What does the public hash chain audit actually check?
- It recomputes one global chain of hash values from end to end. Starting at a fixed genesis digest, it walks every entry in the order it was written and checks two things per entry: that the previous hash it stored is the hash the entry before it carries, and that its own hash is the SHA-256 digest of that event's hash joined to that previous hash. If every link holds, the chain is reported intact.
- Does running the audit reveal what is in anyone's records?
- No. The audit reads hash values and timestamps. Case numbers, item descriptions, collection locations, and the names of the parties are in tables it does not touch, and the result is three figures: the number of entries, whether the chain is intact, and when the most recent entry was written.
- How is this different from verifying a single chain of custody record?
- Scope and inputs. Verification takes the code printed on one form, re-derives that form's content hash from its stored values, and walks that form's own custody events — it answers whether the exhibit in front of you is still what was sealed. The audit takes no input at all and checks that the global sequence of entries is internally consistent. A passing audit says nothing specific about any one record, and a passing verification says nothing about the rest of the ledger.
- Does a passing audit mean the information on a form is correct?
- No, and the distinction matters. The audit demonstrates internal consistency: what was written has not been rearranged since. It cannot know whether the person filling in the form typed the right serial number or the right time. Consistency is not accuracy, and no hash chain has ever been able to supply the second.
- What would a failed audit mean?
- That at least one entry no longer matches the value computed from the entry before it. The cause could be data corruption, a partial restore from a backup, or an alteration. The function returns one global answer rather than naming the entry that broke, so a failure is a reason to ask questions and to check the specific record you care about with its own verification code — it is not, by itself, a finding about any person.
- Do I need an account or permission to run it?
- No. The audit is free, needs no account and no sign-in, and does not identify you to anyone whose records are in the chain. The only limit is a rate limit of ten runs a minute from one network, which exists to keep the service responsive rather than to restrict who may look.
- Am I recomputing the chain myself, or are you?
- We are, on demand: the walk runs on our servers against live data at the moment you press the button, and the response is marked never to be cached. What comes back is the outcome and the counts, not the underlying hash values — publishing every value would disclose more about individual records than their owners agreed to. What you do not have to take on trust is the answer itself, because you can ask for it again at any time, from anywhere, without telling us who you are.
How a chained log works
Reference guides on what this audit is actually checking, what a matching digest does and does not establish, and how to explain either one to a court.
Curious what is being sealed in the first place? See what an Authenticated Chain of Custody Form records.