Restatement Record

Reported figures get corrected. A pipeline that recomputes and overwrites the previous submission destroys exactly the evidence a restatement will be judged on: what was originally reported, why it was wrong, and what changed.

A restatement record keeps both versions, the reason, and a reconciliation between them.

Why the original must survive

A regulator examining a restatement is assessing the control environment, not only the corrected number. The questions are how the error arose, how it was detected, how long it persisted and whether the process caught it or someone else did. All of those require the original.

The same reasoning drives the pipeline's wider design: a figure submitted three years ago must be reproducible today from the data as it was then — exactly, including the reference data in force at the time.

Implementation patterns

• Immutable source snapshots per reporting period, retained for the full obligation, so a rerun reads what the original read rather than what the source holds now.
• Versioned transformation logic, with the version recorded against each submission, so a rerun executes the code that produced the original.
• [[Bitemporal]] reference data, applying rates and classifications as they stood at the reporting date, with corrections tracked separately from real-world validity.
• Deterministic transformations. Dependence on wall-clock time or on a mutable lookup's current value produces a different result rather than a reproducible one, and that difference cannot be explained to a regulator.
• End-to-end lineage from the submitted figure to its source records, which is what a challenge actually demands.
• Sign-off recorded against a specific artefact version, so approval refers to something identifiable rather than to a process.

Industry example

Regulated reporting programmes accumulate the same defect without exception: ad-hoc manual adjustments applied to the output. A number is known to be wrong, the pipeline cannot be changed in time, and someone edits the submission.

Each adjustment breaks reproducibility invisibly, and after enough of them the reported figures cannot be regenerated at all. The fix is not to forbid adjustments — they are operationally necessary — but to make them versioned, approved inputs to the pipeline rather than edits to its output, so the pipeline remains the single path to the number.

Failure scenarios

• Overwriting the previous submission, destroying the comparison.
• No reason recorded, so the restatement cannot be explained later.
• Manual output adjustments, breaking reproducibility silently.
• Non-deterministic transformations, making reruns differ for reasons nobody can articulate.
• Reference data without history, so a rerun applies today's rules to a past period.

Trade-offs

Retaining every version of every submission with full source snapshots is expensive in storage and in operational discipline, and the retention period is measured in years. Reproducing an old submission also requires an execution environment capable of running old code, which is a real long-term maintenance obligation.

Both costs are unavoidable consequences of the requirement. The scoping judgement is which figures genuinely carry the obligation — usually the submitted ones and their direct inputs, not every intermediate dataset the pipeline produces.

Interview question

"You discover that a figure submitted eighteen months ago was wrong. Walk me through what you need in order to correct it defensibly — and tell me what would make that impossible."