I built RLSOK, an open-source execution-authorization layer for robots.
The problem I’m trying to separate is simple:
software deployed ≠ software still authorized to cause physical action
A release can still be installed and running even after its approval has been revoked, its robot/controller configuration has changed, or the current execution state no longer matches what was approved.
RLSOK checks those conditions again immediately before robot command dispatch. If the approved release, robot, controller/configuration, or authorization state no longer matches, the command is not sent.
The current implementation includes:
release identity
approval and revocation
configuration binding
short-lived execution permits
Shadow mode with zero controller dispatch
verifiable execution evidence
RLSOK does not replace functional safety, E-stops, safety PLCs, motion planning, or robot controllers.
There is already a working open-source implementation and ROS 2 reference path. I’m especially interested in feedback from people who operate or deploy real ROS 2 robots:
Do you already have a separate execution-authority layer between deployment/fleet management and physical command dispatch, or is permission to execute currently handled implicitly by the deployment/controller stack?
Thanks — that’s useful feedback. If the website and repo don’t make the behavior obvious, that’s a problem on my side.
The concrete case I’m trying to solve is: a robot software release is already deployed and running, but its approval has since been revoked or its approved robot/controller configuration has changed. RLSOK checks that again immediately before the next ROS command is dispatched; if it no longer matches, that command is not sent.
I do use AI-assisted development tools, but I’m responsible for the implementation and verification. I’ve read the ROS guidelines you linked and I’ll tighten both the project explanation and how I communicate it here.
I’m working on a small ROS 2/Gazebo example that should make the boundary visible without needing to read the architecture first.
I maintain RLSOK. Here is a concrete update on the controller-configuration case, using the example reported in v1.5.0-shadow.4.
The setup used an installed ROS 2 controller manager and JointTrajectoryController, with five joint interfaces on mock_components/GenericSystem:
Export the selected active controller’s state and parameters, prepare the local profile, and approve that baseline.
Capture a fresh observation. The reported baseline result was WOULD_ALLOW.
Deactivate the selected controller and activate a replacement on the same joint interfaces in the isolated mock setup.
Export and capture again, keeping the approval, profile and command example unchanged. The result became WOULD_BLOCK, with fact_mismatch:active-controller.
That is the behavior I meant: the original configuration approval no longer matches the observed controller binding. The exporter reads controller-manager/parameter services and graph metadata; it does not switch controllers or send goals. The controller changes in step 3 were separate setup operations.
This is a local software-controller/mock-hardware result. No trajectory or velocity command was published; WOULD_ALLOW is neither execution permission nor a physical-safety claim. The export is not an atomic or authenticated hardware snapshot. This does not provide the Gazebo recording I mentioned earlier; that part remains outstanding.