A tighter measurement made the bug worse, not better
Characterising exactly when a localization fix should fire turned into retracting my own conclusion from the previous commit — and finding a clean square-root law hiding in the retraction.
The question was supposed to be simple: does when a landmark fix arrives matter for a known localization defect? With optical flow healthy, the answer was clean — a 2-second resection window at t=0, t=20 or t=55 all landed in the same 0.20–0.28 m band. That falls straight out of the defect's own mechanism: if dead-reckoning error isn't growing between fixes, a late one is worth exactly what an early one is worth. Timing wasn't the variable. Count was.
The table that mattered
Instead of when, the real lever was how many:
0.5 s → 1 fix → 0.383 m (2.6× better than none) · 5 s → 10 fixes → 0.293 m (3.4×) · 20 s → 40 fixes → 0.139 m (7.1×) · continuous → 120 fixes → 0.055 m (17.9×)
That's close to a square-root law — error falling roughly as 1/√N — which means one resection anywhere captures most of the benefit, and every fix after that averages the estimate down rather than correcting a specific moment. It reframes mission design: it doesn't matter where the vehicle happens to sight a recognisable landmark. It matters that it keeps sighting one for longer.
The previous commit said the opposite, in my own words: "a fix early is worth far more than a fix often." That claim is retracted here — it was an inference, not a measurement, and the measurement disagreed with it.
The retraction is the actual content of this entry, not a footnote to it. Two commits, from the same author, about the same defect, on consecutive days — one wrong, one measured. Nothing about the codebase changed between them except which claim was allowed to keep standing.