Delivery Revision and Restatement

A restatement supplies corrected data for an already delivered period. A delivery revision identifies that version under an agreed ordering rule. Dataset and period identify what is being corrected; the revision identifies which correction; a checksum identifies the received bytes.

Suppose revision 1 contains 320 rows and revision 2 contains 318. Appending revision 2 double-counts most rows; merging without deletion can retain the two removed rows. If the contract defines a complete replacement snapshot, validate it and replace the period through an atomic publication, including an explicitly empty replacement. Delta deliveries need different apply rules.

An identical retry must not add another effect — the idempotency requirement, carried by the revision identifier rather than by arrival order. Reject different bytes under the same revision as a conflict, and prevent a delayed older revision from overwriting a newer one. Commit validated data, accepted revision, and audit evidence together with appropriate concurrency control. A reconciliation against the source is what shows the replacement landed as intended. Arrival time or a different hash alone cannot establish which correction is newer.

Replacing the data is half the job

Everything above concerns the mechanics of applying a correction. The harder half is that people have already used the old figure — quoted it in a review, built a forecast on it, sent it to a customer. Replacing the rows silently leaves those uses standing, and the discrepancy surfaces later as a dispute about which system is wrong.

So a restatement that affects published numbers needs a notice, and the notice needs enough to act on rather than an apology. What consumers actually require:

• What changed and by how much — the previous and corrected figures, not merely data has been updated.
• Which periods are affected, since that decides whose work is invalid. A correction to one day and a correction to a full quarter demand different responses.
• Why, distinguishing a source error, a late arrival, and a changed definition. The third is different in kind: previously correct work becomes inconsistent by design, so it needs a decision about the definition itself and not only about the data. That is an additional review, not the only case that needs approval — see the threshold below.
• When it takes effect, so a reader can tell whether the number in front of them is before or after.
• Who to ask, named.
• What the consumer must do — the reports to rerun, the extracts to refresh, the caches and downstream copies that will otherwise keep serving the old value.

Two operational points make this survivable. Decide in advance what triggers which response, using both the size of the change and its kind: below some materiality a restatement is applied quietly and logged, above it is announced, and above a second level it needs approval before publication — with a definition change requiring the definitional review regardless of size. A large source-error correction and a large late arrival therefore need approval too; what distinguishes the definition change is the extra question of whether the new meaning is agreed, not a monopoly on needing sign-off. Deciding any of this during an incident produces inconsistent handling and an argument about whether anyone should have been told. And keep the notices somewhere durable and queryable rather than only in a chat message, because the question that arrives six months later is was this period ever restated, and a person’s memory is the wrong index for it.

Where the trigger is a changed definition rather than wrong data, the version of the definition belongs alongside the figures, so that a reader comparing two periods can tell whether the movement is in the business or in the rule.

Further reading

• Worked API and file ingestion lab