Summarize without losing meaning

Beginner · 6 min · Compress text while preserving decisions, numbers, conditions and open questions.

  • summarizing
  • verification

A summary is compressed text that keeps everything a decision depends on: the decisions themselves, numbers, owners, dates, conditions and open questions. Drop an anecdote and nobody notices; drop a condition and people act on a plan that never existed. The failure mode of a summary is silent — it is omission, not error.

The keep-list and the drop-list

Keep: decisions (what was actually settled), numbers and dates, action items (owner plus date), conditions and caveats (“conditional on”, “unless”, “to be confirmed”), disagreements and open questions. Drop: repetition, filler, tangents, meeting pleasantries. When in doubt, keep it — compress the language, not the facts.

How compression goes wrong

The instinct is to keep the shortest text that still sounds true. That instinct quietly deletes load-bearing words: “the beta continues, restricted to existing testers” becomes “the beta continues”; “April, if the security review passes” becomes “in April”. The result reads perfectly and is wrong in the two places that matter. This is the same distortion you catch when tracing claims — each retelling trims a caveat.

The recipe

  1. Name the elements to keep — “keep every decision, number, owner, date and any condition attached to them”.
  2. Name the reader’s job — “for a colleague who will act on this tomorrow” sharpens what is essential.
  3. Preserve ambiguity as ambiguity — “if something is unresolved, keep it unresolved”. Summaries that resolve open questions are editing, not reporting.
  4. Set the length last — “in three sentences” after the content rules, not before.

A bad example

Summary: “The group agreed to move forward in Q2.”

Shorter, cleaner, and it deleted the condition the whole plan hangs on. Everyone acts; nobody re-checks.

A better example

Summary: “Launch moves to Q2, with the March beta staying limited to existing testers. Budget review in April — both depend on the security review passing first.”

One sentence longer, and it carries the restriction, the date and the condition. This is what “summarize” should mean.

One closing habit: summarize for a named reader. “For the person who signs the budget” and “for the engineer who will implement this” produce genuinely different compression — what is load-bearing changes with the job. Name the reader in the request; when the reader changes, one re-run adapts the text and the source never moves. That single move prevents the strangest summary failure there is: technically faithful, and useless to whoever receives it.

Practice

Compare two meeting summaries

A steering group decided: launch postponed to Q2, the March beta stays limited to existing testers, and the budget gets reviewed in April — with everything conditional on the security review passing first. You asked for a short summary for a colleague who missed the meeting.

Work through the rubric for both summaries, then pick the one you would send.

Output A

The steering group postponed the launch to Q2. The March beta continues as planned. The budget will be reviewed in April.

Output B

Launch moves to Q2. The March beta stays limited to existing testers. April brings the budget review — and all of it depends on the security review passing first.

Rubric — answer each question for both outputs before deciding

  • Does it carry the decisions that were actually made?
  • Are the restriction and the condition preserved — the tester limit and the security review?
  • Does it avoid turning conditional items into settled facts?
Which output would you ship?
Hint

What would the colleague do differently after reading each version?

Which version mentions the security review — and who needs to know about it?

Transfer

Next

Next: Meeting notes to action items — from summary to the table people actually work from.