ClawMetry
Partnership vision Robot integrations are proposed development work.
AI is moving from screens into the physical world: humanoids, factory machines, warehouse robots, and civilian drones. Our long-term vision is an open layer that helps people understand their actions, set boundaries, and intervene when needed.
Explore proposed features and examplesBuilt with manufacturers. Designed around the people who use their machines.
Understand intentions, permissions, and human handover in shared spaces.
Connect AI instructions to approvals, machine state, and operator evidence.
Follow autonomous goods movement, operator handovers, and task outcomes across the warehouse.
Make missions accountable, with clear boundaries and flight-aware intervention.
AI-generated concept art made with fal.ai. Proposed use case, not a product demonstration.
What is the robot trying to do? Who allowed it? What happened? How can a person intervene? We want those answers to be understandable to a plant manager, a field operator, or a household.
For manufacturers, that could mean clearer demonstrations, easier operational reviews, and stronger conversations with prospective customers. We want to learn where independent evidence actually helps adoption.
Robot platforms already monitor machines and coordinate work. We want to connect that view to the AI application, the person who authorized the task, and an evidence record the operator controls.
Proposed features to develop with manufacturers. These examples are illustrative, not available robot controls.
Connect a person's request to the AI's declared plan, target, and next requested action.
An AI requests a pick-and-place task. The record would show the initiating application, selected arm, object, destination, and next command before delivery, where the integration exposes them.
Needs task and planner events. Joint measurements alone cannot reveal intent or hidden reasoning.
Explore industrial workflowsExplore permissions tied to a specific task, destination, and period of time.
An operator approves delivery to the inspection tray. If the AI changes the destination, the earlier approval would no longer authorize the revised command. The application would request a new decision before forwarding it.
Needs an agreed command gate that covers the controlled path. Observation after execution cannot block an action.
Keep a proposed action, controller acceptance, and measured outcome visibly separate.
A mobile robot accepts a delivery task, then stops reporting. The operator would see the last observation time and an unknown outcome. Acceptance would not be presented as arrival or successful handover.
Needs source timestamps, task status, and relevant measurements. Missing or stale data stays unknown.
Explore warehouse workflowsRecord who requested a pause, the controller's response, and the state reported afterward.
A person requests a pause. The maker's controller manages balance and the load. The proposed record would distinguish request sent, accepted or rejected, state confirmed or unknown, and any later authorized resume.
Needs model-specific interfaces and validation. An acknowledgement does not establish a safe stop. Local safety remains authoritative.
Explore humanoid handoversExplore a local, exportable history of requests, approvals, robot reports, and evidence gaps.
An incident review would bring together the approved task, application and controller versions, reported motion, timestamps, and missing observations. The operator could compare that record with the manufacturer's logs.
Retention and export rights must be agreed. Tamper evidence can reveal later record changes; it cannot prove a sensor report was true.
Use a common task record across software agents and separately validated robot integrations.
A civilian inspection drone reports an issue. A software agent proposes a maintenance job. The operator could trace the observation, review, and approved follow-up without treating the agent's suggestion as permission to launch another mission.
Needs shared task references and an adapter for each supported system. Existing fleet software, navigation, and flight safety keep their roles.
Explore civilian inspection missionsIllustrative task record. No robot is connected, and no command is sent.
Move the part to the inspection tray.
The operator approves this task and destination.
The controller reports that it accepted the command.
Observations stopped before placement was confirmed.
A readable record should show what is known, where it came from, and what still needs checking.
Begin with read-only observation of one supervised workflow. Evaluate approval gates and intervention only after reviewing the evidence with the manufacturer and operator.
Discuss a workflow for a pilotOur proposal is a shared way to describe tasks, permissions, approvals, and outcomes across manufacturers. Operators could get an independent view while each robot keeps its own local control and safety systems.
Read the founding story and watch the vision videoProposed responsibilities
Intent, permissions, and approval
Activity evidence and authorized requests
Motion, local safety, and confirmed state
Local emergency stops and safety systems stay independent of the observer and cloud.
A real way to intervene.
A factory arm, a balancing humanoid, and a drone cannot all stop in the same way. Our proposed layer would request an authorized intervention and show the response. The manufacturer’s local safety systems and physical emergency stops remain authoritative.
ClawMetry is not a safety-rated emergency-stop system. Robot support would need manufacturer integration and validation for the specific use case.
A public SDK or simulator gives us a practical place to begin. We want to develop against the manufacturer’s supported interfaces, then validate the same integration with their team on a specific physical robot.
Agree which SDK, API, or robot events expose tasks, state, permissions, and operator actions. Begin with observation and record what the interface cannot tell us.
Run normal work and interruptions. Compare recorded requests with simulator feedback, including disconnects and delayed acknowledgements. Keep simulated results clearly identified.
Test the selected model and software version under supervision. Check timing, sensors, physical loads, safety behavior, and recovery before describing hardware support as available.
Working in simulation does not establish physical-device compatibility or safety certification. Each manufacturer, model, and deployment needs validation.
Public development environments we are evaluating
Robotnik ROS 2 simulation Reachy 2 SDK and simulationThese are manufacturer resources, not announced ClawMetry integrations or partnerships.
Choose one supervised workflow. Agree what to record and what to keep private. Compare observations with the robot’s own state. Only then evaluate permissions and intervention through supported interfaces, with the manufacturer and operator involved.
We are looking for robot makers, integrators, and operators who want to build trust into the way their machines work. Invite us to your lab, factory, or test site. We will listen first, learn the workflow, and scope a useful pilot together.
An invitation to collaborate, with no claim of an existing robot partnership.