Use this approach while the mechanism is still unknown. Once an investigation has established a mechanism, the root cause analysis template covers connecting the finding to a corrective action and its effectiveness check. Here, the task is deciding what to investigate first.
State the discrepancy without embedding a diagnosis
The original fictional practice case supplies only these observations:
- A signup import contains 80 rows.
- Six rows have no recorded confirmation-email event in the supplied event extract.
- The extract's coverage period and whether it includes suppressed messages are not established.
- No row-level address validation, queue record, or provider response is supplied.
“Six records lack an event in this extract” preserves the observation. “Six emails failed because the importer corrupted addresses” adds a failed-delivery conclusion and a cause.
The fraction six out of 80 is 7.5% of imported rows. It is not a verified delivery-failure rate. An event could be outside the extract, suppressed, absent for another reason, or missing because the extract is incomplete.
Ask for explanations that make different predictions
Use a small hypothesis set with different evidence needs. These are proposed lines of inquiry for the fictional case, not diagnoses:
| Hypothesis | Evidence that would matter | Proposed check |
|---|---|---|
| Some imported address values are unusable. | Original and imported values for the six rows; declared address rules. | Compare permitted row-level values with those rules without altering the import. |
| Some recipients were suppressed under the system's configured policy. | Suppression records and applicable configuration. | Have the system owner inspect whether those rows have recorded suppression reasons. |
| Events occurred outside the supplied extract's coverage. | Extract boundaries and the corresponding event records. | Confirm coverage and inspect the relevant interval through approved access. |
Each check can weaken an explanation as well as support it. Valid address values would weaken the first hypothesis for those rows; they would not prove the messages were sent. A suppression record might explain an absent send event, while still leaving the reason for that suppression to investigate.
Google's postmortem guidance emphasizes understanding contributing causes and reviewing follow-up actions. It does not establish a cause for this case. Treat the table as an investigation plan that still needs actual evidence.
Copy a hypothesis-and-check prompt
OpenAI's prompting documentation, checked October 24, 2026, recommends explaining the task, context, expected result, and important boundaries. Make “not yet investigated” explicit:
Help plan a root-cause investigation. The mechanism is not established.
Bounded discrepancy and intended system behavior: [ENTER]
Observed records with source IDs and coverage limits: [PASTE]
Checks already performed and actual results: [PASTE OR NONE]
Permitted investigation environment and constraints: [ENTER]
Separate observations from interpretations. Propose a small set of
meaningfully different hypotheses. For each, identify supporting or
contradicting evidence needed and a check that distinguishes it from
the others. State what each possible result would and would not show.
Keep common-cause and multiple-cause possibilities open where relevant.
Do not assign probabilities or declare a root cause from plausibility.
Do not claim checks ran. Do not invent logs, configurations or results.
Flag any access/authorization needed. Propose checks only; do not modify
data, resend messages, change configuration or access production.
Let actual results change the hypothesis set
The system owner should choose approved checks and record the inputs, environment, and actual outcomes. For a reproduction, use the team's permitted test environment and a sanitized fixture. Do not resend real messages simply to see whether the story sounds right.
After evidence arrives, supply it with its source ID and ask which hypotheses it supports, weakens, or leaves open. Keep rejected explanations and the reason for rejecting them in the investigation record. A revised answer is useful only if the new conclusion follows from the new evidence.
Choose a corrective action after the supported mechanism is clear enough to target. Then define how its effect will be checked. If the only result today is that the event extract's coverage is unknown, the next action is to establish that coverage, rather than declare the signup importer fixed.