Candidate Registry

How this registry works

What it is

A registry of candidate features — statistics we might compute per bar and add to the production panel. Each one costs real compute to evaluate, so this page exists to answer is this worth testing? before anyone spends it, and what did we learn? after.

It is not a results dashboard. Nothing here says a feature is good.

Where the numbers come from

candidate_ledger.jsonl   the pool, append-only + hash-chained   110 rows
substrate_register.json  can it be computed from the slice?
feature_hypotheses.json  what does it do, in plain English?
schema.sql               what actually ships in production      15 columns
        |
        v
build_registry.py  ->  feature_index.json + details/<id>.json  ->  this page

Rebuild with moon run odb:dashboard-registry. The page never fetches its rows — they are embedded, so it works from a local file with no server.

The four gates

The D·K·Q·N column is four independent preconditions for “can I run this today”, kept apart on purpose. Hover any segment for its reason.

D — Data

Does the pinned data slice contain every input this needs? 2 yes · 96 nobody checked · 0 provably missing

K — Kernel

Does an implementation exist to run at all? 20 yes · 78 not written

Q — Queue

Is it still awaiting evaluation, rather than settled or shipped?

N — Novel

Has the novelty gate confirmed it is not already in the catalogue?

Next gate is simply the first of those four that is not passing — what you would have to do next. Today 96 of 98 are waiting on a requirement declaration and 0 on an implementation, which makes documentation, not coding, this pool’s bottleneck.

Priority, and what it is not

The score ranks how informative and actionable it is to work on something next. It is not a quality score and not a prediction. A high number never means the feature is good — only that it can be tested today and that testing it would teach us something.

It is built from four components, always rendered beside it: computability, kernel presence, confidence in the written hypothesis, and expected information gain. That last one is bound to the redundancy evaluation, and the direction is deliberate: a candidate whose redundancy is already settled scores zero, because a further test teaches nothing, while one never measured scores highest, because measuring it is exactly what would inform us.

Three distinctions this page refuses to collapse

Novelty ≠ orthogonality

Novelty asks whether the idea is already in our catalogue — cheap and textual. Orthogonality asks whether it carries information our existing columns do not — expensive and empirical. Different gates, different stages.

Lifecycle ≠ result

A stage says where something sits in its process. It says nothing about whether it worked.

Unknown ≠ blocked

“Nobody wrote down what this needs” is a documentation backlog item. “The data provably does not exist” is an acquisition problem. They get different colours because they have different remedies — and the first is 96 of 98 rows here, so collapsing them would misdescribe almost the whole page.

For the same reason there is no plain orthogonal: search token. Two different fields answer that question over populations that do not overlap, so they stay apart as axis-orthogonal: (the recorded axis verdict) and redundancy: (what the rotational probe actually measured).

The views

Work queue

98 candidates you could pick up. Shipped features are excluded — a shipped feature is not work.

All candidates

All 110, shipped ones included. Nothing on this page is unreachable.

Shipped

15 bar_* columns that exist in production, read from the schema rather than from the ledger — which is why it shows 3 that have no registry row. Those are invisible to the novelty gate and can be re-proposed as new.

Searching

Type free text to match name, alias or family, or use field:value tokens. Press ⌘K for the palette.

runnable:true          can be run today
gate:substrate         waiting on a requirement declaration
gate:kernel            waiting on an implementation
kernel:available       an implementation exists
substrate:computable   every declared input is in the slice
redundancy:never       never measured against the shipped panel
axis-orthogonal:PASS   carries a recorded PASS on the orthogonal axis
confidence:high        high confidence in the written reading
stage:pending          still queued to evaluate

One caveat worth carrying

The selection universe is N = 32, and it is a floor: it counts candidates, not the cells and rotations tried inside each one. It also still includes shipped features, because a promoted candidate was a trial — the winning one. A Sharpe deflated with this N is deflated too little, never too much.

31 families are represented in the queue. Confidence describes our confidence in the written reading of the source paper, never the feature’s performance.