Architecture

RLSOK architecture

RLSOK places execution authorization after deployment and immediately before ROS 2 controller dispatch. The robot-side gate rechecks an exact release and bound execution context, fails closed, then records the decision as verifiable Evidence.

Updated · RLSOK

Download and try RLSOK
01

Execution boundary

The authorization gap between deployment and execution is the period in which an artifact can change, approval can be revoked, authority can expire, or robot and controller identity can drift after CI/CD has deployed software but before a controller receives a command.

CI/CD → deployment → RLSOK execution authorization → ROS 2 controller
02

Control-plane responsibilities

  • Store canonical releases, immutable artifact hashes, approval state, and revocation state.
  • Issue short-lived execution authority for an exact release, action, device, and controller.
  • Consume cloud authorization atomically and receive bounded Evidence records.
03

Robot-side responsibilities

  • Observe trusted release, robot, controller, and action identity at the local boundary.
  • Refresh release eligibility and reject revoked, expired, mismatched, unknown, or replayed authority.
  • Remove a local Permit before validation so a failed attempt cannot replay it.
  • Call the existing ROS 2 controller adapter only after every check succeeds.
04

Failure behavior

Cloud-connected operation never silently falls back to weaker offline authority. Unknown state, dependency failure, stale identity, Permit replay, or dispatch ambiguity produces a blocked or failed decision and Evidence rather than implicit permission.

05

Shadow and run modes

Shadow Mode exercises release admission, approval, revocation, bindings, and Evidence while omitting the dispatcher. Run mode adds the controller adapter and separately records whether a signal was not sent, attempted but unconfirmed, or confirmed by the adapter.

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.

Continue with the relevant guide

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