Physical AI

The Physical AI surface is for actions that affect the real world.

This is one of the commercial surfaces of Ratify Platform by Identities AI. The same protocol can also be implemented independently if you do not want the managed product.

Canonical protocol references:

• README
• SPEC.md
• SDK matrix

Examples:

• robot operation
• robot movement
• vehicle operation
• drone flight
• infrastructure control
• actuator access

What the surface does

Physical AI uses the same Ratify proof bundle flow, but the verifier usually runs on-device or at the edge.

The device or controller checks:

• who authorized the action
• what scope was granted
• whether the delegation is still valid
• whether the current context satisfies the constraints

If the proof fails, the device should fail closed.

The current SDKs cover Go, TypeScript, Python, and Rust. For embedded controllers and firmware, we plan to expose the same verifier contract in C and C++ so the authorization model can run closer to the hardware.

Typical flow

sequenceDiagram
  autonumber
  participant Admin as Org Admin
  participant App as Control Plane
  participant Device as Robot / Vehicle / Controller
  participant Ratify as Ratify SDK / Policy

  Admin->>App: Authorize device or mission
  App->>Ratify: Issue delegation for physical scope
  Device->>Ratify: Request verification or challenge
  Ratify-->>Device: Challenge / verification request
  Device->>Device: Sign challenge with SDK
  Device-->>Ratify: Proof bundle
  Ratify->>Ratify: Verify scope + constraints + revocation
  Ratify-->>Device: Allow or deny

SDK examples

Go

result := ratify.Verify(bundle, ratify.VerifyOptions{
  RequiredScope: ratify.ScopeRobotOperate,
})
if !result.Valid {
  panic("deny actuation: " + result.ErrorReason)
}

TypeScript

const result = await verifyBundle(bundle, {
  required_scope: SCOPE_ROBOT_OPERATE,
});
if (!result.valid) {
  throw new Error(result.error_reason);
}

Python

result = verify_bundle(bundle, VerifyOptions(required_scope=SCOPE_ROBOT_OPERATE))
if not result.valid:
    raise PermissionError(result.error_reason)

Rust

let result = verify_bundle(
    &bundle,
    &VerifyOptions {
        required_scope: SCOPE_ROBOT_OPERATE.into(),
        ..Default::default()
    },
);
assert!(result.valid, "{}", result.error_reason);

Scope examples

Use robot:operate for high-level operation permission, robot:move for motion-only authorization, vehicle:operate for drive/flight systems, physical:actuate for direct actuation, and infrastructure:control or infrastructure:access for plant, building, or equipment control.

Infrastructure example

For infrastructure control, use infrastructure:control or infrastructure:access and bind the verifier context to the actual device state, location, time window, or other operational guardrails. That matters when the caller is not a person but a robot, PLC, controller, or remote operator.

The important part is the same: the platform proves authorization, and the device enforces it before it moves the world.

If you are building firmware, the integration point is the same proof bundle and verifier semantics, just compiled down into the embedded controller. C and C++ support is the natural next step for that class of deployment.