Restatement policy

A published settlement value is final unless it meets one of the conditions below. The presumption is strongly against restatement: a benchmark whose history moves is not a benchmark.

When a value may be restated

1. Input error — a venue published a price it later corrected, or a quote was ingested from the wrong contract.
2. Computation error — the engine did not implement the published methodology.
3. Settlement-source error — a resolution was recorded against the wrong outcome.

When a value may NOT be restated

• The value looks wrong, surprising, or unflattering.
• A better methodology has since been adopted (see methodology-change.md — changes are prospective).
• A constituent was later found to be ineligible under rules introduced after the fact.

How a restatement is recorded

• The corrected row is appended, never edited in place, carrying restatement_ref pointing at the date it corrects.
• The original row remains in the ledger, marked superseded. The historical record shows both what was published and what it was corrected to.
• The checksum chain from the corrected date forward is recomputed and republished, so any third party holding an older checksum can detect that history changed and see exactly where.
• The reason is published alongside.

Timeliness

A restatement is made as soon as the error is confirmed. Errors found more than 90 days after publication are disclosed and analysed but not restated — beyond that horizon, the value has been relied upon, and stability is worth more than the correction.