When scoped retrieval returns zero documents after metadata filtering, what should the system do?

## Emptiness is a state, not an absence Once scope is enforced, some queries legitimately match nothing: the user asked about a region they have no documents for, the version window excludes everything relevant, an ACL admits no documents on that subject. The dangerous thing is not the empty result — it is the pipeline treating it as an ordinary result that happens to have zero rows. A retrieval function that returns an empty list, whose caller joins that list into a context block and interpolates it into a prompt, produces a prompt with an empty context section and instructions that assume grounding. The model then answers from parametric memory, in the same register and with the same confidence as a grounded answer, and often with a fabricated-looking citation because the prompt asked for citations. The empty result never surfaced as a decision point. So the first rule is structural: retrieval returns a *typed outcome* — results, empty-scope, or below-threshold — and every caller must handle all three explicitly. ## Two different empties **Nothing matched the predicate.** No document in the collection satisfies the scope conditions. This is a metadata or scope problem: a field that was never populated for the older half of the corpus, a version window that has drifted past all available documents, a tenant with no ingested content, or a predicate combining conditions no document satisfies together. **Documents matched, but none scored above threshold.** The scope is populated and healthy; the query simply has no good answer in it. This is a retrieval-quality problem, and the diagnosis and fix are entirely different — different chunking, different query formulation, a different corpus. Collapsing them into one "no results" branch loses the single most useful diagnostic signal you have. Log the matched-count separately from the returned-count. ## What may be widened, and what may not The split follows the boundary/preference distinction. **Preference predicates may be relaxed** — a recency window, a document-type restriction, a language filter, a source-system restriction. A release-notes assistant scoped to the last two minor versions can, on an empty result, legitimately widen to older versions, provided the retrieved passages are marked as coming from outside the intended window so the downstream step can qualify what it says. **Boundary predicates may never be relaxed** — tenant, ACL group, region, classification. Retrying without them, softening them into score penalties, or returning "the nearest documents anyway, with a warning" all convert an unhelpful answer into a disclosure. The correct behaviour when a boundary predicate empties the result is to stop with an empty scope, every time. When you do widen, do it as a small fixed ladder — one or two predefined relaxations, in a deterministic order, each recorded in the trace so an audit can reconstruct which scope actually produced the answer. Unbounded or model-driven widening ("the agent decides what to loosen") is how boundary predicates get dropped by accident, because the model is optimising for producing an answer, not for staying in scope. ## Do not paper over it Several popular reflexes make things worse. Silently falling back to an unfiltered search is the disclosure case above. Falling back to the model's own knowledge without saying so produces an ungrounded answer indistinguishable from a grounded one. Lowering k or the score threshold to "get something back" fills the context with the least relevant material in the corpus, which is worse than nothing because it looks like evidence. Retrying the same query repeatedly costs latency and changes nothing, since the predicate is deterministic. ## Operating it Empty-scope rate is a first-class metric, tracked per predicate field and per tenant. A step change almost always means an ingestion regression — a producer stopped setting a version field, a reindex dropped a payload attribute, a tenant's connector broke — and it is visible in the empty-scope rate long before anyone files a quality complaint. Alert on the derivative, not the absolute level, since a healthy system has a nonzero baseline. Also track the widening rate. If half of all queries are hitting the recency fallback, your default window is wrong and should be changed rather than repeatedly escaped at runtime. And sample empty-scope queries for review: they are the cheapest available list of what your corpus does not cover. What the user is finally told — how the shortfall is phrased and whether an answer is attempted at all — belongs to the generation and attribution step, not to retrieval. Retrieval's job ends at handing that step an unambiguous, labelled statement of what was in scope and what was not.