Exercise the release path without sending hardware commands.
In RLSOK, Shadow Mode evaluates a release decision while its configured execution path does not dispatch a controller command. It is an application-level behavior, not a ROS 2 controller lifecycle state or a switch that disables every publisher on a ROS graph.
Updated · RLSOK
Choose a zero-dispatch evaluation pathShadow, simulation and inactive controllers answer different questions
| Mechanism | What it tells you | What it does not establish |
|---|---|---|
| Simulation or mock hardware | How the configured model or mock responds to its inputs. | That another reachable ROS graph or publisher cannot reach physical hardware. |
| Controller lifecycle state | The state reported by the selected controller manager. | That the approved software or configuration matches, or that the full robot is stopped. |
| RLSOK Shadow decision | Whether the represented release and bindings meet the evaluated checks without dispatch through that path. | Physical behavior, universal interception of commands, or execution permission. |
What to mirror
- The same release manifest and content hash used by the intended path.
- Representative device, controller, and action bindings.
- Approval, revocation, expiry, replay, and mismatch decisions.
- Evidence that clearly marks hardwareSignalSent as false.
What it can reveal
- Mutable identifiers and configuration drift.
- Unexpected fail-open handling during dependency loss.
- Permit replay or expiry assumptions.
- Missing evidence needed to explain a decision.
Start with the environment you actually have
If you first need to identify loaded controllers and their interfaces, use the native ROS 2 inspection guide below; RLSOK is not required for that step. Keep the controller manager name, package version and observation time with the result.
For the local v1.5.0-shadow.8 evaluation prerelease, use its source-workspace procedure and documented mappings. The stable runtime's UR5e/Jazzy reference is a separate path. Neither route establishes compatibility with an unreviewed robot, ROS distribution or private interface.
Limitations
A Shadow result describes the evaluated path and inputs. Direct publishers, other drivers and external controllers remain outside that path. Begin in an isolated simulation or mock environment with physical controllers unreachable, and keep the existing robot safeguards and operating procedures in place.
WOULD_ALLOW is an evaluation result, not authority to move a robot. No signal through this path does not prove no other process sent a command. Physical dynamics, policy performance and customer integration require separate evidence.
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.