Verify it yourself
Verify an evidence pack
on your own machine.
Download a sample pack, drop it back onto this page, and confirm every hash and signature locally. Nothing is uploaded, and the verifier is readable in this page’s source.
Sample packs
Three fictional organizations, one real export path
Each pack comes from the same export endpoint a real tenant calls, built from about 200 synthetic requests. Inside: the policy and its history, the decision register, a signed audit checkpoint, and the signed manifest that binds it all.
Healthcare
Northern Pines Clinic
Policy blocks Canadian SINs and health card numbers, warns on PHI terminology, redacts payment cards.
Download pack (25 KB)Legal
Harbour Square Legal LLP
Policy blocks explicit privilege markers and warns on litigation and retainer terms.
Download pack (25 KB)Accounting
Clearfield Accounting Group
Policy blocks SINs and warns on CRA business numbers, tax documents, and engagement-file terms.
Download pack (25 KB)-
The data is fictional; the pipeline is not
The three organizations and every event in these packs are synthetic. The export path, hash chain, checkpoint signing, and manifest signature are the shipped product code paths, exercised end to end.
-
Signed with a dedicated sample key
The samples are signed by a dedicated key with fingerprint
710c91b6581ec7ac5e9e07d4d6fec685fbf4a4e16e03cef8dafbdb960153ba2eA green result means the pack matches the key whose fingerprint is shown; deciding whether to trust that key is your step, done by comparing fingerprints.
In-browser verification
Drop a pack, read the result
Works for the samples above and for any pack a Mandate installation exports. The file is read locally; nothing is sent anywhere.
Reading the result
What a pass proves, and what it does not
-
Proved: the pack matches its manifest, and the manifest matches its key
Every file’s SHA-256 is recomputed against the manifest, and the file sets must match in both directions, so an injected or deleted file fails. The manifest carries one Ed25519 signature over every filename, hash, length, the tenant, the export window, and the completeness flags. Change any of it and the signature fails.
-
Your step: decide whether to trust the signing key
A signature proves the pack was signed by a specific key, not that the key belongs to someone you trust. Compare the shown fingerprint to one you already trust: published above for the samples, recorded at deployment for your own installation.
-
Not proved: coverage beyond the mediated path
A pack holds what passed through Mandate for the export window: in-path evidence, not an inventory of AI use across your organization. The README states the same limit, inside the signed content, so it can’t be quietly removed.
Tamper exercise
Break it on purpose
A tamper-evident record is more convincing after you have tampered with one. This takes about two minutes.
-
1. Change one character of the record
Unzip a pack, change one character of
register/decisions.json, and re-zip the files (not the enclosing folder). Drop it above: that file fails its SHA-256 check while the manifest signature still verifies. The math tells you what changed, not just that something did. -
2. Re-stamp the manifest
Now open
manifest.jsonand flip"truncated": falsetotrue, as if re-labelling a complete pack as capped, or the reverse. Re-zip and drop it: the manifest signature fails, because the completeness flags are inside the signed payload, not decoration around it. -
3. Slip in an extra file
Add any file the manifest doesn't list and re-zip. The verifier flags it: every packed file has to appear in the signed content list, so a pack can't quietly carry material its signature never covered.
If your re-zipped archive won't verify at all, check that you compressed the files themselves rather than the folder containing them; the entry paths inside the archive must stay the same (for example register/decisions.json, not pack/register/decisions.json).
Command line
Or verify without this page
Rather not trust a web page you’re verifying against? Run the script it shares its verifier with: one file, no packages, Node.js 20 or newer, readable top to bottom.
curl -O https://mandateco.ca/downloads/mandate-verify.mjs
node mandate-verify.mjs mandate-sample-evidence-pack-healthcare.zip \
--expect-fingerprint 710c91b6581ec7ac5e9e07d4d6fec685fbf4a4e16e03cef8dafbdb960153ba2eExit codes: 0 valid, 1 invalid or fingerprint mismatch, 2 unreadable file, 3 runtime without Ed25519 support. --json emits the full result for scripting. Download mandate-verify.mjs and read it first; it is the same code as this page's inline verifier, kept identical by a repository check.
The checks, precisely
How verification works
Four checks, standard primitives: SHA-256 and Ed25519. Traceability you can recompute, not a badge you take on faith.
-
Per-file hashes, in both directions
Recompute the SHA-256 of every file in the pack and compare it to the manifest's content list. Then check set equality the other way: every file in the archive except
manifest.jsonmust appear in that list. Content edits, deletions, and injected files all surface here. -
One signature over the whole manifest
The manifest carries an Ed25519 signature over a canonical payload: the ASCII tag
mandate.evidence-pack.manifest-sig.v2, the tenant id, the manifest version, the generation time and the export window bounds in Unix milliseconds, two completeness flags, then every filename, SHA-256, and byte length in ordinal filename order, with all integers big-endian. The same layout is pinned by a cross-language test vector in the product's test suites. -
Checkpoints verify on their own
Each embedded audit checkpoint is a 119-byte canonical payload (tag
mandate.audit.checkpoint-sig.v1, tenant id, window event ids, event count, Merkle root), Ed25519-signed. A checkpoint anchors a window of the per-event hash chain, so an export obtained long after the fact can still be shown unmodified. -
Two levels of specification
The pack format described here is public, and this page's source is a working implementation of it: select View Source and read the verifier. The deeper specification for recomputing the per-event hash chain row by row is shared with your auditor or security team under NDA during evaluation.