1. Assess available information — Review what the user has provided. Identify which 5W2H elements are known vs. missing.
2. Elicit missing data — For each gap, invoke

   AskUserQuestion

   using the structured format below. Ask 2-3 questions maximum per turn to avoid overwhelming the user.
3. Apply 5W2H framework — Systematically populate: What, Where, When, Who, How, How Much. Deliberately exclude Why (that's for root cause analysis). See references/5w2h-framework.md.
4. Sharpen boundaries with IS/IS NOT — For each 5W2H dimension, explicitly state what the problem IS and IS NOT. The contrast reveals investigation clues. See references/is-is-not-analysis.md.
5. Quantify the gap — Express deviation numerically: "Measured 15 in-lbs; specification requires 22 ± 2 in-lbs" not "torque was low."

You've described the problem extent and impact. Would you like me to search for severity classification scales from industry standards (MIL-STD-882E, AIAG-VDA) to formally classify this problem's severity?

This provides:

• Standardized severity levels with definitions
• Domain-specific criteria (safety-critical, quality, financial impact)
• Consistent severity language for FMEA and corrective action prioritization
• Severity classification flows automatically to 5 Whys and FMEA analysis
• Yes: Query standards database for severity classification scales
• No: Proceed with problem statement synthesis

Your choice:

• If user says yes: Execute

  knowledge_search

  with query "severity classification scale [domain inferred from problem] impact consequences", filter by domain="rcca" or "fmea"
• If user says no: Note preference, do NOT ask again for severity lookup in this session
• If MCP unavailable: Skip this prompt entirely (banner already warned user at session start)
• Neutral phrasing, not recommendation

1. Show top 2-3 matching severity scales with brief domain labels:
   • MIL-STD-882E (safety-critical systems)
   • AIAG-VDA FMEA (quality/manufacturing)
2. User selects scale, then display full definitions
3. User picks applicable level based on problem description
4. Include in final output with citation: "Severity: 7 (AIAG-VDA FMEA Handbook (2019), Table 5.1)"

1. Synthesize problem statement — Combine findings into a single statement using the template:

[Object] exhibited [defect/failure mode] at [location] during [phase/operation], 
affecting [extent/quantity], detected by [method].

1. Validate against pitfalls — Review statement for embedded cause, embedded solution, vagueness, or blame language. See references/pitfalls.md.

1. What (Object) — Must identify the specific item first
2. What (Defect) — Must characterize the failure mode
3. How Much (Extent) — Critical for scoping and prioritization
4. Where / When — Bounds the investigation
5. How (Detection) — Validates data source reliability
6. Who — Typically least critical, often implicit

What is the specific part number, product, or system exhibiting the problem?

Context: Precise identification prevents confusion with similar items.

Examples of useful answers:

• "Connector housing P/N 12345-A, Rev C"
• "Model X Controller Board, serial range SN2024-001 through SN2024-500"

What specifically is wrong? Describe the observable defect, failure mode, or deviation from specification.

Context: Technical, measurable descriptions enable root cause analysis. Avoid subjective terms like "bad" or "poor quality."

Examples of useful answers:

• "Cracked at locking tab; crack length approximately 3mm"
• "Output voltage 4.2V; specification requires 5.0V ± 0.1V"

How many units are affected? What is the failure rate or reject percentage?

Context: Quantification enables prioritization and verifies corrective action effectiveness.

Examples of useful answers:

• "12 of 400 units inspected (3%)"
• "3 field failures from population of ~2,000 deployed units"

You mentioned the problem occurs at Station 3. Does this problem occur at Stations 1 or 2? Are other similar parts from those stations unaffected?

Context: Understanding what IS NOT affected helps narrow root cause investigation.

• Ask, don't assume: If data is missing, ask. Do not infer or fabricate details.
• Batch questions: Group 2-3 related questions per turn. Do not ask all questions at once.
• Accept uncertainty: If user doesn't know, record as "Unknown — requires investigation" rather than leaving blank.
• Probe vague answers: If user says "several units," ask for specific count. If user says "recently," ask for date.
• Avoid leading questions: Do not embed assumed cause in questions (e.g., avoid "Was the torque too high?").

1. 5W2H + IS/IS NOT table — Systematic data capture
2. Problem statement — Single synthesized statement
3. Severity classification — If user opted for severity lookup

===============================================================================
PROBLEM DEFINITION SUMMARY
===============================================================================

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 CLASSIFICATION:
Severity: 7 (AIAG-VDA FMEA Handbook (2019), Table 5.1)
- Product inoperable, loss of primary function
- Customer very dissatisfied
- Justification: 3% failure rate with complete loss of connector locking function

5W2H 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 |

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

• No assumed cause embedded ("due to...", "caused by...")
• No solution embedded ("need to change...", "should replace...")
• Defect described with measurable terms
• Extent quantified (count, percentage, rate)
• Detection method stated
• Scope bounded (what IS affected, what IS NOT)

/lookup-standard [natural language query]

• /lookup-standard MIL-STD-882E severity classification catastrophic critical definitions

• /lookup-standard AIAG-VDA severity rating scale quality problems customer impact

• /lookup-standard how to classify financial impact in problem definition

• /lookup-standard problem statement examples from 8D methodology

• /lookup-standard IS IS NOT analysis best practices

• /lookup-standard difference between MIL-STD severity categories and AIAG-VDA scale

undefined

• "severity classification safety systems"
• "problem definition 8D methodology"
• "IS IS NOT analysis examples"

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