Published 25 September 2026 · 7 minute read
Every plant has a run that went right. The paperwork was clean, the material behaved, nobody had to intervene. Then three weeks later the same recipe on the same machine produces scrap, and the question everyone asks is the same: what was different?
A golden run is that good run, kept. Not as a memory or a note in a logbook, but as the recorded process data for the whole run — every temperature, tension, speed and pressure, at the rate you logged it. Once you have it, a later run stops being judged only against fixed limits and starts being compared against something your plant has actually achieved.
Most quality systems check a measurement against a range. Zone two must sit between 180 and 190°C. Line tension must stay under a ceiling. That catches the obvious faults, and it is worth having.
What it cannot tell you is shape. A run where zone two sat at 189°C for the entire shift and a run where it drifted from 181 to 189 over four hours both pass the same check. They are not the same run. Neither is a run that dipped for ninety seconds during a splice and recovered before anyone looked.
A golden run keeps the whole trace. Comparing against it asks a different question: not was this number legal, but where did this run depart from the one that worked, by how much, and for how long.
The temptation is to build a golden run out of ideal setpoints. Resist it. A synthetic ideal has no noise in it, so every real run looks bad by comparison and people stop trusting the tool within a week.
A golden run should be:
This is where most tooling overclaims, so it is worth being blunt.
Production data is observational. You did not run an experiment. Setpoints were held deliberately still, because holding them still is the job. When signals barely vary and they move together, a statistical method will happily report that one of them explains your quality result — and it may be reporting the behaviour of the operator, the season, or the supplier, not the physics.
So the honest output of a comparison is a ranked list of the most likely factors: the signals whose departure from the golden run lines up with the results you did not want. That is genuinely useful. It turns "something changed somewhere" into "look at these three things first", which is often the difference between a morning and a fortnight.
It is not a root cause. Confirming a cause means changing one thing on purpose and seeing what happens — a trial, not a chart. Any tool that skips that step and offers to push a correction into the controller is selling you a guess with a confident voice.
ProcessIQ is the part of PulseMQ that does this comparison. It shows quality over time for a recipe, one point per unit of output, and lets you open a single failed one to ask why.
On that screen the golden run appears as a band around each signal, with the selected run drawn through it, so a departure is something you see rather than something you calculate. Alongside it is the ranked list of most likely factors. A numeric contribution only appears when the model actually holds up under cross-validation — below that bar the tool says it does not know, which is the more useful answer.
Periods outside the band are labelled outside golden range, not a failure window, because leaving the band is not the same as causing a failure. And there is no button that writes a correction back to the PLC. What there is instead is a trial planner: it proposes what to change, on purpose, so the next run tells you something the last thousand could not.
Rolls whose input material was never scanned read Unknown. They never match a golden run, because a run you cannot identify the material for is not evidence.
See it run. A one minute walkthrough of ProcessIQ comparing rolls against a golden run, alongside seven other short demos.
Watch the demosPick one recipe on one machine — the one that generates the most argument. Find a completed run whose output passed, and mark it. Then run the comparison on the next failure and see whether the ranked list points somewhere a person who knows the line would have looked anyway.
If it does, you have a tool that will save time on the ones nobody can explain. If it does not, you have learned something about your data rather than about your process, and that is worth knowing before you build a quality programme on top of it.