Evaluate release controls without sending robot commands.
A useful shadow path runs the same release checks as the intended deployment but replaces the hardware output with an explicit evidence-only result.
Updated · RLSOK
Choose the matching Shadow setupChoose a path before you start
| Your starting point | Use this path | Required context |
|---|---|---|
| See what a decision looks like | Recorded walkthrough on the download page | Local Core demonstration with synthetic inputs; no ROS or customer-use claim |
| Have the UR5e/Jazzy reference graph | Stable Runtime v1.4.5 Zero-to-Shadow | Ubuntu 24.04, Jazzy, Fast DDS, official UR driver, live JointState, active trajectory controller, Hosted pairing and independent approval |
| Review supported interfaces or configuration locally | v1.5.0-shadow.8 evaluation prerelease | Reviewed interface meanings, field mappings and local examples; isolated graph for discovery/capture; local approval is separate from Hosted authentication |
Architecture
- Feed representative policy, action, device, and controller identifiers into the normal gate.
- Use real approval, revocation, expiry, and replay logic against isolated test state.
- Route allowed decisions to a shadow sink instead of a hardware publisher.
- Write evidence with hardwareSignalSent=false for every shadow decision.
Test matrix
- Exact match, altered policy digest, and renamed release.
- Wrong device or controller configuration.
- Expired, replayed, and revoked authorization.
- Unavailable API or database with an expected fail-closed result.
Reading results
Compare expected decisions with evidence, inspect unexplained denials, and verify that no code path can reach hardware from shadow execution. The RLSOK repository demonstrates the release, permit, gate, and evidence concepts that can anchor this exercise.
For the local comparison flow, WOULD_ALLOW means the declared local checks passed; WOULD_BLOCK means at least one check failed. Read the reason and the changed fact. A stale observation or missing input can block for a different reason than the configuration change you intended to demonstrate.
Retain the same approval and command example across baseline and changed observations. Record zero attempted controller dispatches separately from the eligibility decision. Shadow results do not show task performance, actual robot motion or customer acceptance.
Limitations
Shadow execution cannot predict all physical behavior and does not validate policy performance. Move toward hardware only through the team's existing safety and operational process.
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.