## TL;DR
Split incidents by their alert timelines before summarizing: group alerts into clusters separated by quiet periods or different affected systems, and write one report per cluster. Never summarize across a boundary the timeline does not support.

## Steps
1. Collect the alert timeline for the reporting window with affected systems.
   Expected: The agent sees when each alert fired.
2. Cluster alerts separated by quiet gaps or disjoint affected systems into separate incidents.
   Expected: Two outages become two clusters.
3. Write one report per cluster, each with its own timeline and impact.
   Expected: Each report tells one coherent story.
4. Have a human confirm the split before publishing.
   Expected: A bad automatic split is caught.

## When to use
- The agent drafts post-incident reports from alerts
- A report once blended two unrelated outages
- Alert volume is high enough that overlaps happen

## When not to use
- Incidents are declared and scoped by humans first
- Only one system is ever involved
- The agent only formats a human-written narrative

## Why this happens
Summarizers see a bag of alerts and write one story, but real operations have overlapping incidents: the network flap at 2am and the database failover at 4am are not the same outage. Merging them produces a root cause that explains neither.

## Edge cases
- Cascading failures are genuinely one incident; the boundary test is whether the alerts share a causal chain.
- Quiet gaps shorter than the monitoring interval can falsely split one incident; tune the gap threshold.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fiFwy2BCRBlYrVUwHUhFgg