Put the safety envelope below the policy
Policies change. Limits should remain legible, enforceable, and close to the machine that receives the command.
A good command can still be a bad motion
A learned policy is allowed to be uncertain. Hardware should not be. Position, velocity, force and workspace limits need to survive a model update, a network hiccup and a rushed experimenter.
That is why we think of limits as runtime data rather than application logic. They should be declared once, visible during a run and checked at the layer that writes to the machine.
Make stopping ordinary
A rejected command is not necessarily a failed session. It is information: the policy asked for something outside the envelope, and the system chose a safe, inspectable outcome. Log it, surface it, and use it when deciding what to change next.
No software limit replaces supervision, interlocks or the approval process appropriate to the work. It does make the intended boundary harder to accidentally bypass.