CHAIN #1728 · ee00380549fdPREREG 3dd9f2ee7c25resolved only against official statistical APIs

Integrity

A forecast record is only worth what its audit layer is worth. Three things run here without anyone asking them to: every resolved question is read a second time, every piece of evidence is scored against what actually happened, and our own failures are written into the same chain as our forecasts.

Revision watch

a resolved question is re-evaluated a day later against the same source; the original result is never edited

re-reads

277

same outcome

277

silent revisions

0

2026-07-27 → 2026-10-25 · inconclusive 0

Official statistics get revised. Our contracts say the first published reading decides the question, so a later revision must never quietly change a settled result. This watch is the evidence that it does not: if a re-read ever disagrees, it is logged as a disagreement, not applied.

Source track record

every directional claim admitted before a resolution is later compared with the outcome

stamped claims

7197

matched the outcome

54.5%

distinct sources

872

SlicenMatched outcome
claims pointing to NO349755.6%
claims pointing to YES370053.4%
source tier 167259.7%
source tier 245953.4%
source tier 3606654.0%

Read this as measurement, not as a verdict on any source. A slice that points toward the more common outcome will look better without being better, so these numbers only become a statement about source quality once the base rate is accounted for and n is much larger. We publish them now because the ledger should be visible while it is still inconvenient.

What we got wrong

failures of our own machinery, written into the chain before they were fixed
  • block 3332026-07-270609ea3e44c2

    Addendum 6 · a mechanism we had preregistered was never wired

    Two earlier addenda specified how resolved outcomes should recalibrate the rules behind a forecast, and we proved the mechanism with rollback tests. It then sat idle: the production resolution path never called it, so for weeks not a single rule carried real-world evidence. We found it, wrote the finding into this chain before fixing it, and made the repair forward-only so no past result was retroactively credited.

  • block 3342026-07-277ce85dcbb4a9

    Addendum 13 · the field that recorded which rules were used was wrong

    Every decision stored a rule set that belonged to a different engine, so the credit and penalty from a resolved question landed nowhere. The verdict itself was never affected, but the learning loop was writing to an empty address. Recorded here first, then corrected forward-only.

  • block 4312026-08-04b919481cf232

    Addenda 15 and 15.1 · the new gate shipped with the wrong formula, and was corrected before it ever fired

    A new publication gate was specified against a measured failure class, but the formula we froze quietly deviated from the exact formula used in the measurement. A pre-acceptance verification pass showed the deployed version would have suppressed our best forecasts instead of the failing class. It was corrected in a follow-up addendum before a single production forecast was affected; both the flawed specification and the correction stand as consecutive blocks in the chain.

  • block 14572026-10-139fcf5645ff2d

    We have stopped publishing in one question family

    Our forecasts on US continuing jobless claims have been poor. The 18 forecasts we published in this family average a Brier score of 0.51; someone who always said 50 percent would score 0.25. The last four weeks were worse: six forecasts on three questions scored 0.70. We have stopped publishing new forecasts in this family. We keep opening questions, forecasting behind the scenes and scoring; none of the past records has been removed or altered. We will return to publishing only if a criterion we recorded in advance is met: doing no worse than a coin flip on at least eight new questions. If we remain clearly worse, we will close the family altogether; if we land in between, we will wait for eight more questions, once.

Anyone can publish a hash chain of their wins. The reason these entries exist is that a record which cannot hold bad news about itself is not a record. Both were repaired forward-only: no earlier result was recalculated, and the chain still carries the account of the failure.

1717 chain blocks · 34 preregistration documents · verify the chain