In this analysis
A summary's acceptable omissions depend on the downstream decision, especially when exceptions or identifiers change the next action.
Summarization became a scale question
Opus 5.5 arrived on September 22, 2026, before Sonnet 5.5 on September 28. The October 7 Haiku 5.5 release highlighted repetitive workloads including summaries. Scaling that operation makes omissions more important, not less. A summary is useful precisely because it discards material, but the discarded material may include an exception that changes the downstream decision. The central acceptance problem is therefore which information may be compressed away for the intended task.
Relevance depends on the next use
An illustrative support summary contains the reported problem, attempted remedy and an exception preventing the usual resolution. A generic shorter version might preserve the first items and omit the exception as detail. That omission can make the next agent repeat an unsuitable action. For a different use, such as counting broad issue categories, the same exception may be unnecessary. There is no context-free ideal summary. Its contract must describe the decision it supports, so that compression can be judged against that purpose rather than against brevity alone.
Identifiers are small but decisive
A case reference, product variant or quoted error token can occupy little space while carrying substantial operational meaning. Replacing a precise identifier with a fluent paraphrase may make the summary easier to read and harder to use correctly. Conversely, preserving every identifier can overwhelm a reader with irrelevant detail. The evaluator needs to identify which references must remain exact for the downstream operation. This is a workflow requirement, not a claim that Haiku always preserves or loses such details under every prompt.
A counterexample-driven fixture
A practical illustrative dataset can pair ordinary cases with nearly identical cases containing a consequential exception. The summary is checked for the facts needed to select the correct next action. A separate check confirms that required identifiers remain associated with the right case rather than merely appearing somewhere in the output. No omission rate is invented here. The fixture explains why aggregate similarity to a reference summary may miss a rare but decision-changing deletion, even when the generated text is fluent and generally accurate.
An omission budget is a design boundary
The release makes cheap repeated summarization a plausible building block, but a low unit cost cannot define acceptable information loss. A task-specific omission budget describes what may disappear and what must survive. It can differ between navigation, categorization and action support. The retrospective lesson is to evaluate summaries through their downstream consequences while retaining enough source connection for review. A shorter output is valuable when it removes irrelevant material, not when it silently removes the fact that would have changed the decision.