Enterprise Egocentric Data Collection

Robotics, AI, manufacturing, logistics, retail, and automotive organizations commission custom egocentric data when the tasks, environments, or embodiments their models need to learn are not already covered by a corpus they hold or can license off the shelf. That spans a robotics team scoping a new manipulation task, a model-training team closing a gap a policy keeps failing on in evaluation, and an operations team documenting real first-person workflows across warehouse, retail, or assembly sites.

What distinguishes an enterprise engagement from a smaller order is less the type of data and more the number of stakeholders involved: an ML team defining the spec, a legal team reviewing consent and licensing terms, and a procurement team reviewing the engagement before it is approved. The same written-spec, Spec Pilot, QA, and licensed-delivery pipeline serves all of them, scaled to however many teams and sites a given program covers.

The program starts with describing the real-world workflows a model needs to learn: which tasks, objects, scenes, and embodiments, and which streams (RGB alone, or RGB plus depth, IMU, and hand pose) and labels (action segments, hand pose) the training approach consumes. That description becomes a written skill spec, the same format used for any custom order, covering tasks, scenes, streams, labels, formats, and the accept criteria a batch has to clear before it is reviewed and signed off.

For an enterprise, the spec also functions as the shared reference document across teams: the ML team that defined the tasks, the legal team reviewing what consent and licensing the spec implies, and the procurement team reviewing the engagement are all working from the same written document rather than separate verbal briefings. Writing the spec once, in a shared format, is what keeps those reviews moving in parallel instead of serially.

Multi-site or multi-team programs do not require a different intake process — the same spec format scales to describe several workflows, sites, or embodiments in one document, or can be split into separate specs per team or site if that better fits how the program is governed internally.

Most programs start with a Spec Pilot: a small, fast first batch captured against the written spec, QA’d against the same accept criteria a full order gets, and delivered with its reject log and coverage reporting. For an enterprise buyer, the pilot is typically the artifact an internal governance or budget-approval process reviews before authorizing the full program, since it is a real, inspectable batch rather than a projection.

Once the pilot is reviewed and accepted, the same written spec — corrected for anything the pilot surfaced — scales directly into production volume without restarting the specification process. Capture, QA, and delivery continue to run in batches as the program scales, rather than as one large drop at the end, so validated data and passing QA arrive incrementally while later batches are still in review.

A median of 48 hours from signed spec to first validated batch applies where coverage is already deep; where a program needs contributors recruited into a new environment, region, or demographic from scratch, a realistic timeline runs three to four weeks, and that distinction is quoted up front against the written spec rather than discovered mid-program.

Every contributor signs a documented release as part of a consent chain, and that record travels with the data through delivery rather than being kept as a one-time assurance. Faces, plates, and screens are detected and irreversibly blurred at ingest, and a human reviewer confirms the anonymization result before anything ships, with the anonymization record delivered alongside the data.

These controls apply at every order size and are not an enterprise-specific add-on; what an enterprise program typically needs on top of them is the documentation that lets a privacy or legal team review the consent chain and anonymization record as part of its own approval process before a program is signed off.

Delivered data ships under a perpetual, buyer-owned, non-exclusive commercial license by default, with exclusivity available so a given collection is not resold to another buyer. For an enterprise, that license is the artifact legal reviews before a model trained on the data can ship in a commercial product, rather than a research-only or hosted-access arrangement that would need renegotiating later.

Provenance and data-processing documentation accompanies the license: the provenance page sets out what is actually delivered, how it compares with alternative licensing arrangements, and the consent and anonymization checkpoints applied to every episode, and the DPA covers data-processing terms for the engagement. Both are written for a buyer’s counsel to review directly rather than requiring a separate documentation request.

Every batch, regardless of when in the program it is captured or which team requested it, is reviewed against the same accept criteria written into the original spec, and footage that does not clear the bar is rejected and recaptured rather than shipped with a caveat. That means a batch captured early in a multi-quarter enterprise program is held to the same bar as a batch captured at the end.

Because the written spec is the single reference document for accept criteria, formats, and labeling, a program covering several sites or teams does not drift into inconsistent labeling schemes or format choices between batches — every batch is checked against the one document the program was scoped from, with a reject log delivered alongside each batch.

Finished data delivers in RLDS, LeRobot, WebDataset, HDF5, zarr, or Rerun .rrd, or as raw streams with metadata — the same set of formats available on any custom order, chosen to match whatever a training pipeline already consumes rather than requiring a new loader. RLDS and LeRobot in particular are built around episodic, step-based sequences that drop directly into common imitation-learning and policy-training pipelines.

On-demand top-ups run against the same written spec and accept criteria after the initial program, so a growing enterprise data program stays consistent with data already delivered to the same pipeline, rather than each new batch requiring its own format or labeling negotiation.