Check a decision record

New here? A record (we call it a receipt) is one file that captures a single decision: the question that was asked, the evidence in front of it, how far that evidence could be trusted, what was decided, and who signed it off. This page opens that file and works out every number in it again, from scratch. Nothing is sent anywhere. Nothing is fetched. All of it happens on your own machine, in this tab.

What this page cannot tell you: whether the facts are true. A record can come through every check and still be an honest note of the wrong thing. What the checks show is that nothing has been changed since the file was sealed, and that the conclusions really do follow from the evidence written on it.

Four answers

PASS — recomputed, same answer.
FAIL — recomputed, different answer.
UNVERIFIABLE — the check ran and could not finish, because the file does not carry what it needs. Counted separately from a pass: these are the checks that would catch a rebuilt record.
NOT APPLICABLE — the check never applied to this record. Named beside the part of the record it would have needed.

The last two are counted separately and never folded into the pass count.

Three absences, and they differ. Not applicable — the check did not apply to this record. Unverifiable — it applied, ran, and could not finish. Not implemented — this page does not perform that check; the reference verifier verify-receipt.js does, and its own table lists which. Every check this page implements is reported on every record, whatever version it is.

Paste in your own record

Paste a record here and press "Check this record". It stays on your machine.

Try to fake it

Change something in the record and watch which check catches it. The last two buttons also re-seal the file — they take fresh fingerprints, so the first two checks go green again. A skilled forger gets that far. Working the evidence out again is where they stop.

How the fingerprint was taken

The sealing rule this record was made under

Who had to sign it off

Worked out again from the record's own sign-off block

Some decisions are too big for one person. The system will not release them until a set number of named, registered people have each signed that exact set of facts. If the facts change afterwards, their signatures stop counting — because what they agreed to was the old set.

Who supplied the evidence, and were they still authorised

Signed observations, and credentials that were later withdrawn

Did anyone outside confirm the date?

Independent timestamp

A record carries the date its own operator wrote on it. That is a claim, not a proof. To turn it into a proof you send the record's fingerprint to an independent timestamping service, which signs it together with its own clock reading and hands back a small signed file (a "token"). Then the date no longer rests on your word.

Does the timestamp checker actually work?

None of the four sample records above has an independent timestamp, so none of them can show you the checker succeeding. Rather than invent one, here is the checker run on a test file, on its own bench, clearly fenced off from every record on this page.

LABORATORY FIXTURE — NOT A RECEIPT · NOT A REAL TIMESTAMP

What this is. A timestamp file we made ourselves, offline, using the timestamping tool built into OpenSSL, signed by a test authority we also created ourselves. It sits in our test suite as test/tsa-fixture.js. It belongs to no record on this page and stamps no decision anybody made.

What it proves, and what it does not. Running it proves that the checking code on this page works: it can open a real timestamp file, read what is inside, confirm the file answers the exact request that was sent, and confirm the signature was made by the certificate it was handed — and it refuses the file when one byte is changed. It proves nothing at all about any time, because we made both the file and the authority that signed it. A timestamp is only worth something when the authority is somebody with no stake in the answer.

The file as it was made

Every check below is run here, in your browser, on the raw bytes.

The same file with one byte changed

Nothing else is different. The same checker is used.

The certificate is supplied from outside the file. The checker is handed the test authority's certificate separately and told to trust that one only. It deliberately ignores the certificates carried inside the timestamp file itself: a file that vouches for itself vouches for nothing.

What even a successful run does not check. It does not trace the certificate back to a public root, and it does not ask whether that certificate has since been withdrawn. It offers no opinion on whether the stamped time is the real time — only that a named authority said so. Saying exactly what was left out is worth more than a tidier claim.

Every check, one by one

#	What was checked	Answer	What we found

Show the raw values — fingerprints, key names, versions

You do not need any of this to read the answer above. It is here so you can copy a value into another tool and check it yourself.

Show the whole file

This page works the record out again from the evidence written on it: the fingerprint of the contents, the link to the record before it, the confidence and the rule that turned it into a decision, the evidence cut-off, the rule book it was judged under, every trust score, the follow-up results behind those scores, the ceilings on evidence borrowed from other records, the sign-off requirement, any risk that was knowingly accepted, and whether anyone's credentials had been withdrawn by the time they signed.

On an independent timestamp it does less than that, and says so. It reads the timestamp file and checks that the file stamps this record and no other. It will only call the signature good when it has been handed a certificate to check it against, from outside the file. It never trusts the certificate riding inside the file, because a file that vouches for itself vouches for nothing. To check one yourself: openssl ts -verify -data head.bin -in head.tsr -CAfile ca.crt, or use the published checker (verifyReceipt(r, {tsa_trust_anchors:[pem]}), the same code as anchors.js::validateTimeStampResponse).

Patent pending — U.S. Patent Application No. 19/747,068.