Physical AI

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

This is one of the commercial surfaces of the Ratify Verify console. 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.

SDKs are available in Go, TypeScript, Python, Rust, and C/C++. The C/C++ SDK ships libratify_c.a (static) and libratify_c.so (shared) with a cbindgen-generated header, supports RTOS targets (FreeRTOS, Zephyr) via custom entropy, and is no_std + alloc compatible for embedded deployments. See the C/C++ SDK page for build instructions and target matrix.

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. The C/C++ SDK is available now — link against libratify_c.a and wire in your hardware TRNG via ratify_set_entropy_source() for RTOS targets.