How the platform works

Specification, contract, collection, validation, delivery, evaluation and the next collection. Each stage leaves an artifact you can check.

From brief to next batch

When a policy is evaluated, its failures become the next specification, and targeted collection is measured against an equal-budget control. A negative result is reported, not hidden.

Before collection

Task specificationSkill, embodiment, streams
Acceptance termsReview window, codes
Rights and site approvalIn writing

During collection

Pilot sampleReviewed by you
Supervised captureEvery attempt logged
ValidationAccepted or coded

After delivery

Versioned datasetManifest, checksums
EvaluationFailure profile
Next batchAgainst a control

You hold accepted data, and what to collect next.

Run around accepted data

Labour is only cheap if the data is accepted. We schedule, supervise and measure collection around the cost of an accepted episode, not paid hours or simultaneous camera streams.

The operator. Paid, trained on the versioned SOP and identified by pseudonym. Pay never silently depends on a buyer's rejections.

The supervisor. Named for each site. Owns resets, safe stops, intervention logging and the attempt log, failures included.

The reviewer. Independent of collection. Applies the contract's acceptance criteria and its reason codes.

One validated cell before any replication.
Active manipulation and reset time reported separately.
A paid trial and a defect taxonomy before volume.
Uploads and checksums verified on site.
Existing operations preferred over new facilities.
Partner production lines left untouched.

One capture contract per task

Before collection, buyer and Motionyard agree the exact fields every episode carries. Force and torque are included only when a sensor measured them, never inferred from video.

Capture contract fields for one episode
Field	What it records
Episode ID	Unique and immutable
Task and version	The SOP version the attempt was run against
Site and operator	Operator by pseudonym, with the permission record
Modality	Footage, staged demonstration, teleoperation or engineering data
Embodiment	Robot and end-effector identity, calibration hash
Observations, commands, state	Synchronized, with per-stream timestamps
Objects and fixtures	Which parts and fixtures were in the cell
Start, end and reset times	Active manipulation and reset reported separately
Interventions	Takeovers, safety stops, manual repositioning
Failures and recoveries	Labelled segments within the attempt
Outcome	From a check the model under test cannot influence
Checksums	For every stream file
Review result	Accepted, or rejected with its code
Split	Train, diagnostic or holdout

Accepted, or rejected with a reason

Rejected units are kept with their codes where authorized. Excluding every failure would bias evaluation and throw away useful recovery data.

Stream synchronization R01: All required streams present and aligned within the contracted tolerance.
Calibration lineage R02: Calibration and firmware hashes match the session record.
Outcome verifiability R03: The terminal outcome is confirmed by an independent check, not inferred from video.
Intervention disclosure R04: Every human assist is flagged; none is edited out.
Rights lineage R05: Site, worker and customer permissions cover this unit and its intended use.
Task conformance R06: The attempt followed the SOP version, objects and fixture it claims.

Rights are part of the data

Every unit carries a permission lineage. If we cannot show where a right came from, the unit is not delivered. Local recording, privacy and labour rules are reviewed by counsel in each country before collection.

Site authorization. Written approval of the specific workflow, camera views and data fields. A membership or an introduction is not permission.

Worker participation. Informed consent and explicit terms; operators are pseudonymized in delivered data.

Customer IP excluded. Owned parts and open designs by default. No customer drawings or production records.

Scoped licences. Training and evaluation use, exclusivity, retention and territory, written per contract.

Pay for accepted data

A task-engineering fee covers specification, fixtures and qualification. Volume is priced per accepted unit, with fixed review windows and milestone payments rather than open-ended rework.

<dataset>/<version>/
  manifest.json
  schema/capture_contract@1.json
  splits/{train,diagnostic,holdout}
  episodes/<episode_id>/...
  rejected/<episode_id>.reason
  sop/<task>@<version>/
  checksums.sha256
  acceptance_report

Format. Agreed at specification to match your training stack; the schema is versioned with the data.

Versions. Immutable and checksummed. A refresh batch is a new version, never a silent edit.

Splits. Diagnostic and final holdout reserved up front; the holdout never chooses the next batch.

Acceptance. A report per batch: accepted units, rejections by code, active and reset time.

Evaluation decides the next batch

Metrics are defined before data is collected, every denominator is reported, and the comparison that matters is targeted collection against an equal-budget control. Read the evaluation protocol.

Task success: All SOP criteria met within the declared attempt and time limits, without disallowed help.
Recovery: Success after a permitted autonomous correction, reported apart from first-attempt success.
Intervention: Operator takeover, safety stop, manual repositioning or unplanned reset. Never edited out.
Speed: Wall-clock execution and reset time, not sped-up video. Failed trials stay in the denominator.
Economics: Accepted episodes per paid operator-hour, review minutes and rejection causes.

Embodiment-agnostic, purchase-gated

We collect on the interface our buyer specifies. A teleoperation station is one cooperative workcell, and a low arm price is not a cell. We commission one, prove it, then replicate. No safety certification is implied.

Commercial gate
The buyer accepts modality, country and embodiment before hardware is committed.
Mechanical gate
Real sample parts fit payload, jaw width, reach and joint limits; a two-arm envelope is collision-free.
Software gate
A supported record and replay path; state, action, time and camera calibration captured; firmware pinned.
Delivery gate
A written equipment list and arrival commitment, with spares on hand.
Safety gate
A site risk review, restrained fixtures, low speed, a trained supervisor and an accessible safe stop.

Bring us a task gap, and we will scope the data for it.

Request a dataset Become a data partner