Method
Why a Public Forecast Record Needs Hashes
The problem with a record you can revise
A forecast that appears after the match has finished is evidence of nothing. It may be sincere, but nothing about it can be checked. A screenshot can be produced at any time, and shows only what its author chose to keep: the entries that went well survive, the rest quietly do not.
The deeper difficulty is not that people lie outright; most do not. It is that an unconstrained publisher can revise an entry, delete it, or forget it ever existed, and end up with a record that feels honest while being selected. Every survivor of that quiet filtering flatters the record. Any claim about accuracy therefore has to rest on something stronger than the publisher’s own word.
What a hash function does
A hash function maps an input of any length to a digest of a fixed length. SHA-256, the scheme this section will use, produces a 256-bit digest, written as 64 hexadecimal characters.
Two properties matter here. First: change any part of the input — a single character, a single digit — and the digest changes completely and without any pattern. There is no small edit to a document that produces a small edit to its digest. Second: working backwards is not practical. Given a digest, you cannot reconstruct the document behind it, nor find a different document that produces the same digest. Together these two properties are all a reader needs: a digest identifies one document, and only that document.
A digest as a commitment
The trick is to split publication into two moments. Before kick-off, the publisher releases the digest of a forecast — the 64 characters, not the forecast itself. After the match, the publisher releases the forecast. Anyone can then feed the published forecast through the same hash function and compare the result with the earlier digest. If they match, the forecast under examination is the same document that existed before the match started. If a single probability in it had been changed afterwards, the digest of the edited document would bear no relation to the one on record, and the mismatch would be plain.
That is the whole mechanism: the digest binds the publisher to a document without revealing it and without asking the reader to trust anyone. The commitment costs one line of text.
Why the digest alone is not enough
A digest proves what a document is, not when it existed. Anyone can compute a digest at any time, including the morning after the match; the mathematics carries no clock.
The record therefore needs an independent anchor for time. The digest has to appear somewhere the publisher does not control, at a moment others can check afterwards. A record whose timing rests only on the publisher’s own database is weaker than one held outside it, and that is a design requirement rather than an implementation detail. Without such an anchor, the timing of the record is an assertion rather than a fact.
An append-only log
The second requirement concerns what happens after an entry joins the record. The log must be append-only: entries are added and never edited or removed.
Chaining makes that enforceable rather than aspirational. If each entry includes the digest of the entry before it, the entries form a chain, each link sealing the last. Remove or change an old entry, and every digest that follows it stops matching, all the way to the present. A deletion that would leave no trace in an ordinary database becomes a visible break in the chain; even a reader who never watched the log can see that something is missing.
The consequence for the publisher should be said plainly: once an entry is in the chain, the only honest move is to let it stand. There is no quiet way back.
Publishing the misses
This is the point the whole design exists to serve. A record that shows only the entries that proved right measures nothing: it is a selected sample announcing itself as a complete one. Football forecasts are probabilities, and probabilities will sometimes be wrong several times in a row; a record with no visible failures in it is not a strong record but a curated one.
For the record to mean anything, evaluation has to be automatic and has to cover every published forecast, with no discretion over which entries get assessed and which quietly do not. The misses will be published alongside everything else. At times this will be uncomfortable, and the discomfort is not a defect of the design — it is the cost of the record meaning anything at all. We would rather own a public failure than publish a flattering fiction.
What hashes do not prove
Rigour cuts both ways, and a page about verification should apply it to itself.
A hash makes a forecast tamper-evident and time-bound. It says nothing whatever about whether the forecast was any good. A perfectly hashed, independently timestamped set of poor probabilities is still a set of poor probabilities. Whether forecasts are calibrated — whether events assigned a given probability happen at roughly that rate over a long run — is a separate question, settled by evaluating the record over many matches, not by the provenance machinery. Provenance makes a record checkable; only its results can make it good.
One further limit: all of this constrains a publisher only if the ledger is complete. Hashing a selected subset of forecasts would inherit exactly the problem this page began with — the mathematics flawless, the sample behind it still chosen by hand. Completeness and append-only storage therefore sit together, not as separate virtues.
| Property | What it establishes | What it does not tell you |
|---|---|---|
| Pre-match digest | The forecast existed, unchanged, before kick-off | Whether its probabilities were sensible |
| Independent timestamp | When the digest was made public | Whether the forecast was skilful |
| Append-only chain | That edits and deletions become visible | Anything about future performance |
| Automatic evaluation | That every forecast, misses included, is assessed | How good the forecasts are — that is read from the record over time |
What LeagueQuant will do
Nothing on this page describes a live system. No LeagueQuant forecast has yet been published, and no accuracy record exists. What follows is the mechanism this section will use.
Forecasts will be published before kick-off, each with its digest made public at the same moment. The log those digests live in will be append-only: entries added, none edited, none removed. After each match, evaluation will run automatically across every published forecast, and the outcome — the misses included — will be added to the public record. The first publication will be an explicit act of the site owner. Until it happens, this section will publish no forecasts and will show no accuracy record. The machinery comes first; any claim about performance will come from the record, and from nowhere else.