A set-level gate that reads the top-ranked candidate before the per-item filters lets a tie-break decide whether any answer exists at all

The lesson

When a filter chain can reject at two different arities — one rule that returns nothing at all, and another that removes individual candidates — the order between them is not a refactoring detail. It decides which candidates the set-level rule is allowed to look at.

Put the set-level rule first and it reads the ranked head, which is whatever won the score race. That head may be an item the per-item filter is about to delete. The whole answer is then discarded on behalf of a candidate that was never going to be returned.

The deeper error is letting rank decide existence. Ranking answers "in what order", and its inputs are tuned for ordering — priors, recency, usage multipliers, tie-breaks. None of those are evidence about whether the collection contains an answer. Wire them into an existence decision and a difference far below the resolution anyone reasons about becomes the difference between "here is your answer" and "there is nothing here."

The failure that taught it

A document-lookup layer had a floor that returned an empty result set when a query's vocabulary looked unanswerable by the corpus, with an escape hatch: if the top hit was decisively the answer, return it anyway. The escape read the top-ranked candidate.

A document's own declared trigger phrase — the corpus's own statement of what that document is for — stopped retrieving it. Scored on the live index, the wanted document was ranked second at a score of 28.254, behind 28.356. A gap of 0.36%, opened entirely by a usage-feedback multiplier that has nothing to do with relevance. The escape hatch inspected the leader, found it undistinguished, returned false at its first line, and the floor emptied the answer.

The leader was itself below the per-item coverage floor. It was never going to be shown to anyone. So a rejection that could delete the entire answer consulted a candidate that the very next statement deletes, and the layer that would have cleaned this up correctly ran one step too late to be asked.

Two things made it hard to see:

The regression had no author. Nothing in the lookup code changed. Enough new documents landed to shift a multiplier, and a threshold calibrated against the old corpus quietly stopped holding. A floor tuned against a corpus is a claim about that corpus, and it expires without anyone editing it.

The first fix passed the tests and was wrong. Widening the escape to scan the top three candidates instead of only the first made the failing check green and every negative case still return nothing — so it looked correct. A different suite caught it: a fixture living outside the main negatives found an unrelated document sitting at rank two with a perfect intent score, because that query had only two scorable terms and matching both is a coincidence over a two-term vocabulary, not a declared contract. Separating the good case from the bad one would have meant fitting a constant between one negative at 0.79 and one positive at 0.9964 — tuning to two points. Reordering the two rejections needed no constant at all, and the coincidental match still correctly yields nothing, because it is not the leader and the leader is not decisive.

How to apply it

1. Inventory your rejections by arity. Which can return nothing at all, and which remove single items? If both exist in one path, the ordering between them is a decision — make it deliberately and write down why.
2. Run the per-item filters first, then ask the set-level question of the survivors. Whether an answer exists should be decided from the candidates that could actually be delivered. Asking afterwards costs nothing and removes the entire class.
3. Never let a ranking input reach an existence decision. Priors, usage counts, recency boosts and tie-breaks answer "in what order", not "is there anything here". If a 1% score change can flip your output between populated and empty, that is the defect, not the threshold's value.
4. When a set-level check regresses after the data grew, suspect the ordering before the constant. Retuning a threshold against the new data reproduces the same expiry later; the ordering fix has no constant to go stale.
5. A fix that turns the failing check green has not been shown to be right. Sabotage it: break the mechanism deliberately and confirm the cases it claims to guard go dark. Then check the suites that do not share fixtures with the one you were fixing — the first wrong fix here was green on every case the failing suite could see.