Two ways to ask "is this move safe"

The left panel floods outward from every occupied cell regardless of whether a candidate will ever ask about it — cells are shaded red→amber by distance only. The right panel does the opposite: it starts from each of the 9 candidates' predicted positions (dots) and searches outward only as far as it needs to, click a dot to see its actual search order. Hazard cells here are coloured by risk_group — the same value _hazard_risk_group already computes, so a hit tells you not just "how far" but "which chain." Cells outlined in white persisted from the other frame unchanged — exactly the cells a rollover would reuse instead of recomputing.

Same real recording (full-campaign-flow-field-1), worst-case horizon (56 frames) forced on every decision frame, benchmarked in isolation against the current production _score cost for the same range.

The theoretically optimal O(n) exact-distance algorithm lost badly in practice: its cost tracks the bounding box around each horizon's hazards, and Python's per-cell overhead in a dense grid dominates over asymptotic complexity at this problem size. Lazy ring search's cost tracks query count instead (504 lookups/frame, fixed), which is why it wins regardless of how spread out the hazards are. Adding risk_group cost ~0.4ms — free at the hit cell, no separate lookup. All 9 candidates query the same per-horizon occupancy set, so a single shared bounding-box pre-check can rule out a whole horizon for all 9 at once before falling back to per-candidate search — a real ~24% win at radius 3, and roughly halves the cost at radius 18. It does not make radius 18 viable on its own, though: _score also uses a 70px threshold check (nearest < 70.0, autoplay.py:25926) to relax a firing-lane-alignment penalty near danger — a tier-5, non-survival gate that doesn't need per-candidate horizon-swept precision. The right fix there is a separate, cheap, frame-global check against hazards' current positions (~13 math.hypot calls), not a wider radius on this field.

The isolated benchmark above never shipped: it was wired into _score behind a use_hazard_field flag, validated correct against 717 tests and a real live Level 1 playthrough, then reverted after two rounds of fixing still left it slower than the code it was meant to replace. Recorded here because the isolated number was real and the integrated regression was also real — the gap between them is the actual lesson.

Two real bugs were found and fixed along the way, each confirmed by re-measuring rather than assumed:

A methodology correction, caught before it became a wrong conclusion: the first attempt at explaining why the regression persisted used validate_campaign.py profile to re-profile the fixed code with cProfile. That tool rebuilds its controller through ReplayModel.__init__ (replay_ui.py:364), which constructs ReactiveController(wall_mask=self.wall_mask) with no way to pass use_hazard_field — a path that was only ever wired through the live record_run.py route. That cProfile pass was silently measuring the flag-off baseline the whole time, not the fixed "on" configuration it was meant to inspect. The resulting "_score self-time unchanged, 803M vs. 772M calls" explanation was retracted once this was caught — it was never evidence about the code being evaluated.

What survives that correction: the live wall-clock numbers above are still valid (measured through the correctly-wired record_run.py --use-hazard-field path), and so are the skip-rate and cell-count diagnostics for both fixes (measured by explicitly setting controller.use_hazard_field = True after construction, bypassing the same gap). The regression itself is real and measured twice over. The specific mechanistic explanation for why it persists after both fixes is not actually diagnosed — that would need a live-path-correct cProfile pass this investigation didn't get to before the decision to revert and return to the architecture question directly.