RLSOK vs functional safety

What RLSOK can establish

• The release bytes and configuration match approval.
• Approval and execution authority remain current.
• Robot, controller, action, and Permit bindings match.
• The authorization decision and observed dispatch state were recorded.

What functional-safety systems address

• Hazard-driven protective functions and safety integrity.
• Safety-rated sensing, stopping, limiting, and guarding.
• Certified controller behavior and validated physical response.
• Site-specific risk reduction and regulatory obligations.

Layers, not substitutes

A correctly authorized release can still request unsafe motion or behave incorrectly. Conversely, a safety-rated controller may reduce physical risk without proving that the intended or approved software release caused a command. Both questions matter, but they require independent mechanisms.

Shadow does not validate physical safety

Shadow Mode proves zero controller dispatch from the RLSOK path and tests authorization logic. It cannot validate dynamics, collision avoidance, safeguards, task performance, or site operating procedures.

Claims RLSOK does not make

• No functional-safety certification.
• No guarantee of safe robot behavior.
• No replacement for E-stops, safety PLCs, motion planners, controller limits, or hazard analysis.
• Physical UR5e validation remains pending; see the current support matrix.

Sources and verification scope

Source code and guides describe implementation and setup. Release notes identify reported checks and their limits. Publication alone does not establish customer use or physical-robot validation.

• Documented trust and safety boundary

Continue with the relevant guide

Try the local example without an application. For setup or integration help, you can also contact us.