What Should a Robotics Data Collection SLA Include?

A robotics data collection SLA (service level agreement, sometimes folded into a statement of work) is the contract that turns a vendor selection into an enforceable commitment. It names the exact scope of what will be captured, how quality will be measured, who owns the result, and what happens when a batch does not meet the bar — before any footage is recorded, not after a dispute starts.

This page assumes you have already chosen a provider. If you are still comparing vendors, our robotics training data RFP checklist covers what to ask for during that selection; this page covers what to write into the agreement once that choice is made. A written skill spec, as described in how custom robotics data collection works, is normally the technical annex the SLA points to.

This page is general guidance, not legal advice. Have counsel review any contract before signing.

The SLA should reference a written skill spec as an attached exhibit, not describe scope only in prose in the contract body. The spec is where task, geometry, environments, condition cells, capture tier, annotation depth, and hour or episode targets per cell are fixed — the contract terms only make sense once that document exists.

The agreement should state that any change to the spec — a new task, a new environment, a different annotation set ��� requires a written change order rather than an informal request, so scope creep does not quietly expand the engagement without a corresponding change to price or timeline.

The SLA should state that billing is per validated hour — footage that has already been measured against the signed accept criteria — not per raw capture hour before anyone has checked it. That distinction determines who bears the cost of footage that fails QA: under a validated-hour term, the provider does, since unvalidated footage is never billed.

The accept and reject rule itself belongs in the contract or its spec exhibit as a written, testable definition, not a general "quality guaranteed" clause. A rule that cannot be checked against a delivered batch is not enforceable if a dispute arises later.

The SLA should require a reject log — items that failed the accept criteria, with reasons — delivered alongside every batch, not only an aggregate pass rate. A reject log is what lets a buyer audit the bar a provider is actually holding, rather than trusting a summary number.

It should also state what happens to rejected items: whether they are recaptured at the provider’s cost, and on what timeline. A contract that is silent on rework leaves the buyer negotiating that question batch by batch instead of once, up front.

The SLA should require a documented consent chain: a signed release per contributor, per episode, that covers not only the person performing the task but anyone who appears in frame incidentally. It should also state that this consent record is delivered with the data, not just held internally by the provider, so the buyer can audit it if a question arises later.

It should specify the anonymization method — detecting and irreversibly blurring faces, license plates and screens at ingest — and require that a human reviewer confirms the result before delivery, rather than trusting automated detection alone. The anonymization record should ship with the batch it applies to.

The SLA should state the license explicitly: a perpetual, buyer-owned commercial license, not a shared, research-only, or revocable one. Many public and academic corpora carry research-only terms that block commercial deployment — a custom collection contract exists in part to avoid inheriting that constraint, and the terms should say so in writing rather than being assumed.

If exclusivity matters to the buyer — meaning the same footage is never resold to another party — that should be a named contract term, since it is not automatically implied by a buyer-owned license on its own. See buyer-owned training data for how ownership and exclusivity differ as contract concepts.

The SLA should name the delivery format the training pipeline actually loads — RLDS, LeRobot, WebDataset, or a schema built on HDF5, zarr, or Rerun .rrd — rather than leaving the format open to be decided after capture starts. It should also require a data card with every delivery, documenting provenance and the consent and anonymization records behind that batch.

For timeline, the contract should reference the provider’s own stated delivery pattern rather than inventing a number: where coverage is already deep, a first validated batch typically lands in a median of 48 hours from a signed spec; thinner environments run three to four weeks because vetting contributors there is the bottleneck. Whatever number the provider quotes, it should be a contract term, not a verbal estimate, and rolling top-ups after the first batch should follow the same spec and accept criteria.

A change-request clause should require any scope change — a new task, environment, or annotation type — to go through a written change order with its own price and timeline, rather than being absorbed silently into the existing schedule.

A pilot data collection is a small first batch run against the same spec and accept criteria the full engagement will use, and the SLA should say explicitly that the pilot and the production run share one spec, one accept/reject rule, and one billing unit. Without that clause, a provider could pass an easy pilot and then quietly loosen its criteria once full volume is committed.

What typically changes moving from pilot to production is volume and cadence, not the underlying terms: the contract should specify a rolling batch schedule for production rather than a single delivery, while keeping the same reject-log reporting, the same per-condition-cell fill-rate reporting, and the same license terms that governed the pilot.