Detection an engineer can interrogate, not a black box that fires.

Why one method is never enough

A fixed threshold catches the excursion but not the drift. A statistical baseline catches the drift but not the combination. A multivariate model catches the combination but cannot say which physical limit is at risk. A trained model can predict a failure days out but only if it is explainable enough for an engineer to act on it. In-Sight runs all four and reconciles them, so a finding is raised once, with the strongest evidence attached, rather than four times from four tools.

• Self-recalibrating baselines, learned per signal and per operating mode
• Western Electric rules for shifts, trends, and oscillation
• Hotelling T² multivariate detection and correlation-breach detection across related tags
• Engineering limits extracted from datasheets and SOPs, armed on confirmation
• Trained models, deployed to live inference, with SHAP drivers on every prediction
• Momentary overshoot detection on high-rate signals at up to 2 kHz per tag

Machine learning that runs in production, not in a notebook

In-Sight trains models on the plant's own historian data, evaluates them against a held-out period, and deploys them to live inference from inside the platform. When a model's predicted risk crosses the line it becomes a finding like any other, with the SHAP drivers listed so an engineer can see which signals pushed the prediction and decide whether that is physically plausible. Drift checks run on a schedule and the model's live precision, measured against the verdicts operators record, is published next to its backtest.

That last point is the one most vendors skip. A model whose backtest precision was ninety percent and whose live precision is forty percent is a liability, and the only way to know is to measure it. In-Sight measures it.

Mode-aware, so planned change is not an anomaly

Plants change mode constantly: rate changes, product changeovers, start-ups, relines, campaigns. A baseline that does not know about them raises noise, and noise is how detection systems get switched off. In-Sight learns normal per operating mode and recalibrates on confirmed operator feedback, so a reduced-rate campaign is a different normal rather than a week of false findings.

A finding is the start of the loop, not the end

Every finding can be confirmed or disputed from the app or from the alert email, opened as an investigation with its evidence chain, dispatched as a work order with the evidence attached, and tracked for recurrence after the fix. Confirmations and disputes flow back into training and recalibration. The detection layer gets sharper with every decision the team records.

Questions we are asked

How does In-Sight explain a machine learning prediction?

Every prediction that becomes a finding lists its SHAP drivers: the signals that pushed the prediction and by how much. An engineer can check whether the drivers are physically plausible before acting.

What data does In-Sight need to train a model?

The plant's own historian data, backfilled through the connector, and the operator verdicts recorded on findings over time. Models are trained and evaluated inside the platform; no data leaves it for training.

How are false positives kept down?

Baselines are learned per operating mode, findings are reconciled across detection methods so the same event is raised once, and confirmations and disputes feed back into recalibration and retraining. Precision is tracked live so the trend is visible.

Can In-Sight detect momentary events on fast signals?

Yes. High-rate capture streams signals such as vibration at up to 2 kHz per tag and detects momentary overshoots at ingest, so a spike that a one-second historian would average away becomes a finding.

Related