The boundary is the design
Every operational system draws a line between what it decides and what it asks a person to decide. That line is usually inherited rather than chosen, it lands wherever the last integration happened to stop. When a programme is described as an automation failure, the line is almost always the thing that failed.
A decision belongs on the system's side of the line when it is frequent enough to be worth encoding, reversible enough to survive being wrong, and supported by evidence the system actually holds. Miss any one of those and the automation is a liability dressed as efficiency.
Automate the decisions you would be comfortable explaining to the person they affect. Keep the rest.
Three tests before you encode
- 01Frequency: does this decision happen often enough that a person is making it on autopilot already?
- 02Reversibility: if the answer is wrong, what does it cost to undo, an hour, or a relationship?
- 03Evidence: is everything the decision depends on present in the data, or does half of it live in someone's memory of last quarter?
The third test is the one that catches most candidates. A dispatcher choosing between two carriers is weighing a service record, a conversation from last week and the weather. Encode the record, and the system will confidently make a decision on a third of the picture.
What people should keep
Judgement under ambiguity, decisions with a person on the other end of them, and anything where being wrong is expensive and slow to discover. These are not the leftovers, they are the reason the operation employs experienced people at all.
The best outcome of a decision layer is not fewer people deciding. It is that the decisions still being made by people are the ones worth their attention, arriving with the context already assembled.
