root-cause-analysis

Finds the cause of a problem by combining the Ishikawa fishbone (scans every category of cause so nothing is missed) with the 5 Whys (drills each strong candidate to a cause you can act on). The deliverable is the cause that, if removed, prevents recurrence, not an explanation of the symptom.

The fishbone head, the cause category sets (the 6 Ms and the service variants), the 5 Whys discipline, the verification tests, and the failure modes live in references/root-cause.md. Load that file before analyzing.

When to use

A defect, failure, incident, or recurring problem has already happened and its cause is unclear. The unit of analysis is one precisely stated effect, not a vague dissatisfaction. This is the diagnostic engine of the Analyze phase of six-sigma-dmaic and the Check/Act of pdca-cycle; reach for it directly when you have an effect and need its cause. Distinguish it from pre-mortem, which anticipates the future failure of a plan that has not yet run: root-cause-analysis diagnoses a failure that already occurred.

Language

Conduct the session and write the report in the language the user is writing in. The reference file is English; keep the framework keyed to it regardless of the output language.

Inputs

• EFFECT (required): the problem to diagnose. Push for one precisely stated effect, quantified where possible. If it is vague ("quality is bad", "the system is slow"), narrow it with one or two questions before starting.
• CONTEXT (optional): the domain (manufacturing, software, service, safety), when and where the effect occurs, its magnitude and frequency, what changed recently, and any data, logs, or incident records available. This selects the category set and grounds the verification.