Ask an AI to summarise a 60-page report and you will get something fluent, well organised and plausible. The problem is the part you cannot see: what it left out. A summary that skips the exception on page 38 reads exactly as confidently as one that doesn’t.
That is not bad luck. It is where long-context models are known to be weakest, and it is predictable enough to work around. The routine below is five prompts. Each one produces something you can check in about a minute, so you find the gaps without re-reading the document yourself.
This routine is assembled from the long-document guidance Anthropic, Google and OpenAI publish for their own models, and from two peer-reviewed studies. It was not benchmarked. Where a vendor makes a performance claim, it is attributed to them.
Why the middle goes missing
In 2023, researchers tested how language models use long inputs by moving the relevant information to different positions in the prompt. Performance was often highest when it sat at the beginning or the end, and degraded significantly when the model had to use something from the middle, even in models built for long contexts. The paper, Lost in the Middle, was published in Transactions of the Association for Computational Linguistics in 2024.
Those were 2023 models, and finding one fact has since become a strength: Google’s current Gemini documentation (updated October 2026) puts a single query at around 99%. But a summary is not one fact. It is dozens of them, and the same page says that with several pieces of information to find, “the model does not perform with the same accuracy”. Its own example is blunt: to retrieve 100 pieces of information at that standard, “you would likely need to send 100 requests” (Google).
A 2024 study of book-length summaries, FABLES, found the same shape from the reader’s side. People who had read each book checked the models’ summaries claim by claim, and found omissions of crucial elements alongside a systematic over-emphasis on events near the end. The same team tried using AI models to grade the summaries, and none agreed strongly with the human readers, especially on spotting unfaithful claims.
So the start and the end get attention, the middle gets squeezed, none of it shows in the output, and asking another model to check is not a reliable fix. Every step below gives you something to check yourself, quickly.
Before you start: make sure it can see the whole thing
Uploading a file is not the same as the model reading it. Depending on the app and the length of the file, a long upload may be searched in pieces rather than read end to end, so the “summary” is built from whichever chunks matched. A document longer than the model’s context window cannot be held all at once in any case.
You will not usually be told which of these happened. Step 2 is how you find out.
One thing to check first: if you cannot select the text in your PDF viewer, the file is a scan, and the words have to be recovered from pictures of pages before anything can use them. That can still work, but it adds a layer of error. Where you have a choice, give the model real text.
Step 1: say what the summary is for
“Summarise this” asks the model to guess what matters. With nothing else to go on, the safe guesses are the generic ones: the introduction, the headline findings, the conclusion. Those are also the parts at the start and the end, which is where the research says attention already goes.
Tell it the decision the summary serves instead. OpenAI’s prompting guide for GPT-5.2 recommends that, on long inputs, the model “re-state the user’s constraints explicitly” before answering (OpenAI). Make that its first job.
I'm going to give you a long document. Before doing anything else, restate in two lines
what I need from it and the constraints that apply.
What I need: [the decision this serves, e.g. "whether we can renew this contract without
renegotiating" or "what changed for our team in this policy"]
Who it's for: [me / my manager / a client]
Constraints: [date ranges, regions, products, anything that narrows what matters]How you know it failed: the restatement is wrong or vague. Correct it now, because everything after this inherits it.
Step 2: ask for the map first
Before any summary, ask for the document’s structure. The same OpenAI guide tells its model to “produce a short internal outline of the key sections” first when the input is long. We suggest making that outline visible, because it is the cheapest check in the whole routine.
Here is the document: [paste the text or attach the file]
List every section and subsection in order, with its page number or position.
Don't summarise anything yet. If any part is unreadable or seems to be missing, say so.How you know it failed: put the outline next to the document’s own contents page, or scroll through and compare. Missing sections mean the model did not see them, either because the upload was searched rather than read or because the document did not fit. Garbled headings usually mean the text came out of a scan badly.
Either way, fix the input now. Split the document into parts, or paste the missing sections in directly. A summary built on half a map is a summary of half a document, and nothing in its wording will tell you so.
Step 3: pull quotes, section by section
Now ask for evidence before conclusions. Anthropic’s guidance for long-document tasks is to ask the model to quote the relevant parts first, before carrying out the task (Anthropic). OpenAI’s GPT-5.2 guide makes the same move from the other direction: anchor claims to named sections, and quote the details that matter.
Both do one useful thing. They force the model to go and fetch material from every part of the map, instead of paraphrasing a general impression formed from the parts it attended to most. It is a small-scale version of Google’s 100-requests point: many narrow questions, not one broad one.
Go through the sections in your outline one at a time. For each section, give me up to
three verbatim quotes that matter for what I need, each with its page or section
reference. If a section has nothing relevant, write "nothing relevant". Don't skip any.How you know it failed: pick three quotes, ideally from the middle sections, and search for them in the original with Ctrl+F (Cmd+F on a Mac). A quote that does not exist is the clearest warning you will get. Models produce convincing text that isn’t there, and an invented quote means the rest of the extract is unverified too.
Also look at what was marked “nothing relevant”. A section you would expect to matter, waved through as irrelevant, is the place to push back.
Step 4: write the summary from the quotes
Only now ask for the summary, and ask for it to be built from the extracts. Two details matter.
Where the instruction goes. The vendors do not agree. Anthropic and Google both say to put your question at the end, after the long material, and Anthropic says that in its tests, queries at the end can improve response quality by up to 30 percent. OpenAI’s GPT-4.1 guide says to put instructions at both the beginning and the end of long context, and if only once, above it.
When you run this routine as a conversation, your newest message is already at the end, so this takes care of itself. If you ever paste a document and a request in a single message, put the request above the document and repeat it below. One extra line satisfies all three vendors.
Where each point came from. Ask for a reference after every point, so anything that surprises you can be traced in seconds.
Using only the quotes above, write a summary for [who it's for] that answers
[what I need]. Lead with the answer. After each point, put the section it came from in
brackets. Flag anything the document leaves uncertain or contradicts itself on.Step 5: ask what it left out
The last step goes straight at the failure the research describes, which is omission. Ask directly.
Compare your summary with your outline. Which sections did the summary not use?
Is there anything in the document that qualifies, contradicts or adds an exception to
what the summary says? Quote it, with its section reference.How you know it failed: check the list of unused sections against the map from step 2. If a section you care about is on it, read that section yourself; one section is a lot quicker than the whole document. And if the model reports no exceptions at all in a contract, a policy or a set of terms, be suspicious. Those documents are mostly exceptions.
If you only have two minutes, do steps 2 and 5. The map tells you whether the model saw the whole document, and the omission check tells you where its summary is thinnest. Together they cover the two failures you cannot see in a fluent paragraph.
Where this still fails
- Numbers and tables. A quote can be accurate while the arithmetic built on it is wrong. Check any figure you will repeat against the source, the same way you would check any other AI claim.
- The one clause that changes everything. In contracts, policies and terms, the routine tells you where the important sections are. It does not replace reading them.
- Documents that do not fit. For anything very long, run steps 2 and 3 on each part separately, then write the summary from all the extracts together.
- Scans and images. If the text could not be selected, treat every quote as a reading of a picture and check the ones that matter against the page.
Summarising is one of the jobs that passes the three questions that decide what AI should touch first: the work is language-shaped, you see the result before it matters, and a routine like this one keeps a plausible-but-wrong answer cheap to catch. If this way of working suits you, the same idea runs through our prompts for work that check their own answers: ask for the evidence in a form you can verify, then verify a little of it.
The thing worth remembering
A summary is a claim about what a document says, and like any claim from a model it is only as good as the evidence attached. This routine works because it makes the model show its working at every stage, in a form you can check faster than you could read: the map, the quotes, the gaps.
If a summary arrives with no way to check it, treat it as a first impression of the document, not a reading of it.