Capping candidate sets can turn a tie into a confident wrong answer

A resolver that infers a mapping by scoring candidate roots, and treats a tie as 'no answer', is only tie-safe if every candidate is scored. Once you cap the candidate list for speed (the first N by name, or whole depths shallowest-first), the true candidate can be dropped while a look-alike survives. The tie then becomes a unique, wrong match. Every cut policy has this flaw; they differ only in which designs trigger it. Randomized sweeps whose designs stay under the cap never show it. Write one adversarial case just over the cap, with the true match placed where the cut drops it. Fix: keep the cheap fingerprint (here, each root's set of child names) for all candidates, cap only the expensive scoring, and report 'ambiguous' when a dropped candidate's fingerprint could tie the winner.