Where it genuinely helps
- Long email threads, for someone joining them
- Call transcripts into a CRM note
- Case or matter files when work changes hands
- Meeting recordings into decisions and actions
- Long documents where the reader needs the gist first
In each case the reader can reach the source if they need detail, which is what makes summarisation safe.
What summaries must keep verbatim
- Numbers — amounts, quantities, dates
- Names of people and organisations
- Commitments — who agreed to do what by when
- Conditions — anything with an if attached
- Anything requiring action
The characteristic summarisation failure is dropping the one specific detail that mattered. Instruct explicitly that numbers, names and commitments are preserved exactly.
Link to the source, always
A summary without a route to the original is something the reader must trust. With a link, it becomes something they can verify in seconds, which changes how they use it.
Where possible, link each point in the summary to its position in the source.
Structure beats prose
| Instead of | Produce |
|---|---|
| A narrative paragraph | What happened, decisions, actions, open questions |
| A general overview | Specific points with attribution |
| An assessment | What was said, not what it means |
| Everything condensed equally | Detail on what requires action |
Structured summaries are scanned; narrative summaries are skimmed and misremembered.
Do not summarise what should be read
Contracts, safety information, regulatory correspondence and anything where the precise wording matters should not be replaced by a summary.
Summarising them to decide whether to read properly is fine. Summarising them instead of reading is not, and the interface should make that distinction clear.