Find the real cause, not the obvious one

In D4, Kanriq separates what produced the defect from what failed to stop it, and equips the team with the methods it already knows.

Illustration of root cause analysis in Kanriq: 5 Whys tree and Ishikawa diagram
Illustration — not an exact view of the interface

Two 5 Whys trees

One tree for occurrence (why the defect happened) and one for non-detection (why it reached the customer). Each level answers the previous one, down to a cause the team can act on; anything the file does not establish is marked as an interpretation.

Ishikawa, timeline and Is / Is Not

The Ishikawa sorts possible causes into the 6M, the timeline puts dated facts in order, and the Is / Is Not table narrows the problem down — with « To check » items when the file cannot conclude yet.

A validated cause, not a guess

Each root cause is confirmed by a validation action (ideally, reproducing the defect). The additional tools inform the analysis without blocking closure: only the 5 Whys gates it.

Frequently asked questions

Why two 5 Whys trees?
Because a defect that reaches the customer has two causes: what produced it and what failed to detect it. Treating them separately avoids fixing an inspection when the process is drifting, and the reverse.
Does the AI make up causes?
No. Each proposed card cites the passage of the file that supports it; a card that goes further is marked « interpretation » so the team checks it.
Can we use only the Ishikawa?
The additional tools are optional and validated separately. The 5 Whys remains the method that gates D4 closure.

Other features

Read the docs

Root cause analysis — Kanriq

Build the 5 Whys trees (occurrence and non-detection), the Ishikawa 6M and the Is / Is Not table, proposed by AI from the facts in the case file.