Candidate generation

Candidate generation is the retrieval step that hands the matcher a short list of the entities a record might be. It is blocking viewed from the other end: blocking describes how the search space is cut, candidate generation describes what comes back — typically a ranked shortlist of five, ten or fifty entities, drawn from an internal catalogue and, where the resolver has them, from live registers.

It is evaluated with recall at k, not with precision. The shortlist is allowed to be mostly wrong; what it may not do is omit the right answer, because nothing downstream can recover an entity that was never proposed. A pipeline reporting 95% end-to-end accuracy on a generator with 90% recall is reporting on the population the generator handed it, not on the population that arrived.

The second property that matters is ranking. A shortlist whose right answer is usually first supports a cheap decision; a shortlist whose right answer is somewhere in the top fifty forces every record through an expensive comparison stage. The two are measured separately, at different k.

On the gated acquisition fixture, 205 name-only records on the gated acquisition fixture. the correct entity was ranked first for 74% (151/205) and appeared in the top three for 100% (205/205). The stub-adjudicated run behind the pairwise gate, not the 317-company live recording behind the tier table. Recall is a property of the list, not of the winner. 74% is far below the 0.90 acceptance floor, so no row of that shortlist may be offered as a match, quoted as an accuracy number, or folded into an accepted-match count.