How is a Decision Dossier tamper-evident, and can I verify one independently?

[ocularminds]

"Tamper-proof evidence" is easy to claim and hard to substantiate. Concretely: what makes a Decision Dossier tamper-evident, what algorithms are involved, and can an auditor who doesn't trust Decionis verify one independently?

[ocularminds]

Short answer: an Ed25519 signature over a canonical serialization of the dossier, verifiable offline against a published JWKS — with a zero-dependency verifier you can run yourself.

We say tamper-evident, not tamper-proof, and the distinction is deliberate. Nothing stops bytes from being altered; what the design guarantees is that altered bytes stop verifying.

The mechanism

1. The dossier document is canonicalized — object keys sorted recursively, arrays and scalars left in place — so the same logical document always produces the same bytes.
2. SHA-256 over those canonical bytes gives canonical_document_sha256.
3. An Ed25519 detached signature is produced over the same bytes, encoded base64url, and carried in the proof bundle along with the key_id that signed it.
4. Signed sub-documents are addressed by RFC 6901 JSON Pointer, so a verifier resolves exactly the document that was signed rather than guessing at scope.

Public keys are JWKs (kty: "OKP", crv: "Ed25519", alg: "EdDSA") published at /.well-known/decision-dossier-jwks.json. Rotation uses JWKS overlap — the previous key stays published through a verification grace period so historical dossiers keep verifying after a cutover.

Verifying it yourself

@decionis/verify is a standalone CLI and library with no runtime dependencies — it uses only Node's built-in node:crypto, so there is no supply chain to trust beyond Node itself.

npx @decionis/verify https://decionis.com/public/decision-dossiers/<id>

Fully offline, once you hold the dossier and the key set:

npx @decionis/verify --file dossier.json --jwks ./jwks.json

Exit code 0 means verified, 1 not verified, 2 a usage or I/O error. It performs three checks: the key_id resolves to a published key (including rotated predecessors), the SHA-256 of the canonical document matches, and the Ed25519 signature is valid over those bytes.

Honest limits — worth knowing before you rely on it

• Bootstrap isn't offline. You need the dossier and the JWKS. Once you've archived both, verification needs no network and no Decionis involvement — but obtaining them initially does.
• A signature proves authorship and integrity, not time. It shows the document is intact and signed by the named key; it does not by itself prove when the decision was made.
• Cross-language verifiers need care. The canonicalization delegates escaping and number formatting to JavaScript's JSON.stringify. If you write a verifier in another language, match that behaviour exactly or you will produce different bytes and a false negative.
• Ledger-chain verification is a separate, stronger check. Dossiers link into a SHA-256 hash-chained audit ledger; confirming that linkage requires the ledger itself, so it isn't part of the standalone offline check.

If you're evaluating this for a compliance use case and need a guarantee we haven't described here — external anchoring, a timestamp authority, customer-held keys — ask in a new discussion. We'd rather tell you what isn't there than let you assume it.

---

Related: What is Decionis, in plain terms? · How policies are managed and versioned · Where Decionis sits in the stack

Have a different architecture or integration question? Start a new discussion — we answer publicly whenever we can.