07 Selection lessons

ROSE applied to its own retrieval. Every other stage learns from outcomes; selection learned from nothing, and it is the stage measured to be worst.

The problem they solve#

Filtering lifts precision from 28% to 48%. That second number is the one that matters: over half of what recall serves is never used. Every unused lesson spends attention, and an unrelated one can actively mislead.

A selection lesson is what a reflection pass writes after watching a session — not knowledge about the work, but knowledge about where the knowledge was:

- When the task runs the integration tests: read nodes/testing/ before running pytest
- When the task is a docs change: nothing in nodes/deploy/ applies, skip it

The next selector reads those and reaches the right set in fewer searches, or skips one it now knows is fruitless. They are written by the reflection fork, which is the only thing in the system that saw both what was loaded and how the work actually went.

Why they live outside the tree#

Selection lessons are not stored under nodes/. If they were, they would be retrieved by the very mechanism they exist to fix, and would compete with real lessons for the same injection budget. They live in .rose/routing/ and are always injected, under their own cap.

They are also the only thing retrieval now costs per prompt. The index is grepped; the rules are sent. So the cap is real: routing.max_tokens, and when it binds, the rules with the worst record of improving a selection fall out first.

The rule that keeps them small#

Every rule must be conditioned on a kind of task. A rule with no when is rejected rather than stored.

This is not tidiness. The second form was measured: annotating candidates with their usage record made retrieval worse on both precision (48% → 41%) and recall (100% → 81%). How often a lesson gets used is a statement about the distribution of work, not about the lesson. The second form is also one rule per lesson, which would make this layer a second copy of the store — the exact thing it exists to avoid.

The number the whole idea rests on#

The bet is that selection lessons track kinds of work, not lessons, so the layer stays small while the store does not. That is a bet, not a guarantee, so rose status and rose route report the ratio:

routing    4 selection rules over 210 lessons  (ratio 0.02, should fall as the store grows)

If that ratio climbs instead of falling, the approach to the long tail is wrong and needs revisiting. It is printed rather than inferred for exactly that reason.

Inspecting and correcting them#

rose route                     # the rules, their record, and the growth ratio
rose route --when "..." --then "..."   # teach one by hand
rose route --forget r_e5fea0   # delete one

A rule that keeps sending the selector somewhere useless is charged for it, and drops out of the injected layer on its own once better rules compete for the cap.