A Fanuc control and a Siemens control name their signals differently, structure their alarms differently, and expose part counts through entirely different mechanisms. A model that learned to recognize “counter” by matching a tag name against a list built from one brand’s conventions would work on that brand and misfire on the next one without anyone noticing until the numbers looked wrong. Spall’s autoML avoids that trap by deciding what a signal is from what its values actually do, not from what it happens to be called.
The problem a name-based model runs into
Picture a molding machine whose shot counter is wired up as a plain numeric reading instead of being explicitly tagged as a counter, which happens more often than it should across real installs. A drift detector that trusts the tag’s declared role alone will treat that shot counter like any other continuous reading, temperature, pressure, and try to fit a band around it. A cumulative counter has no band. It climbs forever. The detector ends up comparing today’s count against an average built from a week of ever-increasing numbers, and produces a finding that reads like “expected 1.5 billion, observed 268 million,” a real bug this exact shape caused before the check that fixes it existed.
That failure isn’t specific to one machine or one tenant. Any counter that slips through without its role correctly set will hit the same wall, on any brand, on any protocol. The fix that closes it has to look at the data itself, not at who mislabeled what.
Three checks, none of them name-based
Before a raw signal is allowed into the pool of things a band-drift model can fairly learn from, it has to clear three independent checks, and failing any one of them is enough to exclude it.
Quarantine. A newly discovered signal that nobody, human or a confident automatic guess, has classified yet stays invisible to every learning and reporting surface until it has a real purpose. That’s the ordinary starting state for anything new, not an error, and it applies before either check below runs.
Role. A signal purposed as a run state, a part counter, a program selector, or an alarm code is excluded regardless of its tag name, because none of those is a continuous reading with a stable center and band, a run flag toggles, a fault code either fires or it doesn’t. This reuses the exact same purpose test the platform’s own capability math already relies on elsewhere, so a signal’s continuous-or-not answer is decided in one place, not reinvented per feature.
Shape. This is the check that catches what role alone misses: a signal purposed as something else entirely, a process variable, a generic reading, whose raw values still climb without ever really going down. Spall tests the actual numbers: if at least 95% of consecutive samples in the training window are flat or rising, with any drop to near zero read as an allowed reset instead of a violation, a counter rolling over or getting re-armed still counts as counter-shaped, that signal is excluded from band-drift fitting no matter what its role says. The reset allowance itself has a cap: it only applies when resets are rare. A load signal that idles at zero and jumps to a running value dozens of times a day, a machine’s power draw, climbs and drops constantly, and that constant dropping is exactly what tells the shape test it’s a load reading, not a counter, so it stays eligible for drift scoring instead of getting excluded by mistake.
Watching this live, not just at the next retrain
Models retrain hourly, but a signal can newly earn one of these three exclusions in the gap between retrains, someone finally classifies a stray signal, or a fresh stretch of data reveals a counter shape that a thinner earlier window didn’t show clearly enough. Instead of letting a stale model keep scoring against live readings for up to an hour, Spall re-checks quarantine, role, and shape at every five-minute scoring pass too, on the exact points it’s about to score. The instant any check trips, that model gets retired and its open insight, if it has one, withdraws in the same motion a person dismissing it would trigger, with the specific reason recorded: reclassified as a counter, excluded by role, or still quarantined. The next scoring cycle doesn’t get a chance to re-fire it either, the model itself is gone, not just the card.
What happens to a model that was already fit against a bad signal
The three checks above don’t only apply going forward. An earlier retrain can have fit a band model against a signal before any of the three exclusion reasons applied to it, before someone classified it, before a shape test existed at all, or before a later stretch of data made the counter behavior obvious. If that model is still open and still scoring, the same retrain pass that newly excludes the signal also walks every currently open insight tied to a model on that exact signal and withdraws it, through the identical state change a person dismissing a card by hand would trigger, with a reason attached: reclassified as a counter, excluded by role, or still quarantined. The Insights page keeps the full history of that card, it doesn’t vanish, it just reads as withdrawn with the reason stated, the same as any other resolved finding.
This matters because withdrawing the insight without also retiring the model underneath it would only hide the symptom. The next scoring pass would read live telemetry against that same stale, wrongly-fit model and produce the exact same nonsense finding a few minutes later. Retiring the model itself is what actually closes the gap.
Cross-gateway signals get the same treatment
Not every signal Spall reasons about was measured by the same device that owns the asset it describes. A derived signal, one computed in the cloud from other readings rather than read directly off a controller, can carry a different device identity than the asset’s primary connection, especially when the calculation spans more than one gateway. None of the three checks above care about that distinction. A derived signal is matched to its asset the same way a directly-read one is, and it goes through quarantine, role, and shape exactly like any other candidate, because none of those three checks has anything to do with where a number came from, only what it does.
Why this is the actual point
None of the three checks above reference a brand, a protocol, or a tag-naming convention anywhere. A press wired over EtherNet/IP, a lathe over MTConnect, and a sensor bus over Modbus all get judged the same way: what do this signal’s values actually do. That’s a deliberate design choice, not an accident of how the code happened to get written, because a model that secretly depends on one vendor’s tag conventions is a model that breaks the moment a different floor, a different integrator, or a different naming habit shows up, and breaks in a way nobody would catch until an insight stopped making sense. What Spall’s AI Learns From Your Machines covers the model zoo this feature selection feeds into, and How to Use the Signal Inbox covers where a newly discovered signal gets its purpose set in the first place.
Quick recap
- A drift model only fits a signal that clears three checks: it isn’t still quarantined, its role isn’t a state, counter, program, or alarm code, and its raw values don’t climb like a counter.
- The shape check exists because role alone misses a signal that was purposed as something else but still behaves like a counter underneath, a real bug this exact gap caused before the check existed.
- A signal that idles at zero and climbs to a running value repeatedly, a load reading, stays eligible for drift scoring, since frequent drops are the opposite of counter behavior.
- All three checks are re-run live at every scoring pass, not just at the next hourly retrain, so a newly excluded signal stops being scored within minutes, not up to an hour later.
- None of this depends on a tag’s name, a brand, or a protocol, the same three checks apply to every signal on every controller Spall connects to.