Define the recovery situation
Name the event that creates the need for recovery, such as a missed grasp, object displacement, or incomplete insertion. Distinguish ordinary task progression from a return after an error. Specify whether the collection should contain naturally occurring problems, intentionally introduced perturbations, or both. Keep those origins visible so a buyer can interpret how the behavior was generated.
Retain the preceding context
A recovery action can be difficult to understand without the observation and command that preceded it. Request enough history to identify the error and the state from which the response begins. Do not join a failed attempt and a later successful attempt as one uninterrupted sequence if a reset or operator adjustment occurred between them.
Record who intervened
An operator may alter commands, move an object, reset the controller, or take over the task. Label these events with timing and source context where available. A recovery performed by a human controller is not the same as autonomous recovery. The dataset should make that distinction available rather than leaving the buyer to infer control mode from video.
Review the final result and grouping
Specify whether a recovered task counts as success and how multiple attempts are linked. Keep related attempts together when the evaluation design requires independence. Inspect whether the record includes all relevant actions and observations, not only a curated ending. For sourcing, provide recovery scenarios and outcome rules so feasibility can be assessed against real collection conditions.
Review checklist
- Name error and recovery triggers
- Preserve pre-error context
- Label assistance and control changes
- Link retries and define outcomes