Verification Explorer

Every forecast below was sealed with a cryptographic hash before the fact it predicts was knowable, then left alone. This page shows what we predicted, when we sealed it, and — once the due dates arrive — how it scored. Hits and misses are published identically.

sealed ledger ● 0 shown

Lanei	Claimi	Predictedi	Forecasteri	Resolvesi	Againsti

How a scored row was graded. A resolved lane is graded against the first print as fetched on the grading run. Statistical agencies revise, so the source may since have been revised — that never reopens a scored outcome, in either direction. skill is measured against the naive anchor published with the row as naive_value: 1 − |err_model| / |err_naive| — above 0 beats the anchor, 0 ties it, below 0 loses to it. What the anchor is: a no-change forecast — the last value the same official source had published before we sealed, carried forward unchanged. For strongly seasonal series it is the same period one year earlier instead; a few event-style lanes use the historical base rate. In every case the anchor is fixed at seal time from the committed data pack and travels with the row, so it cannot be re-chosen afterwards to flatter the score — which is the only reason a skill number means anything. A row marked late_by_design resolved after its due date because the source published late; the date it landed is its release_observed. Lateness is a scheduling fact and never changes the score.

How to read a row: each row is one sealed forecast — append-only, hash-audited, never edited after sealing. Claim is what was committed, Against is the public source that will settle it, and rows sharing a question are competing forecasters on the same question. Hover any i for the full text; click a row for the sealed record, the seal hash and the chart against the real series.

One question, many forecasters question

🛈 What this measures: how well each LLM predicts this metric using a simple, uniform approach - the neutral question plus (in grounded arms) public context, the same prompt for every model, no prompt tuning or retries. Forecast quality depends on the prompt, so a better-engineered one would likely score better; this is a like-for-like comparison of models, not the best achievable LLM forecast.

ForeGlass LLM Ensemble LLM median

Where we disagree with the consensus — stated in advance

Ranking agreement is not a result. This is: the questions where the ForeGlass engine sits furthest from the LLM consensus, published before the answers were knowable. Distance is measured in consensus spreads (z), because a gap means something different when the models agree tightly than when they are far apart. Every input is a published field — recompute this from ledger.json rather than taking our word for it.

Question	Due	ForeGlass	LLM median	Gap	z	LLMs

This is the bet, and it is falsifiable. If the consensus is right and we are wrong, these are the rows that will show it most clearly — and they will be scored and published exactly like every other lane. A forecaster who only disagrees where it is safe is not forecasting.

This ranks agreement, not correctness. Nothing here has resolved yet, so the only honest comparison is where each forecaster landed and how far apart they are. Accuracy columns light up at the first grading date — not before.

Parts that must add up to the whole official published statistics

In plain terms: a forecast about a part should be consistent with the whole it belongs to. Each chain takes an officially published total, splits it into the pieces the statistics agency itself publishes, adds them back up, and shows how far off the round trip lands. A rung marked ◆ carries one of our sealed forecasts. Each chain is a group: open the one you want. The per capita switch redraws the ladders per person or per household where the chain has a stated denominator - that view is a ratio, so the shares, the running total and the residual stay on the totals.

About this tab

These are measured, published values reconciling with each other - the frame our sealed forecasts sit inside.

Where the parent total is independently compiled (the World Bank's EU aggregate), landing on it checks our member set, joins and arithmetic against an outside compiler. Where the parent is only the sum of its own published bands, exact agreement is the expected result - it verifies arithmetic, not two independent measurements.

What this tab does not show

Closure is not accuracy. Almost none of these rungs carry a forecast yet; coverage is stated per chain as a number.
Exact agreement where both sides rest on the same underlying series is expected, not corroboration.
A chain that cannot be built is shown as a refusal naming the blocker.
Per-capita values are ratios on a stated denominator - they do not add up, and where the denominator comes from a different statistical universe than the numerator the chain says so.

What this page is, and what it is not

Forecasts are extracted from committed simulation runs and external model panels, then sealed: the forecast, its due date and its resolution rule are hashed together and appended to a ledger that is never rewritten. When the due date arrives the published statistic is read from the named public source and the forecast is scored — whatever it says.

Seal before witnessing. A forecast enters the ledger with its hash while the outcome is still unknown. That ordering is the whole claim; everything else on this page exists to let you check it.
How a resolved lane is scored. A lane is a hit if the published value falls inside the sealed interval (or matches the sealed point rule). Alongside that we publish skill against a naive forecast: skill = 1 − |err_model| / |err_naive| — above 0 beats the naive anchor, 0 ties it, below 0 loses to it. The anchor itself ships with every lane as naive_value, so the arithmetic is yours to redo: err = |actual − forecast| for each, then the ratio. For the first grading cohort the anchor is the year-ago committed share (2025-Q1) — the same statistic one year earlier, on the print committed at seal time. Publishing a score without the number it is measured against would be a number you could not check, which is the opposite of the point.
Which print counts, and when we are late. A lane grades against the first print as fetched on the grading run. Statistical agencies revise; a later revision never reopens a resolved outcome, in either direction. If a needed release has not published by the due date the lane resolves when the data lands — never voided, never estimated from the prior quarter — and it says so itself: a late lane carries late_by_design and the observed release_observed date, so a resolved_at later than its due date is legible as a slow source rather than as us backfilling.
Resolution rule fixed at seal time. Each lane names the public series and the exact computation that will grade it. The rule cannot be edited afterwards — it is inside the hash.
Misses publish like hits. There is no editorial step between grading and publication. A miss is a recalibration input, not an embarrassment to bury.
Competing forecasters, one question. Where several forecasters answer the same question, all of their lanes are sealed together, so the comparison cannot be assembled after the fact from the winners.
Held forecasts are still committed. Forecasts we are not publishing yet appear on the Verify tab as hash-commitments only — existence and immutability now, content on release.

What this page deliberately does not show: how the simulations work inside — model internals, calibrations, run lineage. The claim on offer is the scored track record, not the recipe; those are separable, and only one of them needs to be public for you to check us.

Verify it yourself

Alongside this page sits ledger.json — the machine-readable ledger behind everything shown here.

Seal algorithm:
What you can check here:
Independent time-anchor. A detached OpenTimestamps proof ships beside the ledger as ledger.json.ots, and every stamped release keeps a dated copy under ledger-archive/. Check it with any OpenTimestamps client: it proves these exact bytes existed before the Bitcoin block they are anchored into. This is the part you do not have to take our word for — it does not depend on us, and we cannot backdate it. It proves nothing about whether the forecasts are good; that is what the grading is for.
Commitments. ledger.json carries a commitments array: one {id, hash, sealed date} row per held forecast. When a held forecast is released, its hash on this page must equal the hash committed earlier — a forecast rewritten in between cannot match.
Time-witness it. Snapshot ledger.json at an independent web archive. That timestamp is outside our control, which is what makes the ordering claim checkable by someone who does not trust us.

Grading status:

Honest limit: two of the fields inside each hash are internal run identifiers, so this ledger does not let you recompute a hash from scratch — it lets you check that a published hash never changed. Independent archive snapshots are what turn that into a time-anchored claim.