---
title: "Failure Catalog"
description: "The failure catalog is the controlled vocabulary your floor uses to describe a breakdown."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.beelocity.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Failure Catalog

The failure catalog is the controlled vocabulary your floor uses to describe a breakdown. Free-text descriptions live on the work order for context, but the catalog codes are the part that powers Pareto analysis, repeat-failure detection, and reliability KPIs. Without a catalog, every breakdown is a snowflake and "what fails most often on our presses?" is unanswerable.

Beelocity ships a three-tier classification: **Problem → Cause → Remedy**.

## Problem codes

What was observed. Picked by the operator at work-request time, before any diagnostic. Each problem code has:

- A stable short identifier (the shipped catalog uses codes like `PROB-STOP`, `PROB-VIB`, `PROB-LEAK`).
- A human label.
- A default severity (H / M / L) — combined with asset criticality to compute the response tier on new requests.
- A description (what the operator would observe).
- Optionally, the asset classes this problem applies to — drives the dropdown filter so a forklift submitter doesn't see CNC-specific options.

Keep the problem list short — a dozen problems per asset class is usually enough.

## Cause codes

Why it failed. Picked by the technician after diagnosis. Each cause has:

- A stable identifier (the shipped catalog uses codes like `CAUSE-BEARING-WEAR`, `CAUSE-OVERLOAD`, `CAUSE-POWER`).
- A human label and description.
- A category — `WEAR`, `OPERATIONAL`, `EXTERNAL`, `DESIGN`, `INSTALLATION`, `UNKNOWN`. Drives the Pareto bucketing on the cause analysis report.
- Optionally, applicable asset classes.

Causes are typically many-to-one with problems: a single observed problem can have several plausible causes, and the technician picks which one actually happened.

Problem codes and cause codes pick their applicable classes the same way: one list of every asset class, and picking none means the code shows for every class.

## Failure mode mappings

For asset classes where you've published reliability data — CNC mills, hydraulic presses — the **failure mode mapping** narrows the cause picker on the technician's UI. A mapping says: "for the CNC mill class and the excessive-vibration problem, the relevant causes are bearing wear, misalignment, overload." The technician sees only the realistic list rather than the full vocabulary.

Mappings are optional, and you author them yourself — the shipped catalog seeds problem, cause, and remedy codes only, never any mappings, so a new organization starts with none. Classes with no mappings show the full filtered-by-class cause list until you curate your own pairs.

## Remedy codes

What was done. Picked when the work order closes. Each remedy has:

- A stable identifier (the shipped catalog uses codes like `REM-REPLACE`, `REM-REPAIR`, `REM-CALIBRATE`, `REM-CLEAN`, `REM-LUBE`, `REM-NO-FAULT`, `REM-ESCALATE-OEM`).
- A human label and description.
- A **Consumes parts** flag — on for replacement-style remedies. Closing with one asks the technician to confirm what went out.
- A `warranty_eligible` flag — false disqualifies warranty claims.
- A `no fault found` flag — marks a "nothing wrong" close, which feeds the no-fault-found-rate report.
- A **Manufacturer escalation** flag — marks a job sent back to the manufacturer or claimed under warranty, which feeds the warranty-exposure report.

The shipped catalog includes `REM-NO-FAULT` ("No fault found") as a first-class remedy so you can track spurious calls — a rising no-fault rate flags either over-reactive reporting or a vague problem catalog — and `REM-ESCALATE-OEM` for jobs handed back to the manufacturer under warranty.

Each catalogue list narrows on its **filter button** ([Working with lists](../getting-started/working-with-lists.html#narrowing-the-list)): all three on **Code** and **Name**; problem codes also by **Default severity** and **Active**; cause codes by **Category**, **Source** and **Active**; remedy codes by any of their five flags — **No fault found — Yes** is the spurious-call sweep, **Manufacturer escalation — Yes** the warranty hand-offs.

## Picker UX

The UI never shows the entire catalog at once:

- **Problem picker** on work-request creation: filtered to the asset's class.
- **Cause picker** on diagnosis: filtered first by failure-mode mappings; falls back to class-based filtering when no mapping exists.
- **Remedy picker** when a work order closes: filtered by its flavour — `BREAKDOWN`, `CORRECTIVE`, and `DISPOSAL` show the full list; `PREVENTIVE`, `INSPECTION`, and `CALIBRATION` show a reduced list of remedies that don't consume parts (adjust, clean, lubricate, calibrate, no-fault-found) because the typical preventive close doesn't need the full breakdown vocabulary.

## Reports

The codes drive a small set of canned reports:

- **Top problems by asset class** — the Pareto of what's breaking, last 90 days.
- **Top causes by problem** — tells engineering whether a vibration problem is mostly bearings or mostly installation.
- **No-fault-found rate** — the share of breakdown work orders closed with a "no fault found" remedy (e.g., `REM-NO-FAULT`). A rising rate flags either over-reactive reporting or a vague problem catalog.
- **Warranty exposure** — count (and cost) of breakdown work orders that happened while the asset was still inside its warranty window but were repaired in-house instead of being escalated to the manufacturer (e.g., with `REM-ESCALATE-OEM`). The money you left on the table by fixing it yourself when the manufacturer was on the hook.

Source: https://docs.beelocity.com/en/maintenance/failure-catalog/index.mdx