An AI finding that gets acted on and never checked again isn’t much better than a hunch someone acted on. Spall closes that gap with a ledger that starts the moment a finding gets linked to a real action, a job, a work request, a dated note, and doesn’t report a result until a fair comparison has actually run.
What starts the clock
Linking an insight to an action is a deliberate step, not automatic. Someone reviews a finding, decides it’s worth acting on, replacing a worn part, adjusting a setting, retraining an operator on a step, and records that action against the specific insight or loss it addresses. That link is what opens a measurement window, a baseline period before the action and a matching outcome period after it, both the same length, both set before anyone knows how the comparison will turn out.
While that window is open, the linked item carries a Measuring badge with the date the result becomes available, instead of either an early verdict or a finding that silently disappears from view while it waits. There’s nothing to read yet, and the interface says exactly that.
What has to be true before the window even counts
A baseline built on too little running time isn’t a fair comparison, so the ledger requires a real floor of operating hours in both the baseline and outcome windows before it will compute anything, below that floor the entry comes back marked insufficient data, every value column left blank instead of a number computed on a window too thin to trust. The comparison is also normalized per operating hour, not raw minutes, so a machine that happened to run fewer hours in one of the two windows isn’t unfairly penalized or credited just for running less.
Watching for what else might have moved the number
A machine’s output shifts for reasons that have nothing to do with the fix someone just made, so the ledger scans the same outcome window for other things that happened on that exact machine: another job that ran, another work request raised, a changeover, a gateway configuration push, a change to the shift schedule governing that machine. Every hit gets named specifically, not folded silently into the number. An entry with three confounders listed next to it is still a real measurement, it’s a measurement with the context attached that lets a reader judge how clean the comparison actually is.
How to Verify a Fix Actually Held covers this same discipline in more depth, the windows, the confounders, when it’s fair to call a result zero. What the ledger adds on top is that the discipline runs automatically, every time, on every linked insight, instead of depending on someone remembering to check for a schedule change before presenting a number in a meeting.
What comes out the other side
Once the window closes, the entry lands in one of three states. Verified means the outcome period measured meaningfully better than the baseline, a real, positive delta outside normal noise. No change means the delta sits inside the range normal variation would produce on its own, the correct answer when a fix didn’t move the number, not a failure of the measurement process, calling it zero correctly is the process succeeding. Worse means the outcome period measured meaningfully worse, which happens, and the ledger reports it exactly as plainly as a win.
When a dollar figure attaches, and when it doesn’t
A verified or worse result gets dollarized only when the underlying rate has a real source behind it, a configured cost rate, a bill-of-materials figure, a resolved product standard. The platform’s own unconfigured default rate is explicitly not treated as good enough to price a ledger entry, that bar is stricter here than it is for a standard insight card, because a savings figure that ends up in a report to leadership deserves a rate someone actually set, not a generic fallback that was never a real choice. An entry that clears the measurement floor but has no qualifying rate still reports its result in raw terms, minutes saved, parts improved, with the dollar column left blank instead of a number built on a rate nobody stands behind.
An example, start to finish
A cycle-drift insight flags a mill running 9% slower than its golden run, with the evidence pointing at a tool nearing the end of its normal change interval. A technician swaps the tool and links that work order to the insight. The ledger opens a baseline window, the two weeks before the swap, and a matching outcome window, the two weeks after, both fixed before anyone can see how the numbers land. Partway through the outcome window, a different work request gets raised on the same mill for an unrelated electrical issue, and a changeover runs two days after the tool swap. Both show up as named confounders next to the eventual result, not folded invisibly into the number.
When the window closes, the mill’s per-cycle pace in the outcome period comes back close to its golden run again, a real, sustained improvement well outside what normal variation alone would explain. The entry lands as verified, priced against the mill’s configured cost rate, with the two confounders listed underneath so anyone reading it later can judge for themselves whether the electrical work or the changeover might have contributed anything, or whether the tool swap plainly accounts for the whole gap on its own.
Why this closes the loop the AI started
The whole point of an insight is that it points at something worth checking. The ledger is what turns “we think this helped” into a number a plant can actually stand behind, with its baseline, its window, its confounders, and its rate source all sitting next to the result instead of behind it. Machine Monitoring ROI: A Worked Example shows the same discipline applied to a pilot’s overall business case, this ledger is that same math run continuously, one linked action at a time, on your own floor’s own numbers instead of a worked example.
Quick recap
- Linking a finding to a real action, a job, a work request, a dated note, is the one manual step. It opens a fixed baseline-and-outcome measurement window before anyone knows the result.
- Below a real operating-hours floor in either window, the entry reports insufficient data rather than a number computed on too little running time.
- Every outcome window gets scanned for other things that happened on that exact machine, another job, a changeover, a config push, a shift change, and any hit is named, not hidden.
- A result lands as verified, no change, or worse. No change is the measurement working correctly, not a failed fix.
- A dollar figure only attaches when the rate behind it is a real, configured source, never the platform’s own unconfigured default.