.png)
Bounded Automation Is Not a Design Choice
The sales order processing team did not sit down and decide which parts of the workflow to automate and which to keep manual. Nobody drew aline and said: machines handle extraction, humans handle release. The boundary exists because of something that happened.
The assumption built into most automation programmes is that scope expands incrementally, more document types, more SKUs, more workflow stages, until human involvement becomes the exception rather than the rule. That is not what happens.
The details vary by operation. A misread product code that generated a confirmed shipment for the wrong SKU, a duplicated order line that doubled a customer's delivery, a price discrepancy that wasn't caught until the invoice was disputed. The specifics matter less than what followed. The mistake reached the customer. It could not be undone by correcting the record. The shipment had left the warehouse, the production run had started, the commitment had been made.
After that, every order was checked.
Where the boundary forms
The check was not placed at the point where the error occurred. It was placed at the point before the action became irreversible. That is always where it goes.
In a sales order workflow, several things happen before an order executes. A document arrives. Lines are extracted. Product codes are matched. Quantities are confirmed. A delivery date is assigned. Each of these steps produces a record. None of them, on their own, commits the business to anything. The moment of commitment is release, the point at which the order enters the fulfilment system and work begins against it.
The check lands immediately before release because that is the last point at which the mistake is still cheap. Before release, a wrong product code is a data correction. After release, it is a mispick, a return, a customer complaint, and a conversation about whether to absorb the cost or pass it on. The boundary is not placed where automation is weakest. It is placed where the consequences of automation failure become unacceptable.
Why the boundary doesn't move
Once the check exists, it is very difficult to remove. Not because the team is resistant to automation, but because the event that created it has not been forgotten and the system has not changed in any way that would prevent it from recurring.
The wrong shipment happened because the system extracted a product code incorrectly and nothing stopped the order from releasing on that basis. The check was introduced to catch that class of error before it reaches the customer again. Removing the check requires confidence that the system can no longer produce that error undetected — and that confidence is not available, because the system's uncertainty is still invisible. The error rate may have fallen since the check was introduced. That does not help. A lower error rate on a system that cannot identify its uncertain outputs still requires the same human presence at the boundary.
The team is not checking every order because they distrust automation in general. They are checking every order because the last time they didn't, something irreversible happened, and the system cannot yet tell them which orders are safe to release without review.
What this produces across the operation
The same pattern repeats in every part of the workflow thattouches execution. Automated purchase order generation runs until a duplicate order reaches a supplier. After that, someone reviews every suggested PO before it is sent. Automated invoice matching runs until a payment is made against a disputed invoice. After that, exceptions are manually cleared before payment is released.
Each boundary formed at a different time, after a different event, and is maintained by a different person. None of them were designed as a system. Together they define the actual automation boundary of the operation — not the boundary that was intended when the systems were introduced, but the boundary that the operation's history has produced.
This is why automation in operational systems does not expand gradually until it covers the workflow. It expands until it produces an irreversible mistake. After that, it stops.
Where Automation Stopped and Why It Stayed There
The check exists because an order reached a customer wrong and could not be recalled. It sits at release because that is the last point the mistake was still fixable. It has not moved because the system still cannot identify which orders would produce the same outcome.
Better accuracy hasn't changed that. Neither has time. The boundary stays until the system can show, on a per-order basis, that the failure that created the check cannot recur undetected.
Until then, every order gets reviewed, and the boundary stays exactly where the last irreversible mistake put it.