Operations System
When a phase failed in a factory, the planner spent between 30 minutes and 2 hours manually recreating all the tasks that had been lost. No history of previous attempts, no validation that conditions had changed, no check that replacement material had actually arrived.
AutoTask was designed to eliminate that overhead. Not only for recovery, but for every moment tasks need to be generated: when a new job is created from a template, when a recurring maintenance task fires, when a phase restarts after an incident. The system generates the tasks. The planner confirms them.
The obvious solution was full automation. When a phase restarts, the system recreates everything automatically. No confirmation, no preview, no friction. That was exactly wrong.
A system that acts without the user understanding what is happening does not reduce errors. It amplifies them. When something goes wrong with fully autonomous action, nobody knows why or how to stop it.
The previous automation attempt had already failed this way. Planners disabled it frequently because it "did unexpected things." When users disable an automation feature, it is not because they do not want automation. It is because the automation they have is not reliable. An unreliable automation system is worse than no automation. It generates distrust in the entire system, not just that feature.
The design goal was not to maximize autonomous action. It was to maximize informed human action assisted by automation.
Human confirmation is never optional
Every AutoTask execution requires planner review and explicit confirmation. No task is created without a human seeing what is about to happen.
Automatic execution when conditions are met. The PM argued that if conditions are satisfied, the rule was designed for that case and confirmation is unnecessary bureaucracy.
The PM had a legitimate point. Confirmation adds friction. More steps, more time, more resistance from planners who are already overloaded. The efficiency argument was real.
Rules are designed in a static context. Execution happens in a dynamic one. The gap between design-time conditions and runtime context is exactly where failures occur in manufacturing. An operator who called in sick ten minutes ago, a machine that entered maintenance while the preview was open. I had to build concrete scenarios with real costs to demonstrate that the confirmation step was not bureaucracy. It was the mechanism that caught those gaps before they became problems on the floor.
AutoTask Decision Tree
Define explicit limits of system autonomy
Define precise criteria for what AutoTask can decide alone and what always requires a human before building anything. Automatic reassignment only under four explicit conditions: replacement is available, has no tasks in the next defined window, affected job has equal or higher priority, and job Risk Tier is LOW.
Progressive automation without defined limits. Build what the system can do and adjust after problems surface.
Defining limits before building feels bureaucratic. It is faster to build, see what fails, and adjust. The PM wanted velocity. Limits on paper do not appear in any mockup.
An automation system without explicit limits is a black box. When something goes wrong, nobody knows if it was a system decision or a system error. The planners in the previous system disabled automation for exactly this reason. Not because they did not want it, but because they did not understand what it decided and when. The limit between system autonomy and human control is not an implementation detail. It is the contract between the system and the user. If that contract is not explicit, it does not exist.
| BEFORE | AFTER |
|---|---|
| Manual task reconstruction after every failure: 30 min to 2 hrs | Structured recovery preview. Planner confirms in under 2 minutes. |
| Automation that "did unexpected things" and was frequently disabled | Transparent preview system. Planners trust it because they see exactly what it will do. |
| No simulation. Activate and see what happens. | SIMULATE RULE. Validate before activating, zero surprises. |
| Emergency Stop as panic mechanism. Blunt and disruptive. | PAUSE and DEACTIVATE RULE. Precise controls for specific situations. |
| Conflicts discovered in the plant | Conflicts surfaced in preview. Resolved before tasks are created. |
| No audit trail for automation actions | Every execution logged with rule, trigger, planner confirmation, and outcome |
| Task creation on potentially non-existent material | material_recoverable field blocks recovery until material is physically confirmed |
Make the social contract more explicit during onboarding. The principle "AutoTask proposes, you confirm" is clear after designing the system. It is not necessarily obvious to a planner using it for the first time. I would design a more explicit first-run experience that communicates that contract from the first interaction. Not as a tooltip, but as a designed moment.
Responsible automation is not about how much the system does alone. It is about how much the system does well with human oversight. The difference between a system that does 100% automatically and one that does 70% automatically with 30% reviewed is that the second one is reliable and the first is a time bomb. In systems with real physical consequences, reliability beats capability.