Offrly Sealed Quarterly Benchmark

Auto-generated, immutable. Snapshots can't be re-curated, re-cherry-picked or re-tuned after the fact — this report is what it is the moment HMLR publishes the matching sales.

How the benchmark works

Snapshot. At the end of each calendar quarter, every BUY valuation issued in that quarter is frozen to data/benchmark/<quarter>.jsonl. The snapshot file is not rewritten.
Wait. HM Land Registry publishes its sold-price data with a delay; we let six months pass so most matched sales are available.
Auto-join. For each frozen valuation, we look up sales on the same full postcode that completed after the valuation date. No admin reviews these matches.
Tie-break. When one postcode has multiple HMLR sales after the valuation date, pick the sale whose price is closest to the prediction.
Metrics. Compute hit rate ±10/±20%, MdAPE, MAE, and 95%-band coverage. Publish all four — even when they're unflattering.

What this number means, and what it doesn't. The benchmark is the most adversarial public read on Offrly because we deliberately do not curate which pairs feed it. The trade-off is that the postcode tie-break (closest-by-price) biases each individual pair toward the model. We surface that explicitly rather than hiding it. If you want the higher-signal, smaller-sample, address-confirmed view, see the accuracy report. The two reports are complementary; the truth lives somewhere between them.

What's in the report, transparently

Scope: sale valuations only. Rentals are not included — there's no public sold-rent equivalent.
Ground truth: HM Land Registry Price Paid Data — every arms-length freehold and most leasehold residential sales in England and Wales.
Licence: Open Government Licence v3.0.
Curation: none. Every BUY valuation issued in the snapshot quarter is in the benchmark population.
Leakage controls: by construction every prediction was made strictly before its matched sold date.
Update cadence: a new snapshot freezes at each quarter-end; metrics for that snapshot land six months later as HMLR catches up.

For more context on how Offrly produces a price in the first place, see how Offrly works.

Frequently asked questions

How is the benchmark different from the accuracy report?

The accuracy report uses admin-curated valuation × HMLR pairs — richer signal per pair, smaller sample, human in the loop. The benchmark snapshots every BUY valuation issued in a quarter, then auto-joins with HMLR sales six months later. No human picks which pairs feed the metrics. The two reports are complementary.

What does '95%-band coverage' mean?

Each Offrly valuation has an internal 95% prediction band. Band coverage is the fraction of true HMLR sale prices that fell inside that band — the calibration test of whether the claimed range matches reality. A well-calibrated 95% band covers ~95% of outcomes.

What happens when one postcode has multiple sales?

We pick the candidate sale whose price is closest to the prediction. This is the most charitable read for the model and we surface that explicitly so reviewers know — there's no hidden choice.

Are snapshots really immutable?

Yes. Once written, the snapshot file is not rewritten. New HMLR sales arriving later add candidates to the auto-join but they cannot change which valuations are in the snapshot — those were frozen at quarter-end.

Source: HM Land Registry Price Paid Data, licensed under Open Government Licence v3.0. Offrly estimates are indicative market guidance — not regulated valuations and not financial, tax or legal advice.