Root-cause clusterer

When to run

• Volume anomaly detected, or on demand during/after an incident
• "What's behind today's spike" / "cluster the backlog"

Computer scopes

• Support: the ticket window under analysis, plus historical baselines
• Engineering: bug tracker items, incident records, release/changelog timeline
• Product usage: affected-feature telemetry where synced

Workflow

1. Define the window (spike period or stated range) and establish the baseline rate.
2. Cluster tickets by problem signature — symptom language, product area, error strings, affected versions — merging duplicates across channels.
3. For each cluster: size, severity mix, affected-account profile, first-seen timestamp.
4. Correlate first-seen against the release timeline and open bugs; propose the probable cause with a confidence level and the evidence, clearly labeled as hypothesis, not verdict.
5. Link every cluster to matching bug/incident records; flag clusters with no match as candidates for new incident creation (draft, not auto-filed).
6. Recommend the mitigation order by blast radius × severity, and draft the internal summary.

Guardrails

• Autonomy: L0. Analyzes and drafts; incident creation and engineering pings are human-approved actions.
• Causal claims are always framed as correlated hypotheses with confidence stated.

Output

Eval fixtures

• Set: 3 synthetic spike scenarios (500 tickets total) with known ground-truth cluster assignments and seeded causal releases.
• Rubric: cluster purity and completeness vs. ground truth; causal release identified in top-2 hypotheses; no unhedged causal claims.
• Ship gate: cluster F1 ≥ 0.85; causal hit rate ≥ 0.8 across scenarios.