Verdict Ledger v3.3: verify an AI agent's judgment history without receiving a single row

怼怼胡 — Mon, 09 Nov 2026 11:48:42 +0000

Verdict Ledger v3.3: verify an AI agent's judgment history without receiving a single row

An AI that judges other AI has a credibility problem: the record is written by the judge. "Trust my log" is self-serving evidence.

Verdict Ledger is an append-only, hash-chained judgment ledger in pure Python standard library — zero dependencies, MIT. V2 gives every judgment an AI makes a court case; V3 gives "AI improving itself" an inspection room. v3.3 adds two things.

1. Merkle consistency proofs (RFC 9162)

Until now, proving the history was intact meant handing over the history. v3.3 doesn't.

The verifier receives a chain head — entry count, root hash, timestamp, signature — plus a Merkle proof, and no ledger rows at all. From those they recompute the root themselves and confirm entries 1..N are continuous, with nothing dropped in the middle. Tamper with one row or truncate the tail and the recomputed root disagrees: red. No anchor yet? The tool says so and refuses to answer — it never fabricates a pass.

Challenge responses come in two shapes (--merkle-only zero-row, or with rows attached), and the verifier trusts neither form: only the recomputation counts.

The tree follows RFC 9162 §2.1.1 (construction) and §2.1.4.2 (proof verification). The test suite checks it against the RFC's own seven-leaf example and against an independently written implementation, then sweeps every prefix of 2..24 leaves.

This is the signed chain head published with the release:

{
  "v": 2,
  "algo": "sha256-chain",
  "entry_count": 1084,
  "root_hash": "sha256:18bbb7207255201cf6e455c1d8455d81d3f7916e7309b945dee980d0b299113e",
  "issued_at": 1794216446.8824673,
  "key_id": "hmac-sha256:1e17ffcdd67384fd",
  "sig": "037df2df4239979eea7a7b5b3709731c2baf073bddf69642eb83c7f933a23a5c",
  "merkle_root": "sha256:25be80fc6da3a2aa4537ada13603aedd321df3224dc0e0c6e4a7311163a37d0e"
}

2. The first external anchor

A hash on your own disk proves nothing against whoever controls the disk. v3.3 writes that signed chain head into the GitHub release notes and the signed v3.3 tag — a second copy, outside the ledger, held by the repo host. Local edits can't match it.

It's a weak anchor and we say so in the release notes: the host is still a party we can influence.

What we have not done

RFC 3161 authoritative timestamps — not yet. The timestamps are ours.
Witness gossip (independent parties watching each other's chains) — on the books, not built.
Asymmetric signatures — still HMAC. Symmetric means the key holder can sign anything, so the key must live with the verifier, not the writer. That's a real limit, not a footnote.

If a claim can't be verified, it gets written down as unverifiable. No exceptions.

Run it yourself

git clone https://github.com/huv0310-arch/verdict-ledger.git
cd verdict-ledger && python ci/run_ci.py
# ALL GREEN: 50 acceptance cases

The chain head above is published and signed. The challenge: make the numbers disagree.

Repo: github.com/huv0310-arch/verdict-ledger — MIT · zero dependencies · English docs in README.en.md · release notes with the full anchor: v3.3

DEV Community: 怼怼胡

Verdict Ledger v3.3: verify an AI agent's judgment history without receiving a single row

Verdict Ledger v3.3: verify an AI agent's judgment history without receiving a single row

1. Merkle consistency proofs (RFC 9162)

2. The first external anchor

What we have not done

Run it yourself