RLSOK glossary

Core terms

Release

An immutable learned-policy artifact plus the declared runtime and target configuration whose canonical manifest is identified by content hashes.

Approval

A durable decision that exact release content completed the required review. Approval is revocable and is not permanent permission to execute.

Permit

A short-lived, single-use authorization bound to release, action, robot or device, and controller identity. It is consumed at the execution boundary.

Execution authorization

The dispatch-time decision that an exact approved release may perform a specific action on the bound robot and controller now.

Bindings and state

Revocation

A state change that removes execution eligibility. RLSOK refreshes and rechecks revocation before controller dispatch.

Robot binding

The exact robot or device identity included in a Permit and compared at the local execution gate.

Controller binding

The controller identity and configuration hash included in the release and Permit and checked before dispatch.

Observation and proof

Shadow Mode

The real authorization and Evidence path with the final controller dispatcher absent, guaranteeing that RLSOK attempts zero controller dispatches in that mode.

Evidence

A verifiable record of release identity, bindings, decision, time, matched rules, and observed dispatch state, linked into a tamper-evident chain.

Dispatch-time recheck

The final local comparison of release eligibility, revocation, expiry, action, robot, controller, and Permit validity immediately before the controller adapter.

Execution provenance

The reconstructable relationship between the release, authorization context, decision, and observed dispatch recorded in Evidence.

Authorization gap

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

Category and scope

The canonical category is robot software execution authorization. RLSOK's current beachhead is learned robot policies and Physical AI executed through ROS 2, without claiming general functional safety or universal robot support.

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.

• Runtime architecture and terminology
• Permit and gate semantics
• Evidence schema and verification

Continue with the relevant guide

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