Rule

Failure Mode Classification Rule

The taxonomy and classification logic that standardizes how equipment failures are categorized — defining failure mode codes, cause codes, effect codes, and the hierarchical structure (asset class → component → failure mode → root cause) that ensures consistent coding across technicians and shifts.

Last updated: February 2026Data current as of: February 2026

Why This Object Matters for AI

AI cannot perform automated root cause analysis or detect failure patterns without a consistent failure classification system; without it, the same bearing failure gets coded five different ways by five different technicians, making pattern recognition across the fleet impossible.

Maintenance & Reliability Capacity Profile

Typical CMC levels for maintenance & reliability in Manufacturing organizations.

Formality
L2
Capture
L2
Structure
L2
Accessibility
L1
Maintenance
L2
Integration
L2

CMC Dimension Scenarios

What each CMC level looks like specifically for Failure Mode Classification Rule. Baseline level is highlighted.

L0

There is no failure classification system. When a technician closes a work order, they write a free-text description: 'fixed the thing,' 'replaced motor,' 'adjusted.' The same bearing failure gets described as 'bearing,' 'brg replacement,' 'noise from spindle,' or 'SKF 6205 swap' by different technicians. Failure mode analysis is impossible because there's no consistent language for describing what went wrong.

AI cannot detect failure patterns because the same failure type is described differently every time. Pattern recognition across thousands of free-text descriptions yields noise, not signal.

Introduce a basic failure classification — even a short list of failure mode categories (mechanical, electrical, hydraulic, pneumatic, instrumentation) that technicians must select when closing a work order.

L1

A basic failure code list exists — 10-15 broad categories like 'bearing failure,' 'motor burnout,' 'leak,' 'sensor fault.' Technicians select a code from a dropdown when closing work orders. But the list is too coarse — 'bearing failure' covers everything from a contaminated grease nipple to a catastrophic spindle seizure. Root cause codes don't exist. 'Other' accounts for 25% of selections. The classification tells you something failed but not why or where specifically.

AI can produce Pareto charts of failure categories but cannot perform meaningful root cause analysis or failure mode effects analysis because the classification is too coarse to distinguish failure mechanisms.

Expand the taxonomy into a hierarchical structure — asset class → component → failure mode → root cause — so technicians can classify failures at the specific level needed for pattern analysis.

L2Current Baseline

A structured failure taxonomy exists with hierarchical codes: asset class (pump, motor, conveyor) → component (bearing, seal, impeller) → failure mode (wear, contamination, overload) → root cause (inadequate lubrication, foreign object, thermal stress). Technicians navigate a guided selection tree. The taxonomy is documented and consistent. But it's a standalone reference — not linked to equipment BOMs, maintenance procedures, or historical failure data for validation.

AI can perform hierarchical failure analysis — trending failure modes by component type and root cause. Cannot validate classification accuracy because the taxonomy isn't linked to equipment data that could confirm or contradict the technician's selection.

Link the classification taxonomy to equipment component hierarchies (so the system knows which failure modes are valid for which components), maintenance procedure libraries (so root causes link to preventive actions), and historical failure records for pattern validation.

L3

The failure classification system links to equipment context. When a technician reports a failure on Pump 7, the system presents only the failure modes valid for that pump type's components. Root cause selections link to the maintenance procedures that address them. Historical failure records for similar equipment validate that the selected classification is consistent with past patterns. The classification becomes context-aware rather than a generic code list.

AI can perform context-validated failure classification — confirming that the technician's selection is consistent with the equipment type and historical patterns. Can identify misclassifications and suggest corrections.

Formalize the classification as a machine-readable FMEA ontology — define the complete relationships between equipment types, component hierarchies, failure mechanisms, root cause physics, and maintenance interventions with formal logic that AI can traverse and reason over.

L4

The failure classification is a formal FMEA ontology with machine-readable relationships. Every failure mode maps to specific degradation mechanisms, physical root causes, detectable precursor signatures, and effective preventive actions. An AI agent can ask: 'for bearing contamination failures on high-speed spindles, what are the detectable vibration signatures that precede the failure by 2-4 weeks, and what maintenance actions have the highest prevention success rate?' and compute the answer from the formal ontology.

AI can perform comprehensive reliability engineering from the formal failure ontology — automated root cause analysis, failure prediction from precursor signatures, and optimized maintenance strategy selection.

Implement self-evolving taxonomy — when new failure modes are encountered that don't fit existing categories, the system proposes taxonomy extensions based on the failure characteristics and similar patterns.

L5

The failure classification taxonomy is self-evolving. When a failure occurs that doesn't match existing categories, the system creates a provisional new failure mode, links it to the equipment and conditions, and seeks similar patterns across the fleet. When enough similar incidents accumulate, the system proposes a formal taxonomy addition. When failure modes become obsolete (equipment retired), the taxonomy prunes itself. The classification system grows and adapts with the maintenance operation's learning.

Fully autonomous failure classification management. AI maintains a self-evolving taxonomy that discovers new failure modes, validates existing classifications, and optimizes the classification structure from operational data.

Ceiling of the CMC framework for this dimension.

Capabilities That Depend on Failure Mode Classification Rule

Other Objects in Maintenance & Reliability

Related business objects in the same function area.

Maintenance Work Order

Entity

The transactional record that authorizes and tracks a maintenance task — containing the target asset, problem description, work type (corrective, preventive, predictive), priority, assigned technician, parts consumed, labor hours, completion status, and root cause code upon closure.

Spare Parts Inventory

Entity

The managed stock of maintenance, repair, and operations (MRO) parts — including part numbers, criticality ratings, on-hand quantities, reorder points, lead times, interchangeability data, and the mapping of which parts serve which equipment assets.

Maintenance Procedure

Entity

The step-by-step instructions for performing a maintenance task on a specific asset type — including safety lockout/tagout requirements, tools needed, parts lists, torque specifications, inspection checkpoints, and expected completion time maintained by reliability engineers.

Equipment Failure History

Entity

The structured record of every equipment failure event — capturing failure date, asset identity, failure mode, root cause classification, affected components, time to repair, production impact, and the corrective action taken, linked to the associated work order and inspection findings.

Lubrication Schedule and Specification

Entity

The managed program defining lubrication requirements for each asset — specifying lubricant types, application points, quantities, frequencies, condition monitoring thresholds (viscosity, contamination), and the route maps that lubrication technicians follow on their rounds.

Equipment Health Score

Entity

The composite condition index maintained for each critical asset — aggregating sensor readings, inspection results, failure history, age, operating hours, and maintenance compliance into a normalized health score that reliability engineers use to prioritize attention and predict degradation trajectories.

Repair-versus-Replace Decision

Decision

The recurring judgment point where maintenance and engineering evaluate whether to repair a degraded asset or replace it — weighing remaining useful life estimates, cumulative repair costs, replacement lead time, production impact, and capital budget availability against defined thresholds.

Maintenance Priority Decision

Decision

The recurring judgment point where maintenance planners determine which work orders to execute first given constrained labor, parts, and production windows — applying criteria such as asset criticality, safety risk, production impact, regulatory deadline, and health score degradation rate.

Preventive Maintenance Schedule Rule

Rule

The codified logic that determines when preventive maintenance tasks are triggered for each asset class — including time-based intervals, usage-based thresholds (run hours, cycle counts), condition-based triggers, and the escalation rules when PMs are deferred beyond acceptable windows.

Work Order Lifecycle Process

Process

The end-to-end maintenance workflow from work request initiation through planning, scheduling, execution, quality check, and closure — defining approval gates, parts staging requirements, permit-to-work handoffs, technician sign-off steps, and the feedback loop that updates failure history and health scores upon completion.

What Can Your Organization Deploy?

Enter your context profile or request an assessment to see which capabilities your infrastructure supports.