Define the unit of behavior
An episode may be a complete task attempt, an operator session, or an export segment. Ask what actually determines its boundaries. A fixed-length file can cut across multiple attempts, while one task may span several files. Describe the review unit your model needs and require enough identifiers to reconstruct that unit from the delivered records.
Separate reset from execution
Moving objects back to a starting arrangement or repositioning the robot may not belong to the task behavior the learner should imitate. Decide whether reset steps are excluded, labeled, or delivered as a separate phase. Record when assistance or a controller restart occurs. Otherwise, reset movements can appear to be unexplained actions within a nominally successful task.
Explain why the episode ended
Completion, timeout, interruption, collection stop, and system error carry different meanings. Keep termination reason separate from task success. A recording can end normally without the task being complete, and a successful result can occur before recording stops. Ask how final observations and actions are represented so a loader does not silently invent an extra executable step.
Check boundary examples in a pilot
Review a clean completion, an interrupted attempt, a retry, and a reset sequence. Compare the boundary flags to the images and action records. Keep the source schema and any export conventions available to reviewers. Resolve disagreements before aggregating episode counts, since a collection’s apparent size depends heavily on what its episode unit actually represents.
Review checklist
- Define what creates an episode
- Label reset and assistance phases
- Separate termination from success
- Review interrupted and repeated attempts