Don't trust us.
Check the maths.
Warden's record is designed so that you will not have to take our word for anything. The algorithm is written out below in full, and the verification tools are published and downloadable. That design is not yet deployed. The prototype backend still seals its ledger with a keyed HMAC, which means verification today would depend on a secret we hold — exactly the arrangement the design exists to remove. Both facts are on this page because a verification page that overstated itself would be self-defeating.
Warden is a design concept. This page describes and exposes a real, working verification mechanism — but there is no live fire & rescue deployment, and any records reachable from here are synthetic. Everything below is stated so it can be checked, including the parts that are not yet true.
00 What is actually deployed, today
The design below is complete. The backend has not been cut over to it. Those are different statements and this page keeps them apart.
Deployed Keyed HMAC — verification needs us
The prototype ledger is hash-chained with HMAC-SHA256 under a secret held in the same database as the evidence. That is enough to detect accidental corruption. It is not enough for an evidential claim: whoever can verify the chain can also regenerate it, and that party is us. No signing key is published, because there is not yet one to publish.
Built, not deployed Ed25519 + anchoring
The asymmetric design in §02, the key registry in §03 and the anchoring scheme in §05 are written, reviewed and tested — including the case that matters, a full-database rewrite with no private key, which fails at the first re-signed event. The migrations exist. They have not been applied, and no anchor has ever been produced.
So the honest position is: you cannot independently verify a Warden record today. What you can do is read the complete algorithm, download the verifier and satisfy yourself that the design does what it claims — and then hold us to having deployed it before any real incident data exists. That sequencing is deliberate: cutting over is cheap while the ledger is empty and expensive once it is not.
Current gaps are tracked in the open on the system status page.
01 The claim, stated precisely
Two different guarantees. They are often conflated; we keep them apart deliberately. Both describe the design — see §00 for what is running.
Integrity Nothing was altered
Every event is hashed, and every hash is chained to the one before it. Change a field, delete an event, reorder the record — and every link after it stops matching. Once deployed this is verifiable by anyone, with no key at all; today the chain is keyed, so it is not.
Authorship Warden wrote it
Each link is to be signed with a private key we hold and never publish, so that a signature verifying against the published public key could only have been produced by the real system. The key registry in §03 reports its own state — and it currently reports that no key has been published.
What this does not claim: that the record is impossible to rewrite. Whoever holds a private key can always regenerate a chain from scratch. That gap is closed by anchoring, not by signatures — and we say so plainly rather than letting the word "immutable" do work it hasn't earned.
02 The algorithm, in full
Enough detail to reimplement it from scratch and get identical bytes. This is the target design — the deployed prototype substitutes HMAC-SHA256(secret, prev || "::" || content_hash) for the chain and produces no signature.
canonical(e) = JSON with recursively sorted keys, over exactly:
{seq, ts, event, meta, actor, gate}
content_hash = SHA-256( canonical(e) ) hex
chain_hash = SHA-256( prev_hash || "::" || content_hash ) hex ← no key needed
signature = Ed25519( private_key,
"warden-ledger-v1|" || key_id || "|" || chain_hash ) base64
first event: prev_hash = "VIGIL::GENESIS"ts is compared as the stored text, byte for byte — no re-formatting, no timezone normalisation. meta is hashed as canonical JSON, so key order in the database is irrelevant. If your recomputation disagrees with ours, the record is wrong or the tooling is — either way, that is the answer you want.
03 The signing key
Published, so verification never depends on us.
Keys are append-only: a published key can be retired but never 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.
04 Verify a record yourself
Two scripts. No credentials beyond a public read key.
01 Check a chain
Recomputes every content hash, every link, and every signature — a completely separate implementation from the one that wrote the record.
curl -O https://wardendfr.com/verify/verify-chain.mjs
npm install @supabase/supabase-js
SUPABASE_URL=… SUPABASE_ANON_KEY=… node verify-chain.mjs INC-4090
# or fully offline, against an exported JSON file:
node verify-chain.mjs --file export.json02 Check the anchors
Recomputes each published digest from the raw record and verifies the anchor chain.
curl -O https://wardendfr.com/verify/verify-anchors.mjs
SUPABASE_URL=… SUPABASE_ANON_KEY=… node verify-anchors.mjsBoth scripts are plain, readable Node — read them before you run them. They only ever read. Neither can write to the ledger; the database will not permit it even with the credentials you supply.
05 Anchoring — why signatures aren't enough
A signature proves who wrote a record. It cannot prove when.
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 we publish a digest of the record, on a schedule, to places we do not control. If the record is later altered, the digest recomputed from it no longer matches what a third party already holds.
Sink 1 RFC 3161 timestamp
The digest is timestamped by an independent Time Stamp Authority. The token is stored and can be verified with openssl ts -verify against the TSA's own root — nothing of ours involved.
Sink 2 A receipt to your DPO
A copy of each anchor is emailed to the deploying service's own data-protection officer. They hold it, in their mailbox, outside our reach. In a dispute that copy is often the more practical evidence.
06 What this does not prove
The limits, stated by us before anyone else has to find them.
Scope The record, not the world
Verification proves the record is internally consistent, correctly signed, and matches what was anchored. It cannot prove that what a commander typed was true — only that it has not changed since.
Custody Key storage
The private key is held in an isolated server-side secret, not a hardware security module. Anchoring bounds the damage a compromise could do; an HSM is the next step, and it hasn't been taken yet.
Warden is tamper-evident, not tamper-proof. The claim is that alteration is detectable by anyone who checks — which is exactly why the tools to check are on this page rather than behind a sales call.
If you can break the chain, forge a signature, or make a record verify when it shouldn't, we want to know before a fire service does. Responsible disclosure →