Exporting and Validating Studio Policies

The physicalai-train package exposes ExportBackend (onnx, openvino, torch, executorch) and policy.export(output_dir, backend=...); physicalai export offers the CLI equivalent. Studio owns export; Runtime owns loading. See the export how-to and Runtime's manifest schema.

Workflow

1. Identify the inputs: installed policy class (e.g. physicalai.policies.ACT), .ckpt path, target backend, and the Runtime loader behavior expected for that backend.
   • Done when: all four are pinned before exporting.
2. Pick the route and keep both consistent — they must produce the same artifact:
   • Python: policy.export(output_dir, backend=ExportBackend.ONNX).
   • CLI: physicalai export --policy physicalai.policies.ACT --ckpt_path model.ckpt --backend onnx --output_dir ./export.
3. Read backend constraints before exporting. See the backend reference for the target (references/<backend>.md). If the selected policy/backend combination is unsupported, explain the constraint instead of modifying Studio source as part of a customer export.
4. Export, then validate numerical parity against the Torch policy path on representative inputs. Parity proves correctness.
   • Done when: max abs/rel diff on sample inputs is within the family's tolerance, or the divergence is understood and documented.
5. Validate artifact structure and metadata against Runtime's manifest schema.
   • Done when: the expected model file and metadata files exist, and input/output/feature names match Runtime preprocessing.
6. Confirm the Runtime path. For deployment-bound artifacts, verify Runtime can auto-detect (by extension) or explicitly load the backend via InferenceModel(...).

Validation loop