Find release-control gaps before a learned policy reaches hardware.
A Shadow Audit is a focused architecture discussion about the identity, approval, configuration, authorization, and evidence around a learned-policy release. It is intended for teams moving from simulation toward repeatable real-robot deployment.
Request a Shadow AuditWho it is for
- ROS 2 teams deploying learned or autonomous policies.
- Teams with simulation-to-real workflows and more than one robot or configuration.
- Engineering leaders who need explicit approval, revocation, and audit evidence around releases.
Risks we examine
- A model artifact changes after review but keeps the same human-readable name.
- An approved policy is dispatched to the wrong device or controller configuration.
- Approval is mistaken for permanent permission to execute.
- Revocation and decision evidence are disconnected from the local dispatch path.
What you bring
Bring a high-level release workflow, representative model or policy identifiers, robot and controller configuration boundaries, and the point where ROS 2 dispatch occurs. Sanitized diagrams and sample manifests are enough; credentials, production data, and access to a real robot are not required.
The 30–45 minute architecture discussion
- Map the path from training output or model registry to a named release.
- Identify the approval subject and the immutable content it actually binds.
- Locate device, controller, and action checks immediately before dispatch.
- Walk through revocation, failure behavior, and the evidence available afterward.
Proof-of-concept options
The process can begin without connecting to a real robot. A follow-on proof of concept can use simulation or ROS 2 Shadow Mode to evaluate the control path while suppressing hardware commands.
Expected deliverables
- A concise release-control boundary map.
- A list of identity, approval, authorization, and evidence gaps.
- A proposed simulation or Shadow Mode validation sequence.
- Explicit assumptions, limitations, and next decisions for the team.
Frequently asked questions
Do we need to connect a real robot?
No. The first discussion can use architecture diagrams, sanitized manifests, and a representative release path.
Does the audit certify a deployment as safe?
No. It identifies release-control assumptions and gaps; it is not a certification, compliance assessment, or functional-safety evaluation.
Can it cover an existing model registry?
Yes. The discussion can start at your current registry or artifact store and trace the bindings through local ROS 2 dispatch.
Continue the architecture review
Ready to map the release path? Request a Shadow Audit.