Assurance — what we verify, and what we cannot

The claim

Statbook never claims to be “100% accurate.” The claim is: traceable, corroborated, re-verified, versioned, signed — and when wrong, detectably and briefly wrong, with a published correction trail. No indemnity is offered at any tier.

How a value earns “corroborated”

Every figure declares which legal instrument governs it (Source A, legislation.gov.uk) and which official guidance page states it (Source B, gov.uk). The two are fetched and extracted by isolated passes that share no state; only when both extractions match can a value carry the corroborated status — the build system is physically unable to emit it otherwise. Mismatches ship as disputed or not at all.

Source independence — the honest statement

Source B is HMG's own interpretation of the legislation, produced downstream of it. Corroboration therefore catches our extraction errors, staleness, and drift — it does not catch an error both sources share, nor resolve genuine ambiguity in the instrument itself. A-vs-B mismatch most commonly means gov.uk hasn't updated yet (early April) — exactly what the gate must catch.

In plain terms: corroboration is a strong net for our mistakes, not a guarantee the government's own documents are right. An error shared by both sources, or genuine ambiguity in the instrument itself, passes through by design and is caught only by the corrections protocol when surfaced.

Assurance by source type

The promise “every figure traceable to primary legislation” is scoped to act/si source types. Other types are published with their assurance level explicit — honesty as a feature, not a broken promise.

source_type	Examples	Two-source gate	Assurance level published
`act`	AMAP rates (ITEPA 2003 s.230(2))	Yes	Full
`si`	Increase of Limits Orders, NMW regs, uprating orders	Yes	Full
`presidential_guidance`	Vento bands (no SI exists; judiciary.uk PDF, URL rotates yearly — each snapshot archived; Crown/OGL via site-wide notice)	Degraded (sole publisher + reproductions)	Labelled
`administrative`	HMRC Advisory Fuel Rates (gov.uk-only, non-binding, page overwritten quarterly)	No — single source, honestly labelled	Labelled
`computed`	Late-payment interest (SI formula × live BoE base rate)	Formula yes; value computed	Labelled + formula shown
`derived`	Max redundancy payment (20 × 1.5 × cap)	Derivation from corroborated inputs	Labelled + derivation shown

April and Budget weeks — “guidance confirmation pending” is the system working

On the day a new instrument is made, gov.uk typically hasn't updated yet. The headline new figures therefore cannot pass corroboration on day one — and the gate refuses to claim corroboration it doesn't have. Promoted figures publish as Primary source only with guidance confirmation pending, and nightly re-verification auto-promotes each one to Corroborated the day gov.uk catches up — leaving a public, dated promotion trail. If you see that badge in early April, you are watching the gate work in public.

Re-verification and corrections

Every current value's sources are re-fetched and hash-compared nightly; last_verified on every record and API response.
Source drift that removes a value auto-flips its status to disputed within 24 hours, before any human review.
Wrong values are never deleted: they stay in history marked corrected, with a numbered advisory in the public corrections log.

Verify a record yourself — no trust in us required

Take any record from the API, e.g. /v1/figures/employment.redundancy.weekly_pay_cap.json — the receipt.record_hash field states its SHA-256.
Recompute it: serialize the figure object as UTF-8 JSON (2-space indent, non-ASCII preserved, trailing newline) and hash it.
Check the same hash appears in the release manifest under record_hashes.
Verify the manifest's minisign signature against the published public key, and compare the manifest with the copy in the public statbook-releases git repository — history rewrites there are detectable by any cloner.
Follow the per-source citations: every uri is the official document, and content_hash pins the exact bytes we extracted or verified from. Where those bytes are a different representation than the cited page — legislation citations point at the human-readable page while extraction reads the as-made data.xml — content_hash_of names the exact URL the hash pins. Sources whose documents we have not yet archived carry content_hash: null rather than a hash we couldn't back.

A reference implementation ships in the repository as pipeline/verify_receipt.py.

The signing key

Every release manifest is signed with this minisign public key (key ID 12D5059844B2CD8F). The same key is published in every API response under meta.signing and in the statbook-releases repository README — cross-check all three so no single source can substitute a key of its own.

Save it as minisign.pub and verify any manifest offline:

untrusted comment: minisign public key 12D5059844B2CD8F
RWSPzbJEmAXVEvTqYZ8O9iHuOcOUii5lCNZM5t9bdoQh4ZnwKsxk/+bd

minisign -Vm manifest.json -p minisign.pub