Concept

What Spall's AI Learns From Your Machines, and What It Does With It

A per-machine model forms automatically from telemetry, production, and downtime history already flowing in. What it learns, what it needs, and where it stays silent.

~8 min · Last reviewed September 13, 2026

Every machine on a floor already produces a pattern: a normal running fraction by hour of day, a parts-per-hour pace, a mix of downtime reasons that shows up week after week. Nobody writes that pattern down. It lives in the machine’s own history, buried under enough noise that a person scanning a trend chart won’t reliably spot when it changes.

Spall’s AI is built to read that history the moment it exists and keep comparing new readings against it. Nothing about a machine gets typed in first. A model forms from what the machine already emits, and it says nothing until it has enough of that history to be worth trusting.

Where the model comes from

Connect a machine and Spall starts collecting whatever it reports: a run/stop state, a part count, downtime events with their reasons, and any numeric readings coming off the controller, a temperature, a pressure, a spindle load. Each of those signals gets its own model, matched to what kind of signal it is.

A run/stop signal becomes an availability model: the fraction of each hour the machine was actually running, learned separately for each hour of the day, so a Tuesday morning gets compared against other Tuesday mornings, not against a Friday night shift with a different normal pace. A part counter becomes a production-rate model on the same hour-of-day basis. Downtime events, once there are a few, become a risk model: expected minutes lost per day, broken out by reason. Every other numeric reading gets a drift detector: a center value and a band around it, watching for a reading that has moved off its own learned range.

The loop that keeps every model current Telemetry to insight, on a loop Raw floor data status, counts, reasons Features per asset, per signal Fit, hourly a model per signal Score, 5 min against the model Insight, when it deviates A model retrains every hour and scores the trailing window every five minutes.
Fitting happens hourly so a model reflects recent behavior. Scoring runs every five minutes so a real deviation surfaces fast without treating one noisy reading as a finding.

None of this is picked by a person. Which model applies to which signal is decided by a rule, not a guess, run automatically the moment enough of that signal’s history exists. If you want to see the reasoning, the Models panel on a machine’s page lists every signal it learned, what kind of model fit it, and how many samples that fit is standing on.

What counts as enough history

A model that fires on three data points isn’t a model, it’s noise wearing a label. Every signal has its own floor before Spall will score anything against it. An availability or rate model wants at least a day’s worth of observed machine-hours before it trusts an hour-of-day pattern. A drift detector on a raw sensor wants at least thirty readings. A downtime-risk model wants at least three completed stops of a given reason before it calls that reason a recurring pattern instead of a one-off.

Below that floor, the machine’s page says so in plain terms: it’s learning, not producing an answer that looks confident but isn’t backed by enough data to mean anything. That line matters more than it sounds. A system that always has an opinion, even about a machine it saw for the first time an hour ago, is a system a plant manager learns to distrust the first time it’s obviously wrong. One that says “still learning” until it has grounds to say more earns the opposite.

A brand new machine doesn’t have to sit silent for days if a similar machine on the same floor already has a learned pattern. When a candidate donor machine is running the same product or program, wired with the same kind of signals, and rated close to the same nameplate speed, Spall borrows that machine’s fit as a starting point and labels every insight it produces with where the pattern came from, something like “running far less than its learned pattern, borrowed from CNC #1 until this machine has a day of history.” The moment the new machine’s own history clears its floor, its own fit takes over and the label disappears. No fabricated day-one confidence, just a reasonable starting guess that’s marked as one and gets replaced by the real thing as fast as the data allows.

What it flags, and what it costs

An insight is only useful if it says what changed and what that’s worth. A machine running below its learned availability pattern gets a dollar figure attached: the shortfall in hours times the resolved cost rate for that machine. A part-counter running slower than its expected pace gets the same treatment in parts. A recurring downtime reason gets priced by its expected minutes per day times the same rate.

A raw sensor drifting off its band doesn’t get a dollar figure, because there’s no clean way to turn a temperature reading a few degrees off its usual range into a dollar loss without inventing a relationship that doesn’t actually exist. That insight still fires, with the expected range and the observed reading spelled out, it just carries no price tag. A number only shows up where the math behind it is real.

What stays off the table

The model zoo behind this only ever compares a machine against its own history. When it goes further and estimates the chance of a failure, that estimate is built from the machine’s own count of past stops, with the count shown next to the number, it predicts from the machine’s own history and shows the evidence, and says not enough history when it has too little. It never writes anything back to a controller. The connection stays read-only end to end. How Spall Predicts a Failure covers how that estimate is built and what it takes before it will show one.

It also stops paying attention to a signal the moment that signal stops being the kind of thing a band model can fairly judge. A part counter that was accidentally treated as a continuous reading, or a signal nobody has classified yet, gets excluded from drift scoring instead of producing a nonsense reading that happens to be technically computed correctly. AutoML on Any Controller covers how that exclusion works and why it never depends on a tag’s name or the protocol it arrived over.

Where to see it

The Models panel on any machine’s detail page is the plainest view: every signal that machine reports, which model type fit it, when it last retrained, and how many samples that fit is built on. The Opportunities screen rolls the same findings up across the whole floor, dollar-ranked findings on top, everything else below with its own evidence attached. Neither view asks you to trust a black box. Every card names the signal, the window it was measured over, and the comparison that produced the number.

Quick recap

  • A model forms per signal, per machine, automatically, matched to what kind of signal it is: run state, part count, downtime reason, or raw reading.
  • Every model has a sample floor before it scores anything. Below it, the machine’s page says “learning” instead of guessing.
  • A brand new machine can borrow a similar machine’s fit for a day, clearly labeled as borrowed, until its own history clears the floor.
  • A dollar figure only appears where the underlying math is real: availability, rate, and downtime risk get priced. Raw sensor drift does not.
  • The comparison is always a machine against its own history, never a forecast, and the connection to the controller stays read-only.

Related guides

From the Help Center

$200/machine/mo · pilots from $4,500 · hardware included

See full pricing →

Bring your machine list. We'll tell you exactly what plugs in.

30 days, hardware included, line pilot $4,500 or plant pilot $8,500, fully credited when you expand.