The cryptographic
evidence layer for AI
Verdict seals each AI agent step routed through it into a single record anchored in Sigstore Rekor, which the regulator, auditor or insurance underwriter who has to check it can verify without trusting Verdict.
Updated · Verdict Systems Inc.
Three boundaries.
Closed by construction.
Every byte that moves through Verdict crosses exactly three boundaries. Each absorbs one source of complexity. Everything between them is deterministic.
One call per step → one Evidence Event
What ships today is an MCP connector. Your agent, or the system running it, calls verdict_create_evidence_record at each step that matters. Remote: https://verdict.systems/api/mcp. Local: npx -y @verdict-systems/mcp.
Each call carries what happened: input and output summaries or their hashes, the model provider, the source system, the event time, and the human review status.
A step that never reaches the connector is not in any record, and a single record cannot show that nothing was left out. Framework wrappers and a trace collector are not shipped.
SHA-256 · Record commitment · Sigstore Rekor
Each Evidence Event is content-addressed with SHA-256. Each Sealed Evidence Record is bound by a domain-separated record commitment, a SHA-256 hash over that one record. The wire format names this field merkle_root; it is not a Merkle tree root. The commitment is signed and anchored in Sigstore Rekor, an append-only public transparency log operated by the Linux Foundation. Batch inclusion proofs are planned for SER v0.2.
On the public sandbox the anchor is signed with an ephemeral ECDSA P-256 key generated per request; a hardware-backed Ed25519 production tier is planned. A record can link to the one before it through a prior_root reference — remove a record from the middle of a linked chain and the next link stops matching. A step that was never sealed leaves no gap to find.
Changing an anchored record so it still matches what Rekor logged would take a SHA-256 second preimage or a compromised Rekor. Sealing an invented event takes neither: the seal shows when content existed, not that it is true.
The honest boundary: Verdict proves integrity and time — that a record existed at a specific time and has not been altered since. It does not prove the factual truth of unverified input, or that the system supplying it was uncompromised. That boundary is what lets the proof survive adversarial review.
One record. Anyone can check it.
The output today is the Sealed Evidence Record itself: a file any reviewer verifies in a browser against its Rekor entry, without trusting Verdict. What each audience can do with it:
- EU AI Act Article 12 — seal the event logs a high-risk system keeps; no Article 12 report is rendered
- HIPAA — keep PHI out of the record by sealing hashes and short summaries; a BAA is planned
- FRE 902(13)/(14) — designed to support certification as a self-authenticating record in U.S. federal court; the MCP connector drafts a 902(14) certificate for counsel to review
- SOC 2 and insurers — auditor packages and insurer submission formats are planned, not built
Six review states.
Named in every record.
Every SER v0.1 record names one of six human-review states and one of nine workflow types. The published specification fixes both lists (§3), and the value sits inside the hashed record. A typed taxonomy of agent events and terminal outcomes is described in the VERDICT-001 application; it is not built.
Awaiting a reviewer's decision.
A reviewer accepted the output as produced.
A reviewer changed the output before it was used.
A reviewer declined the output.
The workflow calls for no human review.
A demonstration record; nobody reviewed it.
One command.
First SER in Rekor in under a minute.
# Claude Code: add the Verdict connector (public sandbox)
claude mcp add --transport http verdict https://verdict.systems/api/mcp
# Ask your agent to seal a step. It calls:
# verdict_create_evidence_record
# Back: the sealed record and its Rekor log index.
# Each call writes a permanent fingerprint to the public
# Sigstore Rekor log, so use test data in the sandbox.
Questions a reviewer asks.
Answered plainly.
What is a Sealed Evidence Record?
A Sealed Evidence Record (SER) is a file that holds one AI agent step: input and output summaries or their hashes, the model provider, the source system, the event time and the human review status. Each record is content-addressed with SHA-256, bound by a signed record commitment, and anchored in Sigstore Rekor, an append-only public transparency log operated by the Linux Foundation.
What does a Verdict record prove, and what does it not prove?
It proves integrity and time: that a record existed at a specific time and has not been altered since. It does not prove the factual truth of unverified input, or that the system supplying it was uncompromised. A step that never reaches the connector is not in any record. The full boundary is on what a record proves.
How do you verify a record without trusting Verdict?
Any reviewer checks the file in a browser against its Rekor entry on the verify page. Changing an anchored record so it still matches what Rekor logged would take a SHA-256 second preimage or a compromised Rekor.
How does an AI agent send a step to Verdict?
What ships today is an MCP connector. The agent, or the system running it, calls verdict_create_evidence_record at each step that matters, either remotely at https://verdict.systems/api/mcp or locally with npx -y @verdict-systems/mcp. Framework wrappers and a trace collector are not shipped.
Which rules is a Sealed Evidence Record designed around?
EU AI Act Article 12: it seals the event logs a high-risk system keeps; no Article 12 report is rendered. FRE 902(13)/(14): it is designed to support certification as a self-authenticating record in U.S. federal court, and the MCP connector drafts a 902(14) certificate for counsel to review. Auditor packages for SOC 2 and insurer submission formats are planned, not built.
The 15-slide thesis. Three forces. One window. Right now.
Origin, mission, market, moat, model. The full reasoning.
