Coverage parity check

The bug report says the page is half empty for one postcode

Why coverage parity across endpoints is a data-model property, not a runtime surprise.

Propalt Team · For PropTech platforms

The worst kind of data gap is the silent one. Your property page calls three sources: one returns a value, one returns an energy rating, one returns nothing. The page renders half empty, no error is thrown, and the first you hear of it is a support ticket for a postcode that used to work. When you stitch together separate vendors, coverage is the ragged edge where their datasets disagree, and the disagreement surfaces in your UI rather than in your logs.

It is fair to say that no dataset covers every property perfectly, and any provider claiming total coverage should be treated with suspicion. The honest position is different: coverage should be consistent across endpoints, so that if a property is present at all, every endpoint that applies to it returns for it. Parity does not promise that every field exists for every property. It promises that your valuation call and your EPC call are looking at the same universe of properties, so one does not silently return while the other silently does not.

Parity is a property of one dataset, not three

When ownership, valuation and energy data come from three vendors, coverage parity is impossible by construction. Each vendor built its dataset independently, so their footprints overlap but never match. A property that resolves in the AVM might be absent from the EPC feed, and there is no way to guarantee otherwise, because the three sources were never reconciled against a common key. The gap is not a bug you can fix; it is a consequence of the architecture.

Propalt resolves every endpoint against the same set of 29 million England and Wales properties, drawn from 8 authoritative UK registers into one dataset. get_property, get_epc_fabric_by_postcode and get_valuation_by_property_id all key against those same records. That means parity is a property of the data model, not something your application has to defend against at runtime. If a property is in the dataset, the endpoints that apply to it resolve for it, and you can reason about coverage once rather than per vendor.

The comparison above is illustrative. The point is structural: parity holds when the endpoints share a dataset and fails when they do not.

Your UX should not encode vendor gaps

When coverage is ragged, the raggedness leaks into your product. You end up writing defensive UI for the case where one source returns and another does not, adding empty states, fallbacks and caveats that exist only because your vendors disagree. That defensive code is a tax you pay on every feature that touches more than one source, and it grows every time you add a vendor.

Coverage parity means you handle the absence of a property once, not the absence of a field three times.

With a single dataset, your handling collapses to one case: the property is present, or it is not. You are not encoding the quirks of three separate footprints into your front end, and a postcode that works today does not stop working tomorrow because one vendor quietly dropped it at a data refresh. The registers refresh on a 24h cycle across the whole dataset, so the coverage your UX depends on moves together rather than drifting apart. Fewer edge cases in the data means fewer edge cases in the code.

Make coverage a fact about the dataset, not a surprise in your support queue.

Try the Coverage parity check → · propalt.ai

Data is drawn across 29 million England and Wales properties from 8 authoritative UK registers plus the Propalt intelligence layer. Figures shown are illustrative. This article is general information for platform teams.