Name each component
An action array needs a field-level dictionary, not just a dimension count. Identify joint targets, translation values, orientation values, gripper commands, or other components as applicable. Document ordering and valid missing-value behavior. A reader should be able to explain what each number asks the robot to do without reconstructing that meaning from a model training script.
Distinguish representation from execution
A target pose, velocity request, or incremental displacement has meaning only alongside the controller that applies it. Ask whether commands are absolute or relative and how long they remain active. Include units and reference frames. Two sources can describe similar physical motion through different interfaces, while apparently similar arrays can instruct very different motion.
Keep commands separate from feedback
Measured state records what sensors or the system reported; an issued action records what was requested. They can differ when motion is constrained, delayed, or interrupted. Preserve both when the project requires them, and explain their timing relationship. Do not rename measured changes as actions simply because they are convenient prediction targets for a particular experiment.
Verify with an interpretable episode
Inspect a simple movement and a gripper change alongside the fields. Confirm that the documented interpretation agrees with observed behavior and available source notes. Record conversions, normalization, and clipping used to create a delivered representation. If semantics remain uncertain, treat that as an unresolved sourcing issue rather than hiding the uncertainty behind a standardized file format.
Review checklist
- Define every action component
- Document controller and duration
- Separate commands from measured state
- Inspect conversion and normalization history