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

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

Iteration 02 — SOTA research synthesized into a robustness blueprint DONE

Surveyed how 8 mature ecosystems keep a registry trustworthy, then combined them into one concrete, prioritized hardening plan for our ledger — now written into the shared-data folder.

✅ What has been grounded

We did NOT invent 'robust' — we grounded it in 8 fields. A 9-agent research sweep studied how the best registries in the world stay trustworthy: ML model registries (MLflow, W&B, DVC), feature stores (Feast, Tecton), data catalogs (DataHub, OpenLineage), schema governance (Confluent, event-sourcing), dedup/entity-resolution, lifecycle/provenance standards (W3C PROV, FAIR), scientific registries (InChIKey, HGNC, PubChem), and reproducible systems (Git, Nix, Certificate Transparency).
'Robust' now means four concrete guarantees. (1) No candidate is ever double-evaluated — identity by content, plus a review band. (2) No entry is ever silently lost or half-written when multiple sessions run at once. (3) No illegal or unproven status change can happen. (4) Every status and verdict is reproducible and tamper-evident. If the registry delivers these four, it is robust — otherwise it is not.
The biggest wins are dedup + safe writing (P0). Borrowing from chemistry's InChIKey and DVC: identify a candidate by a content hash of its definition, not its name — so 'Permutation Entropy' and 'Ordinal Pattern Entropy' resolve to the same thing, and an exact duplicate is caught in one dictionary lookup. Borrowing from databases: make the ledger an append-only log with a file lock + atomic rename, so the parallel bigblack panes can never clobber each other (the failure class behind the old 29,908-duplicate incident).
Identity and lifecycle must be separated. From MLflow/W&B/HGNC: a candidate's id is permanent and never reused; its stage is a movable pointer. Promotion becomes flipping a pointer (an appended event), never editing a winning row. Stage moves are policed by an explicit transition table — banned → promoted simply cannot happen.
Promotion gets machine-enforced, not trusted. From schema-governance + reproducibility: a candidate can only enter promoting if all three axes PASS, the verdicts are pinned to an exact data/code snapshot, and both leakage gates pass. A stale or unprovenanced verdict cannot promote — this is what makes an orthogonality claim defensible. (Two DISTINCT gates: novelty = catalogue-unique against the chronicles, the earlier dedup gate; orthogonality = information-unique against existing columns, this gate. A novel candidate is not automatically orthogonal.)
The blueprint + raw evidence now live in shared_data. Design SSoT: findings/evolution/shared_data/REGISTRY-ROBUSTNESS-BLUEPRINT.md. Raw 8-angle evidence: registry-sota-research.json. Everything is implementable in pure Python over the JSONL — stdlib + a few pure-wheel libraries, no external services.

➡️ What I am doing next

1
Implement P0 first in candidate_ledger.py: the three-tier dedup funnel (content-hash → blocked lexical → optional semantic, emitting covered/unique/needs_review) and the append-only + flock + CAS + atomic-rename write path.
2
Add a one-time migrate() that upgrades the existing 44 rows in place (computing content hashes + stable ids, keeping old ids as aliases).
3
Then P1 (lifecycle transition table + opaque spec-hash ids) and P2 (input-lock verdict pinning + hash-chained provenance history).
4
Surface /registry:doctor and /registry:check-full per the Eon slash-command standard; emit iteration-03 HTML and re-sync the live dashboard.

🎯 How this moves us toward the end goal

This iteration converts a vague goal ('make it robust') into a grounded, prioritized, implementable plan, so we are not guessing. The P0 pieces directly serve the end goal: content-hash dedup makes the 'is this already covered?' check both fast (O(1) exact, blocked near-dup) and correct (catches renamed duplicates), and the safe-write path means the discovery loop can run many candidates in parallel without corrupting the pool. In short: the registry is about to become a trustworthy, high-speed gate in front of the expensive orthogonality test — exactly what lets tomorrow's discovery loop move fast without waste.

The six hardening dimensions (prioritized)

#priorityweakness todayborrowed fix
D1P0dedup is name-only (misses renamed dups, false-fires)content-hash + blocked lexical + review band (DVC, InChIKey, Fellegi–Sunter)
D2P0full-file rewrite races the fleet (lost/half writes)append-only + flock + CAS + atomic rename (event-sourcing, Stripe idempotency)
D3P1stage is a free string; any move is legalFSM transition table + per-edge guards (ISO/IEC 11179, ClearML)
D4P1manual num collides; id tied to display numberstable opaque id from content hash, never reused (HGNC, CAS)
D5P2verdicts not pinned to an input snapshotinput-lock + subject digest, auto-invalidate on drift (Nix, in-toto)
D6P2history is a soft list, no integrityhash-chained PROV/RO-Crate events (W3C PROV, Certificate Transparency)
Full design: findings/evolution/shared_data/REGISTRY-ROBUSTNESS-BLUEPRINT.md · raw evidence: registry-sota-research.json (8 domains, 9 agents).
← Iter 01Iter 03 →