What Is RLSOK? Robot Software Execution Authorization
Learn how RLSOK checks robot software execution authorization: release identity, robot and controller bindings, short-lived Permits, Evidence and support limits.
Read the referenceCheck the release. Compare the configuration.
Practical ROS 2 guides for release approval, controller configuration and Shadow evaluation. Start with the question you need to answer, then check the documented environment and limits.
Start with your question
Procedures include source references and distinguish illustrative examples, developer-run checks and unvalidated environments.
Authoritative product references
Canonical definitions, architecture, support status, integration proof, comparisons, and terminology.
RLSOK Architecture: Authorization Before ROS 2 Dispatch
RLSOK places a fail-closed robot-side execution gate after deployment and immediately before ROS 2 controller dispatch.
Read the referenceSupported Robots and ROS 2 Integrations
Check the UR5e/Jazzy mock-hardware reference, stable runtime and local interface-evaluation prerelease. Physical robot compatibility remains unvalidated.
Read the referenceUR5e and ROS 2 Jazzy: Start a Shadow Evaluation
Check the documented UR5e/Jazzy reference requirements, start a zero-dispatch Shadow evaluation, and understand what the result does and does not prove.
Read the referenceRLSOK vs CI/CD: Execution and Deployment Authorization
CI/CD decides what to build and deploy; RLSOK rechecks whether the exact deployed release may execute on a bound robot and controller now.
Read the referenceRLSOK vs Functional Safety: Exact System Boundaries
RLSOK constrains software execution authority; it does not determine whether robot motion is safe or replace safety-rated controls.
Read the referenceRLSOK vs SROS2: Execution Authorization and ROS Security
SROS2 secures ROS 2 identities, communications, and graph permissions; RLSOK authorizes an exact software release immediately before controller dispatch.
Read the referenceRLSOK Glossary: Robot Execution Authorization Terms
Canonical definitions for Release, Approval, Permit, execution authorization, revocation, bindings, Shadow Mode, Evidence, and execution provenance.
Read the referenceEngineering guides
Concrete workflows for policy identity, bindings, and Shadow validation.
Keep a Baseline While Tuning a Robot
Change one saved Pure Pursuit setting, then compare it with the original baseline. A file-only Pioneer-X example with commands and a readable report.
Read the guideWhat Changed in Your Saved Robot Configuration?
Compare saved robot configuration with a reviewed baseline, read before/after values, and keep missing files visible in RLSOK shadow.12.
Read the guideHow to List Active ROS 2 Controllers and Claimed Interfaces
Inspect ROS 2 controllers, hardware lifecycle states and claimed interfaces with read-only ros2 control commands, then interpret what active actually means.
Read the guideHow to Prevent the Wrong Policy Version from Reaching a ROS 2 Robot
A concrete ROS 2 workflow for binding immutable learned-policy identity to approval and local dispatch.
Read the guideWhy Model Approval Is Not Execution Authorization
Separate durable review decisions from short-lived, context-bound permission to run a learned robot policy.
Read the guideROS 2 Shadow Evaluation Without Sending Robot Commands
Choose a documented ROS 2 Shadow evaluation, compare a matching baseline and a changed configuration, and read the result without sending robot commands.
Read the guideROS 2 Controller Configuration Changes and Release Approval
See why unchanged policy bytes can require a new approval after a controller configuration change, with a clearly labeled example and a scoped Shadow next step.
Read the guideCompare Active ROS 2 Controller Configuration Against an Approval
Use a read-only controller-state export and one unchanged local approval to compare ROS 2 configuration observations. Includes prerequisites and reported mock-hardware results.
Read the guide