What a Golden Run Is covers the concept: the fastest pace a machine has actually sustained, used as the reference instead of a spec sheet number nobody’s ever matched. This guide covers the part that runs automatically underneath it, how the AI finds that pace on its own, keeps it current, and watches every new cycle against it without anyone setting anything up.
Finding the cycles in the first place
Before anything can compare a cycle to a golden run, it needs a reliable way to know where one cycle ends and the next begins. Spall looks for whichever signal an asset actually has, in order: a part counter ticking up, a machine that reports each finished cycle on its own, or, when neither exists, the run signal going from stopped to running again. Whichever source fires is recorded alongside every cycle it produces, so a comparison never mixes cycles that were detected two different ways.
Every completed cycle gets stored with its duration, which of those three sources found its boundary, and, when the asset was running a specific job or program at the time, which one. That last piece matters because a die-cast cell running two different molds has two different paces in practice, and folding them into one number would blur both. Alongside duration, each cycle also carries the mean, peak, and low reading of any setpoint, load, or process-variable signal on the asset during that window, plus an alarm count and a reject count where a reject-purpose signal exists, so a cycle isn’t just a duration, it’s a small bundle of what the machine was actually doing while it ran.
What makes a run “golden”
Among every stretch of ten consecutive cycles in a machine’s recent history, the AI looks for the one with the lowest typical duration, the fastest sustained pace the machine has actually held, not one lucky cycle sitting in the middle of a slower run. That stretch becomes the golden run for this machine, or for this machine running this specific job when the data supports keying it that way.
There’s a floor before any of this fires: twenty total timed cycles in the training window, minimum. Below that, the model states plainly that there’s not enough history and produces nothing, instead of calling three fast parts in a row a proven pace. A brand new machine, or one whose part counter just started reporting, sits in that state plainly until it clears the floor.
Watching drift, continuously
Once a golden run exists, every retrain compares the asset’s most recent cycles, the trailing day, against that reference median. A gap only becomes a finding when it’s real and sustained: at least 5% slower, and backed by at least three recent cycles, not one long part dragging an average down. Below either bar, nothing fires, a single slow cycle is not a trend.
When it does fire, the insight carries the golden median duration and the raw recent cycle durations together, so the Insights page can draw the same small chart What a Golden Run Is describes, the golden pace as a line, recent cycles plotted against it, right on the card. The dollar figure attached to it is built the same way every other priced finding in Spall is: the extra seconds per cycle, times the pace of cycles the machine is actually running per week, times its resolved cost rate, with that rate’s source stated next to the number.
A day-one reference for a brand new machine
A machine connected this morning has no cycle history of its own, which would normally mean no golden run for weeks. When a similar machine already has one, running the same job or a program with a matching key, wired with a comparable set of signals, and rated close to the same nameplate speed, Spall starts the new machine off with that machine’s golden run as a borrowed reference. Every insight built on it says so directly, something like “running slower than its best run, borrowed from CNC #1 until this machine has its own cycle history.” The moment the new machine’s own cycles clear the twenty-cycle floor, its own fit takes over automatically and the borrowed label disappears from anything scored after that point. An insight already open when that happens keeps the wording it fired with, it doesn’t get silently rewritten under a reader’s feet.
Reading the gap once it fires
A cycle-drift finding is a starting point for a conversation on the floor, not a verdict on its own. The same machine, the same program, the same golden pace, can run 8% slower for reasons that have nothing to do with anything being wrong: a tool nearing its change interval, a different lot of material, an operator override left on from a prior shift, or a different part variant that was never going to hit the same pace as the one the golden run was keyed to. The insight’s job is to point at where to look, a small chart showing exactly how far off the current pace sits and since when, not to diagnose the cause on its own.
That’s also why the golden run stays keyed by product or program where the data supports it, instead of lumping everything a machine ever runs into a single number. A press that alternates between two dies has two different fastest paces in practice, and a drift finding on one die’s cycles should never get compared against the other die’s golden run just because they share the same machine.
What the dollar figure is built from
The cost side of a cycle-drift finding uses the same resolved rate every other priced finding in Spall draws from, not a separate calculation invented for this one detector. Extra seconds per cycle gets multiplied by how many cycles the machine is actually running per week right now, not a theoretical maximum, then by the machine’s resolved cost-per-hour rate. The card names where that rate came from, a configured value, a bill of materials figure, or the platform’s own default, the same disclosure Machine Monitoring ROI: A Worked Example walks through for the value-discovery board this finding also feeds into.
Not the same golden run as a recipe snapshot
Spall has a second, unrelated feature that also uses the words “golden run”: a captured snapshot of every setpoint value during a machine’s best-known window, used to catch configuration drift, three of seven setpoints differ from the best-known recipe. That’s a recorded configuration, taken on demand. The golden run this guide covers is a mined pace baseline, built continuously from cycle history with no capture step at all. They answer different questions, what was set versus how fast it actually ran, and share no code or data behind the scenes. If a finding on your floor references setpoints instead of cycle duration, that’s the other one.
Quick recap
- Cycle boundaries come from whichever signal an asset has: a part counter, a self-reported cycle tick, or a run-signal edge, recorded with every cycle so comparisons never mix detection methods.
- The golden run is the fastest ten-consecutive-cycle stretch a machine has actually sustained, mined from at least twenty total cycles, never one lucky part.
- Drift only becomes a finding when it’s at least 5% slower and backed by several recent cycles, priced through the same cost-rate basis every other dollar figure in Spall uses.
- A new machine can start from a similar machine’s golden run as a labeled, temporary reference, until its own history clears the floor and takes over.
- This is a different feature from the setpoint-snapshot “golden run,” which captures configuration, not pace, on demand rather than continuously.