Ranked hypotheses beat prompt-and-pray for incident response

When a page fires at 2 a.m., the last thing you need is a blank chat box and a vague prompt like “what’s wrong with checkout?”

Generic LLM interfaces are good at sounding confident. They are much worse at showing their work across the six tabs you already have open: PagerDuty, Grafana, deploy history, ticket notes, runbooks, and Slack.

The problem with unstructured AI triage

Most “AI for ops” products today look like this:

1. Paste an alert or error string.
2. Wait for a paragraph of possibilities.
3. Manually verify each guess in your real tools.

That workflow treats investigation as a writing exercise. Production incidents are graph problems: signals arrive from different systems, time order matters, and some explanations are mutually exclusive.

Without structure, you get:

• Hypothesis sprawl: five plausible stories, no ranking.
• Missing provenance: no link back to the metric, log line, or deploy that supported a claim.
• Replay risk: the next engineer cannot see why you believed story #3.

What ranked hypotheses actually mean

A ranked hypothesis is not a hotter take. It is a theory plus evidence plus confidence, updated as new signals arrive.

Element	What it answers
Hypothesis	“Replica pool saturated after auth deploy.”
Evidence	DB pool at 98%, deploy 11 minutes prior.
Confidence	78%: strong, but not closed.
Next step	Draft remediation; human reviews before execution.

The ranking forces the system (and the human) to commit to an ordering. That is how experienced engineers already think, they just rarely document it under pressure.

ML without the black box

Machine learning in triage does not have to mean “the model said so.” Useful patterns include:

• Similarity to past incidents: same service, same symptom, same fix.
• Temporal correlation: deploys, config pushes, certificate renewals near the failure window.
• Dependency traversal: blast radius across services that share infrastructure.

The output should still be inspectable. Confidence scores are a prior, not a verdict. Your on-call engineer remains the judge.

Investigation trails, not chat logs

Fixed.sh is built around an investigation workspace: signal map, timeline, evidence rows, and activity feed. The goal is a durable trail your team can hand off, whether that is to the next shift, to tier-2, or to a post-incident review.

That is the difference between AI as a copilot and AI as a second set of eyes that leaves breadcrumbs.

Where to go from here

If you are evaluating AI for operations, ask vendors:

• Can I see why this hypothesis ranked first?
• Does it ingest my stack, or only text I paste?
• What happens when the model is wrong, can we correct and continue?

If those questions matter to your team, ranked hypotheses are not a nice-to-have. They are the minimum bar for trust in production.