When autonomy needs help
Most of the time, the fleet
runs on its own.
The design problem begins when it can't.
I grounded the project in a single failure scenario: R-142 encounters an obstruction, attempts to recover autonomously, and asks for human attention only when it can no longer resolve the issue.
What I learned
Three findings, one reframeSynthesized from desk research: human-factors literature on supervisory control and teardowns of five AMR fleet-management tools.
Automation handles
the routine.
Robots attempt recovery before escalating. ORBIT stays quiet until human attention is truly needed.
An alert is not
understanding.
Operators need context, not a red dot: what happened, what automation already tried, and what is affected.
Recovery is a
handoff problem.
Clearing the obstacle doesn't mean autonomy is ready to resume. That gap is where trust is won or lost.
This was never a monitoring problem.
It's a handoff problem.
Responsibility shifts
from
automation to a human, and back.
escalation, then hand-back.
Designing the handoff
Before any screensBefore designing screens, I defined when
automation operates independently,
when human judgment is needed, and when
responsibility returns to automation.
An issue occurs ≠ human attention required.
Once human attention is required,
the experience follows three steps.
ORBIT in action
The R-142 incident from Chapter 02, now shown end to end through the interface.
Before deciding what to do, the operator needs to understand the incident first.
Intervention is choosing a recovery path, not driving the robot.
The exact action is implementation-dependent.
But the worker walking
toward R-142
isn't looking at this screen.
Physical resolution ≠ system recovery.
Removing the obstacle doesn't mean the robot is ready to move.
Before it resumes, the system checks that it's ready while the
robot signals its status to nearby workers.
intervention
A nearby worker removes the obstruction.
verification
The system re-checks key conditions before the robot can resume.
While verification is in progress, the robot signals its status to nearby workers.
resume
The operator explicitly confirms when responsibility can return to automation.
Return responsibility to autonomy?
Operators need detail to decide. Workers on the floor need enough to act.
Four physical signals answer the two questions that matter there: does this robot need human assistance, and might it move?
May keep moving.
No human assistance needed.
Do not assume it will resume.
Stand clear; movement may resume.
Validation & reflection
What holds, what's untestedA system can be coherent on paper and still fail if operators can't understand it. So the validation plan targets the assumptions, not the pixels.
Can operators understand the incident faster than with status alone?
Measure → time to understanding · explanation accuracyDoes showing recovery behavior help operators know when to intervene?
Measure → unnecessary interventionsDoes verification prevent premature hand-back?
Measure → premature resume attemptsORBIT is a conceptual system based on publicly available AMR workflows, without access to a production fleet or professional operators. Vendor-specific behavior remains implementation-dependent rather than assumed.
The challenge wasn't deciding what the operator should control. It was deciding when human judgment is needed — and how responsibility safely returns to autonomy.