Prevent the wrong policy version from reaching a ROS 2 robot.

Problem: mutable names cross the release boundary

Suppose a launch file requests policy `navigation-latest`. If a registry tag or file changes after review, the same request can resolve to different bytes. A dashboard may still show an approval for the name even though the robot receives a different artifact.

Workflow

• Create a canonical release manifest containing policy digest, runtime requirements, and controller-configuration digest.
• Hash the canonical manifest and make that hash the approval subject.
• Request a permit bound to release hash, action, device, and controller.
• At the local ROS 2 gateway, recompute or retrieve the trusted digests and compare every binding.
• Consume the permit once, then record the decision and whether dispatch occurred.

Example boundary

A planner can publish an intended action, but it cannot directly call the hardware controller. The gateway first checks the release and configuration bindings. A mismatch produces denied evidence and no controller signal.

This requires the controller path to pass through the gate. A direct publisher, another driver or an unreviewed dispatch path remains outside that boundary.

Keep the original approval when checking a change

Begin with a matching baseline in an isolated Shadow environment. Change only the artifact or declared configuration under review, retain the original approval, and inspect the reported mismatch. Renaming a file without changing its bytes is a different case from changing the content behind an unchanged name.

The following is an illustrative comparison, not a captured run or an RLSOK configuration schema. A matching baseline also requires current approval, valid bindings and the other checks for the selected evaluation path.

Original approval: artifact digest A
Baseline observed: artifact digest A → identity matches
Changed observed:  artifact digest B → identity mismatch
Keep the original approval for both observations.

Limitations

Content identity prevents version confusion; it does not establish that the policy is behaviorally correct. Keep simulation, staged hardware validation, safety-rated controls, and operational supervision separate.

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.

• Stable runtime execution-gate source
• UR5e/Jazzy reference setup and scope

Continue with the relevant guide

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