Q01
What does Verdict actually do?
Verdict seals each step your autonomous AI agent, or the system running it, sends to its MCP connector — a model call, a tool call, a policy decision, an outcome — into a cryptographically tamper-evident record: SHA-256 content-addressed, signed, and anchored to the public Sigstore Rekor log. Anyone can later check the record against its log entry without trusting you or Verdict. The connector also drafts an FRE 902(14) certificate for counsel to review. SOC 2, EU AI Act Article 12 and insurer packages are planned, not built.
Q02
What does Verdict prove — and what does it not prove?
A Verdict record, checked against its public log entry, proves what the record contained, that it has not been altered since it was logged, and when that was. It does not prove the factual truth of unverified input, who made the record, or that the system supplying the input was uncompromised. That boundary is deliberate — integrity claims are checkable by anyone; truth claims belong to the fact-finder. Proof that survives adversarial review starts by claiming exactly what it can prove.
Q03
Who is Verdict for?
Enterprises spending more than $50K per month on autonomous AI agents with active liability exposure. The buying committee is dual: General Counsel (driven by regulatory compliance, evidentiary defensibility, and discovery posture) and CISO (driven by audit trail integrity, chain-of-custody, and insurer requirements). Insurance carriers and AI-liability underwriters are a separate audience: Verdict records are built for them to check, though no carrier has adopted SER.
Q04
How is Verdict different from LangSmith, Arize, or Datadog LLM observability?
Observability tools produce mutable debugging logs for engineers. Verdict produces tamper-evident cryptographic evidence for legal, audit, and insurance audiences. A LangSmith trace is debugging data, held by a vendor and editable by whoever controls it; it was not built to be checked by a reader who does not trust the operator. Verdict does not ingest traces: your agent, or the system running it, sends each step it wants sealed to the MCP connector, and the two tools can run side by side.
Q05
How is Verdict different from AI governance tools like Zenity?
Governance tools enforce policy at runtime. Verdict seals the record of a decision — a policy decision included — when the governance tool or the agent sends it, and anchors it to a public log so a later edit is detectable. It does not prove the decision was right or that the event happened as described. Governance without tamper-evident evidence is policy theater; the two layers are complementary and can run together.
Q06
Other systems sign their receipts too. What is different about yours?
Ask where the receipt lives. In most agent systems the component that took the action also writes, signs, and stores the record of it — a self-custodied receipt. That is genuinely better than a mutable log, and for internal forensics or an air-gapped deployment it can be the right design. It stops working the moment the reader is adverse: the custodian and the interested party are the same entity, and the timestamp is the operator's own clock. Verdict seals each step when it is sent and anchors the commitment to a public append-only transparency log it does not operate, so verification runs without trusting Verdict or the operator. See /compare/self-custodied-receipts for the full pattern comparison, including the two rows where self-custody wins.
Q07
Some systems issue a zero-knowledge proof for every agent decision. Isn't that stronger than a signed record?
At the moment of issuance, yes — a zero-knowledge receipt proves the checked computation itself ran, and it hides the policy by construction. The question is what is left of it when the reader arrives. Several implementations of this pattern state in their own documentation that proofs are single-use and marked consumed once verified, and that the proving material lives on the vendor's servers and may not persist across infrastructure updates. Disputes surface years after actions; discovery requires each side to re-verify the same record independently. Verdict optimizes for that reader: sealed when the step is sent, anchored to a public append-only log we do not operate, verifiable by anyone, any number of times, for as long as the record and the log survive. The two patterns answer different questions — a proof that the rules were checked is not a record of the action itself. See /compare/ephemeral-proof-receipts for the full pattern comparison, including the two rows where the ephemeral proof wins.
Q08
Is the Sealed Evidence Record an open standard?
Yes. SER v0.1 is published under Apache 2.0 with a perpetual, royalty-free patent license to any conformant implementation. Verdict has filed six USPTO patent applications in a defensive posture — they protect the standard from being forked into a closed proprietary format, not to extract rent from adopters. None has been examined or granted. See /patents for the full filing details.
Q09
How does Verdict support FRE 902(13) and 902(14)?
Federal Rules of Evidence 902(13) and 902(14) allow electronic evidence to self-authenticate — 902(13) covers records generated by an electronic process or system, 902(14) covers data copied from a device, storage medium, or file — when a qualified person certifies the process and advance notice is given. Verdict is designed to support that certification: every Sealed Evidence Record carries the hashes and record commitment the certification describes, a record sealed on the remote endpoint carries a public transparency-log anchor, and the MCP connector drafts a 902(14) certificate for a qualified person to review and sign. Certification and admissibility are decided by counsel and the court — Verdict supplies the cryptographic foundation built to withstand challenge.
Q10
How does Verdict relate to EU AI Act Article 12?
Article 12 requires high-risk AI systems to allow the automatic recording of events (logs) over their lifetime. Verdict can seal the event records your system sends and anchor each one to a public log, so a reader can check that an entry was not changed after it was logged and when it existed. It does not make a system Article 12 compliant, renders no Article 12 report, and keeps no copy: retaining the logs stays with you.
Q11
How does the insurance integration work?
An underwriter or claims reviewer receives the sealed records themselves and checks each one in a browser against its public log entry, without trusting Verdict or the insured. Insurer-specific submission formats are planned, not built. Verdict is not an endorsed vendor or panel partner of any carrier, and no premium outcome is promised.
Q12
Can a sealed record be redacted?
Not without breaking its commitment; redaction of sealed records is not built. Keep personal, privileged or trade-secret data out of the record by sealing hashes (prompt_hash, output_hash) and short summaries instead of raw text. Only a hash of each record's commitment goes on the public log, and the public sandbox stores no records.
Q13
How fast is the seal step? Will it slow my agent?
On the public sandbox each call seals the record and anchors it to Sigstore Rekor before it answers, so the call includes that network round trip. No latency has been measured for a production deployment, because none exists yet. If a step cannot wait, call the connector after the step completes.
Q14
What languages and frameworks does Verdict support?
One interface ships today: an MCP connector. Any agent or system that can call an MCP tool can seal a step with it, remotely at https://verdict.systems/api/mcp or locally with npx -y @verdict-systems/mcp. Verdict has no SDK and no framework wrappers. A step that never reaches the connector is not in any record.
Q15
How do I start?
Two options. The free option: seal a fact of your own at verdict.systems/live-seal, or add the MCP connector to Claude with one command, and verify the result in your browser. The paid option: request a sample record built for your workflow — a fictional scenario with a real seal — within one business day.
Q16
What is the VERDICT Agent Acceptance Test?
A 10-business-day production approval test for AI agents before pilot, purchase, deployment, or expansion. Verdict stress-tests the agent across unsupported claims, tool misuse, policy breach, escalation miss, and audit gaps, then returns an evidence readiness dossier with launch gates, a SER implementation plan, and a go / conditional go / no-go memo. Verdict does not build the agent; Verdict decides whether the agent can be defended.
