Three senses of the word, and which one is meant
| Sense | Example | Where you meet it |
|---|---|---|
| The architecture | ACT, SmolVLA, GR00T N1.7, Pi0.5 | The model picker in the training form and the pages under /policies |
| The trained artifact | cube-pick-smolvla-v1 | The name you give a run, and the thing checkpoints belong to |
| The running process | Whatever is moving the arm right now | The run and stop commands, and the cockpit |
Most confusion comes from mixing the first two. Two runs of ACT on the same dataset are one architecture and two policies, and only one of them may be worth deploying. When someone asks which policy you are running, they mean the second sense.
What a policy is not
It is a reactive mapping. An observation goes in, actions come out, at whatever rate the model allows, from about 20 ms per action step for ACT to about 485 ms for Pi0.5. Between decisions it keeps executing what it already predicted.
- No plan in the classical sense: no task decomposition, no goal state it checks off, no recovery routine to fall back on.
- No world model to consult, so anything it does in an unfamiliar scene is extrapolation from your demonstrations.
- No separation between perception and control that you can debug independently. The mapping is learned end to end.
- No independence from the setup it learned in: camera placement, lighting and the calibration of the specific arm that recorded the data are all baked in.
Servo zero points differ between two physical units of the same arm model, so the same joint value describes a slightly different pose on each. Running a policy on an arm whose calibration does not match the recording arm produces motion that is systematically offset rather than randomly wrong, and it is easy to misread that as a bad training run.
The five architectures are laid out side by side under /policies, and /learn/run-your-first-policy walks through the first time one of them drives your hardware.