We assemble every plausible match, standardise how each record is written, then remove duplicates before counting. A count moves between passes when that rule changes, a source is added, or dropped — so we publish the rule beside every count, and below three matches we give a range, not a point figure.
What a "comparable-set count" actually means
When we build a comparable set — the group of similar recent sales, listings, or loan-backed properties used to support an opinion of value — the headline number people remember is the count: "we found this many comparables." That number looks like a fact. It is actually the output of a process, and the process has choices built into it that can move the number even when nothing about the underlying market changed.
Two passes over the same universe of records can legitimately return different counts. That is not, by itself, an error. It only becomes an error when a count is published without saying which version of the process produced it — because then two honest numbers look like a contradiction.
Why the count moves between passes
Three things routinely move a comparable-set count, and none of them means an earlier or later number was "wrong" in isolation. They mean the two counts answered slightly different questions.
- A canonicalisation rule changes. Before anything can be counted, every candidate record has to be reduced to a comparable form: address casing standardised, punctuation stripped, whitespace collapsed, so that "123 Main St." and "123 MAIN STREET" register as one building rather than two. Tighten or loosen that rule between passes — for instance, deciding that a building split across two parcel records should count once instead of twice — and the count moves even though the actual set of buildings on the ground hasn't.
- A source is added. A later pass may pull in a registry snapshot, a transaction record, or a loan file an earlier pass didn't have. The set grows for a real reason, not a mistake.
- A source is dropped. A record can turn out, on closer inspection, to be a duplicate, outside the subject's true market, or unreliable, and gets excluded on a later pass. The set shrinks for a real reason too.
Take a hypothetical: suppose a first pass finds 40 candidate buildings in a submarket. A closer look shows four of those are the same physical building, listed under two name spellings and two parcel IDs. Collapse those under one consistent canonicalisation rule and the count drops — not because four buildings vanished, but because they were never four distinct buildings to begin with. That is the ordinary shape of the problem: the number moves, the method explains why, and the explanation has to travel with the number, every time.
The rule: no count travels alone
We treat a comparable-set count as unpublishable by itself. Any time a count leaves the building — in a report, in a proof point, in a page like this one — it carries the canonicalisation rule that produced it: how duplicates were identified, how address text was standardised, and what, if anything, was excluded and why. A bare number invites exactly the failure above: someone reads a count from one pass, someone else reads a different count from a different pass, and without the method attached the two look like a contradiction instead of two honestly different answers to two honestly different questions.
Below three comparable sales, we don't publish a point value at all — we report a range instead. A set that thin doesn't support a single confident number, and presenting one anyway would be a worse failure than admitting the set is small.
We were caught by exactly this failure once
This isn't a hypothetical concern. An internal review once caught a case where an outbound comparable-set count was drafted for publication without its canonicalisation rule attached. The underlying set had in fact produced a different count on each of several earlier passes, for the ordinary reasons described above — but the draft that reached review carried only a final number, with no note of which pass it came from or how that pass had defined a match. The reviewer blocked the draft before it shipped, because a reader handed a bare count has no way to tell whether it's comparable to a different count they may have seen elsewhere, let alone reproducible.
The fix wasn't a one-time correction to that one draft. It became a standing rule: a comparable-set count is not publish-ready on its own. It ships with its canonicalisation method stated beside it, every time, or it does not ship at all. We're naming that this happened, rather than quietly folding the fix into house style, because the failure is common to any process that counts things out of messy source records — restating the rule is cheap, and skipping it is the whole cause of the confusion.
What this means when you're reading our output
If you see a comparable-set count from us, you should also see, right beside it, the rule that produced it: what counted as a duplicate, what sources were in scope, what was excluded and why. If you don't see that, ask for it.
And if a count you've seen from us before differs from one you're seeing now for what looks like the same set, the first question isn't which one is right. It's whether the two passes used the same canonicalisation rule. Usually they didn't — and that difference, not an error, is the entire explanation.