the offset applied in the wrong direction

A helper computed the moment of a daily boundary by converting between two clocks. The offset was applied in the wrong direction, which does not produce a small error: it moves the boundary by twice the offset. Every simulated cutoff landed hours away from where it belonged, in the part of the day the surrounding rule existed to avoid.

The interesting part is who was wrong. The live path was checked first and found correct. The simulation was the faulty one — the code that produced the numbers everyone reasoned from, and the one place where a wrong boundary is invisible, because the output still looks like a number and nothing downstream is qualified to doubt it.

The correction was not a quiet replacement. The affected family was recomputed with the boundary fixed, the corrected table was re-printed, and a correction record was attached to the deliverable naming what had been wrong, which rows it touched, and what superseded them. The retraction sits beside the result rather than underneath it.

Two smaller things were checked while the wound was open: the neighbouring window rule was audited clean, and the fix carries tests at both phases of the yearly offset change, which is where this class of error hides. What it proves is that the record is improved by addition, so that a reader can still see what was wrong and what replaced it.