Human demonstrations
Complete task sequences performed by people in approved household, workplace, technical or field environments.
Robotics & embodied intelligence
Robotics and embodied AI data built around real-world tasks.
Robotics and embodied AI programs need observations that preserve how people interact with tools, objects and environments. AMSYNK structures collection around the target task, viewpoints, devices, sensors, metadata and acceptance criteria.
Capability scope
Data collection patterns for embodied AI programs
Multi-view observations
Egocentric and external camera views when the model or evaluation workflow requires spatial context.
Sensor-aware capture
Project-defined camera, audio, timestamp or sensor requirements can be incorporated when operationally feasible.
Task state metadata
Structured task, environment, device, participant and outcome fields aligned to the client schema.
Operating controls
What we validate before scale and delivery
Acceptance rules vary by project, so the controls below are configured against the approved specification rather than treated as universal thresholds.
Feasibility firstTask access, safety, permissions, equipment and repeatability are reviewed before committing to production.
Pilot validationRepresentative samples confirm whether viewpoints and instructions expose the required task information.
Execution controlField teams follow project-specific instructions, device configuration and escalation procedures.
Traceable deliveryAccepted media and metadata are reconciled into an agreed delivery structure.
Embodied-data design
Capture should preserve the state transitions a robotics team needs to learn from
Robotics and embodied-AI requirements vary widely. The collection design should therefore begin with the task, observation requirements and temporal relationships rather than a generic video specification.
Demonstration definition
Define the task objective, initial state, successful completion state, acceptable variations and failure cases. This creates a consistent unit of collection and makes later review more defensible.
Observation requirements
Specify which views, signals or contextual fields are actually required. Where a project calls for multiple cameras, device telemetry or other modalities, their availability and timing relationship should be proven during the pilot.
Environment variation
Record the factors that should vary and the factors that must stay controlled: workspace, tools, objects, lighting, operator behavior, task difficulty and safety constraints. Variation without metadata can make a dataset harder to interpret.
Failure and exception capture
Decide whether incomplete tasks, retries, mistakes or unusual conditions should be rejected, retained with labels, or routed for review. This distinction is especially important when the learning objective includes recovery or edge cases.
Before scaleValidate task definitions, view coverage, any synchronization requirement, metadata completeness, safe operating conditions and the review path for failed or ambiguous demonstrations.
Delivery structure
Outputs organized around the agreed use case.
The final package can include task recordings, multiple camera views, project-defined metadata, capture notes, QA records and manifests depending on the agreed program.
Related capabilities