AI Summaries Keep Dropping Key Points? Use This Two-Pass Prompt to Make Omissions Impossible to Hide

You ask an AI to summarize a long document, and it returns eight clear, accurate bullet points that read flawlessly. But what you don't know is that the single most important sentence in that document — some exception clause, some deadline, some "never" rule — has been quietly deleted.

This is a different class of problem from AI hallucination. A hallucination fabricates content that doesn't exist, and you can verify it point by point. An omission, by contrast, is a silent absence — there's nothing on the page for you to check against. You walk away confident that you "understand this document," when in fact you've only read half of it.

Solving omissions requires a different approach: you can't verify after the fact. Instead, you need to make the model show what it read and what it dropped before it compresses.

Why Do AI Summaries Lose Important Content?

The instruction "summarize" inherently demands compression, and the logic of compression is to preserve the typical, common content of a document rather than the critical, load-bearing content.

Main rules usually survive. But exceptions to those rules — often just a sentence or two, tucked under a heading that sounds unimportant — are exactly what the compression algorithm sees as "details."

Three categories of content get sacrificed first, and they happen to be the most consequential:

• Exception clauses: "Do X, unless Y." The summary only keeps "Do X."
• Hard constraints: numbers, limits, deadlines, "must" and "must not."
• Small sections: a three-line subsection, no matter how important, can't compete with a thirty-line one.

This isn't a flaw in the model — it's a blind spot inherent to the "summarize" instruction itself. When you ask for compression, the model will use "typicality" as its selection criterion.

What is AI hallucination? AI hallucination refers to a model generating content that seems plausible but doesn't actually exist in the source text — or even contradicts the facts. Along with the "omission" discussed in this article, it forms a mirrored pair of problems: hallucination adds things that aren't there, while omission removes things that are. The two are dangerous in entirely different ways — a hallucination leaves traces, so you can verify each item against the source and cross it out; an omission leaves no trace at all, just blank space on the page, and you have no way to check whether "something should have been there." So the remedy for hallucination is post-hoc verification and fact-checking, while the remedy for omission requires a different approach entirely: intervene before compression happens, and force the model to first expose which content it read, thereby making "what wasn't written" visible.

The Two-Pass Summary Prompt: Map First, Then Summarize

The core idea is to have the model work in two steps: the first pass lists every section of the document (mapping), and only the second pass writes the summary — then for each item that didn't make it into the summary, it provides a risk assessment.

Here's a prompt template you can copy directly:

Summarize the document below in two passes.
Pass 1 — Map: list every section or distinct topic, in order, one line each.
Pass 2 — Summary: write the summary (max [N] bullets). Every bullet must name
 the section it comes from.
Then, Coverage check: list each Pass-1 item that is NOT in the summary, and
for each say in one line whether a reader could get hurt by not knowing it
(yes/no + why).
Numbers, deadlines, exceptions and "must/must not" rules are never dropped
silently: include them or list them under Coverage check.
Document: [PASTE]

Putting the mapping step first is intentional. Once the model has written down every section name, it becomes much harder for it to pretend a small section doesn't exist. And the coverage check forces it to make an explicit judgment about every item it skipped — which is exactly what makes omissions visible. That's the crux of the whole method.

The final rule is especially important: numbers, deadlines, exception clauses, and "must/must not" rules must never be silently dropped. They either go into the summary or appear in the coverage check.

Tested Comparison: Same Document, Same Model

The original author ran a controlled test using PEP 8 (Python's official code style guide). The document is long enough, publicly available, and packed with rules and exceptions — ideal for verification.

Both runs used Claude Sonnet, both with a summary cap of 8 bullets:

• Run A: just the simple instruction "Summarize this document in at most 8 bullet points."
• Run B: the two-pass prompt above, with N=8.

Run A's output looks great. Indentation, line length, blank lines, import order, naming conventions, docstrings, None comparisons, type annotations — all correct, all useful. If you'd never read PEP 8, you'd think you had it covered.

But checking against the original, here's what it missed:

• The "When to Ignore This Guide" section. PEP 8 states right up front that consistency within a project matters more than following PEP 8, lists all the scenarios where you can break the rules, and specifically emphasizes not breaking backward compatibility just to conform to the PEP. Run A preserved every rule but dropped the permission to deviate, making the document read as stricter than it actually is.
• The team exception for line length. Run A gave the 79-character limit, but the original adds that teams can agree to relax it to 99 characters — provided comments and docstrings still wrap at 72.
• The only mandatory trailing comma. Trailing commas are optional in most cases, but single-element tuples are the exception — without the comma, it's not a tuple, and this is a real bug just waiting to trigger.
• Positioning rules for module-level dunder names, including the requirement that from __future__ imports must come before them.

Run B captured all of it. The "permission to deviate" section became the first bullet, with the backward-compatibility warning attached. The 99-character team limit made it into the line-length bullet. The coverage check listed the sections still not in the summary, with a judgment on each:

• When to use trailing commas — Risky: the single-element tuple case "will silently produce a plain string instead of a tuple — a classic hidden bug."
• Module-level dunder names — Risky: the from __future__ ordering rule causes real errors, not just style issues.
• Source file encoding, ASCII compatibility — Low risk: these mainly constrain standard library contributors.
• References, copyright notice — Low risk.

Run B also listed the tails of exceptions that got compressed away: the two narrow scenarios where a bare except: is acceptable, the warning about using return inside finally, and the note that name-mangled attributes are still accessible. These don't all need to go into the summary, but being listed is far better than being silently deleted.

Same model, same document, same bullet budget. The difference is that Run B had to account for what it cut.

What is PEP 8? PEP stands for Python Enhancement Proposal — the official document series the Python community uses to propose, discuss, and record language features, standards, and processes. PEP 8 is the one specifically devoted to the code style guide, covering indentation, line length, blank lines, import order, naming conventions, comments, and docstrings. It's widely regarded as the universal style standard for Python code, and virtually every Python developer encounters it. It makes a good test case because it's long enough, publicly available, and full of "rule plus exception" structures — line length limits, trailing comma usage, module-level naming rules — which are exactly the parts summaries are most prone to silently dropping. That makes it an effective way to amplify the difference between a simple instruction and the two-pass prompt.

Trailing commas and single-element tuples: In Python, a tuple is defined by the comma, not the parentheses. (1) is just a number in parentheses, while (1,) is a tuple containing the single element 1. This means that in the special case of a single-element tuple, the trailing comma is not an optional style preference — it's a syntactic requirement. Omit it, and the code quietly turns from a tuple into a plain value (like a string or a number), often without an immediate error, leading to hard-to-locate bugs later on. That's precisely why it's so dangerous when Run A drops it: trailing commas are indeed optional in most contexts, but once the single-element tuple exception gets compressed away, readers will write incorrect code without realizing it.

Three Limitations of This Prompt

The test exposed three boundaries:

The output is longer. Run B's result was several times the length of Run A's. For documents you'll only skim once, that's extra overhead. It's only worth using when misunderstanding the document carries a real cost.

Risk judgments are subjective. "Would a reader get hurt by this" depends on who the reader is. The model marked "source file encoding" as low risk because it mainly constrains standard library contributors — correct for most readers, but wrong if you happen to be a standard library contributor.

It only covers what the model actually read. Both runs read PEP 8 through a web scraping tool, and Run B's agent reported that some pages returned paraphrased versions rather than verbatim originals. It also reported the mapping as complete — all 42 section headings present — but a mapping built on paraphrased versions could still miss lines. For any important document, paste the source text in yourself.

Four Steps for Practical Use

Once you have the coverage check results, handle them in this order:

1. Read the items marked "risky" first. They're the content the summary would otherwise have hidden from you. On PEP 8 that's two lines; in a contract or policy document, it's usually the reason you're reading it in the first place.
2. Spot-check one "low risk" judgment. Open the corresponding section in the original to confirm the judgment is reasonable. If it's wrong even once, read the rest yourself.
3. Search the source document for "except," "must," "never," "unless," and any numbers. It takes ten seconds and is the fastest independent check for missed constraints.
4. Keep the mapping output. The first pass is essentially a table of contents you can refer back to later — much faster than re-reading.

The essence of this method isn't making AI smarter — it's making its trade-offs transparent. You still need to judge which "low risk" labels are wrong, and you still need to paste the source text yourself. But at least now you can see where the AI made its choices, instead of being kept in the dark by a summary that reads perfectly.