Zepto: the report that changed after it was sent

Constraints

1. 1Closing stock for 5 March means every event with event_at at or before '2026-03-05 23:59:59', whenever it arrived.
2. 2units_on_hand is the sum of delta_units over those events. Positive values are restocks, negative are picks.
3. 3late_events counts the events in that window whose ingested_at is after the same cutoff — the rows the original report could not have seen.
4. 4Report only pairs with at least one late event. A pair whose figure did not move does not need restating.
5. 5Events that happened after the cutoff are out of scope even if they arrived before it.
6. 6Order by store_id, then sku.

Worked example

Store s1 and MILK-1L: four events fall on or before the cutoff — +120, -40, -25 and a -30 pick at 18:40 on 5 March that did not arrive until 04:05 on 7 March. The true closing figure is 25 units with 1 late event. The report sent that night filtered on ingested_at and reported 55 units. It was not wrong when it ran; it is wrong now. Filtering on ingested_at gives you what the warehouse knew, filtering on event_at gives you what happened — and only the second one is reproducible.

What this tests

The distinction between event time and processing time, and the restatement problem it creates: a correct report can become incorrect without anyone changing the query, so a pipeline has to be able to say which figures moved and why.