Think in tasks. Respect the controller.

Put language above the control boundary

A robot neural API may help translate a human request into a high-level task proposal. That does not make a language model an appropriate authority for motor commands, collision constraints, or stop behavior. The controller must own physical execution and enforce its limits independently of the conversation.

Use this track as a conceptual reading path for supervised simulation. It is not a deployment specification or a safety certification. Any connection to physical equipment needs qualified engineering review specific to the hardware, workspace, task, and people who may be affected.

Define the task lifecycle

Propose a known task

Prefer an approved task type and a known target identifier over arbitrary coordinates or free-form execution instructions. If the target is unclear, stop at the proposal stage. A linguistically plausible interpretation is not sufficient evidence that a physical action is valid.

Check the current world

Conditions can change after the user gives an instruction. Validate controller state, active tasks, target freshness, and operator authorization at the point where those checks matter. Prevent an old queued command from being mistaken for a fresh request after a reconnect.

Confirm the outcome

Acceptance and completion are different states. A long-running task needs meaningful progress and a verified terminal result. A cancellation request is also different from confirmation that the equipment has stopped. The interface should preserve those distinctions rather than displaying one generic success badge.

Start with simulation and known limitations

Test task selection, validation, and state transitions using a bounded simulated workspace. Document which real-world effects the simulator does not model. A successful simulation supports conclusions about those simulated conditions, not a universal claim of safe physical behavior.

Include invalid targets, stale observations, repeated requests, network loss, rejected commands, and interruptions after acceptance. Keep an authoritative task identifier and reconcile uncertain results before retrying. The model should explain verified execution state, not guess whether a task probably finished.

Keep stopping independent

An unresponsive browser or unavailable remote model must not be the only thing standing between the operator and the required stop behavior. Identify and verify the appropriate controller-level and physical mechanisms for the equipment. Do not infer cancellation merely because a tab was closed.

For the first application, keep the model's output limited to a proposal that a person can inspect. Show the exact task and target before approval. Expand capabilities only through documented review, and keep unsupported actions unavailable even when a generated explanation makes them sound useful.