Your Model Found an Interaction, Your Picture Showed Parts

The model was right and the room was not persuaded

Our line optimization work runs on a digital twin. We take CAD files, scan the facility with lidar, add photo scans where the geometry is awkward, and put trackers on the lines so the downtime inside the model is the downtime the line actually had. Four input sources, and the back end of it is solid. What comes out the front is a floor drawn as blocks with line data attached.

It does the job, and it is the weakest part of the work. When the model concludes that four people come off a line, that conclusion lands against a picture which is visibly not that line. I have said so out loud while presenting one: I know that is not exactly what your line looks like. The operations leader in the room knows it too. From that point the number is carrying the weight of the picture as well as its own.

I sat down with a simulation engineer whose company builds physics environments for training robots, to find a way to close that gap. The useful part of the conversation was not the tooling. It was the realization that the gap is not cosmetic.

A block diagram cannot draw the thing the model found

Throughput is governed by interaction, not by the capability of any one station. That is the entire reason to build a twin instead of a spreadsheet. A spreadsheet can hold a rate. A twin computes what happens when a changeover upstream runs long while the station downstream is staffed for a rate it will never be fed, and it computes it across a whole run, not at the moment someone was standing there with a stopwatch.

So the finding a twin produces is a statement about a relationship. Two operators at this station are paid to wait because of what the station before them does during a format change, and the person who looks idle is the one holding the line together. That is the value of the model. It is also the one thing a block diagram cannot render, because the relationship is not an object in the plant. It is something the model computed over time. The artifact performs a silent conversion: a relationship goes in, and a list of per-station claims comes out.

Watch what a room does with a list of per-station claims. It audits them one at a time, using the best instrument the plant owns, which is the judgment of people who have run those stations for years. Station by station that judgment is excellent. It will tell you correctly that the packer cannot run faster, that the operator at the seamer is not idle, that nights is already short. Every rebuttal is true. The finding was never a claim about an individual station. It dies anyway, and it dies looking like it was wrong, which is the expensive part.

Robotics simulation carries the opposite discipline. Fidelity is the product there, because a policy trained in a loose environment fails the moment a real gripper touches a real part, and that failure is visible on video. In plant work we tolerate loose fidelity because the output is a presentation, so we pay for it in decisions that quietly revert rather than in equipment that visibly crashes.

The same pressure shows up in sequencing. On one engagement, the task to build the line simulation sat blocked for weeks behind a predecessor that tracked realized savings from work already delivered. That ordering is defensible on paper. It is also what happens to a deliverable whose payoff is hard to picture: it loses every scheduling argument to work that presents itself cleanly. A model nobody can show gets built last.

Build the picture the decision has to survive

The decision in front of a labor finding is narrow. Reallocate the crew on that line, or staff to the current arrangement and stop paying to study it. It belongs to the operations leader who owns that line's schedule, with the model owner in the room to answer questions, and it does not belong to whoever is holding the deck.

What has to change is the deliverable, not the model. Three requirements. State the finding as a relationship with its stations named, so nobody can accept it as a claim about one block. Show those stations in a single view with the dependency between them drawn, so the question a skeptic wants to ask has somewhere to point. Carry the result as a range across the run conditions tested, with the conditions listed, so the first bad shift falls inside the stated envelope instead of refuting the work.

My rule here is narrower than it sounds. I do not bring a modeled number into a room where the picture cannot carry the question. If the person who has to move people cannot point at the place where the hours come out and ask what happens when the upstream format change runs late, the number is not ready to present, however good the model is. That is a constraint on sequence, not on ambition. Build the view, then bring the number.

It also argues for one capture. When the model and the picture are built from the same geometry, a question about the picture is answerable in the model before the meeting ends, and the answer is the same answer. When they come from two sources, every mismatch between what the picture shows and what the floor looks like becomes a reason to doubt the arithmetic, and reconciling them later costs more than capturing them together would have.

Then separate the states. An approved recommendation, a moved crew, and a verified result are three different things, and the model only gets credit for the third. The reallocation is captured when the hours appear as reduced paid overtime, an avoided hire, or redeployed time on a named line, measured over a full schedule cycle. Approval of the slide is not capture, and counting it as capture is how a model earns the record that gets it built last next time.

What a well run model review looks like

Each modeled finding reads as one sentence naming the stations whose interaction produces it. One view shows those stations and the dependency, drawn from the capture the model itself runs on. The result is stated as a range with the tested run conditions listed beside it. The decision maker asks a what-if during the review and gets a modeled answer before the meeting ends. The decision leaves the room with an owner, a date, and the single measure that will show whether the hours landed.

The test to run before your next readout

Open the last modeled deliverable you presented and find its central conclusion. Write it as one sentence that names every station it depends on. If that sentence needs two or more stations, and your picture showed them as separate blocks with separate numbers, the room never saw your finding. Redraw that one view before you present the number again.