concepts
Intended Documentation
What is Physical AI on Intended
How the Intended Authority Runtime layers on top of an existing safety stack to classify, gate, and audit AI-issued physical commands at machine speed.
What is Physical AI on Intended#
Intended is the authority layer for physical AI. When an agentic robot, drone, AGV, or autonomous machine is about to take a real-world action, Intended classifies the structured intent into an Open Intent (OI) category, evaluates it against your policy over a snapshot of live machine state, and — when the action is allowed — mints a short-lived RS256 token bound to that action. If the policy denies, escalates, or the classifier fails closed, no token is issued and your controller falls back to a declared safe-default.
We sit above your existing safety PLC, not in place of it. The safety PLC remains the authority on physical safety hazards (e-stop, light curtains, presence scanners). Intended is the authority on whether the command should be issued in the first place — and it leaves a tamper-evident record of every decision.
Where Intended sits#
Intended classifies and gates the command; the safety PLC, motion controller, and safety bus are unchanged. Authority gating is defense-in-depth, layered on top of the existing safety case.
The safety PLC continues to interrupt power on a hazard. Intended additionally decides whether an AI- or operator-issued command should ever reach motion, and records the decision.
The authority loop#
Every physical action follows the same loop against /v1/physical/*:
Register the actor (once)
Each robot is registered on your tenant's fleet roster via POST /v1/physical/actors. Token issuance for an unregistered actorIdentity is rejected with 403 actor_not_registered — there is no implicit fleet.
Classify the structured goal
A non-text goal (a ROS2 action, an OPC-UA method call, a MAVLink command) is classified into an OI category with a confidence and a safety-bit. The physical classifier is the only place in the platform that emits OI-NNNN codes at runtime.
Evaluate policy over live state
The classified goal is evaluated against your policy clauses over the physicalState snapshot you submit. The default policy denies on emergency-stop, light-curtain breach, and human-in-cell.
Mint a token, escalate, or deny
ALLOW mints an RS256 token bound to the action. ESCALATE returns an operator approval ticket. DENY returns 422 policy_denied (or 423 when the audit-gap clause trips), carrying the clause's declared safe-default.
Verify at the controller
Your controller verifies the token before commanding motion. Today verification is the cloud round-trip; a dedicated edge verifier is on the roadmap (see below).
What you get today#
| What it is | Status | |
|---|---|---|
| Open Intent (OI) v2 | Open Apache-2.0 taxonomy — 29 domains / 173 categories. The vocabulary your robot uses to describe what it is about to do. | Implemented |
| Authority Runtime (cloud) | Structured-goal classifier, policy evaluator, RS256 token issuer, audit chain, escalation/approval workflow, revocation feed. Reachable at https://api.intended.so/v1/physical/*. | Implemented |
| Python SDK | pip install intended — IntendedPhysicalClient, classify + issue + snapshot. | Implemented |
| ROS2 package | intended-ros2 ament package — wraps the cloud calls as a ROS2 node. | Implemented |
| Edge verifier binary | Sub-50ms local verification, offline JWKS cache, revocation sync. | Roadmap |
| Rust / C++ customer SDKs | Native SDKs for real-time firmware and industrial controls. | Roadmap — integrate via the cloud HTTP API today |
Edge verifier and Rust SDK are not shipped
The dedicated edge verifier binary and the Rust edge-verifier SDK are referenced across this track as the eventual hot-path product, but they are not in the repository today. Verification currently happens via the cloud round-trip on /v1/physical/authority-tokens. The /.well-known/jwks.json endpoint serves the physical-AI signer's key, but in dev/sandbox that signer is an ephemeral per-process keypair that loses validity on restart. Plan against the cloud path; treat edge-binary behavior as a forward-looking specification.
What we do NOT do#
- Replace your safety PLC, safety bus, or safety-rated I/O.
- Write controls code, ROS2 nodes, ladder logic, or PLC programs.
- Read your PLC tags directly — you implement a
PhysicalStateProviderand submit the snapshot. - Provide platform-specific adapters for ABB, FANUC, KUKA, UR, Boston Dynamics.
- Decide where to grasp, what trajectory to plan, or which lane to merge into.
- Certify your machine under IEC 61508 / ISO 13849 / ISO 26262. No compliance-framework control mappings exist in the runtime; Intended provides mechanisms (signed tokens, tamper-evident audit), not certifications. See Safety-case writing.
Where Intended fits in your safety case#
You ship a safety case for your machine. Intended provides mechanisms your case can cite. The split:
| Component | Owner |
|---|---|
| Cloud authority issuer (classify, policy, sign, audit) | Intended |
| Edge verifier binary (roadmap) | Intended |
| Robot / PLC / safety bus | Customer |
| Application logic + DAG | Customer |
Safety bus → predicate bridge (PhysicalStateProvider) | Customer |
| Per-deployment safety case | Customer |
Safety-case writing walks through the GSN structure and exactly what is defensible to claim today.
Two-product framing#
| Product | Open / closed | Pricing |
|---|---|---|
| Open Intent (OI) — the standard | Open, Apache 2.0, vendor-neutral | Free |
| Intended Authority Runtime | Commercial product | Per-device or per-cell, annual |
You can adopt the Open Intent taxonomy without buying the runtime. You buy the runtime when you want Open Intent enforced at machine speed with the audit, escalation, and operational properties an enterprise deployment requires. Same shape as Linux + Red Hat, Postgres + RDS, OAuth + Okta.
Next#
- Physical-AI quickstart — register an actor and mint your first token.
- Authority API reference — every endpoint, field, and failure mode.
- ROS2 integration — the canonical SDK for robotics agents.
- PLC migration patterns — translating safety-PLC interlocks into Intended policy clauses.
- Safety-case writing — what to claim, what not to claim.