Partnership vision Robot integrations are proposed development work.

Goods keep moving. People stay in control.

From warehouse transport to order fulfillment, autonomous machines are becoming part of everyday operations. Help us build an open observation and governance layer for logistics and ecommerce robots.

For robot makers, warehouse integrators, logistics operators, and ecommerce teams.

AI-generated concept of a warehouse mobile robot carrying parcels with a supervisor in a separate pedestrian lane
AI-generated concept art made with fal.ai. Proposed use case, not a product demonstration.

Understand every handover, from order to delivery.

Mobile robots carry goods. Autonomous forklifts move pallets. Mobile manipulators pick and replenish. Operators need a clear account of who requested the work, what the robot reported, and when a person needs to take over.

  1. Follow the task across systems

    Explore a shared record linking a warehouse request to a robot mission, permission checks, progress, and completion. Keep the warehouse and fleet systems responsible for assigning and coordinating work.

  2. Make exceptions understandable

    Study blocked routes, delayed jobs, unexpected task changes, and operator handovers. Show when evidence is missing or stale, so a last known position is never mistaken for a live one.

  3. Give buyers evidence they can review

    Use one supervised picking, replenishment, pallet transport, or loading workflow to demonstrate the activity record and human responsibilities. Learn what enterprise customers need before expanding the pilot.

Human intervention, designed for the machine.

A pause must protect people and the load.

Stopping a warehouse workflow needs context: the robot, its load, nearby people, and connected equipment. An authorized task pause would use the manufacturer’s supported interface and report its acknowledgement. Local collision avoidance, safety controllers, 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.

An open layer, built with robot makers.

Our 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 video

Proposed responsibilities

People and operating rules

Intent, permissions, and approval

ClawMetry observation and governance

Activity evidence and authorized requests

Manufacturer’s robot controller

Motion, local safety, and confirmed state

Local emergency stops and safety systems stay independent of the observer and cloud.

Start in simulation. Validate on the machine.

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.

  1. Connect to the supported interface

    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.

  2. Test a real simulator workflow

    Run normal work and interruptions. Compare recorded requests with simulator feedback, including disconnects and delayed acknowledgements. Keep simulated results clearly identified.

  3. Validate with the robot maker

    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 simulation

These are manufacturer resources, not announced ClawMetry integrations or partnerships.

Begin with one workflow.

Choose one route or workstation and begin in the manufacturer’s simulator, where available. Validate read-only observations before studying approvals and task pause requests. Hardware validation needs the robot maker, site operator, and a supervised test plan, including load stability, lost connectivity, and authorized resume.

Before we start

Would this replace our warehouse or fleet management software?

No. Warehouse management, fleet scheduling, navigation, and machine safety stay with their existing systems. We propose independent evidence and explicit permissions around a workflow, connected through supported interfaces. A task cancellation is not proof that the machine has reached a safe state.

Why involve a third party?

Manufacturers know their machines best. Our thesis is that an open observation layer can help customers compare evidence, understand permissions, and keep a consistent operator experience across vendors. We want to test that value with partners, while keeping safety responsibilities explicit.

Let’s make safe AI together.

Invite us to your warehouse, fulfillment center, loading bay, or robotics lab. Show us the real handovers and integration constraints. We would like to learn where clearer evidence and control could help your customers adopt autonomous machines.

A practical first conversation

  1. Show us one real workflow and the people responsible for it.
  2. Choose the evidence, boundaries, and intervention we should study.
  3. Agree a small supervised pilot and how we would judge the result.

An invitation to collaborate, with no claim of an existing robot partnership.