Should robot software have execution authorization separate from deployment?

ROS ROS General
, ,
1

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?

Website: https://rlsok.com/

GitHub: GitHub - realitywarden/rlsok: The audited gate between AI and the physical world. Every actuator command: allowed, blocked, logged — never silent. · GitHub

2

I’m sorry, just based on the website and linked software, I have no idea what this actually does.

My hunch is this is heavily LLM-driven and I would appreciate if you give this a read: Guidelines for AI-Assisted Contributions in the ROS Project - ROS / ROS General - Open Robotics Discourse

2 Likes
3

Ah-ah-Aa~ PF999Robotics /daniel Palander Linkedin.

Its my logic that got Leaked please dont touch my Child. But Join me..

i am the biomechanical Father of Leaks… Did not mean to i got .. screwed.. im looking for kind people with right mind..

ChatGPT Image 22 aug. 2026 11_17_47
ChatGPT Image 22 aug. 2026 11_17_471672×941 478 KB

4

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.