Files
skills-hub/mechanical-skills/upload-md/failure-root-cause-analysis.md

2.6 KiB

name, description
name description
failure-root-cause-analysis Root cause analysis for field or test failures in mechanical systems. Use this skill whenever the user asks why a failure happened, needs 5-Why/fishbone evidence, or must define corrective actions.

Failure Root Cause Analysis

Objective

Deliver senior-level mechanical engineering support for this domain with transparent assumptions, standards-aware reasoning, and decision-oriented outputs.

Focus

isolate root causes and define corrective/preventive actions.

Required Inputs

Collect and state these inputs before final recommendations:

  • Functional objective and acceptance criteria.
  • Geometry, interfaces, and boundary conditions.
  • Load cases and duty cycle (magnitude, direction, duration, repetitions).
  • Material state, manufacturing route, and environment (temperature, corrosion, contamination).
  • Applicable standards, customer constraints, and safety expectations.

If data is missing, proceed with bounded assumptions and clearly mark uncertainty impact.

Workflow

  1. Frame the engineering question and define pass/fail metrics.
  2. Build a first-principles model and choose methods suitable for the available fidelity.
  3. Cross-check with standards, supplier datasheets, and recognized references.
  4. Compare at least two options when tradeoffs are relevant.
  5. Quantify margins, sensitivities, and residual risks.
  6. Conclude with a practical recommendation and next validation step.

Specialized Checks

Prioritize these checks in the analysis:

  • evidence chain integrity
  • competing hypothesis elimination
  • verification of corrective actions

Sources Priority

Use and cite sources in this order:

  1. Binding standards/codes and contractual requirements.
  2. OEM or supplier technical documentation.
  3. Peer-reviewed literature and recognized handbooks.
  4. Internal lessons learned and field evidence.

When sources disagree, explain which source controls the decision and why.

Output Format

ALWAYS use this structure:

Engineering Response

1. Problem Framing

2. Inputs And Assumptions

3. Analysis And Checks

4. Design Options And Tradeoffs

5. Risks, Failure Modes, And Mitigations

6. Recommendation And Next Actions

7. Sources Consulted

Quality Gates

Before finalizing, verify all of the following:

  • SI units are consistent and conversions are explicit.
  • At least one sanity check exists (order-of-magnitude or handbook benchmark).
  • Utilization, margin, or safety factor is reported where applicable.
  • Limitations and confidence level are stated.
  • Cases requiring human expert sign-off or physical testing are clearly flagged.