Inputs
Egocentric or external video, robot episodes, sensor streams, state, actions, force or tactile data when present, task protocol, and target schema.
← All data programs
Physical data, episode to loader.
Turn demonstrations and robot logs into synchronized episodes with task phases, actions, object state, outcomes, failures, and uncertainty represented as separate signals.
- episode
- ep_000184 / native source
- phase
- reach to grasp
- observation
- hand closes around object
- robot action
- null when not supplied
- outcome
- partial success / reviewed
- sync
- streams checked before export
Keep observations and actions separate.
Human video, robot state, controller actions, force, and outcomes are different signals. The program only claims what the source data can support.
Managed work
Capture planning, episode filtering, temporal annotation, object and pose work, language grounding, synchronization review, and schema mapping.
Outputs
Accepted episodes, stream references, phases, interactions, outcomes, failures, tracks, provenance, rejection reasons, and a dataset card.
Quality
Protocol tests, file and stream checks, timestamp audits, boundary review, failure review, duplicate detection, and representative loader validation.
Delivery
The buyer's native episode format remains authoritative, with an agreed compatibility export when useful and technically supported.
Data organized around embodied work.
The program distinguishes capture, curation, annotation, and conversion so a buyer can see where each signal came from.
Collect human demonstrations
Design buyer-defined protocols, qualify participants and devices, validate views and task resets, and record consent, rights, and allowed metadata.
Curate robot episodes
Find broken runs, missing streams, invalid resets, duplicates, interventions, recovery attempts, rare failures, and underrepresented outcomes.
Describe action through time
Mark task phases, actions, contacts, object states, outcomes, failures, recovery windows, poses, tracks, and grounded instructions as scoped.
Align the training record
Review camera and sensor timing, map native fields, preserve explicit nulls, and test representative episodes in the buyer's loader.
Test the protocol before collection.
Physical data gets expensive when an unusable view, missing stream, or ambiguous outcome is discovered after the run.
- 1.0
Define the task
Name the embodiment, environment, inputs, expected signals, outcome rule, rights, and target model job.
Output: task and data specification - 2.0
Inspect the episodes
Review representative successes, failures, resets, missing streams, timing issues, and native loader behavior.
Output: capture or curation map - 3.0
Calibrate the protocol
Run a small batch, test collection or labeling rules, and confirm what can be observed versus inferred.
Output: accepted sample and guide - 4.0
Produce with controls
Validate incoming data, reject unusable runs, annotate the supported signals, and route ambiguous cases to review.
Output: reviewed episode set - 5.0
Validate the handoff
Check synchronization, schema, manifests, explicit nulls, and a representative delivery in the buyer's loader.
Output: episodes, QA report, and rework log
Reject bad episodes early.
Forcing unusable recordings or broken logs through annotation creates false confidence. The rejection record is part of the deliverable.
- View, lighting, reset, device, calibration, environment, and required metadata checks.
- File integrity, stream presence, timestamps, frame rates, duration, and duplicate validation.
- Human motion, robot state, controller actions, inferred contact, and outcomes kept as distinct fields.
- Review of temporal boundaries, object identity, contacts, failures, interventions, and recoveries.
- Representative delivery tested through the buyer's episode loader before scale.
Representative sample
An episode that preserves uncertainty.
This example shows the delivery shape. It does not claim that human video contains controller state or that visible motion proves contact.
task_phasereach to graspreviewed time boundary
visible_eventhand closes around objectobserved in video
contact_stateprobable contactinferred, not telemetry
robot_actionnullnot present in source
outcomepartial successrubric + second pass
Questions before a pilot.
Bring the task, embodiment, environment, available signals, and the way the model team loads an episode.
Is human video robot-action data?
No. Human video can show observations, motion, visible interaction, and outcomes. Robot controller actions, state, force, and tactile signals must come from their own sources.
Can you collect new demonstrations?
Collection can be scoped when the task, environment, participant, rights, device, safety, and quality requirements are defined and supported.
Can you use our native format?
The buyer's native representation is the first delivery target. Flinket maps and tests a representative sample before production scale.
How are failures handled?
Failures, interventions, recovery attempts, incomplete runs, and unusable episodes receive explicit reasons rather than being silently excluded or forced into a success schema.
Start with five representative episodes.
Receive a capture or curation plan, one sample annotated episode, a rejection taxonomy, and a scale estimate.