How rielty's AI uses property data (and why it never makes things up)

Language models have a well-earned reputation for confident nonsense. Ask a general-purpose chatbot about house prices on a specific street and it will happily produce a plausible-sounding number with no source behind it. That is the single biggest reason to distrust "AI" in property — and the problem we designed rielty's search around. Our answer is blunt: the AI never gets to be the source of a fact. It translates your sentence into database filters, and every listing, price and count that comes back was queried from data, not generated by a model. This article is about what that data is and how the AI is forced to stay inside it.

We've written before about the public datasets behind UK property in general terms. This piece is different: it's specifically about how our AI agent uses them — and how they keep it honest.

The foundation: 15.8 million sold homes

The core is HM Land Registry Price Paid data: 15.8 million sold homes across England and Wales, covering every recorded sale since 1995. When rielty's chat answers "what do homes on streets like this go for", it is reading actual transactions, browsable at /sold-prices — not estimating from vibes.

A 1998 sale price on its own is close to useless for judging today's market, so every historic price is indexed to the current market using the UK House Price Index. A house that sold for £62,000 in 1997 can be shown alongside what that sale implies at today's price levels, which is what you actually want to know.

Two honest caveats. First, coverage is England and Wales — we don't claim UK-wide. Second, sold-record results in search are labelled "market examples, not for sale", because that's what they are: evidence of what an area holds and what it costs, not live stock. Live listings come from free agent feeds and sit alongside them, clearly distinguished.

The layers that describe how you'd actually live

"Search by life, not location" only works if the life part is data too. Each thing you can ask for maps to a specific published source:

The commute layer deserves a word on its own. We took the national rail timetable — hundreds of thousands of schedules — and precomputed it into station-to-station journey times. When you say "45 minutes to London", the search checks real weekday timetable journeys, not a straight line on a map. The limit is equally real: it's train, station to station, at weekday peak. We don't claim door-to-door times, and we don't do driving, bus or tube commutes — the walk to the station is shown as a distance instead of being folded into a fictional total.

Around all of that sit the supporting datasets: the EPC register for floor areas and energy ratings, OS OpenData for greenspace, rivers, place names and UPRNs, DfT bus stops, planning applications, Ofcom broadband (shown on property pages, though not a search filter), and Bank of England rates for context.

Grounding, visibly: each card names its school by Ofsted inspection date, and admits its trade-offs — estimated bedrooms, a dated sold price.

What grounding actually means in practice

"Grounded" is becoming a marketing word, so here is what it means concretely in rielty:

• It never invents a listing. Every card you see exists as a row in the database. The model cannot add one.
• It never invents a price or a count. "I've got four" means the query returned four. A price is a recorded sale or an agent-fed listing, full stop.
• Unmatched requirements are disclosed by name. Ask for "a wine cellar" and no filter exists for that — so the search tells you: couldn't use: "wine cellar". Nothing is silently dropped, which means you never get results that quietly ignored half your sentence.
• Known gaps are stated in the product, not buried. Flood risk is England-only and the interface says so. Bedroom counts are missing from most sold records, and the UI warns you rather than pretending to filter reliably on them.

That last discipline — admitting what a dataset can't do — matters as much as the datasets themselves. Environment Agency flood bands are a risk categorisation, so we filter by band and never promise a home is "flood-safe". Proximity to the coast is a distance, so "near the sea" works but "sea view" doesn't — no dataset on earth records what you can see from a bedroom window, and we won't pretend otherwise.

Why this architecture beats a cleverer model

There's a tempting alternative design: let a powerful model answer property questions directly from what it absorbed in training. It would be fluent, fast — and unauditable. When it got a street's price level wrong, nobody could say why.

Our structure is deliberately duller. The model's only creative job is understanding your sentence; retrieval is boring, deterministic database work. That split means an error is diagnosable: either the sentence was misread (and the chip row showing "here's what I understood" exposes that immediately — remove a chip and the search re-runs), or the data has a gap (and the source is named). Fluency without a source is exactly the failure mode we built this to avoid.

It also means the answers age well. When new sold prices land, or a fresh month of police.uk data arrives, the answers change because the data changed — not because a model was retrained into different opinions.

Every dataset and licence behind the answers, published at /data.

Check the sources yourself

We publish where every dataset comes from, with licences, at /data. If you're weighing whether to trust an AI search tool, that page is the test worth applying to anyone: can they tell you, dataset by dataset, where their answers come from? If the sources aren't published, the honest assumption is that some of the answers are generated rather than retrieved.

The practical takeaway for a house-hunter is simple. Treat rielty's answers as what they are: real records, indexed and layered, with the seams shown. Where the data is strong — sold prices, schools, noise, trains — lean on it hard. Where we tell you it's thin, believe us; that warning is the feature.

This is part 5 of our series on rielty's AI search. Next, part 6: how to ask rielty — prompts that work, a practical guide to phrasing searches that use all of this data at once.