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

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

Iteration 07 — Promotion machine-enforced + the registry is now /registry:* commands DONE

A candidate can no longer be promoted without evidence, and every registry capability is now a discoverable slash command with a one-glance health check — making the PR capability-complete per the Eon standard.

✅ What has been grounded

Promotion is now machine-enforced, not convention. Moving a candidate to promoting is refused unless all three axes PASS (parameterless + agnostic + orthogonal); moving to promoted is refused unless it has a production bar_* column. Verified: the block path fires (e.g. a row with parameterless=FAIL is blocked), the allow path works when all three PASS, and promoted without a bar_ alias is blocked.
The registry is now discoverable as /registry: commands. Per the Eon slash-command standard, every capability is one command away: /registry:novelty, /registry:doctor, /registry:check-full, /registry:validate, /registry:transitions, /registry:migrate, /registry:self-test. Backed by a mise task file (the description SSoT) + committed .claude/commands/registry/ wrappers, registered in .mise.toml.
A one-glance health check (the mandated :doctor). /registry:doctor reports rows/stage counts, content-hash coverage (44/44), the needs_review list, transition-table sanity, novelty-engine presence, and validate — all green right now. /registry:check-full runs the novelty self-test (8/8) + validate + doctor together.
Verified end-to-end; real ledger untouched. mise tasks lists all 7 registry tasks; registry:check-full passes; the promotion-guard block/allow/alias paths were exercised on a throwaway copy. The live 44-row ledger stayed exactly 44, still valid.

➡️ What I am doing next

1
Implement P2/D5 fully: stamp each axis verdict with an input_lock (data snapshot + code SHA + params hash + harness version) + subject_digest, so a verdict cannot be reused on a different data window and the → promoting guard also requires a complete lock + leakage gates.
2
Implement P2/D6: hash-chained, tamper-evident history (any out-of-band edit to a past row becomes detectable).
3
Implement D4: stable opaque spec-hash ids (id minted from the content hash; num demoted to an auto display ordinal).
4
Optional: enable the semantic Tier-3 (offline embedding) for abbreviation synonyms.

🎯 How this moves us toward the end goal

The registry is now a robust, discoverable, self-checking system: promotion can't happen without the three-axis evidence, every capability is one slash command away, and health is a single glance. This is the 'high-quality candidate tracking' you asked for — and because the new capability is surfaced as discoverable /registry:* entries with the mandated :doctor and :check-full, the PR is now capability-complete by the Eon standard. The remaining P2/D4 work hardens trust (verdict pinning, tamper-evidence) but the registry is already safe, fast, and easy to track stage-by-stage.

The /registry:* commands

commandwhat it does
/registry:novelty "NAME"catalogue-uniqueness verdict: covered / unique / needs_review
/registry:doctorhealth + enumerate (rows, stages, hash coverage, needs_review, validate)
/registry:check-fullall gates: novelty self-test + validate + doctor
/registry:validatefail-closed ledger validation
/registry:transitionsprint the legal lifecycle transition table
/registry:migratebackfill dedup + content hash (idempotent)
/registry:self-test8 novelty-engine assertions on the live catalog
Promotion guard (enforced): → promoting needs parameterless+agnostic+orthogonal all PASS · → promoted needs a bar_* production column.
← Iter 06Iter 08 →