What a Verified Prediction Record Actually Looks Like

There is a structural problem with every prediction source: nothing prevents it from telling you only the good stories.

Screenshots can be staged. Posts can be deleted. Channels can be cleaned. In most cases there is no way to know how many predictions were published in total, how many missed, and what exactly was said before kickoff.

This explains what a real solution looks like, and how you can check it yourself — here or anywhere else.

Three questions any source must answer

1. What exactly was said? Not "we liked the home side" — what probability, at what price, with what confidence.
2. When exactly was it said? Before kickoff, to the second.
3. How would you know it has not been changed since?

The third is the hard one, and it separates transparency from a claim of transparency.

The solution: a cryptographic hash over a defined payload

Every published prediction receives a fixed payload including:

Field	Contents
Prediction id	A public incrementing identifier
Fixture, market, selection	What exactly was predicted
Model probability	The published number
Confidence and data quality scores	The context around that number
Fair odds, market odds, edge	The economic side
Model version, feature version	What produced it
Data snapshot id	What data it rested on
Generated at, published at	When
Previous prediction id	If this is a corrected version

The payload is serialised canonically — keys sorted, no whitespace, numbers at six decimal places with trailing zeros trimmed — and then hashed with SHA-256.

The result depends on every bit of the payload. Change one digit and the hash changes entirely.

Why canonical serialisation is not a technicality

This is the part people skip, and it is what makes the whole idea usable.

Without a fixed ordering, identical data can produce different hashes depending on field order, whitespace or number formatting. If every party computes differently, nobody can verify anything.

With a defined canonical form, anyone can take the displayed data, serialise it the same way, compute SHA-256 and compare. That is exactly what the proof page does — and the computation runs in your browser, not on our server.

An append-only ledger

A hash alone is insufficient, because whoever holds the data could replace the hash too. The second component is how it is stored.

Publication writes three rows in a single transaction: the current prediction state, a publication row and a proof row. The latter two, together with the audit log, are protected at the database level: any attempt to update or delete them fails. Not "discouraged" — fails.

The consequence: the only way to change a prediction is to create a new version. The new version carries an incremented version number, points at its predecessor and states a change reason. Both exist permanently.

The lifecycle

Publish. Prediction, publication and proof rows are created.

Material change before kickoff. If the selection changes, or the probability moves by at least one percentage point, a new version is created with a pointer to the previous one and a reason. The old one remains.

Lock. At a fixed interval before kickoff — five minutes by default — the prediction locks, and the lock itself is recorded in the ledger.

Settle. The last version published before kickoff is graded win, loss or push. Superseded versions are marked void. Results are never softened.

What the public record shows

Every settled prediction with its identifier, publication time, model version, published probability, confidence score, price at lock, outcome and a link to its proof. Filterable by selection, competition and confidence level.

Above the table sit aggregates computed from the ledger itself: settled predictions, wins, losses, hit rate, average price at lock, Brier score and return per unit.

And one field is displayed in a way worth noticing: closing line value is marked "not tracked yet". Measuring it properly requires closing price snapshots stored systematically, and until that exists at sufficient scale the field stays empty rather than being filled with an estimate.

That looks like a small decision. It is a substantive one: a metric that is not measured is displayed as not measured.

Why this matters especially in this category

In most fields, an inaccurate source is exposed quickly. In sports prediction that mechanism is broken, for a structural reason: outcomes are noisy enough that almost any claim can survive.

A source hitting 50% will inevitably experience runs of seven and eight consecutive wins. Showing only those runs makes it look exceptional. Deleting the posts from the opposite runs leaves no way to tell.

That noise is why a cumulative, public, signed record is worth vastly more than any screenshot — and why a small sample, even a completely genuine one, is not enough to conclude anything.

Three ways records get faked

Worth recognising, because the patterns repeat.

Selective deletion. Publish a lot, delete the misses. Detected by gaps in numbering, or by the absence of numbering entirely.

Vague phrasing. "There is value in the home side" can be read either way afterwards. A prediction that can be interpreted is not a prediction.

Retroactive price selection. Reporting a result against a price that was available at some point, rather than the price recorded at decision time. This is why price at lock is a separate stored field rather than a number chosen later.

How to check any source

Four questions, in descending order of importance:

1. Where are the losses? If they are not in the same table as the wins, you are looking at marketing.

2. What exactly was said, and when? A probability, a price and a timestamp are checkable. A sentiment is not.

3. Can you verify it was not changed? If the answer is "trust us", there is no proof. A hash anyone can recompute is proof.

4. When did they last say there was nothing to do? A source that produces a selection for every fixture every day is supplying a content schedule.

What this does not claim

Important not to overstate it:

• A verified record does not guarantee accuracy. It guarantees integrity. A model can be perfectly honest and not very accurate.
• It does not promise any outcome.
• It does not make every prediction good. It only ensures you see the bad ones too.

Accuracy is measured elsewhere — on the performance page, through calibration and Brier score across a sample. And that page carries the inconvenient finding too: in a walk-forward backtest across five major European leagues, the market's closing price still measures better than the model-only ensemble. It is displayed as it stands, because hiding it would contradict everything above.

The same standard applies to experts

What holds for our predictions holds for other people's predictions shown on our platform. Only an explicit, publicly published prediction qualifies, with a source link, title, publication time and the exact verbatim evidence sentence. A tactical or historical remark is not a prediction. Sources must be approved and permitted — there is no scraping. A reliability score opens only after at least thirty verified predictions, and expert predictions are settled exactly like ours and never deleted.

---

18+. WinPIQ is an analysis tool, not advice and not a promise. Betting can be addictive and money can be lost. Only stake what you can afford to lose, and if betting stops being entertainment, seek help. WinPIQ is not affiliated with Winner or the Israeli Council for the Regulation of Sports Betting.