Skill-Spec-Driven Egocentric Data Collection

Skill-spec-driven egocentric data collection is custom first-person capture in which a written skill spec, not a catalog, decides what gets recorded. The site defines a skill spec as the written contract for a capture program: the named skill, the environments and conditions to cover, the acceptance criteria and the target hours. Nothing is captured speculatively.

This page sells the collection service built around that spec: fast, on-demand, custom collection scoped to the tasks, environments and streams your model is missing. It is not the guide that teaches you to write a spec, and it is not a glossary definition. The guide covers the writing method; the custom egocentric dataset page covers the mechanics of the order. Here the focus is how the spec drives everything that follows.

The site’s guide says a skill spec has five parts: the named skill, the geometry that must be visible, the condition budget in hours, the reject rule and a single acceptance test. Everything else is commentary. The rules behind the parts are to name the verb and the noun rather than a broad activity, to state what must be in frame and for how long, to budget hours per condition cell including failure cases, to write the reject rule first, and to give one acceptance test.

The guide’s worked example is dicing an onion with a chef’s knife. It requires both hands visible at grasp and first cut, budgets hours across daylight, low light, cluttered and failure-case conditions, and rejects an item when the cut is off-frame for more than two seconds, a second person’s hands enter the manipulation region, or depth is invalid over 35 % of the board region. That illustrates the shape of a spec. It is not a fixed template or a program size, and your spec’s fields and numbers are agreed with you.

Capture is briefed from the spec. The named skill sets what contributors perform on camera, the geometry sets what stays in frame, and the condition budget sets which environments and conditions are covered, with failure cases as their own cell. Failure cases and recoveries are recorded uncut rather than edited out.

Labels follow the spec. Hand pose, body pose, segmentation and action labels each add equipment, QA passes and cost, so the site advises ordering what the model consumes rather than everything available. Labels match the accept criteria written into the spec.

QA is applied against the spec. Every item is checked against the reject rule and acceptance test, sync and calibration are verified, and anonymization of faces, plates and screens is reviewer-confirmed before anything ships. Where several streams are ordered, they are hardware-triggered onto one PTP clock domain with a stated sync error of 1.12 ms median, 1.94 ms p99 and a 2.0 ms ceiling, and an episode breaching the ceiling is rejected.

A spec names the streams per episode. The site lists video from the head and wrist cameras, depth, IMU, hand pose, body pose, segmentation and action labels, with RGB as the baseline and the others added where the spec calls for them. Each added stream is a separate cost and QA lever, which is why the streams list belongs in the spec.

The spec also names the delivery format so the data loads without a conversion pass. The site states RLDS, LeRobot, WebDataset and HDF5 for custom collections, and its pilot page adds zarr, Rerun .rrd and raw streams with metadata. Field layout follows the format pages and the episode schema. Anything those pages do not state, such as how a particular label is stored in your chosen format, is set per program in the skill spec.

The site states the order flow as spec, quote, Spec Pilot, scale. The quote is scoped against the written spec because reach, stream count and turnaround each move the number independently. The Spec Pilot is a small, fast first batch captured against the spec, QA’d and delivered with a reject log and coverage report, the same reporting a full order gets.

Once the pilot is accepted, the same spec, corrected for anything the pilot surfaced, scales into the full order without restarting specification. Capture, review and delivery then run in batches, so validated data arrives and QA passes before the program is fully delivered. A pilot can start from a focused written brief covering tasks, scenes and required streams and labels.

Firsthand reports fill rates against the spec per batch, by condition, not just an hour count. The coverage report tells you where the data is thin before training does, and the reject log records each rejected item and why. Both sides look at the same document when a batch is accepted.

Footage that fails QA is rejected and recaptured at the provider’s cost, not billed to you. You are billed per validated hour.

An off-the-shelf egocentric dataset is fixed to whatever it already contains, under whatever license its publishers attached, which is frequently research-only. Without a spec, the site says, you get generic footage and discover the gaps after training. A spec-driven collection reverses that order: the gap is written down first, the data is captured to it, and coverage is measured cell by cell.

Custom is not the answer every time. If a public dataset already covers the gap under a license you can use, there is no need to commission a custom order for it. Choose spec-driven collection when the gap is specific, when you need a commercial license a research-only dataset does not grant, or when you need data on a timeline a static release cannot meet.

Where coverage for your tasks, environments and regions is already deep, the median time from signed spec to first validated batch is 48 hours. Where coverage is thin, turnaround runs three to four weeks, because recruiting has to happen in parallel across more regions before capture can scale. A Spec Pilot gives a real small-scale number for your spec.

There is no fixed price list. Cost moves with the stream count per episode, the validated hours the order requires, how thin or deep existing coverage is, and how fast you need the first batch. You are quoted against the written spec.

Delivered data ships under a perpetual, buyer-owned commercial license, not a hosted-access or research-only arrangement. Every contributor signs a consent release before capture, and that consent record travels with the episode through delivery.

Several details are not fixed on this site and are agreed in the spec instead. The table below separates what the site states from what is set per program, so a buyer can see where the spec conversation starts.

Send the tasks or skills, the environments and regions, the contributors, the streams and labels, the accept criteria and the delivery format you need. If you do not have a written spec yet, the first draft is written with you on a call and handed back as a file for your repository. Then ask for a quote or a Spec Pilot.

If you would rather check the data before specifying anything, the sample page shows what the sample pack contains. If you want the writing method first, read the guide. Otherwise use the request below, and we scope a Spec Pilot or a quote against your spec.