RLSOK vs CI/CD

Where each layer acts

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

CI/CD responsibilities

• Build and test artifacts.
• Record provenance and publish immutable releases.
• Promote and deploy a selected release into an environment.
• Roll back or redeploy software when operators request it.

RLSOK responsibilities

• Bind approval to exact content.
• Bind execution authority to action, robot, and controller.
• Recheck revocation, expiry, and identity at dispatch time.
• Consume single-use authority and record Evidence.

Why deployment authorization is insufficient

A successful deployment does not prove that approval remains current at the later instant of execution. A robot configuration can change, a release can be revoked, a Permit can expire, or a different action can be requested without another deployment.

How the layers work together

CI/CD should publish immutable artifacts and provenance that RLSOK can bind into a release. RLSOK then enforces the narrower dispatch-time decision; it does not replace the build, test, registry, deployment, or rollback systems.

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.

• RLSOK execution-boundary architecture
• GitHub's first-party explanation of CI/CD workflows

Continue with the relevant guide

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