retrieval_telemetry reported write_path_rule with a band "-0.0208 above its floor" — p10 0.6992 against a floor of 0.72.
A negative distance above something is the exact string #4225 was built to stop printing. That fix made band_hugs_floorsuspend when a floor moved inside the window, because across a change the scores and the bar come from two different populations. It did not suspend.
The reason: floor_moves_since answers "did this arm's floor move", and the band check read an empty answer as "no, it held steady". Those are the same answer only where the ledger was watching. Before an arm's first floor row there is nothing to move and nothing to report — absence of evidence was arriving as evidence of absence.
Every install passes through this. The ledger's first row for an arm is written when that install first boots the release that records baselines, so any window longer than the install is old reaches back past it. The lowered-floor direction hides: the gap comes out comfortably positive and reads as a clean bill of health.
The change
floor_history_gaps(since) — services/retrieval_tuning.py, beside floor_moves_since. MIN(created_at) grouped by surface where dial == "floor". Arms come from surface_names(), not from the ledger: an arm the ledger has never heard of is exactly the one at risk, so it cannot be the ledger that decides which arms get asked about. Returns only arms with a gap — ISO timestamp from which the floor is knowable, or None for no history at all.
Baselines count here, the one place the two functions deliberately disagree. A baseline records a default without changing it, so it is not a move and floor_moves_since filters it out. It is the ledger beginning to observe the arm, and from that moment silence genuinely means the floor held — filtering it out here would suspend the band check forever on every install that has never tuned.
floor_history_unknown — retrieval_telemetry._compute_warnings, ordered moved → gap → band, so an arm with a date to give gives it. Two sentences, because the remedies differ: a date says ask again with a smaller days; no history at all says there is nothing to wait for and names what starts the record.
Verification
No pytest locally, so _compute_warnings was AST-lifted from both the working tree and git show HEAD: and run against nine cases:
9/9 pass on the fix.
6 of 9 fail on the code it replaces — including one failing with "negative gap printed", the reported symptom reproduced from source.
The 3 passing both ways are the non-regression guards (covered arm still judged, known move still wins, quiet arm untouched), correctly indifferent to the change.
floor_history_gaps verified the same way: coverage, mid-window, no-history, empty ledger, and both sides of the window boundary. That last case was found while writing the harness and pinned — a row written exactly at since covers the window, one microsecond later does not. An off-by-one there fails expensively: a covered arm reported unknowable retires a working check on a rounding.
CI run 7199 green across all six jobs.
Why now
#4261 measures the work-log change by reading these warnings, and every window for the next month opens before this ledger's first row. Measuring against an instrument that prints a number it cannot support is the #4225 trap one level up.
Carries one commit: `42360f6`.
## The problem
`retrieval_telemetry` reported `write_path_rule` with a band **"-0.0208 above its floor"** — p10 0.6992 against a floor of 0.72.
A negative distance *above* something is the exact string #4225 was built to stop printing. That fix made `band_hugs_floor` **suspend** when a floor moved inside the window, because across a change the scores and the bar come from two different populations. It did not suspend.
The reason: `floor_moves_since` answers *"did this arm's floor move"*, and the band check read an empty answer as *"no, it held steady"*. Those are the same answer only where the ledger was **watching**. Before an arm's first floor row there is nothing to move and nothing to report — absence of evidence was arriving as evidence of absence.
Every install passes through this. The ledger's first row for an arm is written when that install first boots the release that records baselines, so any window longer than the install is old reaches back past it. The lowered-floor direction hides: the gap comes out comfortably positive and reads as a clean bill of health.
## The change
**`floor_history_gaps(since)`** — `services/retrieval_tuning.py`, beside `floor_moves_since`. `MIN(created_at)` grouped by surface where `dial == "floor"`. Arms come from `surface_names()`, not from the ledger: an arm the ledger has never heard of is exactly the one at risk, so it cannot be the ledger that decides which arms get asked about. Returns only arms with a gap — ISO timestamp from which the floor is knowable, or `None` for no history at all.
Baselines count here, the one place the two functions deliberately disagree. A baseline records a default without changing it, so it is not a move and `floor_moves_since` filters it out. It **is** the ledger beginning to observe the arm, and from that moment silence genuinely means the floor held — filtering it out here would suspend the band check forever on every install that has never tuned.
**`floor_history_unknown`** — `retrieval_telemetry._compute_warnings`, ordered `moved` → `gap` → `band`, so an arm with a date to give gives it. Two sentences, because the remedies differ: a date says ask again with a smaller `days`; no history at all says there is nothing to wait for and names what starts the record.
## Verification
No pytest locally, so `_compute_warnings` was AST-lifted from both the working tree and `git show HEAD:` and run against nine cases:
- **9/9 pass** on the fix.
- **6 of 9 fail** on the code it replaces — including one failing with "negative gap printed", the reported symptom reproduced from source.
- The 3 passing both ways are the non-regression guards (covered arm still judged, known move still wins, quiet arm untouched), correctly indifferent to the change.
`floor_history_gaps` verified the same way: coverage, mid-window, no-history, empty ledger, and both sides of the window boundary. That last case was found while writing the harness and pinned — a row written exactly at `since` covers the window, one microsecond later does not. An off-by-one there fails expensively: a covered arm reported unknowable retires a working check on a rounding.
CI run 7199 green across all six jobs.
## Why now
#4261 measures the work-log change by reading these warnings, and every window for the next month opens before this ledger's first row. Measuring against an instrument that prints a number it cannot support is the #4225 trap one level up.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy
`band_hugs_floor` compares an arm's weakest tenth against its floor, and
#4225 made it SUSPEND rather than soften when the floor moved inside the
window — because across a change the scores and the bar come from two
different populations. It reads `floor_moves_since`, which answers "did
this arm's floor move", and it read an empty answer as "no, it held
steady".
Those are the same answer only where the ledger was watching. Before an
arm's first floor row there is nothing to move, nothing to report, and no
way to tell a steady floor from an unrecorded one. The suspension was
reading absence of evidence as evidence of absence, and the symptom is the
one #4225 documented: a band "-0.0208 above its floor" — an impossible
negative distance, printed with the suspension silent.
Every install passes through this. The ledger's first row for an arm is
written when that install first boots the release that records baselines,
so any window longer than the install is old reaches back past it. The
lowered-floor direction hides: the gap comes out comfortably positive and
reads as a clean bill of health.
`floor_history_gaps(since)` answers the question its companion cannot:
which arms' floor history does not REACH the start of the window. Arms
come from `surface_names()`, not from the ledger — an arm the ledger has
never heard of is exactly the one at risk, so it cannot be the ledger that
decides which arms get asked about.
Baselines count here, which is the one place the two deliberately
disagree. A baseline records a default without changing it, so it is not a
move and `floor_moves_since` filters it out. It IS the ledger beginning to
observe the arm, and from that moment silence genuinely means the floor
held — filtering it out here would suspend the band check forever on every
install that has never tuned.
`floor_history_unknown` sits between the known move and the band, so an
arm with a date to give gives it. Two sentences, because the remedies
differ: a date says ask again with a smaller `days`; no history at all
says there is nothing to wait for, and names what starts the record.
Why now: #4261 measures the work-log change by reading these warnings, and
every window for the next month opens before this ledger's first row.
Measuring against an instrument that prints a number it cannot support is
the #4225 trap one level up.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Carries one commit:
42360f6.The problem
retrieval_telemetryreportedwrite_path_rulewith a band "-0.0208 above its floor" — p10 0.6992 against a floor of 0.72.A negative distance above something is the exact string #4225 was built to stop printing. That fix made
band_hugs_floorsuspend when a floor moved inside the window, because across a change the scores and the bar come from two different populations. It did not suspend.The reason:
floor_moves_sinceanswers "did this arm's floor move", and the band check read an empty answer as "no, it held steady". Those are the same answer only where the ledger was watching. Before an arm's first floor row there is nothing to move and nothing to report — absence of evidence was arriving as evidence of absence.Every install passes through this. The ledger's first row for an arm is written when that install first boots the release that records baselines, so any window longer than the install is old reaches back past it. The lowered-floor direction hides: the gap comes out comfortably positive and reads as a clean bill of health.
The change
floor_history_gaps(since)—services/retrieval_tuning.py, besidefloor_moves_since.MIN(created_at)grouped by surface wheredial == "floor". Arms come fromsurface_names(), not from the ledger: an arm the ledger has never heard of is exactly the one at risk, so it cannot be the ledger that decides which arms get asked about. Returns only arms with a gap — ISO timestamp from which the floor is knowable, orNonefor no history at all.Baselines count here, the one place the two functions deliberately disagree. A baseline records a default without changing it, so it is not a move and
floor_moves_sincefilters it out. It is the ledger beginning to observe the arm, and from that moment silence genuinely means the floor held — filtering it out here would suspend the band check forever on every install that has never tuned.floor_history_unknown—retrieval_telemetry._compute_warnings, orderedmoved→gap→band, so an arm with a date to give gives it. Two sentences, because the remedies differ: a date says ask again with a smallerdays; no history at all says there is nothing to wait for and names what starts the record.Verification
No pytest locally, so
_compute_warningswas AST-lifted from both the working tree andgit show HEAD:and run against nine cases:floor_history_gapsverified the same way: coverage, mid-window, no-history, empty ledger, and both sides of the window boundary. That last case was found while writing the harness and pinned — a row written exactly atsincecovers the window, one microsecond later does not. An off-by-one there fails expensively: a covered arm reported unknowable retires a working check on a rounding.CI run 7199 green across all six jobs.
Why now
#4261 measures the work-log change by reading these warnings, and every window for the next month opens before this ledger's first row. Measuring against an instrument that prints a number it cannot support is the #4225 trap one level up.
🤖 Generated with Claude Code
https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy