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

# audit a task end-to-end (GATE mode) — see examples/ for runnable scenarios
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 are release assets: gh release download v0.3.2
#  or https://github.com/goun7/veridict/releases)
veridict verify --ledger dogfood_ledger.jsonl --cert dogfood_cert.json

# 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.

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

Status & roadmap

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–C10), 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.

Contributing

Start with the issue tracker — the tracker is seeded with the project's own exit criteria:

• Independent verifier from the standard alone (exit criterion ①) — write a verifier without reading our code; where you and the reference disagree, either the standard is ambiguous or someone is wrong, and both findings earn errata credit.
• Good-first issues — e.g. canary corpus expansion (self-contained, tests included as reference).
• Errata proposals — a normative sentence that is wrong, ambiguous, or unimplementable. Accepted errata land in §14.2 with credit.

All work is governed by the receipts culture: tests and regenerated evidence over claims. See CONTRIBUTING.md.

Model

Open-core: the standard, the ledger core, and the offline verifier are Apache-2.0 — forever. Commercial offerings (hosted platform, watcher certification, enterprise integrations) build on top and never gate the open core. See docs/commercial-model.md.