DashboardThree-Axis ProbesCandidate Registry Robustness

opendeviationbar-py · three-axis probes · loop campaign

Candidate Registry Robustness

A self-paced loop that makes the candidate registry — the sign-in sheet that tracks every feature idea stage-by-stage — more robust, and turns the slow manual "is this already covered?" check into a fast, automatic, evidence-backed pre-filter. Each iteration below explains, in plain language, what has been grounded, what is next, and how it moves us toward finding new orthogonal features.

Why this matters: the expensive step is testing a candidate for orthogonality on real market data. Re-testing something we already shipped or ruled out is pure waste. This loop guarantees that before any candidate reaches that step it is proven catalogue-unique (not already in the project) and carries an explicit lifecycle status.

Iterations

#iterationstatusheadline
01Grounding the registry + standing up the campaignDONEMapped the whole candidate-tracking system end-to-end and stood up this loop's dashboard so every step is visible.
02SOTA research synthesized into a robustness blueprintDONESurveyed 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.
03Operator steer — Novelty ≠ Orthogonality (terminology locked)DONEThe operator caught a conflation in iteration 02: novelty and orthogonality are two DISTINCT gates. Locked the definition and corrected every artifact that blurred them.
04P0 shipped — the novelty gate is now runnable, tested codeDONEBuilt the three-tier novelty dedup engine (the fast catalogue-uniqueness pre-filter) as a stdlib-only module and verified it against the real 44-candidate catalog — 8/8 checks pass.
05Novelty gate wired into the ledger + fleet-safe writes (D2)DONEAdding a candidate now AUTO-runs the novelty check and records the result, and the ledger can no longer be corrupted or lose appends when multiple sessions write at once — verified end-to-end without touching the real ledger.
06Lifecycle moves now policed (D3) + provenance backfilled onto all 44 rowsDONEStage changes are now checked against a legal transition table (illegal jumps are refused), and every existing candidate was stamped with a content-identity hash so the dedup system covers the whole catalog.
07Promotion machine-enforced + the registry is now /registry:* commandsDONEA 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.
08Tamper-evident, hash-chained history (P2/D6)DONEEvery change to a candidate is now a hash-chained event — editing any past entry out-of-band breaks the chain and the registry detects it. Backfilled onto all 44 rows and verified.
09Verdicts pinned to a data/code snapshot — evidence before promotion (P2/D5)DONEA 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.
10Collision-proof IDs + typo-proof validation + a README — blueprint substantially completeDONENew 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.
11Semantic Tier-3 (abbreviation expansion) — the last gap closed, blueprint completeDONEThe novelty gate now also catches abbreviation synonyms (e.g. A-MF-DFA ≡ Asymmetric MF-DFA) — dependency-free, conservative, flag-for-review. Every blueprint dimension is now implemented.

The end goal (so direction is checkable)

Discover new orthogonal candidate features for the Open Deviation Bar, cheaply and without duplication. This campaign hardens the registry and the coverage check that gate the discovery loop — if an iteration is not making that pre-filter faster, more robust, or better tracked, the loop is off-course.