Enterprise Workflow Video Data Collection

A workflow is a good fit for egocentric capture when it is a real, repeatable, hands-on physical task — operating equipment, assembling or inspecting a product, preparing an order, performing a maintenance check — rather than a purely cognitive or paperwork process with no physical manipulation component. The workflow does not need to already exist as a formal written SOP; a documented procedure, a training video, or a subject-matter expert walking through the steps are all workable starting points, because the capture program writes its own skill spec from whichever source is available.

A workflow with meaningful variation — different tools, part variants, or environmental conditions a worker encounters doing the same job — is still capturable; the written spec defines the range of scenes and variants the collection should cover rather than requiring a single, uniform version of the task. The same applies to a workflow that spans multiple stations or roles: it can be captured as one multi-step spec covering the full sequence, or split into separate specs per station if that better matches how the work is actually organized.

The workflow—whatever form it exists in today, from a formal SOP document to tacit knowledge in an experienced worker’s hands—is described in terms a capture program can act on: which tasks make up the workflow, which scenes and tool or object variants it needs to cover, which streams the training approach consumes (RGB alone, or RGB plus depth, IMU, and hand pose), and the accept criteria a captured take has to clear. That description becomes the written skill spec, the same format used for any custom order.

Writing the spec is also where ambiguity in the original workflow gets resolved: where an SOP document is vague about a step boundary or a completion check, the spec states it explicitly, so the people reviewing captured footage against the spec and the people who performed the original workflow are judging completion against the same written definition.

Task decomposition breaks the overall workflow into step-sized task units before capture starts — each unit becomes its own entry in the skill spec, with its own description, tools or objects involved, and completion check. A full run of the workflow is then captured as an episode, and action segments mark where each task unit begins and ends within that episode, so a continuous capture of the whole workflow still yields individually labeled steps rather than one undifferentiated clip.

Hand pose is captured as a label or stream where the spec calls for it, which matters for workflow steps defined by a specific grip, tool orientation, or manipulation rather than by gross body movement alone. Where a workflow step is prone to going wrong — a part seated incorrectly, a fastener missed — failure case coverage captures the error and the worker’s recovery as its own labeled segment, rather than only the clean completion path.

Every contributor performing a workflow signs a documented release as part of a consent chain, and that record travels with the data through delivery. Faces, license plates, and screens in the capture environment 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.

Workflow capture often happens on a real floor or in a real office, where confidential documents, screens, or other employees may appear in frame incidentally rather than as the subject of the recording. The same detect-and-blur anonymization step applies to anything caught in frame, not only to the contributor performing the task, so incidental bystanders and visible screen content are treated the same way as the primary subject.

The buyer. Delivered workflow data ships under a perpetual, buyer-owned, non-exclusive commercial license by default, with exclusivity available so a given workflow collection is not resold to another buyer. That license is what lets a model trained on the captured workflow ship in a commercial product rather than carrying research-only or hosted-access restrictions.

Provenance and data-processing documentation accompanies the license: the provenance page sets out what is actually delivered and the consent and anonymization checkpoints applied to every episode, and the DPA covers data-processing terms for the engagement — both written for a buyer’s legal team to review directly.

Finished workflow 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. RLDS and LeRobot are built around episodic, step-based sequences, which maps directly onto a workflow already decomposed into task-unit episodes with action-segment labels.

Because the episode and action-segment structure is set at the spec stage rather than reverse-engineered after capture, the same captured workflow can be re-exported into a different one of these formats later without recapturing, if a training pipeline changes.

Start by describing the workflow or SOP you need captured — whatever form it exists in today — and the tasks, scenes, and streams your training pipeline needs. That becomes a written skill spec, and the program typically starts with a Spec Pilot: a small, fast first batch captured against the spec, QA’d against the same accept criteria a full order gets, and delivered with its reject log before you commit to full volume.

A median of 48 hours from signed spec to first validated batch applies where coverage of the workflow’s setting is already deep; where the workflow requires contributors recruited into a new environment, region, or demographic from scratch, a realistic timeline runs three to four weeks. Either way, the same written spec that scoped the pilot scales directly into production volume once it is reviewed and accepted, with capture, QA, and delivery continuing in batches rather than as one large drop at the end.