Silent omission

Silent omission is what happens when a retrieval system leaves something out and the answer gives no sign of it. The output looks the same whether a passage was read and judged irrelevant or never opened at all. Nothing in the response distinguishes the two, so nothing prompts the person reading it to check.

It is the failure mode that matters most in high-stakes work, and it is the one least often designed for.

Why is omission worse than a wrong answer?

A wrong answer can be caught. Someone reads it, recognizes it as wrong, and the system loses a little credibility in a way that is ultimately healthy. An omission cannot be caught by reading, because the missing thing is not on the page. There is nothing to notice.

This inverts the usual intuition about AI risk. Teams protect themselves against fabrication, which is visible and embarrassing, and remain fully exposed to omission, which is invisible and consequential. A fabricated citation gets found in review. A governing exception that was never retrieved gets found when the thing it governed fails.

Why do ordinary retrieval systems omit silently?

Because they are built to return the best matches, not to account for the whole corpus.

A retrieval system takes a question, scores passages by similarity, and returns the top handful. That is the entire contract. It has no obligation to report how much of the corpus it considered, whether the top matches were good matches or merely the least bad ones, or whether the passage that actually governed the answer sat just below the cutoff. The scores are internal. What reaches the model, and then the person, is a set of passages stripped of any indication of what surrounds them.

Scale makes it worse rather than better. On a corpus of roughly 8,200 documents, about 120 million tokens, the fraction a frontier model can hold at once is a rounding error. The system is not occasionally missing an edge case. It is working from a sliver and reporting with the same confidence it would show if it had read everything.

What is a coverage report?

A coverage report is the answer to silent omission. It ships alongside a response and states what was drawn on, what was not, and why.

That turns an invisible property into a visible one. An incomplete answer still happens, because some questions cannot be answered from a given corpus, but it arrives labeled as incomplete instead of arriving dressed as a complete one. The reader can see whether the answer rests on enough of the document set to be worth acting on, which is a judgment ordinary retrieval does not give them the information to make.

This is the difference between a system that is usually right and a system you can rely on. Being right most of the time is not the same as knowing when you are not.

What does this look like in practice?

An engineer asks whether a component is rated for a load. The specification says it is. Two pages later, an exception applies under a particular condition. A chunked retrieval system returns the first statement, and the answer is grounded in a real sentence from a real document, correctly cited, and wrong.

Nothing in that answer indicates a second passage exists. The citation is valid. The source is real. The engineer has every reason to trust it, and the only thing that would have prevented the mistake is a system that said: here is what I used, and here is what I could not reach.

Related terms

• Hallucination: the visible failure, where a system states something no source supports.
• Grounding: answering only from a verified body of knowledge, and saying what cannot be found.
• Traceability: following an answer back to its source, which handles what was included but not what was left out.