Why can narrowing a retrieval query on document-supplied metadata raise a planted chunk's odds of being returned?

## What narrowing actually does to a candidate set A retrieval query with a metadata predicate has two stages a candidate must survive: eligibility, decided by the predicate over structured fields, and ordering, decided by vector similarity against the query. The predicate is a set operation. It does not re-score anything; it deletes rows from the pool that the scoring then runs over. So the interesting question is not what the filter does to the plant - the plant was built to pass it - but what the filter does to everything else. ## Honest corpora are untidy; a plant never is Take the field-service case: an assistant answering technicians from equipment service bulletins, where suppliers submit through a portal and the ingest stage copies each bulletin's front matter into the index payload. The application narrows to a current status, an effective date inside a window, and an equipment model matching the unit named in the question. Now look at the real corpus that predicate runs over. Bulletins migrated from an older system have no status field at all. Some carry dates in a local format the parser stored as a string. Model designations are written with and without a dash, with a revision suffix, in lower case. None of that is malice; it is what a decade of documents from a dozen suppliers looks like. Every one of those rows fails the predicate. A planted bulletin has none of those problems. Its front matter is complete, its status token is the exact one the predicate compares against, its date is comfortably inside the window, its model string is written the way the query writes it. It was authored against a predicate rather than against a reader, so conformance is the one property it is guaranteed to have. The result is a candidate pool that has been filtered *toward* the plant. Narrowing removed competitors and left the entry that was designed to be immune to removal. ## Two things the attacker gains, and they are different The first gain is ranking headroom. A passage that would have placed eleventh among fifty candidates can place third among six, without its similarity score changing at all. The plant no longer has to beat the whole corpus, only the fraction of it that is well formed. The second gain is interpretive, and it is the one that pays. A small result set reads as a curated one. When an assistant answers a technician with three bulletins and a narrow filter behind them, the shortness of the list is taken as evidence of selection - somebody must have decided these three were the applicable ones. Nobody decided anything. Presence in that set means only that a row carried conformant values in fields the row's own author wrote. The trust the interface radiates is a property of set size, not of provenance. ## What it costs the person building it This is not free, and an interviewer will want the cost named. The construction requires knowing which fields the predicate reads and the exact value vocabulary it compares against; a token that is close but wrong fails the filter completely, which is a harsher failure mode than merely ranking low. Date-window predicates expire, so a plant that must stay eligible has to be resubmitted or re-dated over time. A change to the query - a different field, an added source predicate, a normalisation step at ingest that rewrites what the file declared - can eject it silently. And every bit of that effort is wasted where the predicate reads a value the submitter never touched. ## Where it stops working The whole construction rests on the predicate reading document-authored fields. A predicate over a value stamped by the ingest stage at receipt is far harder to aim at, because the submitter controls timing rather than content. A scope computed from the caller's session at query time is not addressable at all from inside a document - a person writing a file cannot write a value that is derived from whoever will ask the question later. ## The claim to keep straight A narrowed result set proves that each surviving row carried values matching the predicate. It does not prove the rows were selected, reviewed, or that they are the applicable ones. Reading a short list as a vetted list is precisely the inference the construction is built to earn.