# Egocentric dataset preparation checklist

Source: [How to Prepare Egocentric Data for Sale](https://www.humanoidsdata.com/articles/how-to-prepare-egocentric-data-for-sale#egocentric-dataset-preparation-checklist)

Template updated: 2026-10-05. Make a new working copy for each dataset release and intended buyer use. Complete this file in your Markdown editor or copy it into your project document.

## Release details

- Dataset name:
- Release version / manifest reference:
- Intended buyer and training or evaluation use:
- Dataset owner:
- Reviewer:
- Review date:
- Next review date:
- Review outcome (pending / blocked / ready for agreed delivery):

## Agreed acceptance criteria

Record buyer-specific criteria before using the checklist. Leave unresolved requirements open; do not invent missing measurements.

| Requirement | Agreed threshold or scope | Measurement / audit method | Evidence reference |
| --- | --- | --- | --- |
| Required tasks and coverage | | | |
| Required modalities and supervision | | | |
| Capture quality and critical-event visibility | | | |
| Timing and synchronization, if required | | | |
| Annotation quality and audit sampling | | | |
| Geometry accuracy, if supplied | | | |
| Duplicate handling and evaluation holdouts | | | |
| Accepted duration and billing unit | | | |
| Delivery format and tested loader version | | | |

## How to record progress

Tick an item only after checking its evidence. For conditional items, record **Not applicable** and a reason in your copy. A missing signal required by the buyer is a blocker, not a reason to mark it inapplicable. Depth, IMU, tracked poses, and calibrated geometry are optional unless the agreed product requires them. Use the buyer's documented thresholds rather than treating the illustrative numbers elsewhere in this guide as universal requirements.

## A. Define the dataset and acceptance criteria

- [ ] **A1.** Record the dataset name, release version, responsible owner, and intended training or evaluation use.
- [ ] **A2.** Write the task list, environments, object coverage, completion criteria, and excluded situations in a collection brief.
- [ ] **A3.** List each promised modality and label as measured, manually annotated, model-derived, or unavailable.
- [ ] **A4.** Agree on acceptance thresholds, audit sampling, rejection reasons, and rework responsibilities before scaling collection.
- [ ] **A5.** Have the buyer evaluate representative pilot episodes in the intended workflow; record accepted scope and unresolved gaps.

## B. Verify rights and privacy evidence

- [ ] **B1.** Trace every episode and third-party annotation or asset to evidence supporting the proposed commercial use and distribution.
- [ ] **B2.** Record the applicable personal-data processing basis, participant notices or permissions, and location permissions where needed.
- [ ] **B3.** Review video, audio, transcripts, metadata, and derived files for bystanders, identifying details, and confidential material; resolve flagged cases.
- [ ] **B4.** Check the delivered copy after redaction or exclusion, including whether privacy edits obscure required task information.
- [ ] **B5.** Keep signed releases and identity lookup records in restricted storage; put only appropriate references and restrictions in the delivery package.
- [ ] **B6.** Document retention, correction, withdrawal or removal handling, and how affected episodes and recipients will be identified.

## C. Inspect recordings and timing

- [ ] **C1.** Record the capture device, mount, firmware where known, resolution, frame-rate behavior, lens, stabilization, and available sensor streams.
- [ ] **C2.** Inspect complete task intervals for framing, required hand/object visibility, blur, exposure, and setup/outcome context against the agreed criteria.
- [ ] **C3.** Validate decoding and frame counts; identify missing, duplicated, frozen, or black frames and document their treatment.
- [ ] **C4.** Document timestamp units, clock domains, capture versus presentation time, frame indexing, and source-to-export time mappings; disclose unavailable timing information.
- [ ] **C5.** Where streams must align, measure offset and drift across recordings and document synchronization residuals, gaps, interpolation, or resampling.

## D. Validate annotations and optional geometry

- [ ] **D1.** For supplied annotations, version the guide and vocabulary; define the included instructions, actions, outcomes, failure/recovery labels, and unknown values.
- [ ] **D2.** If temporal segments are supplied, validate boundaries against episode duration and document interval-end conventions, overlaps, and frame mappings.
- [ ] **D3.** If annotations are supplied, audit a defined sample across relevant tasks and languages; record annotation origin, reviewer coverage, disagreements, and corrections.
- [ ] **D4.** If geometry is supplied, document camera models, calibration versions, units, coordinate frames, transform directions, and joint or quaternion ordering.
- [ ] **D5.** If estimated poses or pseudo-actions are supplied, record estimator versions, input lineage, validity masks, confidence meaning, and accuracy evaluation separately from availability.
- [ ] **D6.** Confirm that field names and documentation distinguish human motion and derived targets from measured robot state or commands.

## E. Audit quality, coverage, and evaluation splits

- [ ] **E1.** Publish a quality report with metric definitions, denominators, audit sample sizes, rejection reasons, and known limitations.
- [ ] **E2.** Reconcile accepted episode hours, active-task hours, camera-stream hours, and annotated hours without double-counting overlapping exclusions.
- [ ] **E3.** Report accepted coverage by task, source session, site, participant, and object instance using the necessary non-identifying references.
- [ ] **E4.** Identify duplicate and near-duplicate groups; where splits are supplied, keep related source clips and their derivatives in the same split.
- [ ] **E5.** If evaluation splits are supplied or claimed, check that participant/site holdouts match that claim and that learned preprocessing does not leak evaluation data.

## F. Build and test the delivery package

- [ ] **F1.** Include a release-specific dataset card, license, schema, manifest, change log, quality report, and file checksums.
- [ ] **F2.** Verify unique episode identifiers, file references, required fields, array shapes, units, missing-value conventions, and annotation-to-video mappings where supplied.
- [ ] **F3.** Pin the exporter, dependencies, and tested loader version; finalize any writers before validating the release.
- [ ] **F4.** Load representative and randomly selected episodes from the final package in a clean environment using the supplied instructions.
- [ ] **F5.** Where applicable, check format-specific semantics such as LeRobot episode offsets or RLDS step fields, terminal states, and invalid final-step actions.
- [ ] **F6.** Test the agreed transfer method, selective or resumable access where promised, downloaded-file checksums, and access restrictions.

## G. Review the commercial handoff

- [ ] **G1.** Confirm that the listing and sample match the actual release, including missing modalities, accepted counts, rights restrictions, and quality limitations.
- [ ] **G2.** Define evaluation versus training rights, affiliates/contractors, redistribution, derivatives, and any exclusivity scope and duration in the agreement.
- [ ] **G3.** Agree on the billing unit, acceptance window, rejection evidence, rework limits, payment milestones, and storage or egress costs.
- [ ] **G4.** Record the exact release and episode manifest supplied to each recipient, with a contact and process for corrections or removals.
- [ ] **G5.** Complete the release review: resolve blockers and document buyer-agreed quality exceptions with their impact, owner, and follow-up action.

For each item, keep an evidence reference and one of four statuses: **Done**, **In progress**, **Blocked**, or **Not applicable**. For example, D4 can be “Not applicable — RGB-only product; no calibrated geometry promised.” C5 must remain blocked if synchronized streams were promised but their alignment cannot be verified. Store references to sensitive rights evidence rather than copying that evidence into a shared checklist.

Do not reduce this review to a percentage score. Unresolved commercial rights or privacy release issues, corrupt or unloadable required data, and missing or contradictory required timing, identifiers, or supervision should stop the affected material from being delivered. A completed checklist records the preparation and review performed; it does not independently certify legal compliance or guarantee model performance.

## Evidence and action log

Add one row per checklist item, using its ID. A tick records Done; leave other items unticked and explain their status here. Use references to restricted records, not personal data or signed releases.

| Item ID | Status | Evidence / exception reason | Owner | Next action and due date |
| --- | --- | --- | --- | --- |
| | | | | |

## Release decision

- Unresolved blockers and affected episodes:
- Excluded material and exclusion-manifest reference:
- Buyer-agreed quality exceptions and supporting agreement:
- Final release manifest / checksums reference:
- Reviewer and decision date:
- Intended recipients and transfer method:
- Correction / removal contact and process: