Shrink the Candidate Space

When the join key is unreliable, the leverage is in reducing how many pairs you even consider — not in making a smarter matcher decide each pair. Cut the candidate space first; tune the comparison second.

Explanation

The source (Working Heuristics — Data, Matching, Product, Org, Tooling) states it as: unreliable join key → shrink the candidate space, not tune the matcher. When you can't trust a key to join cleanly, the instinct is to build a cleverer similarity function. But a matcher operating over the full cross-product is both expensive and error-prone — more pairs means more chances to be confidently wrong.

The higher-leverage move is candidate generation / blocking: use cheap, reliable signals (a shared region, a date bucket, a normalized prefix) to partition the data so only plausibly-matching records are ever compared. A smaller, higher-quality candidate set makes even a simple matcher accurate, and makes a sophisticated one tractable.

Why it matters / where it shows up

• Precision and cost both improve from the same move. Fewer candidate pairs means fewer false positives and less compute — you don't trade one for the other.
• It's a "change the problem, not the solver" heuristic. Rather than absorb an unreliable key as a matcher-tuning burden, you reshape the input so the key matters less. (Compare Falsification Is Asymmetric's "sample the spectrum" — both are about structuring the work before grinding on it.)
• It pairs with identity authority. Once candidates are matched, which record wins is a System of Record question; shrinking the space is how you get good candidates to adjudicate in the first place.

Open questions

• How aggressive can blocking get before it starts dropping true matches that don't share the blocking key? The recall/cost trade in candidate generation.

Connections

• System of Record — matching produces candidate links; authority decides which record is canonical.
• Human-in-the-Loop by Exception — the residual ambiguous pairs after blocking are exactly the "true exceptions" worth a human's confirmation.
• Data Contract — reliable, well-derived keys at the boundary reduce how much candidate-shrinking the matcher needs in the first place.

Sources

• Working Heuristics — Data, Matching, Product, Org, Tooling — "unreliable join key → shrink the candidate space, not tune the matcher."