When should a configuration change require a new approval?

Choose the configuration boundary

List the inputs that change the policy-to-controller contract: device identity, controller package and parameters, model preprocessing, observation and action schemas, coordinate frames, and relevant runtime versions.

Same policy bytes, different declared joint order

Consider this illustrative review example. The artifact is unchanged, but two joint names exchange positions in the declared action contract. Reviewers need to decide whether the existing approval still describes the configuration being evaluated.

The unchanged artifact alone cannot establish that the approval still applies. Separate the fields included in the approved manifest from the facts the runtime actually observes, and from assumptions that still need independent engineering confirmation. A matching digest proves equality to declared content, not that a calibration is correct or that the selected boundary is complete.

Illustrative example only — not an RLSOK schema, runnable configuration, or captured customer result.

Before approval:
  artifact: same-policy
  declared joint order: [joint_a, joint_b, joint_c]

After a configuration edit:
  artifact: same-policy
  declared joint order: [joint_b, joint_a, joint_c]

Create a stable digest

• Normalize the selected configuration into a canonical manifest.
• Reference immutable artifacts rather than deployment filenames.
• Hash the manifest and include the digest in the policy release.
• Make the gateway compare the observed trusted digest before dispatch.

Change workflow

A change inside the approved configuration boundary needs a new release or new approval. Keep the original reviewed values for comparison; do not silently update them to make a mismatch disappear. Use a matching documented Shadow path to inspect the new decision before considering any run-mode integration.

A file and an active controller are different observations

A configuration-file digest shows which bytes were reviewed. It cannot establish that a running controller loaded those bytes or still owns the expected joint interfaces. The local source-workspace evaluation requires a separate controller-state export for its SO-101 and TRIK mappings.

That export reads the selected manager, node, state, claimed interfaces, declared parameters and applicable action endpoints. It is a bounded software observation, not an authenticated hardware snapshot. It does not prove firmware, calibration, compiled binaries or future execution.

Try one relevant step

For the documented UR5e/Jazzy reference, start with the Zero-to-Shadow instructions and inspect the release binding. For local source and interface comparisons, use the separate v1.5.0-shadow.8 evaluation guide and its exact prerequisites. Humble, private action compatibility and physical robot behavior remain unvalidated; local self-attested approval is not Hosted authentication.

After an actual attempt, one useful reply is the first binding field or setup step that was unclear. There is no need to submit a full technical report to give that first feedback.

Limitations

A digest proves equality to declared configuration, not that the configuration is safe or complete. Teams must decide the boundary through engineering analysis and retain independent protective controls.

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 release-binding implementation
• Source inputs and active-controller observation procedure
• Reported mock-controller comparisons and limitations

Continue with the relevant guide

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