Define structure and meaning together
A schema should state required fields, shapes, types, and missing-value behavior, alongside the meaning of actions and observations. Structural validity alone cannot explain a controller convention or success label. Keep a field dictionary with the export and identify which source or configuration each definition applies to when a collection contains several robots.
Explain episode and step semantics
Describe boundary fields, terminal observations, and the relationship between actions and observations. RLDS is a primary reference for an episode-and-step data model, but a format name does not supply every source-specific convention. Review how the particular export represents interrupted tasks, missing sensors, and final records so a loader does not create unintended behavior.
Record meaningful revisions
Changing units, action mappings, image processing, or outcome labels can affect model results even when filenames remain stable. Assign versions and retain a change log with affected episodes or fields. Distinguish a metadata correction from replacement media and explain whether prior annotations still apply. Buyers should be able to identify which exact representation their experiments used.
Validate through the intended consumer
Load representative data with the buyer’s actual pipeline and check how optional fields and boundary conditions are handled. Keep source references and conversion settings available for review. A schema revision should trigger checks appropriate to what changed rather than a blanket claim of compatibility. Include required format, conventions, and version expectations in a sourcing inquiry so delivery scope is concrete.
Review checklist
- Pair structural schema with definitions
- Document terminal and step behavior
- Version semantic and media changes
- Inspect loading of optional fields