DashboardThree-Axis ProbesCandidate Registry Robustness › Iter 10

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

Iteration 10 — Collision-proof IDs + typo-proof validation + a README — blueprint substantially complete DONE

New candidates now get a collision-proof id automatically, stray/typo fields are rejected, and a README ties the whole subsystem together. All six robustness dimensions are implemented.

✅ What has been grounded

New candidates get a collision-proof id automatically (safe D4). --add no longer needs a hand-typed --num: it auto-assigns the next free number under the lock and refuses an id collision. (Decision: the 44 existing ids are deliberately not re-minted — re-keying rows referenced across the repo + live dashboard is risky for marginal benefit, since content identity already lives in spec_hash.)
Typos and stray fields are now rejected (structural validation). --validate flags any unknown top-level field (e.g. a misspelled key) and type-checks aliases/history — fail-closed. Since jsonschema is absent in the environment, this is pure stdlib. Verified: an injected typpo_field is caught (unknown field(s) ['typpo_field']).
The registry is now well-organized and self-documenting. A README navigator (REGISTRY-README.md) maps the files, the /registry:* commands, the six robustness features (D1–D6, all implemented), the FSM lifecycle, and the new-candidate flow — so anyone can pick it up fast.
Verified end-to-end. --validate on the real ledger PASS; --add without --num auto-assigned cand-0064; a covered name was refused; the typo guard fired; the real 44-row ledger was untouched.

➡️ What I am doing next

1
Closing pass: a final /registry:check-full and mark PR #535 ready for your review — the blueprint is substantially implemented.
2
Optional (only if you want it): enable the semantic Tier-3 (a small offline embedding model) to catch abbreviation synonyms like A-MF-DFA ≡ Asymmetric MF-DFA.

🎯 How this moves us toward the end goal

The registry is now a complete, robust, well-organized, self-documenting system: a fast novelty pre-filter, fleet-safe writes, an FSM-guarded lifecycle, evidence-gated promotion, tamper-evident history, collision-proof ids, and typo-proof validation — all discoverable as /registry:* commands. This is the high-quality candidate tracking the campaign set out to deliver: tomorrow's discovery loop can register, dedup, and track candidates at speed, in parallel, without waste, double-evaluation, or corruption — and only spend the expensive orthogonality compute on candidates that are genuinely new to the catalog.

Robustness scorecard (all implemented)

dimensionstatus
D1 — novelty dedup funnel (content-hash → lexical → review band)DONE
D2 — fleet-safe writes (append + flock + atomic rename)DONE
D3 — lifecycle FSM transition guardsDONE
D4 — collision-proof ids (auto-num; spec_hash identity)DONE (safe subset)
D5 — verdict input-lock pinning + evidence-gated promotionDONE
D6 — tamper-evident hash-chained historyDONE
+ structural (typo) validation · /registry:* discoverability · READMEDONE
Navigator: findings/evolution/shared_data/REGISTRY-README.md · design: REGISTRY-ROBUSTNESS-BLUEPRINT.md · all gates: /registry:check-full.