Skip to main content

Sure Start closures methodology

This page describes how FamilyPlans assembles its Sure Start closures dataset, the verification levels we use, the sources we draw on, and the process for updates and corrections. We publish this methodology before the public map and we do not publish individual map markers without an evidenced source for that location.

Verification levels

Each centre in our dataset has one of these verification statuses. The map publishes individual markers for verified_closed, transitioned, and replaced_by_family_hub only. Counts for the others are shown aggregate-only, with the methodology disclosed.

Current dataset state

Current counts (no record updates yet):

We do not publish one fixed “X centres closed since 2010” headline. Counts here update from verified records and are shown with their verification level.

Sources we draw on

The full source register, with licence and review status for each entry, is at /methodology/sources.

How we get from a source to a record

  1. Each source is registered, robots-checked, terms-reviewed, and assigned a refresh cadence before any scraper runs (see /methodology/sources).
  2. Scrapers fetch source pages, store immutable snapshots in private object storage, and extract claims into our claims ledger with a content hash, fetched timestamp, and parser version.
  3. Each centre's verification_status is set based on the strongest available evidence — we never use language stronger than the source supports.
  4. Disputed records are flagged and re-investigated; corrections appear at /research/corrections.

How readers can challenge a record

If you have evidence that contradicts our classification of a specific centre, please report it with a source link. We aim to acknowledge within 2 business days and resolve within 5. Particularly welcome:

What we do not do

The Sure Start closures map publishes verified records only. See /research/sure-start-closures for the interactive view.

Not yet verified

Spotted something wrong? Report an error — we aim to respond within 2 business days.