---

name: policy-deployment description: "Serve StarVLA checkpoints over websocket or GR00T-compatible ZMQ and debug policy client contracts." disable-model-invocation: true metadata: disco-role: operating license: NOASSERTION

policy-deployment

Use this operating sub-skill after a StarVLA checkpoint exists and the task is to serve it, connect a policy client, debug request/response schemas, or bridge the policy to a robot/controller stack. The current StarVLA serving path performs server-side action unnormalization: clients should consume response["data"]["actions"], not reimplement old normalized_actions handling.

Route first

• Websocket or ZMQ server protocol, server metadata, PolicyServerWrapper, PolicyNormProcessor, server_policy.py, server_policy_gr00t_zmq.py, ZmqGr00tPolicyServer, Gr00tCompatPolicy: read policy-server-protocols.
• Websocket client request/response schemas, image/state shape checks, GR00T named state/action split, optional helper validation: read client-contracts and use check_policy_server_contract.py.
• Real-robot or controller bridge design, safety gates, GR00T-WBC/Unitree G1/EgoVLA/RoboChallenge/Franka caveats: read real-robot-bridges.
• Failure diagnosis for checkpoint config/statistics, multiple unnormalization keys, request shape mismatch, stale normalized-action clients, codec mismatch, port/timeouts, or device/bfloat16 mistakes: read troubleshooting.

Route elsewhere when the question is not serving/client deployment:

• Simulator environment installation, benchmark-specific eval launchers, MuJoCo/Vulkan/rendering, or benchmark metrics -> ../benchmark-evaluation/SKILL.md.
• Dataset registry, data_mix, DataConfig, modality/statistics key construction, or dataset_statistics.json generation -> ../data-integration/SKILL.md.
• Training a checkpoint, YAML training overrides before a checkpoint exists, Accelerate/DeepSpeed, or resume planning -> ../training-config/SKILL.md.

Operating invariants

1. Start from server metadata. action_chunk_size, available_unnorm_keys, default_unnorm_key, training_data_mix, training_obs_image_size, and any exposed action_keys/state_keys are the authoritative handshake for a served checkpoint.
2. If metadata reports multiple available_unnorm_keys and no default, every inference payload must pass a top-level unnorm_key matching the requested embodiment/statistics key.
3. Websocket clients send a payload with examples; each example carries explicit image views, language, and optional state. The server never infers camera count or camera order.
4. StarVLA websocket responses return already-unnormalized actions shaped like [B, T, action_dim]. Treat docs or clients expecting normalized_actions as stale until migrated.
5. GR00T-compatible ZMQ clients use endpoint messages and the custom ndarray codec. Named state groups are flattened in checkpoint state_keys order; flat actions are split into named groups using action_keys and key dims.
6. --config_override KEY=VALUE is a repeatable OmegaConf dotlist override for the websocket server path. Do not pass a bare string into the Python API; pass a sequence of KEY=VALUE entries.
7. Robot bridges own observation capture, controller grouping, clipping, stale-action handling, and safety interlocks. They should not duplicate StarVLA action unnormalization.