Mapped the whole candidate-tracking system end-to-end and stood up this loop's dashboard so every step is visible.
The registry IS one file. The 'pool' is findings/evolution/shared_data/candidate_ledger.jsonl — one JSON line per candidate — driven by the tool candidate_ledger.py. It holds 44 candidates today. Think of it as the single sign-in sheet for every feature idea.
Each candidate moves through fixed stages. identified → pending → evaluating → evaluated → promoting → promoted, with three exit doors deferred / banned / out_of_scope. Today: 21 evaluated, 11 pending, 4 banned, 3 promoted, 3 out-of-scope, 1 promoting, 1 deferred. Three features have actually shipped: bar_dispersion_entropy, bar_petrosian_fd, bar_katz_fd.
Three tests decide promotion. Parameterless (no hidden tuning knobs), Agnostic (two honest implementations agree), Orthogonal (adds information no existing column already has). A feature ships only if it passes all three; a tunable knob vetoes everything. Run cheapest-first to save the expensive bigblack compute for last.
The 'nobility / novelty check' is a 4-source check — and today it is manual. Before a candidate is worth testing we ask 'do we already have this?' against four places: (1) the py crypto production schema, (2) the patterns repo ban-list, (3) the patterns audit graveyard, (4) the evolutionary ledger / parallel sessions. Two safety nets sit on top: an attacker/defender pair and the G9 adversarial audit (which caught the Shannon forex-vs-crypto scope error). This is exactly what we are about to make fast and automatic.
We do NOT need to scan all ~399 patterns audit folders. ~80% are trading-rule/strategy audits, irrelevant to a feature. evolution.jsonl is a strategy ledger, not a feature index. Feature coverage lives in a tiny authoritative set: CH_FEATURE_BANLIST.md, ch-feature-store-manifest.json, the latest orthogonal-extension handoff, and ~2 feature-probe folders.
Two meanings of 'covered' — keep them apart. Catalogue uniqueness = 'we have no record of this' (cheap, what this campaign automates). Information uniqueness = 'it carries signal no column already has' (only the orthogonality probe on real bars can prove this). 'unique-and-pending' is a catalogue verdict + a lifecycle stage — never a claim of orthogonality.
The check must be a build-once, check-many index. Harvest a frozen covered_index once per loop from the small authoritative source set, then each candidate is an O(1) lookup — lexical + semantic + an adversarial default-deny confirm — yielding a three-way verdict covered / unique / needs-review, with a scope split (crypto-covering vs forex-informational).
1Run exhaustive SOTA web research (8 angles: ML model registries, feature stores, data catalogs, schema governance, dedup/entity-resolution, lifecycle/provenance, scientific candidate registries, reproducibility) and synthesize one robustness blueprint.
2Write the blueprint + refined intake/coverage protocol into the shared_data folder (markdown + JSONL, not HTML).
3Harden candidate_ledger.py: add a first-class coverage field, atomic/append-safe writes (fleet-race-proof), semantic + content-hash dedup, an explicit lifecycle state machine with transition guards, stronger fail-closed validation, and auto-assigned candidate numbers.
4Wire a build_covered_index.py + coverage_check.py into --preflight so a new batch comes back tagged unique-and-pending (with evidence) in seconds.
5Link this campaign from the probes hub, publish the live dashboard under /home/nasimubd/sites, and open the PR from this worktree.