Supervised live robot operations

Every supervised operations program needs a written scope: which robot units are under supervision, which missions are in play, which alerts require acknowledgement, which commands are permitted under procedure, and who holds escalation authority. Without that scope, operators invent local habits that cannot be compared across shifts. The scope should also name the systems that remain outside supervision tooling, including safety controllers and emergency-stop paths.

Dagmont Command can record the supervision workflow, but only after the organization decides what the workflow is. Start with a one-page supervision charter that shift leads can open at handover.

Mission state is the operator view of what the robot is supposed to be doing and what it is actually doing. Useful mission state includes the active mission or workflow phase, recent state transitions, blocking conditions visible to the operator, and the time window for the current observation. Attribution matters as much as visibility.

When two operators disagree about whether a robot was idle, waiting on infrastructure, or failed mid-task, the record should show what the console presented at the time, not what people later remember. Capture mission state snapshots at acknowledgement and at escalation so investigators inherit the same picture the floor saw.

An acknowledgement is not a casual click. It is an operational decision that someone saw the alert, accepted responsibility for the next procedural step, and started a clock for follow-up. Strong acknowledgement practice records who acknowledged, when they acknowledged, what the alert identity was, and what immediate action the procedure required.

Weak acknowledgement practice buries alerts in a stream that nobody owns. For Physical AI environments, acknowledgement also needs environmental context when the alert is intermittent: shift, traffic load, charging state, or nearby equipment conditions that the operator can observe. That context often becomes the difference between a reproducible investigation and a closed ticket that returns next week.

Command history is the accountable list of operational commands issued or approved during supervision: who issued them, under which procedure, against which robot or mission, and with what outcome visible to the operator. Teams sometimes omit command history because they fear it will be used punitively. The better framing is operational learning and investigation integrity.

When a failure appears after a sequence of manual interventions, investigators need that sequence. When a customer asks whether operators followed the approved procedure, the history answers without reconstructing radio logs. Record commands at the time they are issued.

Retroactive reconstruction after a serious failure is slower and less reliable.

Supervision ends and investigation begins when the team can no longer restore reliable operation through approved procedures, or when the event touches an acceptance condition, safety concern under site policy, recurring failure pattern, or customer commitment that requires a durable case record. Escalation should create a Deployment Intelligence case with the operational snapshot: alert history, acknowledgements, command history, mission state, and the operator narrative of what was tried.

Do not escalate every nuisance alert. Do escalate events that will otherwise be forgotten by the next shift and then rediscovered as unexplained production loss.

Useful supervision measures include acknowledgement latency for high-severity alerts, completeness of escalation packages, recurrence of the same alert without escalation or corrective action, and the rate at which Deployment Intelligence cases arrive with missing operational context. Vanity metrics such as total clicks or total alerts closed teach the wrong behavior. Review one escalated event each week with both operations and deployment engineering present.

Ask whether Command history answered the first investigation questions. If engineers still start by interviewing the floor for basic timeline facts, the supervision record is incomplete and the charter needs tightening.

• Publish a supervision charter naming robots, alert classes, permitted commands, and escalation authority
• Require acknowledgement fields that capture person, time, alert identity, and next procedural step
• Snapshot mission state at acknowledgement and at escalation
• Record command history with attribution when commands are issued
• Define explicit criteria for creating a Deployment Intelligence case from live operations
• Include remote support actions in the same command and acknowledgement history
• Run weekly reviews of escalation package completeness with engineering
• Keep safety and emergency-stop paths outside the supervision tooling scope