A Wrong Call on a Running Line Costs a Shift

One bad automated call on a running line can cost a shift of output or a whole batch. The risk is identical whether the call comes from a person or a tool: a fast decision, made under pressure, with nobody signing off and no record of why.

• Equipment failure is the largest cause of unplanned downtime. Roughly 42% of incidents (Siemens, True Cost of Downtime, vendor-reported).
• Alarm fatigue dulls the one that matters. A supervisor can spend much of a shift on alerts that turn out to be nothing.
• Night shift is where it bites. Thin staffing, fewer senior people, and no second opinion on a fast call.

Not every automated call needs a person. The ones that stop a running line do, and the layer decides which is which before anything moves.

• A sign-off desk between the call and the line. Routine, low-risk flags keep moving. High-consequence moves wait.
• The signal is checked before anything acts. Currency, range, cross-source agreement and actual machine state, so a stale reading cannot trigger a move.
• Hard limits on critical equipment. Nothing touches it without a person, whatever any tool decides.
• Plain-language record of every call. What the signal was, what was done, how it turned out, ready for shift handover.

This is not a question about models. It is a question about who is allowed to do what on a running line, answered once and enforced on every shift rather than re-argued at 3am by whoever is nearest.

• The routine tier. Low-consequence flags act without waiting for anyone. If a supervisor has to confirm everything, the desk becomes the bottleneck it was put there to remove.
• The sign-off tier. Slowing or stopping a line, holding a batch, changing a setpoint on critical equipment. These wait, and they arrive as one approve or reject with the evidence attached.
• The never tier. Equipment where no automatic action is permitted at any confidence. The limit is set by asset before go-live, and the layer enforces it rather than the tool respecting it.
• The escalation path. Who is pulled in when the supervisor is on the floor and not at a screen, and how long a hold waits before it escalates. Agreed in advance, because the worst moment to design this is during the incident.

The data these calls run on comes off equipment that predates the tools reading it. A reading can be stale, out of range, or simply wrong, and none of those look wrong in the output.

• Current. A reading older than the window set for that asset is treated as unknown rather than as unchanged. Age is the most common defect and the cheapest to check.
• In range. A value outside the physically possible band is a sensor fault. It is recorded as one instead of being dispatched as a process event.
• Agreeing with something else. Where a second source exists, the two are compared. A single source disagreeing with the rest of the cell is a reason to hold, not a reason to act faster.
• Matching the machine's actual state. The asset may be in changeover, already down, or handed over for work. A correct diagnosis against the wrong state is still a wrong move.

Night shift is where this bites.

Thin staffing, fewer senior people, and a fast call with no second opinion. The desk is the second opinion.

This is a 60 to 90 day proof of concept on a single line, cell, category or product family. The figures below are what the proof of concept measures against a baseline captured in its first two weeks. They are targets and instrumentation, not results already delivered.

• Wrong calls prevented before the floor. Each hold logged with the check that caused it.
• False alerts not chased. Measured as supervisor hours returned against the weeks 1-2 baseline.
• Handover and root cause from the record. Designed so an incident review reads a log rather than reconstructing memory.