Veridict

The verdict that survived verification. | Türkçe

Veridict is a protocol and reference implementation for auditing AI with AI when humans no longer can. An append-only, hash-chained evidence ledger records every step of an audit: falsifiable claims, machine verifiers, a blind heterogeneous jury, third-party watchers, and a signed certificate that anyone can verify offline — no trust in the auditor required.

The founding premise: as AI output outgrows human review capacity, the human role is not code reviewer but risk owner. Veridict is built around that transformation — the machine owns the verdict of intelligence, the human owns the verdict of responsibility.

Why an audit ledger

• No silent passes. No evidence → INCONCLUSIVE, flagged — never a clean bill.
• Tiers, not vibes. Evidence has a fixed rank order: what a machine can check directly (W1a) beats what can be reproduced statistically (W1b), and both beat what a jury of models believes (W2/W3) — the ladder never lets doctrine overturn machine evidence, and W3 alone never verifies.
• Identity is binding. Every entry's hash binds its author; watcher manifests are signed, W1a is structurally impossible for them; a calibration ledger discounts producers whose claims were contradicted.
• Verify, don't trust. Certificates replay offline against the ledger. examples/spec_verifier.py is a verifier written from the standard alone (zero imports of this codebase) that reaches the same verdicts from the published test vectors.

Quickstart

pip install veridict-standard
# PyPI name is `veridict-standard` (the bare `veridict` on PyPI is a
# DIFFERENT project — not ours). Same package from the repo, if preferred:
#   pip install -e . && pip install pytest

# first run: who am I, what can I do
veridict --version && veridict --help

# the system audits itself: ledger → claims → jury → certificate → offline verify
python scripts/dogfood.py

# verify a certificate offline (the property third parties care about)
# ledger + cert ship as release assets: gh release download --latest
veridict verify --ledger dogfood_ledger.jsonl --cert dogfood_cert.json

# your own repo, three commands: see "Audit your own repo" below

# regenerate the standard's conformance test vectors (deterministic)
python scripts/build_test_vectors.py

# measure GATE latency against the design budget (§6.5: p95 < 30 min)
python scripts/measure_latency.py

Receipts (evidence over claims)

The self-audit badge above is regenerated by CI on every push from the actual dogfood certificate (never hand-drawn) — and it links to that certificate, which you can verify offline yourself: fetch the ledger and certificate from the latest release (gh release download or the assets list), then run veridict verify --ledger dogfood_ledger.jsonl --cert dogfood_cert.json. A failing audit turns it amber or red — worst-verdict-wins.

CI runs the suite, the dogfood self-audit, and the offline replay on every push — the receipts are regenerated, not narrated. The 1500-ledger tamper soak runs nightly (the push run exercises a 150-ledger slice).

Register a watcher in 3 commands

veridict registry init --registry r.jsonl --key-out r.key.json
veridict registry register --registry r.jsonl --manifest examples/manifests/example-security.json --key-file r.key.json
veridict registry index --registry r.jsonl --out index.json

Then audit with the external registry as authority: veridict audit ... --registry r.jsonl — revoked watchers are refused (§6.6). See CONTRIBUTING.md for writing your own.

Audit your own repo in 3 commands

The fastest way to see Veridict work on your code: write a one-file task manifest naming your checkout and the claims you want evidence about, run the audit, verify the certificate offline — then link the pair from your README. A runnable demo lives in examples/run_audit.py.

# 1) a task manifest (see examples/ and TaskManifest in veridict/schemas.py)
cat > task.json <<'EOF'
{"task_id": "my-audit", "artifact_path": "/path/to/your/repo",
 "actor_identity": "you", "intent_lines": ["DOCTRINE: modules are idiomatic python"],
 "criticality": [], "has_existing_tests": true, "pytest_args": []}
EOF

# 2) audit → ledger + certificate
veridict audit --task task.json --mode HYBRID \
    --ledger my-ledger.jsonl --cert-out my-cert.json

# 2b) or WATCH a live audit as it writes (streaming transport, §10.3):
veridict watch --ledger my-ledger.jsonl --forever

# 3) verify offline (anyone can; no trust in the auditor required)
veridict verify --ledger my-ledger.jsonl --cert my-cert.json

Want the reference implementation to run the audit for you and publish the certificate? Open an Audit my repo issue — the certificate that comes back is evidence, not endorsement (§13): anyone can replay it offline against the published ledger, and a REFUTED claim says exactly which evidence refuted it.

Audit on every push (GitHub Action)

Run Veridict inside your own CI without installing anything locally — two equivalent styles:

# style 1 — the composite action (root action.yml; appears on the
# GitHub Marketplace as "veridict audit")
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: goun7/veridict@v1
        with:
          intent: "DOCTRINE: modules are idiomatic python"
          mode: HYBRID          # GATE / WATCH / CERTIFICATE also available
          fail-on-refuted: false # flip to true once you trust the audit

# style 2 — the reusable workflow (same engine, same inputs)
  audit-wf:
    uses: goun7/veridict/.github/workflows/veridict-audit.yml@v1
    with:
      intent: "DOCTRINE: modules are idiomatic python"
      mode: HYBRID

The run uploads veridict-audit artifacts (ledger + certificate) — download once, verify forever: veridict verify --ledger veridict-ledger.jsonl --cert veridict-cert.json. See the workflow file for all inputs — notably anchor: rekor (pin the checkpoint to the public transparency log; the verify step checks the sidecar automatically) and actor-family (declare the authoring model's family and same-family jury opinions are excluded — the self-preference guard).

By default the jury runs on scripted stubs (loudly marked in the report — stubs never pretend to be judges). To bring a real model jury, the action reads the same environment as the CLI — step-level env: flows into composite steps:

      - uses: goun7/veridict@v1
        env:
          VERIDICT_JURY_URL: https://api.openai.com/v1      # any OpenAI-compat
          VERIDICT_JURY_KEY: ${{ secrets.JURY_KEY }}
          VERIDICT_JURY_MODEL: gpt-4o
          VERIDICT_JURY_URL2: https://api.anthropic.com/... # a 2nd FAMILY
          VERIDICT_JURY_KEY2: ${{ secrets.JURY_KEY2 }}      # (required: juries
          VERIDICT_JURY_MODEL2: claude-sonnet-4-5           #  need ≥2 families)
        with:
          intent: "DOCTRINE: ..."

Interoperability

Positioning vs runtime governance (e.g. microsoft/agent-governance- toolkit): those constrain agents before/during actions; Veridict adjudicates after the fact into a certificate a counterparty verifies without trusting vendor, auditor, or runtime. Directions of flow differ — a deployment can run both, and the runtime's own action logs are exactly the evidence class an audit anchors on.

Two ways a Veridict verdict reaches tooling that never heard of us:

• External anchoring — veridict audit … --anchor rekor (or in CI, the anchor: rekor action input; or veridict anchor publish) pins the certificate's checkpoint to the Sigstore Rekor public-good transparency log. The anchor proves existence at time T; authority stays with the certificate's own key. Anyone holding cert + ledger
  • anchor sidecar checks it fully offline: veridict verify --ledger L --cert C --anchor A (pinned Rekor key, no network, no trust in us). The v1 release's dogfood certificate is anchored live — see docs/receipts-anchor-v1-dogfood.json.
• SLSA export — veridict export --format vsa projects a certificate onto a SLSA v1.2 Verification Summary Attestation (in-toto Statement) so existing supply-chain policy engines can consume the verdict. The VSA is a lossy projection: it names the certificate by digest (inputAttestations) and embeds the full binding as a spec-sanctioned extension field; the certificate remains the authoritative object. Optional --sign KEYFILE wraps it in a DSSE envelope under the issuing key.
• SPDX 3.0.1 export — veridict export --format spdx emits an SPDX 3.0.1 AI-profile JSON-LD document, validated in CI against the pinned official schema. The audited artifact rides as an ai_AIPackage (identity, digest, supplier); every audit semantic — claims, evidence, jury composition, risk, Rekor anchor — rides on core Annotation/Relationship/ExternalRef elements. Deliberate limit: the AI profile models AI systems, not audit verdicts, so no ai_* field is made to carry a meaning the spec does not give it (our risk_level never occupies ai_safetyRiskAssessment — there is a test locking that refusal in). The certificationReport externalRef binds the authoritative certificate by canonical digest.

Public site

The standard and the design document are readable (and linkable) at https://goun7.github.io/veridict/ — deployed from main on every push. The launch article — "Agents already found their forum. We built the better one." — is on dev.to.

Documents

• Standard (normative draft): docs/specs/2026-09-10-veridict-standard-v1.0.md — §14.2 carries errata; errata proposals are a first-class issue template
• Standard v1.1 delta (draft): docs/specs/2026-09-12-veridict-standard-v1.1-delta.md — ratifies the WATCH transport latency sentence (D10); read on top of v1.0
• Design document (founding paper): docs/specs/2026-09-09-veridict-design.md
• Architecture: ARCHITECTURE.md — module map to standard sections
• Commercial model: docs/commercial-model.md — open-core model, growth levers, anti-corruption guardrails
• Contributing / Governance / Security: CONTRIBUTING.md · GOVERNANCE.md · SECURITY.md
• Building your own verifier (independent of this codebase, issue #1): docs/verifier-onboarding.md — closure kit: trusted-artifact table, byte-level traps list, one-command parity harness, proofs-as-behavioral-spec

Status & roadmap

Formal core (Sep 2026): every structural layer of the core is machine-checked in Lean (v4.34, kernel-only). The ladder (proofs/ladder/Ladder.lean) proves seven invariants over evidence lists of arbitrary length — fail-safe-empty, no-silent-pass, W1a-decisiveness, doctrine-can-never-topple, escalation conditions, split visibility, meta-budget — and a generated oracle (TruthTable.lean, digest-tied to the bounded receipt) re-verifies the model against all 28,080 sampled cases on every CI run; its first build caught a real model-vs-code divergence and the model moved. The ledger chaining (proofs/ledger/Chain.lean) proves six theorems over chains of arbitrary length — writer/reader agreement, prefix-closure, payload-edit and honest-remint tamper detection (the one collision hypothesis is stated, not smuggled), genesis-rooting. The anchor sidecar (proofs/anchor/Anchor.lean) proves nine theorems about certificate⇄CT cross-verification — its headline (A4): with the wrong binding, valid ECDSA signatures cannot rescue a sidecar; structural rejection is unconditional. ECDSA itself stays honest TCB: no structural proof discharges a computational assumption, so it enters the model as a disclosed opaque boolean rather than being silently "proven". Trust placement (kernel decide; disclosed native_decide for the oracle lane only) and the measured axiom footprints (C1 and I1/I7 axiom-free; the rest [propext]/Quot.sound-maximal) are disclosed in the file headers and re-printed by proofs.yml on every run — per house doctrine: receipts, not narrative.

Phase 1 (core) and Phase 2 (watcher layer) are implemented with end-to-end receipts in the dogfood run. Phase 3 (platform + standard) substrate is in place: spec draft, conformance kit (C1–C13), marketplace index, test vectors, spec-only verifier. The remaining exit criteria are external by nature:

1. an independent verifier implemented from the spec by someone else,
2. a first external production deployment,
3. ≥10 active watcher manifests on the marketplace.

Roadmap decisions are tracked in the issue tracker — the post-launch expansion plan is Roadmap v2 (#10) (launch-hygiene fixes first, then standard maturity, federation, and formal verification); the commercial model is documented in docs/commercial-model.md.