Fmeca

FMEA/FMECA Skill

Produce consulting-grade Failure Mode and Effects Analysis (FMEA) and Failure Mode, Effects, and Criticality Analysis (FMECA) outputs. This skill supports five workflows: interpreting existing analyses, authoring new ones, reviewing/critiquing quality, generating formatted deliverables, and parsing technical documents into reusable FMECA context files.

Reference Files

Read the appropriate reference files from references/ BEFORE doing substantive work. This is essential — the reference libraries contain domain-specific failure mode knowledge that prevents hallucination and ensures technical accuracy.

For any given task, read the standards guide plus the relevant sector taxonomy. If client-specific context files exist for the asset being analysed, read those too — they contain parsed equipment hierarchies, operating context, failure history, and maintenance regimes extracted from real client documentation and will significantly improve analysis quality.

Core Concepts

FMEA identifies failure modes, their effects on system performance, and existing controls. Typically uses Risk Priority Number (RPN = Severity × Occurrence × Detection) to prioritise action.

FMECA extends FMEA with formal criticality assessment — either qualitative (criticality ranking matrix) or quantitative (criticality number using failure rate and failure mode ratio data per MIL-STD-1629A). FMECA is standard in defence and heavy industry.

The Hierarchy

Every FMEA/FMECA is built on a consistent decomposition:

System (e.g. Tram Braking System)
  └── Sub-system (e.g. Friction Brake)
        └── Component/Maintainable Item (e.g. Brake Pad Assembly)
              └── Function (e.g. Convert kinetic energy to heat via friction)
                    └── Functional Failure (e.g. Unable to generate braking force)
                          └── Failure Mode (e.g. Brake pad worn below minimum thickness)
                                ├── Failure Effect (local / system / end effect)
                                └── Failure Cause/Mechanism (e.g. Normal abrasive wear)

This hierarchy is non-negotiable — every analysis must trace from system context down to failure modes. If a user provides data that skips levels, flag the gaps.

Key Distinctions

• Failure mode vs failure cause: A failure mode is the observable manner of failure ("bearing seized"). A failure cause/mechanism is why it happened ("loss of lubrication due to seal degradation"). Many poor FMEAs conflate these.
• Local effect vs system effect vs end effect: Effects cascade upward. Local = at the component. System = at the sub-system/system. End = what operator/customer/public experiences.
• Evident vs hidden failure: Evident failures are apparent to operators under normal conditions. Hidden failures (typically protective devices) only become apparent when demanded.

Discovery Process

Before starting any workflow, conduct a discovery interview. Tailor depth to the workflow.

Essential Questions (all workflows)

1. What asset/system are we analysing?

   • Equipment type, make/model if known
   • Operating context (where, how, how hard)
   • Sector (rail, port, mining, other)

2. What's the purpose of this analysis?

   • Regulatory/compliance requirement
   • Maintenance strategy development (RCM-adjacent)
   • Design review / DFMEA
   • Risk assessment for decision-making
   • Insurance or safety case input

3. What standard should we align to?

   • IEC 60812 (default — broadest applicability)
   • SAE J1739 (if automotive or rolling stock design-focused)
   • MIL-STD-1629A (if defence or quantitative criticality required)
   • ISO 14224 (if petroleum/gas or aligning to that failure taxonomy)
   • Client-specific methodology (ask for details)

4. What data is available?

   • Existing FMEAs or maintenance strategies
   • Asset registers or BOMs
   • Failure/work order history
   • OEM manuals or maintenance documentation
   • P&IDs, schematics, or system diagrams

Additional Questions by Workflow

For authoring: Level of detail expected? How many equipment items? System-level or component-level? Who reviews?

For review: What concerns prompted the review? Known gaps? Consequence of errors?

For outputs: What format does the client expect? Do they have a template? What scoring scale?

Workflow 1: Interpret & Explain

When a user uploads or pastes FMEA/FMECA data and wants to understand it.

1. Parse the input — Identify structure, columns, scoring method, hierarchy depth, standard alignment. Note what's present and what's missing.

2. Summarise the scope — What system/asset, how many failure modes, what scoring method, what standard it appears to follow.

3. Explain the findings — In plain language: highest-risk items, what scores mean practically, hidden failures, common-cause failures, recommended actions.

4. Flag quality issues — Missing data, inconsistent scoring, vague descriptions, missing hierarchy levels. Even when interpreting, note these.

5. Provide context — Relate findings to operating context. A high RPN on a tram braking component has different urgency than on a warehouse HVAC unit.

Lead with the "so what" — what should the reader care about and do next.

Workflow 2: Author from Scratch

When building a new FMEA/FMECA from available data.

1. Establish the system boundary — What's in scope and out. Define top-level system and interfaces.

2. Build the hierarchy — Use the appropriate sector taxonomy from references/ as a starting point. Decompose to maintainable item level (the level at which you'd write a work order).

3. Define functions — State what each component does in quantifiable terms where possible. "Maintain hydraulic pressure at 200 bar" not "Works properly". Every item needs at least one function.

4. Identify functional failures — For each function: total loss, partial loss, intermittent loss, degraded performance, unintended function, over-function.

5. Determine failure modes — Specific, observable manners of failure. Use taxonomy references as a prompt but adapt to the specific asset. Quality test: could a technician read this and picture exactly what's wrong?

   • Good: "Impeller blades eroded reducing flow by >20%"
   • Bad: "Pump degraded"

6. Describe failure effects — At three levels (local, system, end). Include secondary damage, safety implications, environmental consequences.

7. Identify failure causes/mechanisms — What initiates or drives each failure mode. Link to operating context. Multiple causes per failure mode is normal.

8. Assess severity, occurrence, and detection — Read references/scoring-scales.md. Apply consistently. Document assumptions.

9. Calculate RPN or criticality — Per the selected standard.

10. Recommend actions — For high-priority items: preventive tasks (with intervals), condition monitoring, design modifications, redundancy, operational changes, or risk acceptance with justification.

Quality Checks During Authoring

Run continuously, not just at the end:

• Every component has at least one function stated
• Every function has at least one functional failure
• Every functional failure has at least one failure mode
• Failure modes are specific and observable
• Effects cascade correctly (local → system → end)
• Causes are distinct from failure modes
• Scoring is consistent across similar items
• No orphaned rows (failure modes without effects or causes)

Workflow 3: Review & Critique

Score each dimension 1–5 and provide specific findings:

1. Structural completeness — Hierarchy complete? Functions stated? Orphaned entries?

2. Failure mode quality — Specific and observable? Common modes covered? (Cross-reference against sector taxonomy.) Cause-mode confusion?

3. Effects analysis quality — All three levels described? Safety/environmental consequences addressed? Cascading effects considered?

4. Scoring consistency — Scale documented? Similar modes scored consistently? Severity reflects end effects? Detection based on current controls?

5. Completeness of recommendations — High-RPN items have actions? Actions specific? Clear link between failure mode and recommended task?

6. Standard alignment — Format matches claimed standard? Mandatory fields present? Criticality methodology correct?

Output: Structured review report

• Executive summary (overall quality rating, key concerns)
• Findings by dimension (with specific examples)
• Priority recommendations (what to fix first)
• Positive observations (what's done well)

Workflow 4: Generate Outputs

Spreadsheet (.xlsx)

Use the xlsx skill. Structure columns per selected standard:

IEC 60812 / general FMEA columns: Item | Function | Functional Failure | Failure Mode | Failure Cause | Local Effect | System Effect | End Effect | Severity | Occurrence | Detection | RPN | Recommended Action | Responsible | Target Date | Status

MIL-STD-1629A FMECA columns: Item ID | Item Name | Function | Failure Mode | Failure Cause | Mission Phase | Local Effect | Next Higher Effect | End Effect | Severity Class | Failure Rate | Mode Ratio | Criticality Number | Compensating Provisions | Remarks

SAE J1739 columns: Item/Function | Potential Failure Mode | Potential Effect(s) | Severity | Class | Potential Cause(s) | Occurrence | Current Prevention Controls | Current Detection Controls | Detection | RPN | Recommended Action | Responsibility | Target Date | Action Taken | Revised S | Revised O | Revised D | Revised RPN

Other Formats

• Risk matrix — HTML artifact: severity × occurrence heat map showing failure mode distribution
• Summary report (.docx) — Executive-level: scope, methodology, findings, risk profile, recommendations
• FMECA register (.xlsx) — Full register with filtering, conditional formatting, summary dashboard

Formatting Standards

• Conditional formatting on RPN/criticality (Red/Amber/Green thresholds)
• Legend/key sheet explaining scoring scales
• Summary sheet with counts by risk category
• Frozen headers, auto-filter enabled
• Appropriate column widths

Workflow 5: Parse Document into FMECA Context File

When a user uploads a technical document and wants to extract FMECA-relevant information into a structured markdown file for reuse in future sessions.

This workflow is foundational — it turns raw client/OEM documentation into a machine-readable reference that dramatically improves the quality of subsequent FMEA/FMECA work. The output .md file is saved directly into the skill's references/ directory so it's automatically available in future sessions alongside the sector taxonomies.

Supported Document Types

Parse any of these into a context file. Each type yields different information — extract what's present and flag what's missing:

Process

1. Read the document — Use the appropriate tool to access the uploaded file. For PDFs, extract text. For spreadsheets, parse the structure. For images of P&IDs or diagrams, describe what's visible.

2. Read the context file template — Read references/context-file-template.md for the output structure. This is the target format.

3. Identify the document type — Determine which type(s) from the table above. A single document may span multiple types (e.g. an OEM manual contains both equipment specs and maintenance recommendations).

4. Extract and structure — Pull out all FMECA-relevant information and organise it into the template sections. Be thorough — it's better to capture something that turns out to be marginally useful than to miss something critical.

5. Cross-reference against taxonomy — Compare the extracted equipment hierarchy against the relevant sector taxonomy. Note where the document's naming differs from standard taxonomy terms (this mapping is valuable for future work).

6. Flag gaps and uncertainties — At the end of the context file, explicitly list:

   • Information that was expected but not found in the document
   • Ambiguous items where interpretation was required
   • Areas where additional documents would significantly improve the context
   • Any conflicts between the document and standard taxonomies

7. Name the file descriptively — Use the pattern: {client}-{asset}-{doctype}-context.md Examples: yarratrams-bclass-oem-context.md, geelongport-shiploader1-condition-context.md, santos-compressor-fmea-context.md

8. Save to the skill's references directory — Write the context file directly into the FMECA skill's references directory so it's automatically available in future sessions:

   Claude Code / Agent SDK (filesystem-based skills): Save to the project or user skill path, whichever contains the fmeca skill:

   .claude/skills/fmeca/references/{client}-{asset}-{doctype}-context.md
   

   If the project path (.claude/skills/fmeca/) doesn't exist, fall back to the user path:

   ~/.claude/skills/fmeca/references/{client}-{asset}-{doctype}-context.md
   

   Claude.ai (container environment): The container filesystem resets between sessions, so save to both locations:

   • Working location: /mnt/skills/user/fmeca/references/ (if writable) or the skill's own references directory
   • Download copy: /mnt/user-data/outputs/ so the user can manually add it to their skill directory outside the session

   Confirm with the user before saving. State the full file path and ask them to confirm. If the references directory doesn't exist yet, create it.

9. Register in the reference table — After saving, remind the user to add an entry to the SKILL.md reference table so the context file gets loaded in future sessions when relevant. Suggest the entry in this format:

   | `references/{filename}.md` | When working on {client} {asset} FMECA |
   

   If running in Claude Code with write access to SKILL.md, offer to add the entry directly.

Extraction Rules

These rules ensure consistency across context files regardless of who creates them:

Equipment Hierarchy

• Decompose to the maintainable item level (the level a technician would write a work order against)
• Use the document's own naming where it exists, but add standard taxonomy mapping in parentheses where terms differ. E.g. "Traction Power Module (≈ Traction Inverter per rolling-stock-taxonomy)"
• Preserve the document's item numbering/coding scheme — this is essential for traceability

Functions

• State functions in the format: verb + object + quantified performance where available
• Good: "Maintain brake pad contact pressure at 12-15 kN per caliper"
• Acceptable if doc lacks specifics: "Provide braking force to decelerate vehicle"
• Always note the source: "(per OEM Manual Section 4.3)" or "(inferred from system description)"

Operating Context

• Capture everything that affects failure behaviour: environment, duty cycle, loading, temperature, exposure, utilisation rate
• Note seasonal or campaign-based variations
• Include any operating restrictions or limitations documented

Maintenance Context

• Capture current tasks, intervals, and the basis for those intervals (OEM recommendation, regulatory, experience-based)
• Note where tasks are time-based vs condition-based
• Capture any documented maintenance access constraints (outage required, confined space, etc.)

Failure Information

• Record failure modes exactly as described in the source document
• Map to standard taxonomy terms where possible, but preserve the original language
• Capture any quantitative data (failure rates, MTBF, Weibull parameters) with units and source
• Note sample sizes and confidence levels where available

Protective Devices & Hidden Failures

• Explicitly list every protective device, alarm, trip, relief valve, standby system
• For each, note: what it protects against, how it's tested, test interval, last known test result
• These are the most commonly missed items in FMEAs — extracting them upfront is high-value

Combining Multiple Documents

When multiple documents relate to the same asset/system:

• Parse each document individually first, saving each to the skill's references directory
• Then create a consolidated context file that merges the information, named: {client}-{asset}-consolidated-context.md
• Save the consolidated file to the same references directory — it replaces the individual files as the primary reference for that asset (keep the individual files for traceability)
• Where documents conflict (e.g. OEM says 500hr service interval, maintenance plan says 750hr), note both values and the source of each — don't silently pick one
• The consolidated file should cross-reference source documents for traceability: "[Source: OEM Manual Rev C, Section 4.3.2]"
• Update the SKILL.md reference table entry to point to the consolidated file

Output Quality Check

Before finalising the context file, verify:

• Every equipment item has at least one function stated (or flagged as "function not documented")
• The hierarchy is internally consistent (no orphaned items, no gaps between levels)
• Operating context section is populated (even if sparse — note what's missing)
• Protective devices section is populated (or explicitly states "no protective devices identified")
• Source references are traceable to specific sections/pages of the input document
• The gaps/uncertainties section is honest and actionable

General Guidance

Common Pitfalls to Flag

1. Vague failure modes — "Component fails" is not a failure mode
2. Cause-mode confusion — "Corrosion" is usually a cause, not a mode
3. Inconsistent scoring — Same failure type scored differently without justification
4. Missing hidden failures — Protective devices frequently missed
5. Single-point-of-failure blindness — Not identifying absent redundancy
6. Copy-paste syndrome — Generic descriptions reused without adaptation
7. Detection score confusion — Rates current controls, not theoretical capability
8. Severity creep — Everything rated 9-10 makes analysis useless for prioritisation
9. Missing operating context — Same equipment, different environment = different failure behaviour

When Data is Insufficient

Be transparent. State assumptions clearly. Flag where engineering judgement has been applied vs data-supported assessment. Recommend data collection for critical gaps. Never fabricate failure rate data — use qualitative ranges and state the basis.

Integration

This skill works with: xlsx skill (worksheets), docx skill (reports), pptx/presentation skills (stakeholder presentations). Read the relevant output skill first, then apply FMECA domain knowledge.