Two robots may complete the same task in the same facility. One may do so under onboard autonomous control. The other may receive cloud guidance, request remote assistance at a doorway, and have a person complete the final action through teleoperation.
The visible result can look similar. The operational facts are not.
Control mode describes how authority over a robot’s behaviour was exercised at a particular time. It is not a minor technical setting. It affects what a capability claim means, which dependencies mattered, where human involvement occurred, and which organization may hold relevant evidence about an event.
For that reason, control mode should be a first-class part of the operational record, not an unstated assumption behind a generic label such as “autonomous.”
Control mode is about authority in operation
A robot does not have one permanent level of autonomy. Its operating arrangement can change by task, site, configuration, condition, or even during a single mission.
The practical question is: who or what was directing the robot’s behaviour when it mattered?
An operational record should distinguish at least the following modes:
- Autonomous, onboard: the robot performs the defined task using local control and onboard capabilities.
- Autonomous, cloud-dependent: the robot performs the task autonomously but relies on a remote AI, inference, mapping, or other material cloud service.
- Supervised autonomy: the robot acts autonomously within an approved boundary while a person monitors or can intervene under defined conditions.
- Mixed autonomy: control or decision-making is shared between automated and human elements as part of the intended workflow.
- Remote assistance: a human assists the robot with a discrete exception or decision without necessarily taking continuous control.
- Teleoperation: a human directly controls the robot’s actions or movement remotely.
- Manual or local control: a person operates the robot directly at or near the machine.
- Safe-stop or emergency control: the robot enters a state intended to prevent continued operation until an authorized response occurs.
These categories can be refined for a particular deployment. The essential discipline is to avoid collapsing them into a single nominal mode.
A single mission can include several modes
Consider a delivery robot navigating a facility. It may begin in autonomous onboard operation, encounter an obstacle outside its handling rules, request remote assistance, resume autonomous movement, then enter safe-stop after a sensor fault. A person may later move it manually to a service area.
Describing the whole mission as “autonomous delivery” does not provide enough information for operations, review, or improvement. It conceals the transition points where the operating authority, dependency, and potential responsibility changed.
The record need not capture every low-level command or become a real-time telemetry platform. It should preserve the material control-mode intervals and events relevant to the task, configuration, deployment, intervention, or incident.
This is especially important when field evidence is used to support capability claims. A task completed after remote assistance is meaningful evidence, but it is not identical to a task completed without intervention. A safe-stop may reflect appropriate operational restraint, rather than failure, but it should remain visible.
Control mode changes the meaning of an autonomy claim
The word “autonomous” is often used as a broad product description. In an operating environment, it must be bounded.
An autonomy claim should identify the task, physical unit or cohort, configuration baseline, operating conditions, control mode, human-intervention arrangement, evidence, claimant, and validity period. The claim is then specific enough to be tested, understood, and revised when the underlying conditions change.
For example, a robot may be authorized for supervised autonomy in a defined warehouse zone during certain hours, with remote assistance available for exception handling. That is a useful, honest operating claim. It should not be translated into an unqualified assertion that the robot operates autonomously in every environment or circumstance.
The distinction protects both operators and robot makers. It creates a record that recognizes legitimate mixed-control models rather than forcing every deployment into an artificial binary of fully autonomous or fully manual.
Control mode reveals material dependencies
The applicable control mode may depend on external services and organizational arrangements.
A cloud-dependent autonomous robot may require network connectivity, a remote inference service, and a defined fallback when that service is unavailable. Supervised autonomy may require trained personnel, an intervention channel, and escalation procedures. Remote assistance and teleoperation may depend on a service provider, communications path, and authorization structure. Safe-stop may trigger a maintenance or return-to-service process.
These dependencies can change the robot’s behaviour without changing its physical identity or manufacturer serial number. They belong in the operational configuration and deployment record when they are material to the task.
The point is not to disclose sensitive operational detail publicly. Access-controlled records can preserve the relevant relationship, version, role, and evidence without exposing credentials, raw video, personal data, or proprietary systems.
It also clarifies who had a role in an event
Control mode helps establish the factual context for accountability.
If a robot was in autonomous onboard mode, the relevant evidence may concern its local configuration, sensors, and operating boundary. If it was cloud-dependent, the service provider and connectivity profile may be material. If remote assistance or teleoperation occurred, the operator or service that intervened may have relevant records. If the robot was safe-stopped, the facility team, maintainer, or deployment approver may have made the next consequential decision.
This is not an automatic allocation of liability. It is the difference between an event record that can be investigated and one that relies on assumptions.
A robust record associates the control mode with its effective period, claimant, evidence, verification state, and any correction or dispute. It then preserves the operational history even after the robot later returns to another mode.
The record should show transitions, not only labels
The most useful operational record answers four questions:
- What control mode was authorized for the defined task and deployment?
- What control mode was actually in effect during the material event or interval?
- Did a transition occur, and what triggered it?
- What evidence and organizations are linked to that transition?
These questions make it possible to compare evaluation with real deployment, distinguish planned intervention from unplanned exception handling, and understand how a robot operated under changing conditions.
They also support a more mature conversation about autonomy. The aim is not to celebrate or penalize a particular mode. Each can be appropriate for a particular task and environment. The aim is to make the mode explicit.
A record of how the work was done
The operational record of a commercial robot should not only state that work was completed. It should preserve, at the right level of detail, how the work was done.
IDWorthy does not control robots, provide teleoperation, manage remote assistance, or certify autonomous operation. It preserves the durable, evidence-backed links between the physical robot, its configuration, operating conditions, control mode, human intervention, and lifecycle history.
When control mode is visible, autonomy claims become more precise, operational events become easier to interpret, and the organizations around the robot can make better decisions.
That is why a robot’s control mode belongs in its operational record.