Check the evidence bundle you were handed
Paste or upload a SPEQ Governance Evidence bundle and this recomputes every claim it can: the bundle’s own hash, each record’s content hash, the append-only chain, and whether each attestation is actually covered by the chain it points at. It resolves nothing and looks nothing up — it checks the file, and it tells you which step it could not perform.
What this page does not claim
This checks the bundle you supply — its hashes, its chain, and whether each record is covered by it. It does not look anything up, it does not establish that a record still describes a running system, and with no published issuer key it cannot establish who issued the file.
What gets checked
These are the steps the bundle carries inside itself, so a recipient who never opens this page can follow them with any SHA-256 tool. Step 3 is the one that matters and the one an outsider cannot perform today — verifying a signature needs the issuer’s public key, SPEQ publishes no key directory, and a directory nobody has ratified would be an authority claim SPEQ has not earned. It is reported as not checked rather than skipped quietly.
- Check bundleHash — the JCS/SHA-256 of this bundle with bundleHash removed. It proves the bundle arrived whole; it proves nothing about the records inside it.
- For each record, recompute the JCS/SHA-256 of the record with its verification block removed. It must equal verification.content_hash. A mismatch means the record was edited after issue.
- Verify verification.signature.value (ed25519, base64) over the hash you recomputed in step 2 — NOT over the value in content_hash. An issuer who edited a record could restamp that field; they could not produce a matching signature without the key.
- Walk the audit chain: each record's prev_record_hash must equal the previous record's record_hash, sequences must be dense from 0, and the first prev_record_hash must be 64 zeroes.
- Confirm each attestation's verification.audit_anchor.record_hash appears in that chain. An attestation anchored to a record the chain does not contain is not covered by it.
- Read limitations and notCovered below before relying on any of the above.
THE BUNDLE
The bundle is checked and discarded. Nothing is stored and nothing from it is logged. It is checked on SPEQ’s server because the canonical hash runs there, so the file does leave your machine — if you would rather it did not, the bundle carries its own verification steps and you can follow them with any SHA-256 tool.
WHAT A CLEAN RESULT STILL DOES NOT ESTABLISH
Carried here in the same words that travel inside every bundle. The first one is the largest: the chain is self-anchored, so whoever holds the store could produce a consistent chain saying anything. Only external anchoring of the head hash would change that, and SPEQ does not implement it.
- That the chain was not rewritten wholesale. It is self-anchored: whoever holds the store can produce a consistent chain saying anything. Only external anchoring of the head hash would change that, and SPEQ does not implement it.
- That the tool behaved correctly, or that a prediction is right. SPEQ records what was run and against what criteria; it does not validate the tool or approve its use.
- That the operator's declarations are true. Intended use, context of use and criticality are stated by the operator and carried verbatim; SPEQ checks they are present and internally consistent, not that they are accurate.
- That the regulations named are the only ones that apply. The applicability determination covers the frameworks it names and says so; it is not legal advice.