Benchmark governance

Restatement policy

The three narrow conditions under which a published value may be corrected — and the many under which it may not.

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.

The same-day provisional window. A value for the current day is provisional until that day's close: same-day re-runs replace the live row, and only the closing print enters the final record. Prior days are never touched. This window is what the settlement writer enforces (commitRow in scripts/index-settle.ts) and is stated here so the published policy matches the code; replacing a provisional same-day value is not a restatement.

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 corrective row chains off the superseded row: its previousChecksum is the superseded row's checksum, so the chain EXTENDS through the correction rather than being rebuilt across it, and a restated series still verifies end to end.

    Correction, 2026-08-20. This bullet previously read "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." That is not what the code does and not what the ledger shows. The one restatement on record — WETGRI 2026-08-03, in content/indices/benchmarks/retired-v1-2026-08-05/wetgri.json — has the superseded row at checksum b4bb575c1ad5cf88 and the corrective row carrying previousChecksum: b4bb575c1ad5cf88. Nothing downstream was recomputed. data-licence.md already stated the correct behaviour; this page and README.md had not caught up.

    The distinction matters to anyone verifying, which is why it is corrected rather than tidied: a consumer who drops superseded rows before recomputing gets a BROKEN CHAIN FROM CORRECT DATA and will conclude the history was tampered with. Superseded rows must be included in any recomputation.

  • A settlement date can therefore carry more than one row. Key a cache, an index, or an on-chain record on checksum, never on date — see data-licence.md.

  • 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.

The rest of the set
Methodology change & consultation
What counts as a material change, the 14-day consultation window, and why changes are prospective.
Data licence & rights
What the free tier grants, what attribution it requires, and what commercial use needs.
The loop architecture
The nine scheduled agents that cultivate indices, which one may publish, and the six mechanisms that assure accuracy.
The confirm gate
What human confirmation covers — merges only — and how to read the provisional and single-venue counts.
Cessation & fallback
What happens when a benchmark cannot be computed, and why the history stays published forever.
Conflicts & the conflict wall
The wall between index operations and the trading circuit, plus standing disclosures.
Data-error playbook
Detection, triage, quarantine — and the commitment to disclose errors nobody noticed.
Complaints & challenges
How to challenge a value, a rule, or a constituent. No account required.
Settlement-reference licensing
What licensing a benchmark to settle against requires — and why publication alone does not grant it. Reading a value is free; referencing it in something that settles is not the same act.
Determination, disruption & cessation
Written for contracts rather than charts: who determines a final value, the disruption fallback ladder, and why a refusal is not a cessation.
The independent committee seat
The seven-part independence test, published before a candidate exists; the power to block rather than comment; and what the administrator may do while the seat is vacant.
Incident process
Who is paged, what they do, and what gets published when the machinery fails — as distinct from a wrong value, which is the data-error playbook.
Finding — the WETX coverage breach, August 2026
Why WETX refused for five consecutive days, the change that caused it, and what is still not established. Published because an availability figure without the incidents behind it is a number nobody can check.