What AI Can and Cannot Tell You About a Machine

An anomaly detector does one thing: it learns what a machine's signals look like during normal running, and it raises a score when new data stops looking like that. This is genuinely valuable. Machines drift into failure over days and weeks, and a model that watches every hour can notice a change long before the next manual measurement route comes around.

But be clear about what the score contains. A reading of 0.91 does not say bearing, does not say misalignment, does not say loose sensor cable. It says: look here. Naming the fault still takes physics — defect frequencies, envelope analysis, an analyst who knows what a 1x-spaced sideband means. An anomaly score is a prompt to look, not a diagnosis, and every deployment that treats it as more than that eventually gets burned.

Anomaly detection has no idea what a bearing is. 'Normal' is defined entirely by the data the model saw during training: those speeds, those loads, that season, that sensor in that mounting position. If the baseline was recorded in winter at one duty point, then a hot afternoon at a higher pump speed is, mathematically, an anomaly — the model cannot tell an unfamiliar operating condition from a fault, because both are simply 'far from what I learned'.

This is why the boring metadata matters as much as the waveform. Recording speed, load, and measurement setup alongside every capture — a tachometer or speed reference logged alongside simultaneous multi-channel sampling, the kind PhonoVibe's parallel-sampled inputs make straightforward — is what later lets you ask the only question that separates a false alarm from a find: did the machine change, or did the operating condition change?

Every anomaly system needs a threshold, and every threshold is a trade. Set it low and you catch faults early but flag every speed step and process change; set it high and the panel stays quiet until the fault is loud. The trend below shows the two events that matter: a sharp spike when the operating condition changed — over in hours, back to baseline, no fault — and a slow, sustained rise that keeps climbing week after week. The shape of the excursion carries more information than the fact of crossing the line.

False alarms are not free. Each one sends someone to a healthy machine, and each wasted trip spends a little of the team's trust. After enough of them, flags get acknowledged without being investigated — alarm fatigue — and the one alert that mattered dies in a full inbox. A practical rule: act on sustained trends, and check every alarm against the operating state before checking it against the machine.

There are two ways to feed a machine signal to a model. Hand it raw waveform windows and let a deep network find its own patterns — flexible, but data-hungry, and when the score rises nobody can say why. Or compute engineered features first — band energy, envelope-spectrum lines at bearing defect frequencies, crest factor, sideband ratios — and let a simpler detector watch those. The feature path usually detects a little later, but it fails in ways an engineer can inspect.

That auditability is worth a lot in practice. TVIB computes and exports exactly these quantities — narrowband FFT, crest factor, band and sideband cursors — so when an alarm fires you can open the feature that moved and see, for instance, that energy rose in the bearing band. The alarm stops being a mystery score and becomes the first line of the diagnosis.

A plant puts an anomaly model on a cooling-water pump, trained on three months of normal running. In summer, operations raises the VFD speed to meet load — and the score spikes. The baseline never contained that speed, so to the model the healthy pump at the new duty point is an anomaly. A technician walks out, finds nothing wrong, and the team retrains the baseline to include the new condition. That trip was the cost of a biased baseline, not a model bug.

Weeks later the score begins a slow, sustained climb with no matching change in operating state. This time the flag earns its keep: a technician connects a two-channel PhonoVibe D, and the narrowband spectrum in TVIB, read against the band and sideband cursors, shows non-synchronous lines at a bearing defect frequency. The fault now has a name, the repair gets scheduled instead of forced, and the division of labour is exactly right — the model prompted the look, the measurement and the analyst named the fault.

If you want the model to do more than say 'not normal' — to rank likely fault types, or estimate severity — you need training data where the fault is actually known, and in a working fleet that is the scarce resource: failures are rare by design (that is the whole point of maintenance), so collecting enough labelled examples of any one fault to train a classifier means living through a lot of unplanned downtime first. Scraped field data makes the shortage worse, not better: labels get assigned weeks after capture from work orders and teardowns, real failures mix several mechanisms at once, and speed and load drift between recording and inspection. A simulator reverses the order: on a TMFSS the fault is installed and documented before the signal is captured, the same defect can be repeated across speeds and loads, and the accelerated-bearing-wear kit lets you record a staged degradation sequence rather than a single good-or-bad pair. To-Learn Vibe trains the analyst side of that same problem: the trainee diagnoses a simulated fault against a known answer, building exactly the pattern-recognition skill an anomaly flag still needs once it reaches a human.

This post is the second half of a pair: the earlier note on building predictive-maintenance datasets, at /blog/ml-ai-predictive-maintenance, covers how that labelled data gets generated and captured; this one covers what the trained model can honestly tell you afterwards. For the theory underneath both, the free primers at 101.tieraonline.in include AI Condition Monitoring 101 — a free primer, not an accredited certification — and TIERA's formal TCAT programme, detailed at /services, adds structured coursework with proctored exams at exams.tieraonline.in.

TIERA does not sell a model that names your faults — after this post, you would not trust one that claimed to. What we build is the rest of the loop: a simulator that generates fault data where the label is set before the signal exists, a measurement chain that captures it (and your field data) consistently enough to compare, and the analysis and training tools that keep a human who can read a spectrum in the loop.

If you are building or buying anomaly detection, that is the part worth spending on first: ground truth to train and test against, capture you can audit, and an analyst who can turn a score into a diagnosis.