For public sector and research

Sourced, dated, methodology-stamped UK area metrics that survive FOI.

Provenance on every signal: source, observed period, confidence reason. Country-scoped percentiles by design. The methodology changelog is public and the engine version is stamped on every response. Built for council planning, central-gov analytical units, regeneration bodies, and research institutes.

Get an API keyRead the methodology
The problem

Every number you publish has to defend itself.

Public-sector teams cannot publish numbers they cannot defend. A council briefing, a regeneration committee paper, a research note, an FOI response: every figure has to point at a source, a release date, a methodology, and a confidence that holds up under questioning. A black-box AI score is unusable here.

Most vendors lump England, Wales, and Scotland together into a single “UK area score” and call it normalised. That is a methodological lie. England’s IMD, Wales’s WIMD, and Scotland’s SIMD are different methodologies on different release schedules. Comparing them directly inflates or deflates rank in ways that would not survive procurement review.

Analysts also need reproducibility. The methodology cannot silently change between the procurement notice that named the vendor and the deliverable six months later. Same area today and on the contract end-date should produce the same metric, or the difference has to be a documented version bump rather than an undisclosed change.

How it fits

Five integration points from sourcing to publication.

What an analytical-unit or research integration looks like. Sourced signals, balanced triage, locked methodology, tracked priority set, audit-replayable AI.

Step 01

Resolve any area with sourced signals

GET /v1/area returns the seven-category catalog at LSOA grain. Each signal carries an explicit source, observed period, confidence value, and a plain-language confidence_reason. Country-scoped percentiles where the store backs them (deprivation, property, crime).

GET /v1/area?postcode=M1 1AE
-> { "signals": [
       { "key": "deprivation.imd_decile",
         "value": 1, "percentile": 5.4,
         "source": "IMD 2025 (England)",
         "observed_period": "IMD 2025",
         "confidence": 0.95,
         "confidence_reason":
           "IMD 2025 release; complete LSOA coverage." } ],
     "meta": { "engine_version": "2.0.2" } }
Step 02

Triage areas with the research profile

POST /v1/score with the research baseline profile is the general-purpose composite for triage. Balanced default weights across safety, transport, amenities, demographics, environment. Deterministic, no AI in the path, methodology version stamped on body and header.

POST /v1/score
{ "area": "M1 1AE", "preset": "research" }
-> { "score": 62, "area_type": "urban",
     "dimensions": [ ... 5 default-weighted ... ],
     "engine_version": "2.0.2" }
Step 03

Lock the methodology for the contract cycle

PUT /v1/orgs/:id/methodology pins the engine version your org consumes. Owner-only, validated at write time. Same call from any key inside the org returns responses stamped with that version. Procurement teams pin to the version named in the contract; analysts get reproducible numbers across the deliverable timeline.

PUT /v1/orgs/:id/methodology
{ "engine_version": "2.0.1" }

# Every subsequent product response:
X-Engine-Version: 2.0.1
Step 04

Track priority areas as a portfolio

Save your priority LSOAs (regen targets, levelling-up wards, intervention catchments) as a portfolio. Run change detection on a cadence. Static signals like deprivation produce zero change rows by design; only signals that actually move bite. Sample-size gating means a price swing on two sales never lights up a council briefing.

POST /v1/portfolios/:id/changes
{ "baseline": "first",
  "threshold_pct": 5,
  "min_transactions": 8 }
-> { "material_count": 4,
     "changes": [ {
       "signal_key": "property.median_price",
       "area": "E01005207",
       "period_from": "2025-04",
       "period_to":   "2026-04",
       "pct_change":  12.2 } ] }
Step 05

Audit-replayable analyst queries

When analysts use natural language via /v1/query, the response echoes the executed plan plus plan_source. Any analyst answer can be replayed as a deterministic programmatic call. The AI is the interface; the database is the answer. The trail is the API response itself.

POST /v1/query
{ "question":
   "wards in our priority set where IMD decile is 1 or 2" }
-> { "plan_source": "nl",
     "plan":   { "op": "rank_areas", ... },
     "results": [ ... ] }
# Replay deterministically by pasting the plan back:
{ "plan": { /* echoed above */ } }
Products you reach for

All four products. Each one earns its place in the publication trail.

Signals for raw sourced data, Scores for balanced triage, Monitor for tracked priority sets, Intelligence for audit- replayable analyst queries. One API key.

§ 01

Signals

See product →

Primary surface for public-sector workflows. Every signal carries an explicit source, observed_period, confidence value, and plain-language confidence_reason. Country-scoped percentiles where the store backs them. Provenance is on the wire on every response, ready for an FOI footnote.

GET /v1/area?postcode=M1 1AE
-> { "geo":   { "lsoa": "E01005207", "country": "England" },
     "signals": [
       { "key": "crime.total_12m",
         "value": 3712, "percentile": 92.1,
         "source": "police.uk",
         "observed_period": "Apr 2025 to Mar 2026",
         "confidence": 0.9,
         "confidence_reason": "12 months of data." } ],
     "meta": { "engine_version": "2.0.2",
                "fetch_mode": "hybrid" } }
§ 02

Scores

See product →

Research baseline profile is the general-purpose composite. Balanced default weights across safety, transport, amenities, demographics, environment. Deterministic engine, golden-tested, no AI in the path. Pin the engine version for the contract cycle and the numbers stop drifting under your deliverable timeline.

POST /v1/score
{ "area": "M1 1AE", "preset": "research" }
-> { "score": 62, "area_type": "urban",
     "dimensions": [
       { "key": "safety_crime", "score": 70, "weight": 20 },
       { "key": "transport_links", ... },
       { "key": "amenities_services", ... },
       { "key": "demographics_economy", ... },
       { "key": "environment_quality", ... } ],
     "engine_version": "2.0.2" }
§ 03

Monitor

See product →

Track priority LSOAs (regen targets, levelling-up wards, intervention catchments) as a portfolio. Change detection is on-demand; static signals produce no rows by design; sample-size gating keeps a noisy 2-sale swing from earning an alert. The ChangeReport carries baseline + threshold + min_transactions so a published "areas that moved" note has the methodology stamped inside the artifact.

POST /v1/portfolios/:id/changes
{ "baseline": "first",
  "threshold_pct": 5,
  "min_transactions": 8 }
-> { "areas_checked": 64,
     "material_count": 7,
     "changes": [ ... lineage-stamped rows ... ] }
§ 04

Intelligence

See product →

Audit-replayable analyst queries. /v1/query accepts free-text questions; the response echoes the executed plan plus plan_source. Any natural-language answer can be re-run as a deterministic programmatic call by pasting the plan back. The AI is the interface; the database is the answer. 92.9% planner accuracy measured on a 14-case curated corpus (the corpus is in the repo and version-controlled).

POST /v1/query
{ "question": "..." }
-> { "plan_source": "nl",
     "plan":   { "op": "rank_areas", ... },
     "results": [ ... ] }
# Replay deterministically:
{ "plan": { /* echoed plan above */ } }
-> plan_source: "client"
What you can defend

Six properties that hold up at FOI and procurement review.

The defensibility pitch. Each property is documented on /methodology and stamped on every response, ready to be cited in your methodology section.

§ 01

Country-scoped percentiles by design

Normalisation runs national-within-country. England's IMD 2025, Wales's WIMD 2019, and Scotland's SIMD 2020 are different methodologies on different release schedules. We refuse to manufacture a cross-border percentile that would not survive procurement review.

§ 02

Provenance on every signal

Every Signal carries an explicit source, observed_period, confidence (0-1), and a plain-language confidence_reason. Lineage stamps (source_snapshot_id, engine_version, boundary_version) on every persisted row. Ready for an FOI footnote without you stitching it together.

§ 03

Sample-size honest

Monitor change detection gates price moves on transaction count (default 8 in both periods). Static signals produce zero change rows. The system says when it cannot tell instead of hallucinating a move that would embarrass a council briefing.

§ 04

Plan-replayable AI

Every Intelligence response echoes the executed plan plus plan_source ('nl' or 'client'). Any natural-language analyst answer can be replayed as a deterministic programmatic call. The methodology behind the answer is a JSON object you can store in the publication appendix.

§ 05

Methodology version pinning for the contract cycle

Per-org engine_version pin honoured on every product response via X-Engine-Version header. Owner-only, validated against the supported window. Two API calls under the same pin return the same numbers across deploys, which is exactly what a procurement deliverable timeline requires.

§ 06

Published methodology, citable in any research note

The methodology is public on /methodology. Every response carries an engine_version stamp + X-Engine-Version header. Your research note can cite the methodology page + the exact engine version that produced any number.

Frequently asked

Questions a research or analytical unit asks first.

Will the numbers survive an FOI response?

Yes by construction. Each signal carries an explicit source, observed_period, confidence, and plain-language confidence_reason. The methodology version is stamped on every response body and the X-Engine-Version header. The full methodology is public on /methodology. Your FOI footnote can point at the source, the release, and the engine version.

Can we pin the methodology for a contract or procurement deliverable?

Yes. PUT /v1/orgs/:id/methodology persists an engine_version pin per organisation. Owner-only, validated against the supported version window. Every product response honours the pin via the X-Engine-Version response header. Two API calls under the same pin return the same numbers across deploys, which is exactly what a procurement deliverable timeline requires.

Do you cover Northern Ireland?

Not yet. England, Wales, and Scotland are covered today via the ONS NSPL spine and the three national deprivation methodologies (IMD 2025, WIMD 2019, SIMD 2020). NIMDM (Northern Ireland's deprivation measure) and the NI postcode spine are on the roadmap. The Signal contract is country-scoped, so NI postcodes return null rather than a fabricated cross-border value.

Can the analyst cite OneGoodArea in a research note or report?

Yes. Each signal carries a source string (e.g. police.uk, IMD 2025, HM Land Registry) you can cite directly. For methodology citation, the canonical reference is the /methodology page plus the engine version your queries ran under (visible on the X-Engine-Version header).

What about precision and statistical confidence intervals?

Confidence today is availability + sample based (0 to 1) rather than a calibrated statistical CI. Property dimensions cap at MEDIUM when the underlying YoY swing is wide (variance-aware rubric). Calibrated outcome-based confidence with proper intervals is on the roadmap as Phase 7; the current value is honest about being a v1 trust signal, not a statistical CI.

Can we aggregate signals to ward or district level?

Today aggregation is country and Local Authority District via the ONS spine. Ward-level and MSOA-level aggregation are on the roadmap. For now the typical pattern is to resolve a list of LSOA codes (the ward's constituent LSOAs from your own spine lookup) and aggregate client-side. Levers peer cohorts persist named LSOA lists if the aggregation is one your team uses repeatedly.

What gets stored about us as an org?

Org row with name and slug; member roster with three-tier RBAC (owner, admin, member); api_keys table linked to your org. Optional Levers state: signal bundles (named signal-key whitelists), saved scoring profiles, methodology pin, peer cohorts, white-label display_name and brand_url, per-key IP CIDR allowlist. No PII about residents of the areas you query; the LSOA grain is statistical, not personal.

Sourced, dated, methodology-stamped. Built for the publication.

Pin the methodology for the contract cycle, track priority LSOAs as a portfolio, replay any analyst query as a deterministic plan. The audit trail is the API response itself.

Get an API keyRead the methodology