The order nobody asked him about

The planning engineer used to walk the floor at quarter to six, before the shift handover, and settle the morning's running order in his head before he touched a screen.

He knew which machine had run hot the night before and needed a lighter job first. He knew which operator was new to a line and should not get that week's trickiest changeover. None of that was written down anywhere. The plant had hired him, in part, for exactly that knowledge.

A scheduling tool went in to save him the hour it took each morning to work the order out by hand. It read the job list and the shift roster overnight, and by the time he arrived there was already a running order on the screen, already sent down to the floor.

Most mornings the order was close enough to his own that changing it felt like second-guessing a colleague, so he let it stand. One morning it was not close enough. A machine that had run hot overnight went first anyway, because nothing in the data said it had run hot — only a hand on the casing at the end of the previous shift said that, and nobody had told the system. He was the one who had to explain, afterward, why the order had been wrong. It had not really been his order any more. He had just stopped checking.

Why we build it this way

Every account we have read of an industrial AI programme that actually stuck lands on the same sentence: the system is there to make the engineer faster, not to make the decision in his place. The programmes that forget this do not usually fail loudly. They get quietly switched off, or quietly ignored, by the people who were supposed to be using them.

The obvious engineering answer looks like the better one: if a system gets it right most of the time, let it decide outright and save the person's attention for the exceptions. That reasoning fails on one detail. Exceptions do not announce themselves. A machine running hot is not a field any system reads unless someone puts it there, and the person who would have caught it has just been handed a finished answer instead of a question worth checking. Take the decision away from him and you also take away the one moment he was testing his own knowledge against the day's facts. That knowledge does not move into the system. It simply stops getting used — until the day it was the only thing that would have caught the problem.

So the system's job is to hand over a proposal, with its reasoning attached, early enough that changing it costs nothing — never a locked order that merely waits to be rubber-stamped before the floor acts on it.

How it works, roughly

Before the shift starts, the system reads:

• The day's job list and the shift roster
• Machine and line status already logged by someone on the floor
• Anything the planning engineer has flagged as a standing watch — a machine to go easy on, an operator still learning a line

It gives back a proposed running order with a short reason next to each placement, not a sequence handed down as settled. The planning engineer can reorder any of it in one move. When he does, that change is kept against the job it altered, with his name on it — not to watch him, but because it is the same record that shows the call was his, correctly, whatever happens afterward on the floor.

A year on, the hour he used to spend building the order from nothing is mostly gone. What is left is his: catching the case the system had no way of knowing about, and saying so before the floor acts on it, not after.

AI Transformation · drag to turn