Put Fathom on a real robot.

Factor Bridge is the reference client. Advanced customers may implement the same protocol directly. Both paths use one narrow contract.

Four objects

Connection. An authenticated Factor Bridge or custom API client that exposes configured robot evidence and high-level skill contracts.

Robot. One provisioned machine behind a Connection. It retains local safe hold and all physical control authority.

Instance. One versioned Fathom configuration on one robot: mode, evidence, allowed skills, Handoff destination, and activation rule.

Shift. An automatic work and billing record opened from Bridge work state. A human Handoff pauses its meter.

1. Provision a Connection

Add the robot in Settings → Connections. Factor shows its credential once. Store it in the Bridge, not in browser code. The first complete adapter is Insight/RM5. Generic skill API clients use the same wire contract.

2. Activate Instance

Choose Observe, Assist, or Operate. Select evidence sources, approved high-level skills, standing instructions, the human Handoff destination, and when the Bridge should open a Shift. Fathom is the only reasoning brain.

3. Report work state

curl https://factor.ac/v1/factor/robots/ROBOT_ID/heartbeat \
  -H "Authorization: Bearer $FACTOR_ROBOT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "status":"ready",
    "work_state":"active",
    "work_id":"delivery-1837",
    "work_scope":"Complete the assigned delivery"
  }'

With the recommended when_working rule, active, working, busy, mission_active, or on_shift opens a Shift. An explicit idle state closes it. The response returns the active Instance and Shift.

4. Ask Fathom

curl https://factor.ac/v1/factor/shifts/SHIFT_ID/supervise \
  -H "Authorization: Bearer $FACTOR_ROBOT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "robot_id":"ROBOT_ID",
    "instruction":"Clear the blocked pickup and continue",
    "state":"safe hold; route blocked; front camera current",
    "images":["data:image/jpeg;base64,..."]
  }'

Fathom returns a bounded JSON decision. Verity checks its schema, expiry, mode, and skill allowlist. Observe is record-only. Assist requires approval. Operate may authorize an allowed high-level skill for Bridge validation. The customer stack still decides whether execution is physically safe and feasible.

5. Report acceptance and outcomes

curl https://factor.ac/v1/factor/shifts/SHIFT_ID/events \
  -H "Authorization: Bearer $FACTOR_ROBOT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "robot_id":"ROBOT_ID",
    "kind":"local_rejection",
    "payload":{"skill":"retry_route","reason":"local planner rejected"}
  }'

Valid kinds are task, observation, decision, action, local_rejection, outcome, and note. Factor never invents execution or outcomes.

6. Hand off

curl https://factor.ac/v1/factor/shifts/SHIFT_ID/handoffs \
  -H "Authorization: Bearer $FACTOR_ROBOT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "robot_id":"ROBOT_ID",
    "from":"fathom",
    "to":"human",
    "reason":"Evidence is occluded after two bounded retries",
    "safe_hold":true,
    "robot_state":{"mode":"safe_hold"}
  }'

A human Handoff requires explicit safe-hold confirmation and resolves only in the console. Factor pauses Fathom reasoning and the Shift meter while the person owns the next decision.

Control boundary

Fathom reasons. Verity checks the decision contract. Factor Bridge enforces mode, expiry, and allowed high-level skills. The customer's onboard executor owns transforms, rate limits, collision checks, navigation, motion planning, reflexes, watchdogs, emergency stops, safety, and actuators. A cloud response is never direct motor authority.