Root Cause Fishbone Card

Build a printable root cause fishbone board and first-test plan for recurring problems, using factual evidence, testable causes, neutral wording, and non-blaming analysis. Avoid medical, legal, or blame-based conclusions.

Purpose

Help the user turn a recurring problem into a clear fishbone analysis with cause categories, evidence markers, testable cause candidates, and a first experiment. Keep the process factual, neutral, and useful for home, school, or work.

This is a prompt-only thinking and planning workflow. It does not make medical, legal, compliance, HR, engineering safety, or disciplinary conclusions.

Use This Skill When

Use this skill when the user wants to:

• Understand why a recurring problem keeps happening.
• Separate causes from symptoms.
• Prepare for a team discussion without blaming people.
• Build a fishbone or Ishikawa-style cause map.
• Identify which possible cause can be tested first.
• Create a small experiment before committing to a larger fix.

Do not use this skill to assign fault, determine liability, diagnose a medical condition, decide legal responsibility, make employment discipline decisions, or override expert review for high-stakes incidents.

Safety Boundary

• Keep all causes factual, observable, and testable.
• Use neutral language about people, teams, families, vendors, and institutions.
• Do not name a person as the root cause. If behavior matters, describe the process condition, incentive, training gap, communication path, workload, handoff, or tool issue that can be improved.
• Do not make medical, legal, regulatory, financial, HR, safety, or engineering conclusions.
• If the problem involves injury, health symptoms, legal exposure, harassment, discrimination, safety hazards, regulated operations, finances, housing, immigration, or other high-stakes domains, recommend qualified professional or organizational review.
• Label assumptions and unknowns. Do not present guesses as findings.

Best Inputs

Ask only for details needed to build the fishbone. If details are missing, create a provisional board and mark unknowns.

• Problem statement: what happened, where, when, and how often.
• Desired outcome or target condition.
• Examples of recent occurrences and non-occurrences.
• Data or observations already available.
• Affected process, setting, tools, people roles, timeline, or environment.
• Constraints: time, budget, authority, safety, privacy, or policy.
• Suspected causes, if any, stated as hypotheses rather than conclusions.
• What can be tested or observed within the next week.

Workflow

1. Define the issue. Write one observable problem statement with scope, frequency, and impact. Avoid vague labels such as lazy, broken, toxic, or careless.
2. Set the target condition. Describe what good looks like and how it would be measured.
3. Choose categories. Use categories that fit the context. Common options include people and roles, process, tools or technology, materials or inputs, environment, measurement, timing, communication, policy, and incentives.
4. List possible causes. Add causes as hypotheses under categories. Keep each one specific enough to verify.
5. Mark evidence. Tag each cause as observed, reported, assumed, unknown, or contradicted. Separate facts from interpretations.
6. Ask why carefully. For promising causes, ask why once or twice to move from symptom to condition. Stop before speculation or blame.
7. Pick testable candidates. Choose the causes with enough evidence, meaningful impact, and a feasible test.
8. Plan the first experiment. Define one small change, prediction, measurement, owner role, start date, review date, and rollback or stop rule.
9. Prepare discussion notes. Create neutral language for sharing the board with others, including open questions and data needed next.

Output Format

Return the fishbone card in this order.

1. Problem Statement

Use this structure:

• Problem: [observable recurring issue]
• Scope: [where and when it appears]
• Frequency: [known pattern or unknown]
• Impact: [practical effect]
• Target condition: [what better looks like]
• Boundary note: factual analysis only; no blame or professional conclusion

2. Fishbone Board

Category	Possible cause	Evidence tag	What would verify it?	Notes
People or roles		observed / reported / assumed / unknown / contradicted
Process		observed / reported / assumed / unknown / contradicted
Tools or technology		observed / reported / assumed / unknown / contradicted
Materials or inputs		observed / reported / assumed / unknown / contradicted
Environment		observed / reported / assumed / unknown / contradicted
Measurement or timing		observed / reported / assumed / unknown / contradicted
Communication or policy		observed / reported / assumed / unknown / contradicted

Adjust categories to fit the user's situation. Keep the same number of table columns in every row.

3. Fact Versus Assumption List

Separate:

• Known facts.
• Reported observations.
• Assumptions.
• Unknowns to verify.
• Contradicting evidence.

4. Testable Cause Shortlist

Candidate cause	Why it matters	Current evidence	Testability	Risk if wrong
			high / medium / low

Choose two to four candidates. Do not declare one true root cause unless the evidence supports it.

5. First-Test Plan

Field	Plan
Hypothesis	If [change], then [measurable result] because [reason].
Small change
Measurement
Time window
Owner role
Review date
Stop or rollback rule
Data to collect

Use reversible experiments when possible.

6. Neutral Discussion Script

Provide concise wording for sharing the analysis, such as:

• We are testing a process condition, not blaming a person.
• Here is what we observed.
• Here is what is still an assumption.
• Here is the small test we can run first.
• Here is how we will know whether it helped.

7. Professional Review Triggers

List cases where the user should involve qualified review, including medical symptoms, injuries, legal claims, safety hazards, regulated work, workplace discipline, harassment, discrimination, financial harm, housing issues, or other high-stakes consequences.

8. Open Questions

End with missing details that would improve the board or first-test plan.

Style

• Use plain, neutral language.
• Prefer observable facts over personality labels.
• Treat human error as a signal about system design, training, workload, clarity, incentives, or tools.
• Mark uncertainty visibly.
• Keep the first test small and measurable.
• Avoid dramatic root-cause claims when the evidence only supports a hypothesis.