Iteration 09 — Verdicts pinned to a data/code snapshot — evidence before promotion (P2/D5) DONE

A candidate can no longer be promoted on a stale or unprovenanced verdict: each axis verdict is now bound to the exact data + code that produced it, and promotion requires that pin to be complete.

✅ What has been grounded

Verdicts are now pinned to an input snapshot (D5). Each axis verdict can carry an input_lock — data_snapshot_sha + code_git_sha + params_hash + harness_version — plus a subject_digest (a hash of those four). A verdict without all four is 'unpinned'. The new --set-verdict ID AXIS VERDICT command records the verdict + lock as a tamper-evident history event.

Promotion now requires pinned evidence. → promoting is blocked unless all three axes are PASS and each carries a complete input_lock. Verified on a throwaway copy: three axes PASS but no lock → BLOCKED ('unpinned: parameterless, agnostic, orthogonal'); the same three with a full lock → allowed. So a verdict from a different data window can't quietly carry a promotion.

Health reporting + forward-only enforcement. /registry:doctor now reports how many all-PASS rows are fully input-locked. The gate is forward-only: existing promoted features (which predate D5) are grandfathered — not retroactively blocked. The real ledger was not mutated (D5 is enforcement + new fields, no backfill needed).

Chain integrity holds through verdict events. Every --set-verdict appends a hash-chained event; --verify-chain stayed intact after a batch of verdict writes. So the new evidence is itself tamper-evident.

➡️ What I am doing next

Implement D4: stable opaque spec-hash ids (id minted from the content hash; num demoted to an auto display ordinal), keeping old cand-NNNN as aliases.

Add stdlib structural validation (jsonschema is absent) to reject unknown/typo'd fields on append.

Closing pass: cross-link the blueprint + a short README in shared_data, final /registry:check-full, and mark PR #535 ready for review.

Optional: enable the semantic Tier-3 (offline embedding) for abbreviation synonyms.

🎯 How this moves us toward the end goal

This closes the loop on evidence before promotion: a promotion can no longer rest on a stale or unprovenanced verdict — the verdict is bound to the exact data + code that produced it, and if either drifts the lock no longer matches. Combined with the novelty gate (catalogue-uniqueness, up front) and the separate orthogonality probe (information-uniqueness, the expensive step), the registry now enforces both gates with evidence — exactly the disciplined, high-quality candidate tracking the campaign set out to build.

The input-lock (what a verdict is pinned to)

field	meaning
`data_snapshot_sha`	which exact data the verdict was computed on
`code_git_sha`	which code revision produced it
`params_hash`	the parameters/config used
`harness_version`	the evaluation harness version
`subject_digest`	sha256 of the four above — the pin

Promotion rule (now): → promoting needs parameterless + agnostic + orthogonal all PASS AND a complete input_lock per axis. Record with --set-verdict ID AXIS PASS --data-snapshot … --code-sha … --params-hash … --harness ….

← Iter 08 Iter 10 →

Campaign spoke · APPEND-ONLY loop record · regenerate via build.py · part of the Three-Axis Probes dashboard · registry SSoT: candidate_ledger.jsonl