Table of Contents

If you summarize a long email thread before feeding it to an LLM, the summarizer will quietly drop the one line that says what was not done — the cancellation, the exception, the reversal. This article shows how to summarize threads while forcing those decisions to survive. It is the how-to companion to The Summarize-then-Extract Pitfall, which explains why this loss happens; here we fix it.

The core move is simple to state: don’t run one summary, run two tracks. A gist track for readability, and a decision track whose only job is to preserve confirmations, status changes, exceptions, negations, and reversals — verbatim, never paraphrased away.

Why a plain summary drops the decisive line

A summarizer’s objective function is gist compression: keep what is salient, discard what is not. The problem is that the most operationally important clause in a business thread is often the least salient one to a language model.

“We shipped the samples” is high-salience — it is a concrete action, stated plainly, usually near the top of a message. “We decided not to ship that batch this round” is low-salience — it is a negation, often a single subordinate clause buried mid-thread, and negations carry less surface weight than affirmations. The summarizer is not malfunctioning. It is doing exactly what gist compression asks: it keeps “what happened” and sheds the short qualifier about “what was deliberately not done.”

That qualifier is the decision. Months later, when someone asks “why didn’t that batch ship?”, the answer lived in the clause the summary deleted.

The fix: decision-aware summarization

Decision-aware summarization is a summarization pass that is explicitly instructed to treat decisions, exceptions, and reversals as mandatory-retain content, regardless of their salience to the compression objective. It has three parts.

Part 1 — Instruct the summarizer to preserve decisions explicitly

The default prompt asks for a summary. A decision-aware prompt names the categories that must never be dropped and tells the model to keep them in the actor’s own terms.

Summarize the email thread below for an analyst who must later
reconstruct what was decided and why.

Hard requirements — these MUST appear in the output, verbatim where possible:
- Every decision, including decisions NOT to act, cancellations, and reversals.
- Every exception, exclusion, or carve-out ("all except…", "hold the X batch").
- Every status change (approved, rejected, on hold, postponed).
- Who made each decision and when, if stated.

Do not paraphrase a negation into a neutral statement. If the thread says
"we decided not to ship batch B", keep "not to ship batch B" — never compress
it to "shipping was discussed".

Output two clearly separated sections:
1. GIST — a short readable summary.
2. DECISIONS — a bulleted ledger of the items above, each with its source quote.

The single most important instruction is the negation rule. Models will, unprompted, “smooth” a negation into a neutral mention — turning decided not to ship into shipping was discussed. Naming that failure mode in the prompt is what stops it.

Part 2 — Store two tracks, not one

Keep the gist and the decision ledger as separate fields, not one blended paragraph. The gist serves readability and embedding; the decision ledger is the audit-grade record you query when provenance matters.

from dataclasses import dataclass, field

@dataclass
class ThreadSummary:
    thread_id: str
    gist: str                              # lossy, readable
    decisions: list[dict] = field(default_factory=list)  # audit-grade

# Each decision entry keeps its evidence so it is traceable, not asserted.
# {"statement": "...", "type": "reversal", "actor": "...",
#  "at": "2026-05-12", "source_quote": "..."}

The reason to separate them is that they have different failure tolerances. A slightly lossy gist is fine. A lossy decision ledger is the bug this whole technique exists to prevent — so it gets its own field, its own retention rule, and its own validation.

Part 3 — Add a negation/reversal detector as a safety net

Prompts reduce the failure rate; they do not eliminate it. Add a cheap deterministic pass that flags messages containing negation or reversal language, then assert that anything flagged is represented in the decision track.

import re

REVERSAL_CUES = re.compile(
    r"\b(?:not|won'?t|will not|do not|don'?t|cancel(?:led|ed)?|"
    r"reversed?|on hold|postpone[d]?|except|exclude[d]?|instead|"
    r"no longer|rather than)\b",
    flags=re.IGNORECASE,
)

def messages_needing_review(messages: list[dict], summary: ThreadSummary) -> list[dict]:
    flagged = []
    for m in messages:
        if REVERSAL_CUES.search(m["clean_body"]):
            covered = any(m["id"] == d.get("source_msg_id") for d in summary.decisions)
            if not covered:
                flagged.append(m)          # cue present but not in ledger → review
    return flagged

This detector is intentionally high-recall and low-precision: it over-flags. That is the right trade-off, because the cost of a false flag is a quick human glance, while the cost of a missed reversal is a decision that silently vanishes from the record.

Where this sits in the pipeline

Decision-aware summarization runs after normalization, not instead of it. First clean and reconstruct the thread — strip boilerplate, collapse quoted chains, dedupe fan-out, rebuild the thread in time order, as covered in How to Clean Enterprise Email for LLM and RAG Pipelines. Only then do you compress, and only with the two-track method above. Cleaning is lossless; summarization is the one deliberately lossy step, which is exactly why its losses must be controlled.

Frequently asked questions

How do I summarize an email thread without losing key decisions? Use decision-aware summarization. Explicitly instruct the summarizer to preserve decisions, reversals, state changes, and exceptions verbatim, however brief — a default summarizer drops exactly these because they’re low-frequency against the main narrative. Back it with two-track storage (keep the raw thread, not just the summary) and, optionally, a negation/reversal detector as a safety net.

Why does a normal summary drop the one line that mattered? Because summarizers infer importance from frequency, and a single “we decided not to ship” line loses to a dozen “on schedule” messages. Negations and reversals — the highest-information lines for decision tracing — are dropped fastest of all. A plain summary optimizes for the gist, and the decisive line usually isn’t the gist. This is the summarize-then-extract pitfall applied to threads.

What is decision-aware summarization? It’s summarization with an explicit contract: preserve decisions, confirmations, reversals, cancellations, state changes, and exceptions word-for-word, even when they’re a tiny share of the thread. You’re correcting the summarizer’s default objective (compress the gist) so it stops discarding the low-salience signals that a decision trace depends on.

Should I keep the original email thread if I already have a good summary? Yes — store two tracks. The summary is the skim layer; the raw thread is the trace layer. Even a decision-aware summary misses things depending on the model and the document, so keep the source retrievable. When a tracing question descends past the summary, the answer is still there. Treat the summary as an optimization, never as the single source of truth. See also why you normalize email before the LLM.

Takeaway

A summary keeps what happened and drops what was deliberately not done. Decision-aware summarization fixes that by running two tracks — a lossy gist and an audit-grade decision ledger — and by treating every negation, exception, and reversal as mandatory-retain content.

The shape of the fix generalizes beyond email: any time you compress a record that will later be queried for why a decision was made, separate the readable gist from the decision ledger, and never let a negation be paraphrased into neutrality.