{"course":{"slug":"context-engineering","title":"Context Engineering","url":"https://addaly.com/learn/context-engineering","level":"advanced","track":"build"},"lesson":{"slug":"summarise-or-include","title":"The source or a summary of it","url":"https://addaly.com/learn/context-engineering/summarise-or-include","position":18,"of":87,"minutes":9,"answer":"Summaries preserve coverage and lose precision (especially negations, qualifiers and exact figures) so compress orientation material at ingestion time, keep verbatim the text an answer must be grounded in.","keyIdea":"Summaries preserve coverage and lose precision (especially negations, qualifiers and exact figures) so compress orientation material at ingestion time, keep verbatim the text an answer must be grounded in, and always store a pointer back to the source."},"body":{"format":"markdown","text":"## Compression is a decision, not an optimisation\n\nAt some point every context pipeline meets material that will not fit: a 40-page contract, an hour of transcript, nine months of conversation. The choice is to include part of it verbatim, or to include a summary of all of it. Both are lossy. They lose different things, and knowing which is which decides the call.\n\n**Verbatim excerpt** loses whatever you did not select. What survives is exact: every number, name, qualifier and negation as written. The failure is a missing section.\n\n**Summary** loses precision everywhere and keeps coverage. Summaries systematically drop qualifiers (\"usually\", \"except where\"), collapse specific numbers to approximations, lose the distinction between what a document asserts and what it quotes, and (the one that causes real damage) turn conditional statements into unconditional ones. \"Refunds are available within 30 days for unopened items\" becomes \"refunds are available within 30 days\".\n\nThe summary is also model output, which means it is a guess, and the next stage will treat it as a source.\n\n## The rule that holds up\n\n**Never summarise the text the answer must be grounded in. Summarise the material that provides orientation.**\n\nSo: summarise conversation history, previous tool results, background documents, the earlier part of a long-running task. Do not summarise the contract clause the question is about, the code the model must modify, the medical note, the passage a citation will point to.\n\nA useful test: if a user might reasonably ask \"where exactly does it say that\", the text must be present verbatim. Anything else is fair to compress.\n\n## Two places to spend the compute\n\nSummarising costs a model call, which costs money and time. Where you put that call changes the economics entirely.\n\n**At ingestion.** Summarise each document once, store it, reuse it for every query. Marginal cost at request time is zero. This is where document-level summaries, section abstracts and generated chunk context belong. It is also where you can afford a larger model, since you pay once.\n\n**At request time.** Summarise only what could not have been anticipated: this conversation's history, this tool's oversized result. Adds latency to every call, so use a small fast model and cap the input.\n\nThe most common design mistake is doing at request time what could have been done at ingestion. Summarising the same document on every query is paying for the same work thousands of times, and adding a second or two of latency to each one.\n\n## The pattern that gets most of both\n\nSummary for orientation, source for grounding, with a path between them:\n\n1. Include a short summary of each candidate document: one or two sentences, generated at ingestion.\n2. Include the full text only of the two or three passages the retriever ranked highest.\n3. Give the model a tool to fetch the full text of any document by its handle.\n\nThe model sees the shape of everything available, reads exactly what it needs, and can go and get more. This costs one extra round trip when the model asks for more, and it turns a fixed budget into an adaptive one. It is also the design that scales best when the corpus is far larger than any window.\n\n## Losing the negation\n\nWorth its own warning, because it is the failure that reaches customers.\n\nSummarisers drop negations and exceptions at a measurably higher rate than they drop positive claims. The summary of a page listing four conditions under which something is *not* permitted often reads as a description of the thing being permitted. Every subsequent stage then works from a document that says the opposite of the original.\n\nTwo defences. Where a summary will be used as a source, prompt for the structure rather than for prose (\"list every condition and exception, one per line, using the document's own words for numbers and dates\") which suppresses the fluent-paraphrase behaviour that loses qualifiers. And spot-check summaries against sources on a sample: not a formal evaluation, just twenty documents read side by side. Nearly everyone who does this finds at least one reversal.\n\n## Keep the pointer\n\nWhatever you compress, store the link back:\n\n```json\n{\"summary\": \"...\", \"source_id\": \"doc_8831\", \"span\": [1420, 3980],\n \"summarised_by\": \"haiku-2026-04\", \"at\": \"2026-09-01T10:22Z\"}\n```\n\nThree things become possible: a user can be shown the original, an evaluation can check the summary against it, and when you eventually discover the summariser had a systematic flaw, you can identify and regenerate everything it produced. A summary with no pointer to its source is a claim with no evidence, and six months later that is exactly what it will be treated as."},"check":{"question":"A pipeline summarises each retrieved passage with a fast model before assembly, to fit more documents. Support quality drops on questions about eligibility rules. Why is this the predictable failure?","options":[{"text":"Summarising adds a second model call, so the added latency causes timeouts on complex questions.","correct":false,"tempting":"Identifies a real cost of request-time summarisation but not one that changes the content of an answer."},{"text":"Summaries lose conditions and negations at a higher rate than positive claims, turning \"refundable if unopened\" into \"refundable\".","correct":true},{"text":"Shorter passages score lower against the query, so the ranking degraded after summarisation.","correct":false,"tempting":"Confuses the order of operations: summarisation happens after retrieval here, so ranking is unaffected."},{"text":"The summariser was a smaller model, so the summaries are lower quality across the board.","correct":false,"tempting":"Blames general model capability rather than the specific, systematic loss that explains why eligibility questions in particular broke."}]},"prev":{"slug":"metadata-that-earns-its-tokens","title":"The header on every chunk","url":"https://addaly.com/learn/context-engineering/metadata-that-earns-its-tokens"},"next":{"slug":"packing-to-a-budget","title":"Packing the budget","url":"https://addaly.com/learn/context-engineering/packing-to-a-budget"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'The source or a summary of it', in Context Engineering. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/context-engineering/summarise-or-include (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"The source or a summary of it","courseTitle":"Context Engineering","module":{"index":2,"slug":"what-earns-a-place","title":"Selection: what earns a place"},"answer":null,"keyIdea":"Summaries preserve coverage and lose precision (especially negations, qualifiers and exact figures) so compress orientation material at ingestion time, keep verbatim the text an answer must be grounded in, and always store a pointer back to the source.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"compression-is-a-decision-not-an-optimisation","runs":[{"text":"Compression is a decision, not an optimisation"}]},{"t":"p","runs":[{"text":"At some point every context pipeline meets material that will not fit: a 40-page contract, an hour of transcript, nine months of conversation. The choice is to include part of it verbatim, or to include a summary of all of it. Both are lossy. They lose different things, and knowing which is which decides the call."}]},{"t":"p","runs":[{"text":"Verbatim excerpt","b":true},{"text":" loses whatever you did not select. What survives is exact: every number, name, qualifier and negation as written. The failure is a missing section."}]},{"t":"p","runs":[{"text":"Summary","b":true},{"text":" loses precision everywhere and keeps coverage. Summaries systematically drop qualifiers (“usually”, “except where”), collapse specific numbers to approximations, lose the distinction between what a document asserts and what it quotes, and (the one that causes real damage) turn conditional statements into unconditional ones. “Refunds are available within 30 days for unopened items” becomes “refunds are available within 30 days”."}]},{"t":"p","runs":[{"text":"The summary is also model output, which means it is a guess, and the next stage will treat it as a source."}]},{"t":"h2","id":"the-rule-that-holds-up","runs":[{"text":"The rule that holds up"}]},{"t":"p","runs":[{"text":"Never summarise the text the answer must be grounded in. Summarise the material that provides orientation.","b":true}]},{"t":"p","runs":[{"text":"So: summarise conversation history, previous tool results, background documents, the earlier part of a long-running task. Do not summarise the contract clause the question is about, the code the model must modify, the medical note, the passage a citation will point to."}]},{"t":"p","runs":[{"text":"A useful test: if a user might reasonably ask “where exactly does it say that”, the text must be present verbatim. Anything else is fair to compress."}]},{"t":"h2","id":"two-places-to-spend-the-compute","runs":[{"text":"Two places to spend the compute"}]},{"t":"p","runs":[{"text":"Summarising costs a model call, which costs money and time. Where you put that call changes the economics entirely."}]},{"t":"p","runs":[{"text":"At ingestion.","b":true},{"text":" Summarise each document once, store it, reuse it for every query. Marginal cost at request time is zero. This is where document-level summaries, section abstracts and generated chunk context belong. It is also where you can afford a larger model, since you pay once."}]},{"t":"p","runs":[{"text":"At request time.","b":true},{"text":" Summarise only what could not have been anticipated: this conversation’s history, this tool’s oversized result. Adds latency to every call, so use a small fast model and cap the input."}]},{"t":"p","runs":[{"text":"The most common design mistake is doing at request time what could have been done at ingestion. Summarising the same document on every query is paying for the same work thousands of times, and adding a second or two of latency to each one."}]},{"t":"h2","id":"the-pattern-that-gets-most-of-both","runs":[{"text":"The pattern that gets most of both"}]},{"t":"p","runs":[{"text":"Summary for orientation, source for grounding, with a path between them:"}]},{"t":"ol","start":1,"items":[[{"text":"Include a short summary of each candidate document: one or two sentences, generated at ingestion."}],[{"text":"Include the full text only of the two or three passages the retriever ranked highest."}],[{"text":"Give the model a tool to fetch the full text of any document by its handle."}]]},{"t":"p","runs":[{"text":"The model sees the shape of everything available, reads exactly what it needs, and can go and get more. This costs one extra round trip when the model asks for more, and it turns a fixed budget into an adaptive one. It is also the design that scales best when the corpus is far larger than any window."}]},{"t":"h2","id":"losing-the-negation","runs":[{"text":"Losing the negation"}]},{"t":"p","runs":[{"text":"Worth its own warning, because it is the failure that reaches customers."}]},{"t":"p","runs":[{"text":"Summarisers drop negations and exceptions at a measurably higher rate than they drop positive claims. The summary of a page listing four conditions under which something is "},{"text":"not","i":true},{"text":" permitted often reads as a description of the thing being permitted. Every subsequent stage then works from a document that says the opposite of the original."}]},{"t":"p","runs":[{"text":"Two defences. Where a summary will be used as a source, prompt for the structure rather than for prose (“list every condition and exception, one per line, using the document’s own words for numbers and dates”) which suppresses the fluent-paraphrase behaviour that loses qualifiers. And spot-check summaries against sources on a sample: not a formal evaluation, just twenty documents read side by side. Nearly everyone who does this finds at least one reversal."}]},{"t":"h2","id":"keep-the-pointer","runs":[{"text":"Keep the pointer"}]},{"t":"p","runs":[{"text":"Whatever you compress, store the link back:"}]},{"t":"code","lang":"json","label":"JSON","text":"{\"summary\": \"...\", \"source_id\": \"doc_8831\", \"span\": [1420, 3980],\n \"summarised_by\": \"haiku-2026-04\", \"at\": \"2026-09-01T10:22Z\"}"},{"t":"p","runs":[{"text":"Three things become possible: a user can be shown the original, an evaluation can check the summary against it, and when you eventually discover the summariser had a systematic flaw, you can identify and regenerate everything it produced. A summary with no pointer to its source is a claim with no evidence, and six months later that is exactly what it will be treated as."}]}],"check":{"question":[{"text":"A pipeline summarises each retrieved passage with a fast model before assembly, to fit more documents. Support quality drops on questions about eligibility rules. Why is this the predictable failure?"}],"options":[{"text":[{"text":"Summarising adds a second model call, so the added latency causes timeouts on complex questions."}],"correct":false,"tempting":[{"text":"Identifies a real cost of request-time summarisation but not one that changes the content of an answer."}]},{"text":[{"text":"Summaries lose conditions and negations at a higher rate than positive claims, turning “refundable if unopened” into “refundable”."}],"correct":true,"tempting":null},{"text":[{"text":"Shorter passages score lower against the query, so the ranking degraded after summarisation."}],"correct":false,"tempting":[{"text":"Confuses the order of operations: summarisation happens after retrieval here, so ranking is unaffected."}]},{"text":[{"text":"The summariser was a smaller model, so the summaries are lower quality across the board."}],"correct":false,"tempting":[{"text":"Blames general model capability rather than the specific, systematic loss that explains why eligibility questions in particular broke."}]}],"order":[0,3,2,1],"why":null},"prev":{"slug":"metadata-that-earns-its-tokens","title":"The header on every chunk","minutes":8},"next":{"slug":"packing-to-a-budget","title":"Packing the budget","minutes":9}}}