Unsupervised and semi-supervised anomaly detection models trained on your normal equipment operating data -- not on generic equipment benchmarks that don't account for your specific machine configuration, operating loads, or ambient conditions. The model learns what normal looks like for your asset under your operating conditions, so anomaly detection is calibrated to your specific baseline rather than a population average. Model selection based on the number of sensors, sampling frequency, and the subtlety of the fault signatures: statistical process control (SPC/Western Electric rules applied to rolling windows of individual sensor channels) for single-sensor monitoring of simple assets where the failure signature is a gradual threshold drift; Isolation Forest for multivariate anomaly scoring where multiple sensor channels are monitored simultaneously and the anomaly is in the correlation pattern between channels rather than any single channel exceeding a threshold; convolutional autoencoder models for high-frequency vibration data (1-25kHz FFT spectra) where the fault signature is a change in the frequency domain that requires the model to learn the full spectral shape of healthy operation rather than tracking individual frequency bins. Each model outputs a continuous anomaly score (0-1) per inference cycle -- not just a binary alert. The score enables alert tiering: a score above 0.6 generates a watchlist flag for the maintenance team to increase monitoring frequency; a score above 0.85 generates a maintenance alert; a score above 0.95 generates an urgent work order. This tiered approach reduces false positives (which cause maintenance teams to stop trusting the system) while ensuring genuine developing faults are caught at the watchlist stage, not only when they become urgent. Anomaly scores logged to a time-series database (InfluxDB, TimescaleDB) alongside the raw sensor readings so post-fault analysis can review the full score trajectory leading up to a failure event.

Remaining Useful Life (RUL) regression models that estimate how many operating hours, cycles, or days remain before a specific failure mode is expected to occur based on the asset's current degradation trajectory -- giving maintenance planners a time horizon rather than just an alarm. The RUL model addresses the specific failure mode identified by the failure mode classifier (bearing wear, seal degradation, insulation breakdown) rather than producing a single aggregate life estimate for the whole machine. Degradation trajectory modelling using the Health Index -- a normalised 0-1 score derived from the relevant sensor features that tracks the progression from healthy (1.0) toward failure (0.0). The trajectory is fitted using exponential or polynomial degradation curves calibrated on historical failure sequences where the run-to-failure data is available; for assets without run-to-failure history, physics-informed degradation curves from equipment specifications and ISO standards (ISO 10816 vibration severity for rotating machinery) are used as the prior, updated with actual asset behaviour as data accumulates. Calibrated confidence intervals: the RUL output is not a point estimate but a probability distribution expressed as a P10/P50/P90 range -- the maintenance planner sees "P50 estimate: 18 days, P10-P90 range: 9-31 days", which tells them the urgency is real but there is a planning window. RUL predictions updated every inference cycle (typically 15-minute intervals for most industrial applications) as new sensor data arrives and the degradation trajectory is re-fitted to include the latest readings. When the P10 estimate falls below 7 days, the system escalates the alert urgency regardless of the anomaly score, because the confidence interval is now narrow enough that even the optimistic scenario is within the planning window. Parts and resource planning integration: RUL predictions connected to the maintenance planning system so spare parts can be pre-ordered before the predicted maintenance window, eliminating the scenario where the right diagnosis arrives at the right time but the parts are on a 2-week lead time.

Supervised multi-class classification models that identify not just that a deviation is occurring but which specific failure mode is developing -- because arriving at an asset with the wrong parts and tools because the fault was misidentified wastes the maintenance intervention and risks unnecessary downtime. Failure modes addressed by equipment class: for induction motors and rotating equipment, the classifier distinguishes bearing defects (inner race, outer race, ball defect -- each producing characteristic BPFI/BPFO/BSF frequency peaks in the vibration spectrum), rotor imbalance (1x vibration peak at running speed), shaft misalignment (1x and 2x peaks with axial vibration component), stator winding insulation degradation (partial discharge signatures in high-frequency current measurements), and fan blade damage (frequency peaks at 1x per blade count). For hydraulic systems, the classifier distinguishes pump cavitation (high-frequency acoustic emissions, irregular pressure pulses), internal leakage (flow/pressure relationship deviation), and contamination (particle count sensor trend). For electrical switchgear and transformers, the classifier addresses hot spots (thermography or distributed temperature sensors), partial discharge, and insulation breakdown. Feature engineering for classification: frequency domain features extracted from vibration spectra (peak amplitude at fault frequencies, frequency band energy ratios, sideband spacing), time domain statistical features (RMS, kurtosis, crest factor), and envelope analysis features -- the signal processing steps that convert raw sensor readings into the features that discriminate between failure modes. Model training approach when class imbalance is severe (many healthy examples, few examples of each failure mode): SMOTE oversampling for minor fault classes combined with class-weighted loss functions; physics-informed synthetic data generation for failure modes where historical examples are absent entirely. Classification output provides the failure mode probability vector, not just the predicted class, so the maintenance engineer sees "bearing outer race defect: 78% probability, imbalance: 15%, other: 7%" and can make an informed decision about what to inspect first.

Automated work order creation in your CMMS triggered when the model anomaly score or RUL estimate crosses the configured threshold for a specific asset -- the final integration step that converts a model prediction into a maintenance action without requiring a maintenance planner to monitor a separate predictive maintenance dashboard and manually create tickets. CMMS systems integrated via their published REST APIs or SOAP web services: IBM Maximo (via Maximo Application Framework REST API), SAP Plant Maintenance (via SAP RFC/BAPI calls or SAP Work Order Management REST API), Infor EAM (via Infor ION API), UpKeep (REST API), Limble CMMS (REST API), eMaint/Fluke Connect (REST API), and custom CMMS systems via generic REST or SQL-level integration. Work order content generated at alert time: asset identifier (matching the CMMS asset master record exactly to ensure the work order is visible against the correct asset history), fault type and failure mode from the classifier output, recommended inspection action mapped to a configured text template per fault type (bearing outer race defect maps to "Inspect bearing outer race, measure vibration spectrum, check lubrication"), alert severity level (watchlist/maintenance/urgent mapped to CMMS priority 1-3 or equivalent), and the sensor evidence that triggered the alert including the anomaly score, the specific sensor channels showing deviation, and the rolling 24-hour trend. Alert suppression logic: a second work order is not created for the same asset and failure mode if an open work order for that condition already exists in the CMMS -- preventing duplicate work orders from accumulating during sustained anomaly periods while the first inspection is pending. Work order feedback loop: when the maintenance engineer records the inspection outcome in the CMMS (confirmed fault, no fault found, different fault found), that outcome is written back to the model's training log to improve future classification accuracy.

Operational dashboard built for maintenance engineers and plant managers who need to act on the model's outputs without needing to understand the underlying ML -- the interface separates what to act on from the underlying model behaviour. Fleet health view: all monitored assets displayed as a grid with a health status indicator (green/amber/red based on anomaly score threshold), the current anomaly score, the P50 RUL estimate for assets with active degradation, and the count of open work orders per asset -- the 30-second scan that tells the maintenance manager which assets need attention today. Asset drill-down: clicking an asset shows the full sensor time series for the last 72 hours for the monitored channels, with the anomaly score overlaid so the correlation between sensor behaviour and the model's assessment is visible. The specific fault frequency markers (BPFI, BPFO, BSF for bearing defects calculated from equipment geometry) are optionally overlaid on the vibration spectrum to help engineers validate the model's failure mode classification against their own spectral analysis. Historical fault event timeline per asset showing the date and type of each prior alert, the RUL estimate at time of alert, the actual time to failure or inspection outcome, and the maintenance action taken -- the data that allows the maintenance team to calibrate their confidence in the model's predictions based on how accurate it has been on this specific asset. Fleet prioritisation view for maintenance managers: assets sorted by RUL P10 estimate (most urgent first) alongside the estimated cost of the failure mode if unaddressed (based on estimated repair cost + downtime cost configured per asset class) -- so when competing for a limited maintenance resource, the manager can prioritise by business impact rather than just technical urgency. Dashboard accessible on mobile for supervisors on the plant floor, with a simplified view showing only critical alerts and the current shift's pending work orders.

Automated model performance monitoring comparing prediction outcomes against actual maintenance inspection results to track precision and recall over time -- because a predictive maintenance model that was accurate at commissioning will degrade as equipment ages, operating conditions change, and new failure modes emerge that the original training data did not cover. Precision monitoring: of the work orders created by the model in the last 90 days, what percentage were confirmed as genuine faults during inspection? A precision rate below 60% indicates the model is generating too many false positives and will erode maintenance team trust. Recall monitoring: of the actual faults found during inspections (including planned maintenance inspections), what percentage were detected by the model before the inspection? Low recall indicates the model is missing developing faults that the sensor data should be capturing. Performance metrics broken down by asset type and failure mode so degradation in one failure mode classifier doesn't obscure acceptable performance in others. Model drift detection: statistical tests (Kolmogorov-Smirnov test on feature distributions, Population Stability Index) run on a weekly schedule to detect when the incoming sensor data distribution has shifted from the training distribution -- an early warning that the model is operating on data that looks different from what it was trained on, often caused by equipment modifications, operating condition changes, or sensor recalibration. Scheduled retraining pipeline: when performance metrics drop below configured thresholds or model drift is detected, a retraining job is triggered automatically using the expanded training set (original training data plus all new labeled examples from CMMS inspection outcomes). Retraining uses MLflow for experiment tracking so each model version is reproducible, and A/B comparison between the new model and the current production model is run on a held-out validation set before the new model is promoted to production. The maintenance engineering team receives a model performance report monthly showing precision/recall trends, drift indicators, and the outcome of any retraining performed in the period.