Late-arriving data can revise an earlier day

An order can arrive with the wrong business date, channel or amount. A later event arrives with a higher source version and the correct values. The daily report for the wrong day has already been read; the question is how to revise the order fact and the affected daily group without hiding the change.

This companion story uses the same synthetic retail-orders project as the flagship. The amount is integer AUD cents, dates are UTC, and the orders are not recognised accounting revenue. The pipeline that decides which day the corrected order belongs to is the one explained here.

Every event carries a source update timestamp that records when the source system wrote the row. Each event also carries a business order date that records which day the order belongs to in the report. The two values can disagree: an event written on 3 January can describe an order that belongs to 1 January, and a later correction can move that business date again.

• The source update timestamp decides ordering between competing events for the same order.
• The business order date decides which daily group the order contributes to.
• An accepted correction can change the business order date, which moves the contribution between daily groups.

The current order fact is one row per order. When a corrected event wins by source version, timestamp and stable event identifier, the order state and the order fact are replaced with the corrected values. There is no edit history per field; the order fact always reflects the winning complete state.

Because the order fact has been replaced, the daily groups that aggregate over the order fact change at the same time: the original date-channel group loses the previous contribution and the corrected date-channel group gains the corrected contribution. The two daily groups are rebuilt together inside one commit so the change is atomic.

Only the daily groups whose date or channel is affected change. Groups whose date and channel stay the same are rebuilt from the same set of contributing orders and therefore show the same values. The committed daily groups are an aggregate of the current order facts, so changing an order fact changes the aggregate.

The change is not a separate post-processing step. Rebuilding the daily groups is part of the same atomic commit that updates the order fact. If any quality check fails on the rebuilt groups, the commit is rolled back and the previous values remain visible.

An event with a lower source version, an equal version with an earlier timestamp, or an equal version and timestamp with a lexicographically smaller event identifier cannot win against the committed order state. The pipeline records the event in the event ledger but does not change the order fact, the daily groups or the quality checks.

These stale or no-op events appear in the run summary as ignored events. They are not errors; they are the documented behaviour when a retry delivers an older correction after a newer correction has already been committed.

If two events in the same batch or one event against the ledger carry the same event identifier with a different raw payload, the pipeline stops before any mutation. The batch is reported as a conflict and the committed state stays authoritative.

When two events share the same order identifier but have different event identifiers and the same source version, the deterministic winner tuple is source version, source update timestamp, then lexicographically greater event identifier. The runner surfaces this situation as a warning rather than a failure, because both payloads are valid; the pipeline simply picks the documented winner.

A daily report that cannot move a corrected order between days would mislead anyone reading the previous day. A correction that overwrites silently would make the audit trail unreadable. Recognising that a higher source version wins, rebuilding the affected daily groups atomically, and leaving stale events visible gives an operator a clear answer for every scenario.

For this synthetic project, late-correction handling is demonstrated inside one browser session against a small sample dataset. It does not prove production durable recovery, regulatory retention, accounting treatment or how this rule should be reconciled with downstream financial systems.

The pipeline uses a strict tuple (source version, source update timestamp, then lexicographically greater event identifier) to choose the winning complete order state. The alternative would let the most recently processed event win regardless of the tuple, which would make the order fact depend on the order in which retries arrived.

Choosing the tuple keeps the answer reproducible across retries and across processes. The cost is that two competing events at the same tuple position with different payloads must be surfaced as a conflict or a warning rather than absorbed into a silent overwrite.

The saved result below is shown only when its build, sample data, schema, SQL and runtime identities match this application. It is a captured browser run from a real pipeline, not a fabricated outcome. Its sample is the follow-up batch, which contains a higher-version event for an already-known order, a stale lower-version event for another order and an event that reuses an already-committed event identifier.

Late-correction numbers a reader can read directly off the saved result: the order o100 changed from the initial web order on 2026-01-01 to the corrected web order on 2026-01-02 with a new amount, the inserted count is the order o106 that appeared for the first time in this batch, and the ignored-event count of three includes the stale event that could not outrank the existing order state and the raw-identical repeat of an already-committed event.

The grain of the saved evidence is per-batch: input event rows reconcile to invalid rows, identical valid duplicates removed and unique valid events accepted. The current order facts are one row per order; the daily groups are aggregates by UTC date and channel. Event totals, fact rows and daily groups are separate grains and should not be added together. The example proves behaviour for these small synthetic inputs and this browser pipeline. It does not establish production scale, accounting treatment, durable recovery or regulatory retention. If the engine cannot start, this explanation and the bundled SQL remain available.

Evidence mode: saved browser run captured 2026-10-23T20:36:39.286Z from build 821aed49a48d with sample file SHA-256 464d7430a9cf and SQL SHA-256 cd70dcad203d. New local runs from the flagship are labelled separately.

Read the flagship end-to-end story 

See how replay does not duplicate an accepted order 

Inspect the bundled pipeline SQL 

The architecture fragment below is the part of the flagship pipeline that decides which corrected order replaces the previous one and which daily groups change. The event identity gate prevents conflicting payloads from mutating state; the ledger and current state stages pick the winning complete order state; the order fact and the daily groups are rebuilt and checked together.