Exclusive Egocentric Training Data

Exclusive training data means no other lab is licensed to train on the same footage or, in the stronger form, on data captured to the same skill spec. That is a narrower claim than “custom” or “commissioned”. A vendor can build a dataset to your spec and still sell equivalent data captured under a similar spec to someone else, unless the contract says otherwise.

Egocentric training data is first-person video recorded from the operator’s own point of view, with synchronized sensor streams and labels alongside. This page is about buying a custom collection of it where exclusivity is one of the terms you can ask for. It is general information about how the site words these terms, not legal advice.

Two things are kept apart throughout. Where the footage comes from is a sourcing question: it is captured by our own contributors to your spec. Who else may receive it is a licensing question: non-exclusive by default, with exclusivity available as a named term. Mixing the two is how buyers end up assuming protection they were never given.

A public dataset is available to every lab that wants it, so anything trained on it is available to competitors on the same terms. A shared or off-the-shelf commercial dataset is usually licensed non-exclusively to many buyers at once, so the underlying footage is not unique even when the license is commercial. Neither gives a lab a data advantage its competitors cannot also buy.

Custom collection changes the starting point. The target is agreed in a written spec before any contributor is briefed, the footage is recorded by contributors in our own network, and the recordings exist because a buyer asked for them. It does not change the license on its own: the default grant stays non-exclusive until exclusivity is negotiated in.

The table below sets the three side by side. Our custom vs. off-the-shelf comparison covers the fuller buy-versus-build question, and the first-party page covers the sourcing chain in detail.

The buyer owns it. Delivered data ships under a perpetual, irrevocable, worldwide license that is non-exclusive by default. The permitted use is training, evaluating, fine-tuning and deploying models, including commercial models. Derived weights are yours, with no royalty, no revenue share and no reporting obligation, and there is no expiry: a lapsed program does not revoke data already delivered.

Redistribution is not permitted for the footage itself, and is unlimited for models derived from it. We warrant the consent chain for every delivered episode and indemnify against claims arising from it. The terms page adds that delivered datasets are licensed under the terms of the applicable order form, and that where the order form grants a perpetual, buyer-owned commercial license, those license terms control over anything on that page.

Duration and exclusivity are independent. A buyer can hold a perpetual but non-exclusive grant, which is the default here, or a perpetual grant with exclusivity added. Our perpetual vs. term guide explains the duration axis, and the table below lists each term with the page that states it.

Exclusivity is available per skill line or per environment, priced as a multiplier, as the provenance page words it. This page states no multiplier or price, because none is published; it is quoted against your spec. Exclusivity is an added term on top of the base commercial license, and it is what guarantees the demonstrations you pay for will not also be resold to another buyer, including a competitor.

A buyer-owned license is necessary for exclusivity but not sufficient for it. It settles who can train on the delivered footage and for how long; it does not by itself stop a vendor capturing equivalent data for another party. So the exclusivity term has its own scope, and our exclusivity guide describes that scope as a negotiated decision rather than a fixed default.

That guide describes the scope choice this way: covering only the footage stops the exact files being resold, while covering the spec as well stops near-identical data being captured under the same task design for another buyer. Duration is likewise negotiated rather than set as a default. We do not state a period on this page, and the site does not either.

It does not make a dataset legally unchallengeable, and nothing here is legal advice. Have counsel review the actual order form. It does not replace consent: the consent chain is the ceiling a license cannot exceed, which is why every contributor signs a release before capture and the consent artefact IDs are listed per episode in the batch data card.

It also does not turn human demonstrations into robot data. Firsthand captures first-person human video, not robot or teleoperation data, and capture does not take place at a customer’s own facility. Using the episodes for a specific robot means your own pipeline bridges the embodiment gap.

Finally, exclusivity says nothing about model quality or results. We do not claim that any customer’s model was trained on this data or performed in any particular way. What exclusivity gives you is a contractual position on who else can receive the data, nothing more.

You describe the task your pipeline needs covered and that becomes a written skill spec: the tasks, environments, objects and streams, how many attempts, what counts as a completed attempt, and the accept criteria. It sets the capture tier and annotation depth, and says how much failure and recovery coverage the batch should include.

The spec is also where exclusivity belongs. Our exclusivity guide says to write the exclusivity terms into the skill spec and order form before capture begins, not to ask after delivery. That means naming the license, the consent and provenance documentation you will receive, and the scope of the exclusivity, alongside the usual task and acceptance criteria.

The spec is quoted for reach, timeline and price before any capture begins, and the accept criteria are signed into it. Most programs begin with a Spec Pilot: a small, fast first batch that proves the spec and the accept criteria hold up on real footage, with coverage, reject rate and a real timeline figure, before you scale to the full order.

Paid, consented contributors perform the real task against your spec while wearing the capture rig. The instrumented tier is a head-mounted stereo rig: first-person RGB, with a metric depth stream recovered from the calibrated stereo rig rather than from a standalone depth sensor, and 6-DoF IMU data at 200 Hz from head- and wrist-mounted sensors.

Every stream is hardware-triggered onto one PTP clock domain, with int64 nanosecond timestamps per stream, so depth, motion and hand pose are aligned to the same video frame rather than approximated afterwards. The rig is calibrated before capture and again after the session ends. Wrist views are delivered as their own streams alongside the head view.

Collection is on demand, so you do not need a standing program, and a focused brief is a normal starting point. Contributors are paid hourly, with no per-task bounty. Because the footage is collected through our own network to your spec, there is no unknown intermediary between the person recorded and the dataset you receive.

Each attempt is one episode. Inside it, action segments divide the task into start- and end-timestamped spans, each carrying start_ns, end_ns, verb and noun. The other fields are the standard episode schema: hand_joints and hand_visible for 21-joint 3D hand pose with a per-joint visibility flag, wrist trajectories, contact_events for the moment the hand meets an object, and objects.

Where the spec calls for it, per-frame instance masks are delivered at the depth resolution, 848×480. The head and wrist IMU streams carry the motion record that goes with the video. The table below maps each label to its delivery field as listed on the episode schema page. No field is specific to exclusive orders: exclusivity changes who may receive the data, not what is in it.

Acceptance is measured against signed accept criteria written into the spec before capture begins. Each batch goes through per-batch QA, and a reject log ships with every batch. An episode is accepted only if RMS reprojection stays under 0.28 px and the drift is within tolerance; otherwise it goes to the reject log. Only footage that clears the criteria is billed as a validated hour, and rejected items are recaptured at our cost.

The consent chain is documented on the provenance page. Before capture a written release is signed and identity verified. At capture, site permission is on file. At ingest, faces, plates and screens are detected and speech is scrubbed of identifiers. At review, a human confirms no un-consented person is identifiable in any frame. At delivery, consent artefact IDs are listed per episode in the batch data card.

Clips that cannot be de-identified are discarded rather than delivered. Delivered footage cannot be recalled after delivery, and the release says so; withdrawal requests are honoured for undelivered footage. De-identification protects the people captured rather than the exclusivity term itself, but footage with identifiable bystanders is harder to hold and license exclusively in practice.

You receive the accepted episodes in the format your stack already reads: RLDS, LeRobot, WebDataset, HDF5, zarr or Rerun .rrd, or raw streams with metadata. Readable converter source ships alongside the data so the schema can be retargeted to your own loader.

Each batch arrives with its data card, the consent artefact IDs listed per episode, the signed accept criteria it was measured against, and the reject log. If exclusivity is part of the order, the terms you agreed are the ones written into the order form, which is the document the terms page says governs.

From signed spec to first validated batch, the timeline is a median of 48 hours where coverage is deep and three to four weeks where it is thin and contributors need to be recruited first. After the first batch, on-demand top-ups run against the same accept criteria, so you can add more attempts or environments without rewriting the spec.

Negotiating exclusivity is a contract step, and this page makes no promise about how long it takes. Settling the scope early, in the Spec Pilot conversation, is the way to keep it from becoming the slow part.

Describe the tasks, environments and streams your model needs, and say whether you want exclusivity, and over what scope: the footage, the spec, or both, per skill line or per environment. That becomes a written skill spec, quoted for reach, timeline and price before capture begins, and most programs run a Spec Pilot first.