← Blog · Incident Response · September 20, 2026 · 7 min read · By Operate Editorial Team

The Case Definition Must Not Contain Your Hypothesis: What Outbreak Investigators Do at Step Four That Incident Channels Skip Entirely

Outbreak investigators define who counts as a case before hunting for cases, and the definition must not contain the suspected cause. Incident channels skip that step, and blast radius pays for it.

The Case Definition Must Not Contain Your Hypothesis: What Outbreak Investigators Do at Step Four That Incident Channels Skip Entirely

The Case Definition Must Not Contain Your Hypothesis: What Outbreak Investigators Do at Step Four That Incident Channels Skip Entirely

TL;DR: To prevent biased root cause analysis and understated blast radius, incident responders must define the affected population using objective criteria—time, place, and person—before investigating the cause. A working case definition should never include the suspected source of the failure, ensuring the investigation tests a hypothesis rather than merely confirming one.

Two people in the incident channel are counting different things

In the heat of a live incident, communication often breaks down at the most fundamental level: the count. One engineer reports two hundred affected customers based on a specific error log; a support lead insists the entire EU region is degraded because their queue is spiking. Both are technically correct, but neither has written down a working case definition.

The result is predictable. Because the boundaries of the incident were never explicitly defined, the team spends the first hour talking past each other. More importantly, the true scale of the impact is almost always revised upward three days later during the postmortem. When we don't define who "counts" as affected at the start, we only see the failures we were already looking for.

The step field epidemiology puts at number four

When public health officials investigate a disease outbreak, they follow a rigorous, thirteen-step procedure. According to the CDC’s Principles of Epidemiology, Step 4 is "Construct a working case definition."

Crucially, this step occurs after verifying the outbreak exists and verifying the diagnosis, but before Step 5, which is finding cases systematically. In software, we almost always skip Step 4. We jump from "something is wrong" (Step 1) straight to "find all the errors" (Step 5).

A case definition, per the CDC, consists of clinical criteria plus restrictions by time, place, and person. It must be simple, objective, and applied consistently to every entity under investigation. It is the yardstick that determines what is in scope before the search begins.

The rule: your definition of affected must not contain your theory of the cause

The most common mistake in both epidemiology and systems engineering is baking the suspected cause into the definition of the victim.

The CDC provides a classic worked example: If you suspect a foodborne illness was caused by a specific salad bar in the west wing of a facility, your case definition should not be "illness among people who ate at the west wing salad bar." Instead, it should be "illness among anyone in the facility." You then test whether those in the west wing had a higher risk.

In software, we violate this daily. We define incidents as "checkout errors caused by the 14:02 deploy" or "timeouts from the payments service."

Key Takeaway: Defining an incident by its suspected cause creates a circular investigation that ignores any data points that don't fit the initial theory.

When you define the incident by the deploy, you only pull logs for that deploy. Anything failing for a different reason—or a failure that started at 13:55—is definitionally excluded. The postmortem then "confirms" the hypothesis because the dataset was curated to ensure it could do nothing else. The correct approach is to define the case as "failed checkouts between 14:00 and 15:30" and then analytically test if the deploy cohort failed at a higher rate than the baseline.

Confirmed, probable, possible. Your channel has one tier and it is confirmed.

Epidemiologists use tiers—confirmed, probable, and possible (or suspect)—because diagnosis is often uncertain early on. The CDC cites the PAHO meningococcal disease definition as a model: a "confirmed" case has laboratory evidence, while a "probable" case has clinical symptoms and a link to a confirmed case.

Software incident channels typically have exactly one tier: confirmed. If a request doesn't explicitly throw a 500 error, it is counted as "not affected." This creates a systematic bias where the blast radius is always understated. By including "probable" cases (e.g., requests with 99th percentile latency) and "possible" cases (e.g., all active sessions during the window), you capture the full scope of the volatility before the evidence disappears.

Loose first, tight later. Teams do the opposite.

The CDC advocates for a sequence: use a loose, sensitive case definition early to characterize the extent of the problem, then tighten it later for analytical work to prevent false positives from corrupting the results.

Software teams often do the inverse. They start tight—looking only at the specific error messages they personally observed—and never widen their gaze. They are then blindsided when a second or third customer report arrives from a different region or service. While the CDC notes that newly recognized syndromes like SARS or AIDS may start with a narrow definition to ensure accuracy, for the vast majority of "outbreaks" in production, starting narrow is a recipe for missing the forest for the trees.

Before you believe the spike, rule out your own instruments

According to the CDC, Step 3 (verifying the diagnosis) exists partly to rule out "laboratory error" as the basis for an apparent increase in cases.

In software, an apparent spike in errors is often a measurement artifact. Before launching a full-scale investigation, responders should spend ninety seconds checking the instruments:

Ignoring this step leads to hours of investigating a "ghost" incident caused by a change in how we count, not a change in what is happening.

Time, place, person

A robust case definition requires three dimensions that most software incident scopes ignore:

  1. Time: Define the window with a defensible start, not just "when the alert fired."
  2. Place: Identify the affected surface—region, shard, availability zone, or specific client version.
  3. Person: Identify the cohort—which tenants, subscription plans, or device classes are affected?

An incident scope that says "Checkout is down" is useless. An incident scope that says "Internal Server Errors (Time) on the mobile web surface in US-East-1 (Place) affecting Enterprise tier tenants (Person)" is a working case definition.

Get it while you can

The field axiom "get it while you can" is the strongest operational takeaway from epidemiology. Investigators are encouraged to collect extra data while on-site because returning is expensive.

In software, once service is restored, the most valuable evidence often evaporates. Connection states, in-flight queue depths, and pod logs about to rotate are lost forever. If you haven't defined your case broadly enough to capture this volatile data during the incident, your postmortem will be written from what survived rather than what actually mattered.

The ninety-second version

You don't need a thirteen-step process during a P1. You need a ninety-second pause to paste a structured message into the channel:

Where the analogy stops

Outbreak investigations run for weeks; software incidents are resolved in minutes. The CDC acknowledges that in urgent situations, steps may be simultaneous or reversed. The goal isn't to turn SREs into medical doctors; it is to recognize that one specific step—defining the population before hunting for the cause—is the difference between an investigation that finds the truth and one that merely validates a guess.

The reason this step is so often skipped is that the person responsible for the definition is usually the same person tasked with the restoration. A self-hosted AI SRE platform like Operate can bridge this gap by opening its own case and writing the working definition first. By stating the affected population in terms of observed symptoms—independent of a suspected cause—Operate gathers evidence for the entire affected population, ensuring the root cause analysis is based on the full scope of the failure rather than a filtered subset of logs.

Sources & further reading

#incident response#SRE#root cause analysis#epidemiology#blast radius