The hardest check: what was left out

An absence has no signature

Every other failure in this module leaves a mark. A fabricated citation can be searched for. A wrong number is out of proportion. A misread clause has a real sentence you can go and read.

An omission leaves nothing. A summary of four payment terms that covers three reads exactly like a summary that covers four. You cannot see it by looking at the answer, because looking at the answer is not where it is.

This is the failure most likely to reach a decision, and it gets the least attention.

Where omissions come from

Compression. Summarising is selection, and the model’s sense of what matters is not yours. The clause that matters to you may be unremarkable in general.

Position. Material in the middle of a long context is used less reliably. A document’s middle section is where things quietly go missing.

A stopping habit. Asked to list items, models tend to produce a comfortable number (five, seven, ten) and stop. If there are fourteen, you often get ten and a fluent closing sentence.

Retrieval. With a long attached file, only some passages may have reached the model at all.

Your own framing. Ask “what are the risks?” and you get risks. A cost that is not a risk, a dependency, an opportunity: none of them were asked for and none will appear.

Count before you analyse

The single most effective technique, and it takes one extra step.

First: list every clause that mentions payment, by clause number and first five words. Do not summarise or analyse. Count them and give me the total.

Now you have a number. If it says four and you expected more, you have caught the omission before any analysis was built on it. Then run the analysis over the enumerated list.

Locating and reasoning are different jobs. Doing them separately is the theme of half this course, and this is the sharpest instance.

Ask for the boundary of the answer

Three lines that turn silence into information:

After the answer, list: anything relevant you found but did not include, and why. Anything I asked about that the document does not address. Anything you were unsure whether to include.

The third one is the surprising one. It regularly surfaces the item that was on the edge of the selection, which, being an edge case, is disproportionately likely to be the thing you cared about.

Adversarial checks

Ask a question whose answer you know, or can quickly establish, and see whether the answer holds up:

• “Does this document say anything about X?” where you know it does. A false negative tells you retrieval or attention is failing.
• “How many sections does this document have?” against the actual count.
• “Quote the last sentence of the document.” Catches truncation instantly.

For anything long and important, the last of these takes five seconds and is worth doing every time.

The structural fix

For recurring work, a checklist beats vigilance.

If you review contracts, you have a list of the twelve things you always check. Put the list in the prompt and require a line for each, including “not present”. Now an omission is a visible row rather than a silence.

That is the same move as the fail-visibly lesson, applied to coverage instead of values: make absence occupy space. An empty row is something you can see. Nothing is not.

The limit worth stating

None of this catches an omission of something you did not know to ask about, and no method can. A checklist covers what is on the checklist. Enumeration covers what you thought to enumerate.

Which is the honest reason that, for anything consequential, somebody who knows the domain reads the document. The tools make that person faster. They do not replace the fact that only a person who knows what should be there can notice that it is not.

Why this failure is under-reported

Nobody writes a complaint about an omission, because nobody knows it happened. The wrong figure gets corrected loudly; the missing clause is discovered eighteen months later, by a lawyer, in a dispute.

So the anecdotes people share are all about the visible failures, and the impression forms that models mostly invent things. Invention is the noisy failure. Omission is the common one, and if you adopt one habit from this module it should be enumerate-then-analyse, because it is the only one that addresses the failure you will never otherwise hear about.