===============================================================================
5 WHYS ROOT CAUSE ANALYSIS
===============================================================================

✓ **Inherited Context** (from Problem Definition)

Problem Statement:
Connector housing P/N 12345-A, Rev C exhibited cracked locking tabs (crack
length 3mm) at final assembly station 3 during torque verification, affecting
12 of 400 units (3%), detected by visual inspection.

Severity: 7 (AIAG-VDA FMEA Handbook (2019), Table 5.1)
- Product inoperable, loss of primary function
- Customer very dissatisfied

[Expandable] Full 5W2H + IS/IS NOT analysis ▼
| Element | IS | IS NOT |
|---------|----|----- ---|
| What (Object) | Connector housing P/N 12345-A, Rev C | Other connector types |
| What (Defect) | Cracked locking tab, 3mm length | Fully severed |
| Where | Final assembly station 3 | Stations 1, 2 |
| When | Week 12 production | Prior weeks |
| How Much | 12 of 400 units (3%) | All units |

===============================================================================

Proceeding to iterative Why analysis with inherited severity context...

===============================================================================
5 WHYS ROOT CAUSE ANALYSIS
===============================================================================

ℹ️ **Recommendation:** Run `/problem-definition` first

No problem definition context found. For effective root cause analysis, I recommend
establishing a clear, bounded problem statement first using `/problem-definition`.

This provides:
- Structured 5W2H + IS/IS NOT analysis
- Severity classification (flows to FMEA and corrective action prioritization)
- Problem scope boundaries (what IS and IS NOT affected)
- Consistent context for root cause validation

Options:
1. Run `/problem-definition` first (recommended for formal RCCA/8D investigations)
2. Continue 5 Whys standalone (I'll elicit basic problem statement below)

Your choice:

1. What is the specific problem or deviation observed?
2. When was it first observed? When does it occur?
3. Where does it occur (location, process step, equipment)?
4. What is the magnitude/extent (how many, how much, how often)?
5. What is the expected vs. actual state?

• Specific and measurable (not vague)
• Describing a deviation from expected performance
• Free of assumed causes or solutions
• Observable and verifiable

1. Who has direct knowledge of this problem/process?
2. What data, logs, or evidence is available?
3. Has this problem occurred before? What was done?

1. Ask: "Why did [previous answer/problem] occur?"
2. Record: Document the answer verbatim
3. Validate:
   • Is this answer based on fact/evidence or assumption?
   • Does this answer logically follow from the previous statement?
   • Could there be multiple causes? (If yes, branch the analysis)

Would you like me to validate this proposed cause against documented root cause patterns from industry standards (AIAG-VDA, ISO 26262)?

This can:

• Confirm if this matches known failure mechanisms
• Suggest related causes or contributing factors
• Identify if this is a symptom vs. true root cause
• Provide confidence level: High/Medium/Low
• Yes: Query standards for root cause patterns matching "[answer]"
• No: Continue to next "Why" iteration

Your choice:

• If user says yes: Execute

  knowledge_search

  with query "root cause pattern [answer from Why] failure mechanism common causes", filter by domain="rcca" or "fmea"
• If user says no: Continue, but still offer at next iteration (different causes may benefit from validation)
• If MCP unavailable: Skip this prompt entirely (banner already warned user)
• If user declines 3+ times consecutively: "I'll stop offering validation. Use

  /lookup-standard

  if you want to validate a specific cause."

✓ High confidence match

This matches documented pattern: "Inadequate process control leading to variation" (AIAG-VDA FMEA Handbook (2019), Section 4.3.2)

Common related causes from standards:

• Lack of statistical process control
• Inadequate inspection frequency
• Process capability (Cpk) below 1.33

This is a recognized root cause pattern. Consider if any related factors apply.

⚠️ Medium confidence match

Partial match to documented patterns in ISO 26262-9 Section 8.4.3:

• Systematic failures in sensor calibration
• Environmental stress factors

Consider these related factors. You may want to explore another "Why" level.

ℹ️ Low confidence match

No exact match found for "[answer]" in documented root cause patterns.

This could indicate:

• Novel root cause (not previously documented in standards)
• Opportunity to explore another "Why" level
• Need to refine the causal statement

Recommendations:

1. Consider another Why level or alternative cause paths
2. Search related terms: [suggested related queries based on answer]
3. Continue with this cause if supported by strong evidence/expertise

1. Test: Read the chain backward: "Therefore..." - does it make logical sense?

• Further "Why" produces no meaningful answer
• You've reached a process/system issue (not a person)
• Addressing this cause would plausibly prevent recurrence
• The cause is within your control to address
• Standards validation shows high confidence (recognized root cause pattern)

• Answer is still a symptom, not a root cause
• Answer blames a person rather than a process
• Answer is "it's always been that way" or similar deflection
• Standards validation shows low confidence (suggests deeper investigation needed)

1. Reversal Test: Read the chain forward with "therefore" - does each link hold?
2. Prevention Test: If we fix this cause, would the problem be prevented?
3. Recurrence Test: Has this cause produced similar problems before?
4. Control Test: Is this cause within our ability to address?
5. Evidence Test: Is this cause supported by data, not just opinion?

1. How will we fix this? (immediate action)
2. How will we implement it? (plan)
3. How will we verify it works? (validation)
4. How will we standardize it? (documentation/training)
5. How will we sustain it? (monitoring/audits)

• Overall Score: Weighted average × 20 = 0-100 points
• Passing Threshold: 70 points minimum

python scripts/score_analysis.py

• Stopping too early (at symptoms)
• Blaming people instead of processes
• Accepting assumptions as facts
• Single-track thinking on multi-cause problems
• Failing to validate the causal chain

• Manufacturing equipment failure
• Software deployment failure
• Customer complaint investigation
• Process quality deviation

• Fishbone Diagram: Use to brainstorm potential causes before 5 Whys
• Pareto Analysis: Use to prioritize which problems to analyze
• 8D Process: 5 Whys fits within D4 (Root Cause Analysis)
• A3 Report: Include 5 Whys in the root cause section

1. Facilitate, don't lead: Ask questions without suggesting answers
2. Document everything: Record exact wording of each answer
3. Challenge assumptions: Ask "How do we know this?"
4. Stay process-focused: Redirect person-blame to process gaps
5. Allow branching: Multiple valid answers create parallel chains
6. Verify with evidence: "Show me" is better than "tell me"

/lookup-standard [natural language query]

• /lookup-standard common root causes for sensor failures automotive systems

• /lookup-standard systematic failures ISO 26262 definition examples

• /lookup-standard how deep should 5 Whys analysis go stopping criteria

• /lookup-standard validation tests for root cause analysis AIAG-VDA

• /lookup-standard difference between symptom and root cause

• /lookup-standard 5M Man Machine Material Method Measurement root causes

• /lookup-standard process capability Cpk root cause manufacturing

undefined

• "root cause pattern process control"
• "common failure modes manufacturing"
• "5M root cause categories"

**Availability:**
Requires knowledge-mcp connection. If unavailable:
> Standards database not available. Use embedded reference data in `references/root-cause-patterns.md`.