Verify a Decision Dossier without an account.

What a public corpus of signed authorization records proves, what it deliberately does not, and the exact commands — two files, one package — that reproduce every check this site makes, including the negative cases a verifier must refuse.

The claim, and its boundary first

Every authorization decision Decionis makes leaves a Decision Dossier: a signed record of what was proposed, which policy version applied, what the verdict was, who approved it, and — when the dossier is execution-bound — the exact payload and target the verdict covers. The claim this site makes about that record is that someone who does not run Decionis can verify it. Until recently that claim could only be tested by someone who had a dossier of their own, which meant an account, which meant the invitation was really “sign up, then check”.

The corpus removes that. It is a set of synthetic dossiers, signed by a key that is published on purpose, with the negative cases included. Here is the boundary before the claim: The corpus proves the verifier behaves correctly, including when it should refuse. It does not prove that a production dossier verifies — that needs a real dossier and the live JWKS, and the repository documents that check separately rather than shipping a production artifact it should not have.

Two files, one package

Clone the repository, or download the two files the command names. The verifier is on npm as @decionis/verify (0.2.0), has no runtime dependencies, and uses Node’s built-in crypto.

git clone https://github.com/decionis/agent-safe-pipeline.git
cd agent-safe-pipeline
npx -y @decionis/verify \
  --file dossiers/vectors/owned-execution-bound.json \
  --jwks dossiers/corpus-jwks.json

The run reports each artifact kind it verified — the portable artifact, the inputs snapshot, the JSON-LD, and the execution binding — and finishes with a reproduction status. Exit code zero means verified; one means not verified; two means the input could not be read. It drops into a CI job as a gate without a wrapper.

What the verifier actually checks

Each signed artifact names the document it covers, a canonical SHA-256 digest of that document, the key identifier, and an Ed25519 signature over the canonical bytes. Canonicalisation is deterministic — object keys sorted recursively, serialised as UTF-8 JSON — and the verifier also implements RFC 8785 (JCS) for artifacts that declare it. The key is selected from the published key set by identifier; the corpus ships its own key set, and a production dossier points at the live one:

https://api.decionis.com/v1/.well-known/decision-dossier-jwks.json

Two properties are worth keeping apart, because most “tamper-evident audit trail” claims blur them. A signature proves the record was not altered after it was written. Re-derivation — running the recorded inputs through the recorded policy and obtaining the same verdict — proves the answer was the one the policy required. The verifier gives you the first; the dossier page’s reproduction check gives you the second, because it needs the deterministic engine. A record can be tamper-evident and still wrong; the corpus lets you confirm the verifier will not tell you otherwise.

The cases that must fail

A corpus in which everything verifies proves only that our verifier agrees with our signer, which is not a claim anyone needs. The credibility is in the refusals, so the corpus includes them, each labelled with the failure it should produce:

• A mutated verdict

  Change one byte inside a signed artifact — flip a verdict from ALLOW to BLOCK — and both the canonical digest and the signature fail. The verifier reports both, separately, so a reader can tell tampering from a broken key.

• A grafted issuer claim

  Take the valid claim that a dossier was minted by an owned account and graft it onto another dossier. The signature breaks — and the verifier also declines to report the grafted claim, because a claim counts only inside an artifact whose signature verified. Without that rule, an anonymous mint could borrow a paying customer's provenance.

• A key the set no longer lists

  The key set keeps superseded keys through a grace window and then drops them. An artifact signed by a key outside the set does not verify, and the verifier says which key it looked for.

Regenerate the corpus yourself. The signing key is disclosed for exactly this reason: a reader who re-signs the fixtures from scratch and gets the same digests has confirmed the verifier’s behaviour without trusting anything we shipped.

What this does not prove, again

A synthetic corpus signed by a disclosed key proves the verifier. It does not prove that any real Decionis dossier verifies — that needs a real dossier and the live key set above, and the repository documents that check as a command a reader runs rather than shipping a production artifact it should not have. Nor does verification prove the decision was a good one: it proves the record of the decision is authentic, not that the policy behind it was right. The verify page lists the other things a verified signature does not prove.

The trust boundary the corpus lives inside

The repository is the reference implementation of the architecture: agents may propose actions but cannot authorise their own execution, and every authorisation leaves a verifiable record. Its documents are the ones a security reviewer wants before the code:

• ARCHITECTURE.md — the trust boundary
• THREAT-MODEL.md — abuse analysis
• FIXTURE-PROVENANCE.md — where every fixture comes from
• SECURITY-EVIDENCE.md — what has been checked, by whom

Cite it

The corpus is archived with a version DOI that identifies these exact bytes and a concept DOI that follows later releases — which is what a reproducibility claim needs, since “re-derivable” is a weaker statement about an artifact that can be edited after publication.

Jejelowo, Festus B. “Agent-Safe Pipeline: Reproducible Execution-Authority Reference Architecture and Decision Dossier Corpus.” Zenodo, version v0.1.3, 5 September 2026. https://doi.org/10.5281/zenodo.22312956.

Concept DOI 10.5281/zenodo.22312955. License Apache-2.0.