The Simulation Gap Is A Data Problem Or A Physics Problem
A sliced-meat processor ran four fill lines under a shared cook system.
The line that looked broken was the cleanest one
A sliced-meat processor ran four fill lines under a shared cook system. We built a digital twin off a full year of their data and calibrated it to 98.2 percent accuracy against actual facility performance. Three of the four lines modeled above 98 percent. One line came back at 88 to 89 percent.
The instinct in that moment is obvious and wrong. The low line looks like the weak link, the candidate for a rebuild, the reason the numbers do not add up. So you start scoping a fix for it. But this line was not slow. Six to seven weeks of its OEE history read above 100 percent, which is physically impossible; a machine cannot run more than all of its available time. That was a counting fault in the data, not a performance fault on the floor. The line was fine. The instrument feeding the model was broken.
Two gaps that look identical and mean opposite things
When a model and the floor disagree, there are only two real explanations, and they point in opposite directions.
The first is a data-integrity artifact. The model is being fed measurement that never happened. An OEE week above 100 percent is the clean tell, but the softer versions, a sensor that double-counts, a downtime code that stops logging, a shift that never closed its record, do the same damage more quietly. The fix here has nothing to do with the equipment. You clean the input and the gap closes on its own.
The second is a system-interaction ceiling. The model is right, and the line genuinely cannot go faster, because something shared and downstream governs the real throughput. In this plant the cook system capped the entire site near 18M lb per year, about three times current volume, no matter how the four fill lines were tuned. You cannot line-optimize past a shared constraint. Optimize all four lines and you simply build a longer queue in front of the cook.
Confusing these two is where the money leaks. Treat a data artifact as a physics problem and you spend capital rebuilding a line that a broken counter made look slow. Treat a physics ceiling as a data problem and you keep tuning lines that feed a downstream resource already at its limit. Same symptom, a gap between the model and the floor, and two fixes that share nothing.
Which gap do you actually have
The sequence that separates them is cheap and repeatable.
Pull a year, not a month. Thirty days of data hides seasonality and hides intermittent faults. It was the full-year pull that surfaced the six-week counting error in the first place; a month-long sample would have shown a clean-looking line and buried the artifact.
Flag the impossible readings before you calibrate anything. Any week where OEE crosses 100 percent is a broken counter. Quarantine it. Do not try to normalize it into something plausible; you cannot repair a number that describes an event that did not occur, and the effort spent smoothing it is worse than wasted because it launders the error into your baseline.
Calibrate to within 2 percent of measured baseline before you trust a single scenario. A twin that cannot reproduce today has no standing to tell you about next year. The 2 percent gate is what earns the right to run a scenario at all.
Name the true ceiling as a system resource, not a line number. Before pricing $1.4M of auto-loaders, the binding question was whether the shared cook could absorb the added output. If it cannot, the line spend buys queue, not throughput, and the payback you modeled evaporates against a constraint you never put in the same model.
Phase it even when the model says you can cut over. A one or two line trial with the new equipment proves the savings on real product before the whole floor commits. The model earns the capital; the trial earns the trust.
What a trustworthy twin reads
Every line clears 95 percent model accuracy and the whole facility sits within 2 percent of measured baseline. Impossible readings are quarantined, not smoothed. The binding constraint is stated as a system resource carrying a number, here the cook near 18M lb per year, and every proposed line investment is checked against that ceiling before it is priced. Data older than a month lives in the model; data younger than a week is reconciled against the physical counters, because the twin is only ever as honest as its worst week of input.
The line that looked like the problem was the cleanest one on the floor. The number was lying, not the machinery. And the real ceiling sat three rooms downstream, in a cook system nobody had thought to put in the same model as the lines.
ARTICLE TITLE: The Simulation Gap Is A Data Problem Or A Physics Problem