Appearance
Investigation & Root Cause
Investigation is where an incident stops being a report and becomes something the organisation can learn from.
What is recorded
| Element | Purpose |
|---|---|
| Investigation narrative | What happened, in sequence, with evidence |
| Timeline | When each event occurred, including detection and response |
| Root cause category | The classified underlying cause |
| Contributing factors | What made the incident possible or worse |
| Lessons learned | What should change |
Requires incident.investigate.
Root cause and contributing factors
These are different, and both are needed.
- The root cause is the condition without which the incident would not have occurred.
- Contributing factors are conditions that made it more likely, harder to detect, or worse in impact.
Most incidents have one root cause and several contributing factors. Recording only the root cause loses most of the learning.
| Element | In the payment duplication example |
|---|---|
| Root cause | The batch submission process had no idempotency check; a resubmitted file was processed as new |
| Contributing factor 1 | The failed batch produced an ambiguous error message that did not distinguish "not submitted" from "submitted and failed downstream" |
| Contributing factor 2 | The duplicate detection threshold was set above the value of 14 of the duplicates |
| Contributing factor 3 | The runbook for a failed batch instructed the operator to resubmit without a check step |
Fixing only the root cause leaves three ways for a similar incident to recur.
Writing the timeline
A timeline is more useful than a narrative for one specific purpose: it exposes the gap between occurrence and detection, and between detection and response.
| Time | Event |
|---|---|
| 02:14 | Batch run fails downstream |
| 02:31 | Operator resubmits per runbook |
| 02:33 | Duplicate transactions begin processing |
| 02:53 | Duplicate detection control alerts |
| 03:10 | Payments Operations begins investigation |
| 04:05 | Processing halted |
| 06:12 | All identified duplicates reversed |
Detection took 20 minutes. Response to detection took 17 minutes. Halting took a further 55. Each of those intervals is a separate improvement opportunity, and none is visible from a narrative alone.
AI assistance
Five advisory capabilities are available, all requiring incident.ai_assist and the AI entitlement.
| Capability | What it produces |
|---|---|
| Draft incident summary | A draft executive summary from incident context |
| Classification suggestion | A heuristic classification with reasoning and an advisory notice |
| Investigation questions | Structured inquiry suggestions, including five-whys and timeline prompts |
| Root-cause hypotheses | Candidate causes across process, control, human and technical factors |
| Lessons learned draft | Preventive recommendations for post-incident review |
AI suggestions never autonomously modify authoritative records
Every one of these produces a draft with full provenance. None sets a classification, records a root cause, creates a finding or closes anything.
The investigation-questions capability is the most genuinely useful of the five. A structured set of prompts at the start of an investigation costs nothing and reliably surfaces the question nobody thought to ask.
From investigation to remediation
Findings and action plans are created from the investigation by explicit human action. See Incident Register.
The pattern that works: one finding per contributing factor worth fixing, with its own action plan and owner. A single finding titled "improve batch processing" produces a single vague action plan that nobody can verify.
Investigating well
Separate what happened from why. Get the timeline agreed before debating cause. Disputes about cause are usually disputes about facts.
Ask what made detection slow, not only what caused the event. In most incidents the detection interval is more improvable than the cause.
Record what worked. Controls that operated correctly, escalation that happened quickly, decisions that limited impact. An investigation that records only failures teaches the organisation that reporting incidents is punitive.
Do not stop at human error. "The operator resubmitted the file" is a description, not a cause. Why did the runbook tell them to? Why was there no check?
Permissions
| Action | Permission |
|---|---|
| View investigations | incident.read |
| Record narratives, root causes and contributing factors | incident.investigate |
| Create findings and actions from the incident | finding.remediate / action_plan.write, plus incident.manage |
| Generate AI advisory drafts | incident.ai_assist |
Example
Incident INC-2026-0014, investigation outcome.
| Element | Content |
|---|---|
| Root cause | No idempotency control on batch payment file submission |
| Contributing factors | Ambiguous downstream error message; duplicate detection threshold set above 14 of the duplicate values; runbook instructed resubmission without a verification step |
| What worked | Duplicate detection identified 1,398 of 1,412 within 20 minutes; reversal completed within the same business day; no customer detriment |
Findings raised — one per contributing factor worth fixing:
| Finding | Subject |
|---|---|
FND-2026-0155 | No idempotency control on batch submission |
FND-2026-0156 | Duplicate detection threshold excludes low-value transactions |
FND-2026-0157 | Batch failure runbook lacks a submission verification step |
The ambiguous error message was recorded as a contributing factor but not raised as a finding — the vendor platform's error semantics are not within the bank's control, and the runbook change addresses the operational consequence. That decision, and its reasoning, is on the record.
Troubleshooting
"I cannot record an investigation." Requires incident.investigate, which is separate from incident.manage.
"AI hypotheses are generic." They draw on the incident context recorded so far. A thin description produces thin hypotheses. Write the narrative first.
"Findings were not created automatically from the root cause." Correct. Creation is human-gated.