“How long until this actually tells us something” is a fair question to ask before a pilot starts, and the answer isn’t the same for every model. Some findings show up within a day of a machine reporting. Others need a full week or more, not because Spall is slow to react, but because the underlying pattern simply isn’t there yet in less data than that, and showing a guess before it exists would be worse than showing nothing.
Day one: the machine has to be seen at all
Nothing learns from a machine that isn’t reporting. The floor for anything at all is a working connection, at minimum a run/stop signal so Spall knows when the machine is on and producing. That’s true whether the connection comes through a PLC, an MTConnect agent, or a current-sensed clamp on a machine with no controller to talk to, the model doesn’t care which. What it cares about is a steady stream of readings, not a burst followed by silence.
Day one to two: the first real numbers
Once telemetry is flowing, an availability model and a production-rate model, if a part counter exists, both need roughly a day of observed running time before they’ll say anything. That floor is deliberately close to what a person would need to eyeball a “normal” pace themselves, not an arbitrary number picked for the demo. Below it, the machine’s own page says plainly that it’s still learning, not a guess dressed up as a finding.
A raw sensor reading, temperature, pressure, needs about thirty samples before its own drift detector will trust a band around it, which on most polling intervals happens well inside the first day too. A brand new machine doesn’t have to sit through any of this alone if a similar machine on the same floor already has a learned pattern, Spall can start it off borrowed from that machine, clearly labeled as such, until its own history takes over.
Mid week: patterns that need repetition
Downtime risk needs at least three completed, reason-coded stops of a given kind before it calls that reason a recurring pattern instead of a coincidence. That floor is about repetition, not calendar time, a line that stops often will clear it inside a day or two, a line that rarely stops might take the better part of a week. The same logic governs a golden-run pace reference: twenty total timed cycles, minimum, with the fastest ten-cycle stretch among them becoming the reference. A machine running a thirty-second cycle clears that floor in minutes. One running a fifteen-minute cycle takes most of a day just to accumulate the cycles, longer to have enough history for the comparison to mean something.
What this actually asks of a floor, practically
None of the floors above ask for configuration work. They ask for two things a floor already does, or should be doing regardless of whether AI findings are part of the plan: keep the connection live, and code stops with real reasons as they happen instead of leaving them blank. A telemetry feed that drops out for hours resets the clock on whatever model was building toward its floor. A week of stops left uncoded means downtime risk and precursor patterns have nothing to learn from no matter how much raw downtime accumulated underneath them, the context density figure on the Opportunities page exists specifically to show how much of a window’s downtime carries a real reason, so a plant can see that gap before it becomes a surprise later.
Patterns that take longer than a week, by design
Alarm-sequence and numeric precursor patterns need several qualifying events before a pattern earns a card, three stops of a given reason at minimum, and the alarm code has to have actually preceded at least half of them. A reason that only comes up once a month will take months, not because the model is being cautious for its own sake, but because three occurrences of a monthly event really does take a quarter to accumulate. The failure-risk estimate on the Maintenance page sits at the far end of this same curve: it needs at least five real failure-to-repair cycles, deduplicated and floored at a real duration, before it will show a percentage at all. On a well-maintained machine that rarely breaks, that’s a feature working as intended, not a gap. A machine that fails often enough to have five real cycles inside a pilot window is exactly the machine where a percentage is most useful, and one that doesn’t is, by definition, not costing much in unplanned failures yet.
What shortens the wait, and what doesn’t
Adding more machines doesn’t speed up any individual machine’s own clock, each one’s floors are measured against its own history, not a fleet total. What does help is exactly what already helps every other part of Spall: connecting a similar machine sooner, since a new one can borrow a comparable machine’s fit as a starting point instead of sitting silent, and coding stops accurately from the first day rather than catching up on a backlog later, since a week of blank reason codes contributes nothing to the downtime-risk or precursor floors no matter how much raw downtime happened underneath them. Neither of those is a configuration project. Both are just doing, from day one, what a floor would eventually want to be doing anyway.
What to check in week one
The Models panel on any machine’s page is the plainest read on where it stands: every signal it reports, which model fit it, and how many samples that fit is built on, updated every hour. A machine still short of a floor says so directly instead of a blank screen implying nothing is happening. Checking that panel a few days into a connection tells you more about what to expect than any fixed calendar would, because the real answer depends on how fast that specific machine cycles and how often it actually stops, not a number stated in advance.
Quick recap
- Nothing learns without a live connection. A run/stop signal is the floor for anything at all.
- Availability, rate, and raw-sensor drift models need roughly a day of real running time or about thirty readings, whichever their signal calls for.
- Downtime risk and golden-run pace references need repetition, three coded stops or twenty timed cycles, which can take a day or the better part of a week depending on how often the machine stops or cycles.
- Precursor patterns and the failure-risk estimate need several real qualifying events, sometimes well past a single week, and that’s the model working correctly on a machine that doesn’t fail often.
- The Models panel on each machine’s page shows exactly where it stands against every one of these floors, updated hourly, no calendar guess required.