fault-hypothesis-engine

name	fault_hypothesis_engine
description	Use when: Brainstorming, prioritizing, and documenting technical fault hypotheses and fault trees based on symptoms, measurements, and functional blocks. Creates a ranked list of probable failure causes with verification paths. Fehlerhypothesen, Fehlerursachen, Fehleranalyse, Priorisierung, Fehlersuche, fault tree, root cause analysis.

<skill_purpose> Generates a structured, prioritized list of failure hypotheses based on symptoms, observed evidence, and functional block knowledge. Guides the technician toward the highest-value diagnostic action first. </skill_purpose>

- Symptom description (e.g., "device turns off under load", "intermittent connection", "won't charge") - Functional block map (from `functional_block_reconstruction` or equivalent) - Component inventory (from `board_image_intake` or equivalent) - Optional: Any prior measurements or observations to factor in 1. Interpret the reported symptoms from a purely technical viewpoint — separate the observable symptom from the inferred cause. 2. Compare mechanical failure modes (cracks, contact resistance, lifted pads) with electrical modes (short, open circuit, degraded component). 3. Derive at least three verifiable fault hypotheses covering different failure classes. 4. Prioritize by: symptom match strength, typical failure probability for this component class, and required verification effort. 5. For each hypothesis, identify the single fastest confirming or disconfirming measurement.

<output_format> Create or update analysis/04_fault_hypotheses.md (or the path specified by the user).

Per hypothesis, use this mandatory table format:

---

Hypothesis [N]: [Short descriptive title]

Field	Content
Technical mechanism	[How this failure mode produces the observed symptom]
Supporting evidence	[Observations / measurements that support this hypothesis]
Counter-evidence	[Observations that argue against this hypothesis]
Priority	[1 = highest priority to investigate]
Fastest verification	[Single measurement or visual check to confirm or refute]

---

Example (do not copy verbatim — adapt to the actual case):

Hypothesis 1: Cold solder joint at battery connector J1

Field	Content
Technical mechanism	Increased contact resistance under current load causes voltage drop → undervoltage shutdown
Supporting evidence	Intermittent symptom correlates with load [Symptom]; flux residue visible at J1 [Image]
Counter-evidence	No visible crack under normal-angle inspection
Priority	1
Fastest verification	Measure V_battery at cell terminals vs. V at circuit input pad simultaneously under load

Hypothesis 2: Degraded battery internal resistance

Field	Content
Technical mechanism	Aged cell with high R_internal drops terminal voltage under load below cutoff threshold
Supporting evidence	Device is older, symptom worsens after partial discharge [Symptom]
Counter-evidence	Open-circuit voltage appears normal
Priority	2
Fastest verification	Measure cell voltage under load vs. no-load — drop > 0.3V confirms degraded cell
</output_format>

<prioritization_logic> Apply this ordering when assigning hypothesis priority:

1. Mechanical contact failures: loose connector, cold solder joint, broken PCB trace
2. Contact resistance degradation: oxidized terminal, corroded pad, intermittent solder
3. Load-dependent voltage drop: battery internal resistance, trace resistance under current
4. Switch or discrete transistor failure: leakage, stuck open or closed
5. IC-level failure: assign only after discrete and mechanical causes are ruled out

Weight "intermittent" or "worse after shaking / flexing the board" symptoms strongly toward mechanical causes. Distinguish "voltage present at idle" from "voltage maintained under load" — these represent different fault classes requiring different measurements. </prioritization_logic>

- Always compare at least three hypotheses — never conclude after the first plausible explanation. - Assign Priority 1 to an IC failure only if simpler mechanical or discrete causes do not fit the symptom. - Every hypothesis must have at least one verifiable measurement that can confirm or refute it. - Cite evidence sources with tags: [Image], [Measurement], [Research], [Domain Knowledge].