How approvals keep your robot safe

A policy runs on a robot only after a person approves it. An agent can do almost everything else: train the policy, test it in simulation, and ask to run it. This page explains each step, who may take it, and how a run stops.

An agent can train and test

Your own AI, or the hub's agent, can work with a key you made. It can start a training run on your computer or in Lucen cloud. It stops at the budget you set. It can test every checkpoint in simulation, where each test is scored Pass or Fail. Nothing in these steps reaches a robot.

Only a person approves

To run a policy on a robot, someone files a request. It names one policy, one robot, and how many minutes the policy may run. An agent can file it. Only a person signed in to the hub can approve it. An API key cannot, whatever its scope, so an agent can ask and then wait.

Before anyone decides, the hub checks the request and shows the result:

• whether the robot accepts this policy's inputs and outputs;
• whether this kind of policy may run on the robot;
• the fail-safe the robot declared;
• the latest sim test of this policy on this robot, or that there is none;
• whether the policy still matches the robot's current description;
• the exact file that would run, named by its checksum.

The request waits in the person's Inbox until they decide. They can approve it, shorten the window first, or deny it with a reason. A robot that belongs to an organization can require a second person, so the one who asked cannot also approve.

What one approval covers

Each approval covers one policy, on one robot, for the minutes you choose. It never renews on its own. Running the policy again needs a new approval.

The approval names the file by its exact bytes. If the file changes after the request, the approval no longer matches it, and the robot refuses to run it.

The robot checks for itself

The hub signs each approval. The robot checks that signature itself, without asking the hub. It downloads the file and checks that the bytes match. It refuses a policy whose inputs and outputs do not fit it. Then it runs the policy until the window ends, and stops on its own clock.

The robot never holds an API key. It joins the hub with a short code, and makes a key of its own that only it holds.

Stopping a run

A person presses Stop now on the run's page, or STOP on My robots. The robot reads the stop on its next heartbeat, a few seconds at most. It holds still, then stops, and reports that it stopped. Only a signed-in person can press Stop. It does not replace the robot's own hardware emergency stop.

When the connection drops

A walking or balance policy runs on the robot itself, so a lost connection does not stop it. It runs until its window ends, then stops on the robot's clock. A Stop pressed in the meantime reaches the robot when the link returns.

A slower skill policy can run on a hub server instead. If that link drops, the robot holds still, then stops, without waiting for the hub.

The record

The request's page keeps every request, decision, start and stop, in order, with who did it. The page stays as the record after the run.

To do this yourself, follow Deploy a policy to your robot. API keys and scopes lists what a key can do, and what only a person can.