About OneGoodArea

We’re building the data and intelligence layer underneath UK property workflows.

Deterministic signals, configurable scoring, portfolio monitoring, and a typed AI query plane over monthly area time-series. One API, one methodology, version-pinned per organisation.

01Why we exist

UK property workflows still stitch area data from seven portals.

An underwriter wants crime, deprivation, education, and price context for a postcode. They open four tabs, copy numbers into a spreadsheet, and hope the dates line up. A site selection team wants to rank 40,000 catchments against their own criteria. They cannot, because no single API answers a compound query against the ONS spine with country-correct percentiles.

We built the layer underneath. The same official sources every compliance team already trusts, but stitched into one API with the dating, attribution, and percentile scoping done correctly by construction. Methodology version stamped on every response. Sample-size gates on every change-detection job. A published methodology behind every architectural choice.

It exists so the underwriter, the planner, the site selection lead, and the analyst all pull from the same numbers, with the same methodology, on the same engine version. Decision-grade by construction. Auditable on first request.

02What we believe

Six principles, applied in code and stamped on every response.

These aren’t marketing words. Each one is enforced in code, documented in /methodology, and citable in your audit footnote.

  1. 01

    Deterministic at the source

    The engine sets the number, not the AI. Every score, signal, and percentile is computed by a versioned SQL + rules pipeline you can replay byte-for-byte. AI sits on top as a planner and a query plane, never as the source of truth.

  2. 02

    Methodology is public

    Every dimension, every weight, every aggregation step is documented on /methodology. The methodology version is stamped on every response. If a number lands in your report, the trail is citable.

  3. 03

    Plan-replayable AI

    Natural-language queries emit a typed plan (Zod-strict JSON) before any SQL runs. The same plan replays without an LLM call. The AI is auditable because it is not the executor.

  4. 04

    Sample-size honest

    When the underlying data is thin, confidence drops and the response says why. Price moves on two transactions never trigger a webhook. We would rather say less than say something wrong.

  5. 05

    Pinnable per organisation

    Methodology version locks per-org. Your contract cycle survives engine upgrades. Two calls in the same window return the same numbers across deploys.

  6. 06

    Country-scoped percentiles

    England compared against England, Scotland against Scotland, Wales against Wales. No cross-border lies. Three official deprivation methodologies, three percentile spaces, by design.

03How it got built

Engine first, surfaces second, AI last.

OneGoodArea is built lean by a small team. The first phase was the engine: the ONS postcode spine, the three national deprivation methodologies, the price and crime time-series, the confidence rubric, the version stamp. The four products you see today (Signals, Scores, Monitor, Intelligence) all sit on that same core. Same numbers, four shapes.

AI joined the stack only after the engine was deterministic and the methodology was published. The planner emits a typed plan first; the SQL runs second; the LLM never touches the numbers. That ordering is the architecture, not a slogan. It is the reason a public sector analyst can replay an AI query a year later, without an LLM call, and get the same rows.

  • v2.0.2
    Engine version stamped on every response
  • 4
    Products live (Signals, Scores, Monitor, Intelligence)
  • 5
    ICPs served (PropTech, insurance, lenders, CRE, public sector)
  • 35+
    Architectural decision records published
04Talk to us

Procurement question? Methodology question? Building on top of us?

Whichever it is, the fastest channel is the one below you already use.