Don't trust us.
Check the maths.

So the honest position is: the record is tamper-evident and independently verifiable from an export, with no known issues within the reviewed scope, and events up to the latest time-stamped anchor (one whose token verifies) cannot be altered undetected after that anchor's time-stamp (check it with both verifiers, the comparison of the record and ledger exports in §04, and openssl). The newest events are not covered until the next anchor. Read the algorithm, pin the fingerprint, run both verifiers, compare the record and ledger exports as §04 sets out, check the time-stamp token with openssl, keep your own copy of each anchor, and hold us to keeping the anchors coming before any real incident data exists.

One more limit, stated plainly: an export, today, means someone signed in to the console with a staff role reading records out of the ledger (in a deployment, the service's own staff). The console has no export button yet, so an outside checker depends on whoever holds the record to hand one over, and the public access key this page uses (Supabase's anon key) cannot read the ledger at all, by design. Current gaps are tracked in the open on the system status page.

What signatures alone do not prove: that the record was not rewritten. Whoever holds the private key could regenerate a chain from scratch and every signature would still verify. That gap is narrowed by anchoring, not by signatures, and only for events an anchor already covers; §05 says what that does and does not prove. We say so plainly rather than claim more than the design delivers.

ts is compared as the stored text, byte for byte (no re-formatting, no timezone normalisation), and must be exactly what JavaScript's toISOString() produces: UTC, milliseconds, a trailing Z. meta is hashed as canonical JSON, so key order in the database is irrelevant. The first event of every chain is INCIDENT OPENED, and its signed meta carries that incident's id and reference, so a complete, honestly signed chain from a different incident cannot pass as this one. If your recomputation disagrees with ours, the record is wrong or the tooling is; either way, that is the answer you want.

This is the value to pin. It is written into this page's own source rather than fetched, so nobody who can only change our database can change it. To check a public key from an export against it without our tools, in Git Bash or any Linux shell:

Below, for convenience, is the key registry exactly as our database (hosted by Supabase in Ireland, eu-west-1) serves it. Your browser computes each entry's fingerprint and compares it with the value above; anything that does not match is marked not the published key. The list itself is never trusted.

Keys are append-only: a registered key can be retired but not deleted or altered, so signatures made years ago stay verifiable. If a key is ever compromised we rotate, retire the old id, and say so here.

Both scripts are plain, readable Node — read them before you run them. They only ever read. Neither writes anything: offline, they read only the export file you give them and make no network connection.

Where an export comes from, today: someone signed in to the console with a staff role reads the records out of the ledger (in a deployment, the service's own staff). There is no export button in the console yet, and the public access key this site uses cannot read the ledger, by design.

If we ever wanted to rewrite history, we could regenerate the whole chain and re-sign every event. Every signature would verify. That is a real hole, and cryptography alone does not close it — so a digest of the whole record is time-stamped by an authority we do not control, which signs the time at which it saw that digest. If an event up to the anchor's cutoff is later altered, removed or inserted, the digest recomputed from the record no longer matches the time-stamped one, and a new time-stamp cannot be backdated.

The first anchor was made on 1 November 2026. Its token was checked with openssl before we said so here. For the events an anchor covers, the hole above is closed from that anchor's time-stamp on, with the exception below: regenerating them would no longer match a time-stamp issued before the change. Events newer than the latest anchor, and any incident opened after it, are not covered until the next one; until then the holder of the signing key could still alter or remove them undetected. An anchor is attempted once a day, with no retry; on a day when FreeTSA does not answer, or its token fails our anchor function's check (below), the scheduled run writes no anchor and the newest events wait longer. The claim holds only for an anchor whose token verifies with openssl and whose time-stamp is minutes after its cutoff, checked with both verifiers and the comparison of the record and ledger exports (§04). The exception: someone with owner rights over the backend could rebuild the ledger and anchor it again from scratch, with a fresh, later time-stamp. That shows only against a copy of an earlier anchor kept outside Warden, so keep each anchor's digest and token when you see it: the anchor log is world-readable for that reason.

The record is tamper-evident, which is not the same as impossible to alter: alteration is detectable by anyone who checks an export of the record against the pinned fingerprint. Limits remain. Events written after the latest anchor (usually up to about a day's worth, more after a day with no anchor) are not covered until the next one: until then, whoever holds the signing key could alter them, or remove the most recent events of an incident or a whole incident opened since that anchor, without detection. An anchor is attempted once a day, with no retry: on a day when FreeTSA does not answer, or its token fails our anchor function's check, the scheduled run writes no anchor, and FreeTSA is a free service with no service guarantee. An anchor's claim needs both verifiers (verify-chain for each incident's content, verify-anchors for the anchors), the comparison in §04 showing that each event up to the anchor's cutoff has the same chain_hash and ts in the record export and the ledger export, and openssl for the token's signature and time. The anchor check needs an export of the whole ledger, which today only someone signed in with a staff role can produce. And someone with owner rights over the backend could still rebuild the ledger and anchor it again from scratch, with a later time-stamp; that is detectable only against a copy of an earlier anchor kept outside Warden. So keep your own copy of each anchor's digest and token when it is published: the anchor log is world-readable for that reason. That is why the tools to check are on this page rather than behind a sales call.