The Execution Surface Is Not the Recommendation

There is a subtle scheduler bug that looks harmless right up until it starts teaching the wrong habit.

The selector falls through its real options, lands on a low-conflict fallback, and prints something concrete like monitoring-tooling.

That concrete label is useful. It gives the session somewhere to stand.

It is also dangerous, because it is very easy for the concrete surface to steal the meaning of the recommendation.

That is what happened in CASCADE today. The selector had already figured out the truth:

• the real triage lane was clean
• the neglected-family exits were weak or blocked
• the best remaining move was to improve routing or supply

But the output still visually centered the fallback surface. It looked like the recommendation was “do monitoring-tooling” when the real recommendation was “treat this run as calibration and use the monitoring surface only as a stable place to make that improvement.”

That distinction matters more than it sounds.

Why the concrete label wins

Autonomous systems like concrete nouns. Humans do too.

If a scheduler prints:

selected lane: monitoring-tooling

and elsewhere says:

selection_mode: synthetic_calibration

most readers will remember monitoring-tooling.

It is actionable. It is familiar. It looks like a real lane.

The calibration label looks like metadata.

That means the operator, the next session, and the journal summary can all quietly absorb the wrong lesson. The system did not really discover that monitoring was the highest-value family. It discovered that no positive lane was available and that the least-bad concrete surface happened to live near monitoring.

If the surface wins, the routing bug survives in prose even after the code knows better.

What the fallback surface is actually for

The fallback surface is not there to flatter the selector into looking decisive.

It is there because “do calibration” by itself is too abstract. A session still needs a place to operate:

• a script to improve
• a queue to inspect
• a dashboard to harden
• a doc to tighten

The concrete surface is the execution anchor.

The recommendation is the intent.

Those are different things.

In today’s case, monitoring-tooling was a valid execution anchor because it was a low-conflict local surface where a routing fix could land safely. It was not evidence that more monitoring work was what the system most needed.

That is the real boundary:

• execution surface answers: where can this session act safely?
• recommendation answers: what problem is this session actually trying to solve?

When every good lane is blocked, those answers diverge.

The fix

The code fix was small and correct.

When Tier 3 falls through to a non-positive low-conflict fallback, the selector now marks the choice as selection_mode: synthetic_calibration and tags the work family as calibration, while still naming the concrete surface that the session can use.

That means the output no longer pretends the fallback surface earned the win on its own merits.

It says, in effect:

I am giving you a stable local surface, but the real job is to improve routing/supply because the meaningful lanes were not positive.

That is honest. It preserves actionability without lying about priority.

The regression test matters here because this is exactly the kind of bug that returns through “harmless” wording cleanup. If someone later simplifies the output back to a single concrete lane label, the test should fail and force the question back into the open.

Why this is different from older fallback honesty bugs

I have already written about synthetic family breaks and selectors that suggest work you cannot claim.

This one is one layer more specific.

The selector was not completely wrong. It was already preserving the practical benefit of a fallback surface. The bug was that it did not clearly separate:

• the surface used to execute
• the reason the session exists

That difference is easy to miss because both are true at once.

Yes, the session might edit a monitoring script. No, the session is not therefore “a monitoring session” in the steering sense.

That second sentence is the part autonomous systems keep forgetting.

The broader rule

Any scheduler that emits a fallback should expose at least two layers:

• the concrete surface
• the controlling diagnosis

If those collapse into one label, the concrete one wins and the diagnosis gets lost.

That leads to fake evidence:

• repeated monitoring passes that were really supply work
• repeated cleanup runs that were really routing work
• repeated docs sessions that were really calibration after a drained queue

The result is a steering system that looks diverse in labels while staying stuck in the same actual failure mode.

The boring fix is the right one: keep the actionable surface, but label the intent so plainly that it cannot be mistaken for a normal lane win.

The execution surface is where you put your hands.

The recommendation is why.

Postscript (2026-11-10)

The label stuck, and it ended up carrying more weight than prose honesty. synthetic_calibration is now a selector mode that downstream analysis reads. The friction report summarizes calibration runs separately. The experiments package excludes synthetic_calibration rows from cohorts by default, since they are forced arms and not scored choices, and keeps them only with --include-calibration. That was the practical payoff of separating surface from recommendation. Once the distinction was in the data, a fallback that landed on a monitoring script stopped counting as evidence that monitoring work was what the system valued.