Check it yourself
If you are holding a quote we sealed, an audit archive we exported, or an anchor digest we published, this page is how you check it without taking our word for anything. There is no box to paste a document into, and that is deliberate.
What this page cannot do
It cannot tell you a document is genuine. We are the party you would be checking, so an answer from us is not evidence about us — and a page that produced a green tick would be inviting you to believe exactly the thing you came here to test. What we can honestly do is give you the method and the tool, and then get out of the way.
The one useful thing a server we run can do is disagree with itself. If you already hold a digest we published, and what we say today no longer matches it, the copy you are holding is what shows it. That is the whole of the third section below.
Three things you can check
Each of these is a check you run, on your own machine, against bytes you already have.
A sealed quote
When a quote is accepted, a checksum is taken over its number, currency, totals and every line, and stored with it. Ask the business for that checksum when you accept. If a line is changed afterwards, the stored checksum stops matching the document — and you are holding the number it has to match.
An audit archive
An exported audit trail arrives as a zip containing the rows as JSON Lines and a standalone verify.php. Run php verify.php audit.jsonl. It recomputes every hash from the file, exits 0 if the chain is intact and 1 if it is not, naming the row that broke. It needs nothing installed and it does not contact us.
An anchor digest
A hash chain does not secure its own end: delete the newest rows and the rest still verifies. So the newest row's hash is fixed periodically as an anchor and published outside our reach — to an endpoint the business runs, to a timestamp authority, and onto the printed procedural documentation. Keep one, and a shortened chain contradicts it.
The method, in full
Not a summary. This is the whole construction, and the verifier you downloaded above implements exactly it — read the script rather than trusting this table.
Scroll the table sideways to see every column.
| Step | What happens | Why it is that way |
|---|---|---|
| Serialise | Every field of a record is written as its byte length, a colon, then the bytes. Absent and empty are different markers. | Length-prefixed, never delimiter-joined. With a delimiter, a value containing it can be read as two fields — so one checksum would verify two different documents. The length is read before the bytes, so it cannot. |
| Hash | SHA-256 over those bytes, together with the hash of the record before it. | Changing any field changes that record's hash and breaks every record after it. Removing one from the middle leaves a gap in the numbering, which a unique database index makes impossible to close quietly. |
| Version | The serialisation's version number is stored on every record. | A canonical form that changed would invalidate every historical hash. So it never changes: a new form is a new version, and old records keep verifying under the old one for ever. |
| Anchor | The newest record's hash is published periodically, and the anchors are themselves chained to each other. | Nothing inside a database can attest to its own end, because whoever is deleting also controls it. Chaining the anchors means a removed anchor is as visible as a removed record. |
Looking up an anchor you hold
Fetch /verify/anchor?digest= followed by the 64 characters you were given. Spaces are fine — the printed form is grouped in eights so it can be copied off paper.
You will get plain text back saying whether we still hold that anchor, which audit record it names, and whether our chain still contains that record today. It is a lookup, not a search: a partial digest is refused, because a prefix lookup would turn a 64-character question into one somebody could guess.
This is the only thing on this page we answer, and it is worth saying plainly what it is worth: on its own, nothing. It becomes useful the moment our answer stops agreeing with the copy in your hand.
What none of this proves
A list with nothing missing from it is a list nobody checked.
That a record was written at all
No hash chain can show that something happened and no entry was made for it. It shows that entries which exist have not been altered since. Nothing closes that gap, and anybody telling you otherwise is selling something.
That the newest rows are covered
An anchor attests only to records at or below the one it names. Anything written since the last anchor is attested by nothing. Anchoring more often moves that window; it never closes it.
That an unpublished anchor means anything
An anchor kept only in our own database can be revised by whoever could delete the record it anchors. It is not weak evidence — it is none. It counts only once it has reached somebody who is not us, which is why the anchor is pushed out rather than merely stored.