From production graph to confident decision

Step 1 · Build → Sketch what is.

Draw your production line node by node. Set rates, add buffers, mark decoupling points.

This is the step where modeling projects quietly go wrong. A graph drawn from a spec sheet describes the line the vendor sold you; a graph drawn from the plant describes the one you actually run. The difference does not show up here — it shows up three steps later as a model that is confidently wrong. What you want at the end of this step is a topology someone on the floor would recognize: the right machines, in the right order, with the buffers where they physically are.

Step 1 · Build → Parameterize what

im); margin:0;">Feed historian data to to find the right failure distributions.

Nominal rates are the easy part, and they are not what decides output. What decides it is how each machine actually fails — how often, for how long, and with how much spread. ReliaStats fits those distributions from your own event history rather than asking you to pick one, so every unit operation carries its own interrupt signature instead of a shared average. For a line that does not exist yet, the Interrupt Designer lets you choose the shapes deliberately, which at least makes the assumption explicit.

Step 2 · Validate → Validate against lor:var(--text-dim); margin:0;">Compare to your historian. Each point is an interrupt. On the diagonal = model matches reality.

This is the step that separates a simulation from an opinion, and it is the one most often skipped. Validation here is not a sanity check on the total: every interrupt is compared individually against what the historian recorded, and each should land on the diagonal inside its confidence band. A model that matches annual OEE while getting the individual failure modes wrong will still answer your questions — it will just answer them incorrectly, and you will not find out until the capital is committed.

Step 3 · Predict → Gain

nt-size:14px; color:var(--text-dim); margin:0;">Each machine is an actor with its own rhythm. When the ensemble performs together, blocking and starving emerge from the interaction.

Gain ≠ Loss is the part that surprises people, and it is the whole reason a loss report is not a plan. Remove a failure mode and you do not simply get its downtime back. Some of that loss was absorbed — the line caught up in a buffer, or the machine was starved during the stop anyway. Some of it was cascading into the machines downstream, so removing it returns considerably more than it appeared to cost. Which of the two you are looking at depends on where the failure sits in the system, and no ranking of losses can tell you. The simulation removes each one individually and re-runs the whole system to find out.