Why robots stop at the first exception

A robot program is a list of expected cases. Pick the box from position A, check the label, place it on the pallet. As long as the world matches the list, the cell runs on its own. The moment something does not match, the program has two options: stop, or do the wrong thing. Most integrators, sensibly, choose stop.

Exceptions are rare one by one and constant in aggregate

Any single exception is rare. A torn label happens once in a few hundred cartons. A new packaging arrives a few times a year. A supplier ships a day early once a quarter. Add them up across products, suppliers and shifts, and the cell sees an exception every few minutes. Each one costs the same: the line waits until a person walks over, decides, and restarts the robot.

The cost is not the decision. The decision takes a person a second. The cost is the interruption: the walk, the wait, and the context switch for whoever had to leave their own work.

The three usual answers

More programming. Every exception becomes a new branch in the program. This works for the exceptions you already know, at the price of a ticket to the integrator each time. It does nothing for the exception you meet next week.

More people. Someone watches the cell and steps in. This works, and it removes most of the reason to have a robot.

A lower bar. Let the robot act on anything that looks close enough. This is how damaged goods get shipped, and how nobody can explain afterwards why.

What a decision layer does instead

A decision layer sits between perception and the robot controller. For every item it does four things.

1. It turns the scene into structured facts: what the item is, what state it is in, where it sits.
2. It asks the rule engine which actions are allowed here. Hard safety rules live in this step, as deterministic code.
3. It picks one of the allowed actions and attaches a confidence to that choice.
4. It compares the confidence with a threshold set for the task. Above the threshold the robot acts. Below it, an operator gets the case on a tablet and decides with one tap.

Every step is written to a log: what was seen, what was chosen, with what confidence, who approved.

The threshold is the important part. It is not a technical constant. It is a business decision about how much doubt you accept before a person gets involved, and it can differ between tasks. A cell that loads vials into a tray can be strict. A cell that moves empty crates can be relaxed.

What stays the same

The decision layer does not replace the safety concept. Guards, light curtains and emergency stops stay with the cell and with the integrator who built it. It does not replace the robot program either. The controller still runs the motions. The layer only decides which of the allowed motions to run, and when to ask instead.

Where to start

Take the last month of stops at one cell and write down the reason for each. Most lists have a short head of frequent cases and a long tail of odd ones. A decision layer helps with both, in different ways: the head becomes rules in plain language, the tail becomes questions to an operator.

If you cannot get that list, that is the first thing to fix. You cannot manage exceptions you do not record.