Failure Codes & FMEA Basics
Failure codes are a controlled vocabulary for what failed (mode), why (cause) and what fixed it (remedy) — the raw material of every Pareto and every FMEA.
Failure codes only earn their keep if the discipline behind them is airtight — a mode picked at breakdown time is nearly worthless if cause and remedy stay blank once the job is closed. This is where most plants running spreadsheets or loosely configured CMMS lose the thread, and where a hard closure rule changes the outcome.
Where AssetAI Enforces the Discipline
A breakdown (BM) or corrective (CM) work order in AssetAI cannot move to Completed or Closed unless both cause and remedy are filled in, in addition to the mode captured by the operator at the moment of reporting. This isn't a soft warning — it's enforced in two separate code paths, so there's no route to a closed record with a blank cause. Free-text fields for root cause, action taken and closure remarks sit alongside the coded fields, giving technicians room to record detail the master list can't anticipate.
The practical effect: every closed BM/CM record carries a complete mode+cause+remedy triple. That triple is what feeds the downtime-cost Pareto in Analytics, ranking the top 8 assets by rupee cost and tracking failure count as a KPI tile. If your Pareto has ever been quietly wrong because half the records had an empty cause field, this is the mechanism that prevents it.
Note the scope: this gate applies to BM and CM work orders specifically. PM and PdM work orders follow a different workflow and aren't subject to this cause/remedy check — they're not failure records in the same sense, so forcing a cause field on a preventive task would be meaningless.
What This Is — and Isn't — Building Toward
It's worth being direct about scope here, because "failure codes" and "FMEA" get used interchangeably in plant conversations and they aren't the same thing in AssetAI:
- There's no severity/occurrence/detection scoring, no RPN calculation, and no FMEA worksheet anywhere in the product — if your team runs a formal FMEA process, it stays an offline exercise, in a workshop or a spreadsheet.
- Mode, cause and remedy are always chosen by a person from your company's master list — nothing is auto-classified from a photo, a text description, or a sensor reading.
- A recorded failure doesn't feed a risk register or trigger an engineering-change review; there's no design-FMEA linkage.
- The master lists themselves are maintained by company/plant admins as a controlled vocabulary — there's no separate taxonomy editor with versioning or approval workflow layered on top.
What AssetAI does give reliability engineers is clean input data: a history of closed failures where mode, cause and remedy are guaranteed to be present, ready to feed into whatever offline FMEA process your team already runs. One place this history pays off directly is the knowledge card feature, which lets a recorded fix be promoted into an asset's PM checklist as a line item — numbering stripped, duplicates skipped — so a past breakdown can inform a future preventive task without a manual rewrite.
If your plant is still deciding how failure history should feed OEE and downtime reporting, it's worth reading what a CMMS actually does and how it connects to OEE before you standardize a code list. And if you want to see the closure gate and Pareto working against your own asset list rather than a slide deck, book a 30-minute demo.
Failure codes are only as useful as the vocabulary behind them, and the vocabulary is only as useful as the discipline that keeps it clean once a workshop-level FMEA exercise or a Pareto review needs real data to chew on.
Building a Master List That Works on the Shop Floor
Company and plant admins own the mode/cause/remedy master lists in AssetAI — operators and technicians pick from this controlled vocabulary rather than free-typing descriptions, which is what keeps the Pareto in Analytics comparable across shifts, lines and plants. A few practical guidelines matter more than the tool itself:
- Keep mode entries specific to how operators actually describe a stoppage (bearing seizure, belt slip, sensor fault) rather than generic categories like "mechanical" or "electrical."
- Separate cause from remedy cleanly — cause explains why the mode occurred, remedy explains what was actually done, and mixing the two erodes the value of both fields.
- Review the list periodically against the free-text root-cause and closure-remarks entries technicians actually write; if the same explanation keeps showing up as free text, it belongs in the master list.
- Avoid over-engineering the list into a formal taxonomy with versioning or approval workflows — AssetAI doesn't offer that layer, and most Indian plants get further with a lean, well-maintained list than an elaborate one nobody keeps current.
This is a governance habit, not a one-time setup, and it's the same discipline plants relying on manual logs or loosely configured CMMS tools tend to skip — see What is a CMMS for the baseline this builds on.
From Closed Work Orders to an Offline FMEA
AssetAI does not run FMEA — there's no severity/occurrence/detection scoring, no RPN calculation, and no worksheet inside the platform. What it does produce is exactly the input a reliability engineer needs to run FMEA properly offline: a history of closed BM/CM records where every mode+cause+remedy triple is guaranteed complete, because closure is gated on it. Reliability engineers can export this history into a spreadsheet or bring it to a workshop, use failure counts and downtime-cost rankings from the Pareto as evidence for which modes deserve scoring first, and keep the scoring and risk-register work in whatever format their team already uses. If your organisation is standardising failure taxonomies against a framework like ISO's published standards, that mapping happens at the master-list design stage, not inside AssetAI — see ISO & standards for how AssetAI's data structures line up with common reference points.
From Failure History to Preventive Action
The one place a past failure directly shapes future maintenance is the knowledge card. When a fix is recorded against a piece of equipment, that fix can be promoted into the asset's PM checklist — numbering is stripped and duplicate lines are skipped automatically. This works at the granularity of a checklist line, not a structured FMEA action item with an owner and due date, so it's a modest bridge rather than a closed-loop reliability engine. Used consistently, though, it turns recurring corrective fixes into standing preventive steps without anyone re-typing them. To see how this fits alongside OEE and downtime reporting, check OEE explained, or book a demo to walk through the failure-code setup on your own asset list.
Failure Codes & FMEA Basics FAQs
How do I make sure technicians actually fill in the root cause before closing a work order?
AssetAI enforces a hard closure gate—a breakdown or corrective maintenance work order cannot be marked Completed or Closed unless both cause and remedy fields are filled. The gate is built into two separate code paths, so even if someone tries to bypass it one way, the system prevents closure the other way. This means every closed failure record in your system will have a complete mode, cause, and remedy triple that feeds into your downtime-cost analysis.
Can AssetAI automatically suggest failure modes when a technician reports a breakdown?
No—AssetAI requires a human to choose the failure mode from your company's master list at the point the operator reports the breakdown. There is no automatic classification from photos, sensor data, or free-text descriptions. The operator picks the mode first (before the technician even arrives), then the technician later adds the cause and remedy codes. This manual approach keeps classification honest and tied to your plant's own failure vocabulary.
What's the difference between failure mode and root cause in your system?
Failure mode is what broke or stopped working (e.g., "bearing seized"), while cause is why it failed (e.g., "inadequate lubrication"). AssetAI captures both as separate code selections from your master lists, plus free-text fields for root cause detail that the codes alone cannot express. The mode is recorded first by the operator at breakdown; the cause and remedy are added by the technician before closure, and both must be filled for the work order to close.
How do I turn a repair that worked into a preventive maintenance task?
AssetAI's knowledge cards let you promote the fix steps recorded in a closed failure work order into an asset's preventive maintenance checklist. The system strips out the work-order numbering and skips duplicate steps, so you extract only the actionable repair logic. This is the one real bridge in the product between a past breakdown and a future preventive maintenance task, letting you prevent the same mode from recurring.
Can I see which failures cost me the most downtime?
Yes—because every closed failure record is gated to have mode, cause, and remedy filled, AssetAI's Analytics module uses that complete triple to build a downtime-cost Pareto chart. The gate ensures no closed record has missing cause or remedy, so your Pareto is built on complete data. You can then rank failures by their cost impact and prioritize which modes and causes to address first through preventive maintenance or design change.
Does AssetAI include an FMEA worksheet or RPN scoring?
No. AssetAI does not have an FMEA module, severity/occurrence/detection scoring, RPN calculation, or FMEA worksheet templates. It is a failure recording and traceability system, not a predictive risk assessment tool. If your plant needs formal FMEA, you would conduct that separately and then use AssetAI's failure codes and knowledge cards to track how well your preventive actions reduce the modes and causes that FMEA identified as high-risk.
If I'm using failure codes in AssetAI, how do I know which ones to create for my plant?
Start with your most common breakdowns—spindle failures, pump cavitation, electrical shorts. Add codes for each asset type and failure pattern you actually see. Review your repair history from the last 12 months to identify recurring issues. Keep codes specific enough to be useful (not just "mechanical failure") but broad enough that technicians won't overthink classification during urgent repairs. You can refine codes quarterly as patterns emerge from your work order data.