Failure Mode and Effects Analysis Prompt

This prompt is for reliability engineers, SREs, and system architects who need to conduct a structured Failure Mode and Effects Analysis (FMEA) on a specific system component, service, or data flow. Use it when you have a defined scope, a known function, and you need a ranked inventory of failure modes with severity, occurrence, and detection scores. The output is a prioritized risk register, not a general resilience review. This prompt assumes you already have a component design or architecture description to analyze. It does not replace a full system-level FMEA or safety-certified analysis required by regulatory standards like ISO 26262 or DO-178C.

The ideal input is a focused description of a single function or component—for example, a payment authorization service, a message queue consumer, or a database connection pool. The prompt works best when you provide concrete details about the component's inputs, outputs, dependencies, and failure boundaries. Avoid feeding it an entire system architecture document; the model will produce a shallow, unfocused analysis. Instead, run the prompt multiple times for different components and aggregate the results into a system-level risk register. Each run should target one function, one failure scope, and one set of operational assumptions.

Do not use this prompt when you need a certified safety analysis, when the component design is still undefined, or when you lack the engineering judgment to validate the model's severity and occurrence scores. The prompt generates a starting point for expert review, not a final deliverable. Always have a domain expert review the failure mode enumeration for completeness and adjust the Risk Priority Number (RPN) scores based on real operational data. If the component handles safety-critical functions, financial ledgers, or irreversible side effects, add a human approval step before any generated mitigations are committed to an implementation backlog.

This prompt template guides a structured Failure Mode and Effects Analysis for a single system component. It requires a detailed description of the component, its functions, and its dependencies. The model will enumerate potential failure modes, assign severity, occurrence, and detection ratings, calculate Risk Priority Numbers (RPNs), and recommend mitigations. The output is a ranked inventory suitable for reliability engineering review.

textCopy
You are a reliability engineer conducting a Failure Mode and Effects Analysis (FMEA).

Analyze the following system component for potential failure modes.

COMPONENT NAME: [COMPONENT_NAME]
COMPONENT DESCRIPTION: [COMPONENT_DESCRIPTION]
COMPONENT FUNCTIONS:
[FUNCTION_LIST]

SYSTEM CONTEXT: [SYSTEM_CONTEXT]
DEPENDENCIES: [DEPENDENCY_LIST]

CONSTRAINTS:
[CONSTRAINTS]

For each identified failure mode, provide:
- Failure Mode: concise description of how the component could fail to perform its function
- Potential Effect(s): impact on the system, users, or downstream components
- Severity (S): 1-10 rating where 10 is catastrophic system failure or safety hazard
- Potential Cause(s): root cause or triggering condition
- Occurrence (O): 1-10 rating where 10 is almost certain to occur under normal operation
- Current Controls: existing detection or prevention mechanisms
- Detection (D): 1-10 rating where 10 means no current control can detect the failure before impact
- Risk Priority Number (RPN): S × O × D
- Recommended Mitigation(s): specific actions to reduce severity, occurrence, or improve detection

OUTPUT FORMAT:
Return a JSON object with this exact schema:
{
  "component": "string",
  "analysis_date": "string (ISO 8601)",
  "failure_modes": [
    {
      "id": "string (FM-001, FM-002, ...)",
      "failure_mode": "string",
      "potential_effects": ["string"],
      "severity": number,
      "potential_causes": ["string"],
      "occurrence": number,
      "current_controls": ["string"],
      "detection": number,
      "rpn": number,
      "recommended_mitigations": ["string"]
    }
  ],
  "rpn_summary": {
    "highest_rpn_items": ["string (failure mode IDs)"],
    "average_rpn": number,
    "items_requiring_immediate_action": ["string (IDs with RPN > 100 or severity > 7)"]
  }
}

Before returning the JSON, verify:
1. At least one failure mode is identified per function listed
2. All RPN values are correctly calculated as S × O × D
3. Severity ratings above 7 have corresponding recommended mitigations
4. No detection rating is 1 unless there is a proven automatic detection mechanism described in current controls

If [RISK_LEVEL] is "high" or "critical", add a "human_review_required" boolean field set to true for any failure mode with severity >= 8.

Adaptation guidance: Replace all square-bracket placeholders with your specific component data. The [FUNCTION_LIST] should enumerate every function the component performs—the model uses this to ensure complete failure mode coverage. Set [RISK_LEVEL] to "low", "medium", "high", or "critical" to control the human-review flagging behavior. The output schema is strict JSON; if your harness requires a different format, modify the OUTPUT FORMAT section but preserve the field semantics. For components with safety implications, keep the severity scale anchored to real harm categories rather than abstract ratings. Run the output through a JSON schema validator before ingesting into your reliability tracking system.

The FMEA prompt is not a one-shot report generator. It should be embedded in a harness that validates the output schema, recalculates Risk Priority Numbers (RPNs), flags missing failure modes, and routes high-severity findings for human review before the analysis is accepted. The harness is responsible for making the prompt's output trustworthy enough to act on, especially when the analysis informs architectural changes or operational runbooks.

Start by enforcing the output schema. Parse the model's JSON response and validate that every failure mode entry contains the required fields: component, function, failure_mode, effect, severity, occurrence, detection, rpn, and recommended_mitigation. Reject entries where severity, occurrence, or detection fall outside the 1–10 range. Recalculate rpn as severity * occurrence * detection and flag any mismatch between the model's stated RPN and the computed value. If more than 10% of entries have RPN mismatches, discard the entire response and retry with a stricter instruction that emphasizes arithmetic accuracy. Log every validation failure for prompt improvement cycles.

The harness should also check for completeness. Maintain a known list of components and functions from your system architecture documentation. After parsing the model's output, compare the enumerated failure modes against this expected scope. Flag any component that has zero failure modes as a potential gap. For high-criticality systems (e.g., payment processing, authentication, safety controls), require a minimum number of failure modes per component. If the model's coverage falls below this threshold, append a follow-up prompt that asks specifically for failure modes on the uncovered components, using the existing analysis as context.

Human review is mandatory for any failure mode with severity >= 8 or rpn >= 200. Route these entries to a review queue where a reliability engineer can confirm the scoring, adjust the mitigation recommendation, and link the finding to an incident ticket or architecture decision record. The harness should also track whether the same high-severity failure mode appears across multiple analysis runs, which may indicate a systemic gap that the model consistently identifies but the team hasn't yet addressed. Store all FMEA outputs with a timestamp, model version, and prompt version so you can compare analyses over time as the system evolves.

For model selection, prefer a model with strong structured output support and arithmetic reliability. GPT-4o and Claude 3.5 Sonnet both perform well on this task when output is constrained to a strict JSON schema. Avoid smaller or older models that may hallucinate RPN values or skip detection scoring. If you're running FMEA on a large system with many components, consider splitting the analysis into multiple calls—one per subsystem—and merging the results. This reduces the risk of the model truncating the failure mode inventory due to output length limits. Always set a max_tokens value high enough to accommodate the expected number of failure modes, and check for truncation in the harness before accepting the output.