Anomaly Review and Maintenance Advisories

Anomalies become useful when they are reviewed in context. Predictive Maintenance should help maintenance teams understand what changed, which equipment is affected, what evidence supports the finding, and whether the next step is observation, inspection, or a work order.

Review Flow

Prerequisites

Requirement	Why it matters
Reviewed equipment identity	The anomaly must point to the right asset and location.
Health and signal evidence	Reviewers need the readings behind the anomaly.
Maintenance owner	A named team must accept, reject, snooze, or dispatch the advisory.
Work-order path	Accepted recommendations need a route to field execution.
Outcome policy	Closed work needs a feedback label for later review.

Source Data Inputs

Input	Use
Anomaly event	Carries affected equipment, timestamp, type, score, and severity.
Health snapshot and history	Shows whether the anomaly matches a broader degradation pattern.
Signal trend	Lets reviewers inspect the source readings behind the event.
Failure-mode catalog	Helps connect symptoms to likely maintenance causes.
Work-order and inspection history	Explains recent repairs, known issues, or repeated symptoms.

Start from the Anomaly List

Open /pdm/anomalies and review open items first.

Field	How to use it
Equipment	Confirms the affected asset and location.
Severity or level	Helps prioritize review order.
Anomaly type	Suggests the first diagnosis path, such as vibration, temperature, or operating deviation.
Score and threshold	Shows how far the current signal is from expected behavior.
Timestamp	Confirms whether the event is current, stale, repeated, or correlated with operating changes.
Resolution state	Separates open anomalies from reviewed or resolved ones.

The anomaly list is a triage surface. Open the equipment detail before making a maintenance decision.

Review Evidence Before Action

For each meaningful anomaly, check:

1. equipment profile and location;
2. latest health snapshot and health history;
3. raw signal trend for the affected signal;
4. recent work orders or inspections;
5. related alerts or operating-state changes;
6. likely failure mode and recommended action;
7. model readiness or rule state when available.

This review reduces unnecessary work orders and helps identify data-quality issues.

Advisory Decisions

Advisories should capture a traceable decision.

Decision	Use when	Required evidence
Accept	Maintenance action is justified.	Equipment, symptom, likely failure mode, action, priority, and owner.
Reject	The event is a false positive or irrelevant to maintenance.	Reason, reviewer, and source evidence.
Snooze	The item needs later review after more data, inspection, or an operating window.	Review date or condition, reason, and owner.
Resolve anomaly	The event has been reviewed and no longer needs open triage.	Resolution note and reviewer.

Failure Modes and Recommendations

Failure-mode context helps explain why an anomaly matters. Depending on equipment class and configured templates, the workflow may show likely fault patterns, signal contributions, and recommended field checks.

Example evidence	Review use
Vibration increase	Check imbalance, misalignment, looseness, bearing defect, or resonance.
Temperature trend	Check load, cooling, lubrication, airflow, fouling, or ambient condition.
Repeated alarms	Check whether a known operating mode or unresolved work order explains the pattern.
Recent maintenance	Check whether a repair, replacement, or calibration reset changed the baseline.

Create Maintenance Action

Accepting an advisory should produce an operational action:

1. confirm equipment and location;
2. choose recommended action or write an inspection request;
3. assign priority and response window;
4. create or link a work order;
5. preserve the advisory link for outcome feedback.

Use Advisory-to-Work-Order Closed Loop for the handoff and feedback process.

Expected Output

Each reviewed anomaly should end with one of these results:

• accepted advisory with owner, priority, and recommended action;
• rejected advisory with reason and reviewer;
• snoozed advisory with later review condition;
• resolved anomaly with resolution note;
• data-quality issue routed to the data owner.

Validation Checklist

• Anomaly is linked to a real equipment profile.
• Signal evidence is recent enough for the decision.
• Health state and model readiness are understood.
• Reviewer can explain the likely failure mode or data issue.
• Accepted advisories have owner, priority, and next action.
• Rejected or snoozed advisories include a reason.
• Work-order feedback will be captured after field action.

Troubleshooting

Symptom	Check
Anomaly lacks equipment context	Equipment profile, source mapping, and tenant boundary.
Severity looks too high or too low	Threshold, baseline, equipment class, and operating state.
Reviewer cannot explain the recommendation	Failure-mode mapping, signal contribution, and recent work history.
Advisory action is blocked	Work-order permission, maintenance owner, and CMMS route.

Related Docs

• Health Scores, Baselines, and Model Readiness
• Advisory-to-Work-Order Closed Loop
• Predictive Maintenance AI Tools
• CMMS With Facility Operations and Predictive Maintenance