Dashboard › Three-Axis Probes › Candidate Registry Robustness › Iter 09

2026-06-16-candidate-registry-robustness-sota · iteration 09 · 2026-06-16

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

1
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.
2
Add stdlib structural validation (jsonschema is absent) to reject unknown/typo'd fields on append.
3
Closing pass: cross-link the blueprint + a short README in shared_data, final /registry:check-full, and mark PR #535 ready for review.
4
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)

fieldmeaning
data_snapshot_shawhich exact data the verdict was computed on
code_git_shawhich code revision produced it
params_hashthe parameters/config used
harness_versionthe evaluation harness version
subject_digestsha256 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 08Iter 10 →