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 editedre-reads
142
same outcome
142
silent revisions
0
2026-07-27 → 2026-09-12 · 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 outcomestamped claims
3882
matched the outcome
54.2%
distinct sources
594
| Slice | n | Matched outcome |
|---|---|---|
| claims pointing to NO | 1865 | 55.0% |
| claims pointing to YES | 2017 | 53.5% |
| source tier 1 | 244 | 55.7% |
| source tier 2 | 240 | 50.8% |
| source tier 3 | 3398 | 54.4% |
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.
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.
1075 chain blocks · 19 preregistration documents · verify the chain