Sealing every forecast

The problem

Forecasts are easy to improve after the fact. A record can be edited, a bad call quietly removed, a prediction rewritten once the answer is known. None of this needs bad intent; it only needs the possibility. A record that cannot rule it out cannot support a claim of accuracy.

What is sealed

Since 11 October 2026, the moment a forecast is logged the server, not the browser, assigns its time. It then computes a SHA-256 digest over the forecast’s identifier, its account, that time, the verdict, the stated claim and the structured prediction (the event and its step on the scale). The digest is stored with the forecast as its seal.

From then on, those fields cannot be changed through the application. An attempt to rewrite them is reverted to the sealed values. Information that arrives later, such as what the person did next or whether the forecast was useful, stays writable, because it is not part of what was predicted.

Forecasts made before 11 October 2026 were sealed on that date. They can be evidenced from then, not from when they were made, and we say so wherever they are used.

Day roots

Each day’s seals are combined into a single root: a SHA-256 digest over all of that day’s seals in identifier order. A root commits to every forecast made that day while revealing nothing about any of them. The idea follows Haber and Stornetta’s method for timestamping documents (1991).

What this guarantees today, and what it does not

Today the seals and roots are held by us. That protects the record against edits made through the product, but it is not independent evidence: someone with administrative access to the database could in principle alter a forecast and recompute its digest. We do not want anyone to take our word for it, so we do not claim otherwise.

Independence comes from publication. Once each day’s root is published somewhere we do not control, in an append-only log, any later change to a forecast from that day becomes detectable by anyone. Sealing is in production. Publishing roots is planned, and until it is in place the record should be read as sealed but not yet independently verifiable.

How a forecast will be verified

1. Recompute the forecast’s seal from its fields and check it matches.
2. Recompute the root for its day from that day’s seals.
3. Check the root against the one published for that day, and that it was published before the outcome.

If all three hold, the forecast existed in exactly that form before its outcome was known. That is the property every accuracy claim we make will rest on.