Robotics Capability Framework
The Robotics Capability Framework is a reference framework published by Arm in September 2026 for describing what intelligent robots and other embodied AI systems can do. It sorts robotic behavior into six levels of sophistication, from RL0 Reactive to RL5 Self-improving, and pairs those levels with a capability taxonomy (perception, localization and mapping, physical action, decision-making, learning, interaction and governance, plus compute and ecosystem properties) so that a robot can be described as a profile across capabilities rather than with a single label.[1][3] Arm introduced it on 8 September 2026 as one of the first collaborative initiatives of Arm Total Design for Physical AI, a partner program that Arm said more than 80 companies were joining.[2]
Arm presents the framework as a starting point for a shared vocabulary, not as a standard or certification scheme. Its web page says the framework creates a shared foundation "without standardizing performance, architecture, or implementation", and the framework document states that it is not intended to "define a certification programme".[1][3] Arm has invited robotics companies, customers, regulators, insurers, researchers and standards bodies to help develop it.[4]
Background
Arm's case for the framework is set out in a manifesto by its chief architect, Richard Grisenthwaite. He argues that words such as autonomous, intelligent, adaptive, collaborative, contextual and self-improving are widely used in robotics but "do not always carry consistent meaning across vendors, use cases, operating environments or supervision models", which makes systems harder to compare, integrate and assess.[4] The manifesto gives examples: one company's "autonomous" robot may need continuous human supervision while another uses the same word for a system working independently in a bounded environment, and "collaborative" may describe a safety-rated industrial arm, a mobile robot near workers, or a service robot dealing with the public.[4] It lists the practical consequences as requirements that are harder to write, systems that are harder to compare, integration that is harder to plan, safety reviews that are harder to frame, insurance and operational risk that is harder to assess, regulation that is harder to reference without endorsing a specific technology, architecture or vendor, and investment decisions that are harder to make.[4]
The manifesto describes Arm's position as that of a company working across silicon, software, AI, devices, infrastructure and developer ecosystems "rather than building finished robots ourselves", and says the framework is "not intended to become an Arm-only initiative".[4] It also cites International Federation of Robotics figures of more than 4.28 million industrial robots operating in factories worldwide, with annual installations above half a million units for the third consecutive year.[4] Those are the IFR's World Robotics 2024 figures for 2023; in September 2025 the IFR reported 4.66 million robots in operation and 542,000 installations in 2024, the fourth straight year above 500,000.[8]
Arm draws a comparison with road vehicles. Drew Henry, Arm's executive vice president for physical AI, wrote in the launch post that "As SAE Levels created a shared vocabulary for driving automation, robotics needs a common language of its own".[2] The manifesto makes the same point more cautiously, saying the automotive industry showed the value of shared capability frameworks but that robotics is a broader problem because machines are diverse "with no single dominant operating domain".[4] Trade coverage in AI News described the framework as "patterned after the SAE Levels used for driving automation".[5]
Launch
Arm announced the framework on 8 September 2026 alongside Arm Total Design for Physical AI, an extension of its existing Arm Total Design program to physical AI.[2] Henry's post named AWS, ECARX, Hugging Face, Liquid AI, NXP, PlusAI, PSYONIC, QNX, Qwen, Siemens and Unitree Robotics among the more than 80 companies joining the program, and cited an Arm estimate of a $200 billion annual compute opportunity in physical AI industries in the 2030s.[2]
According to the launch post, the framework's "initial structure was informed by perspectives and feedback from across the robotics ecosystem", and Arm said it would continue to shape it with companies including Anaxi Labs, ANYbotics, FMC³ Robotics, Fourier, Galbot, Gravis Robotics, Lenovo, McKinsey and Robotec.ai.[2] The framework document is labelled document 112293, Issue 1.0, a 60-page non-confidential release dated September 2026 and described in its revision history as the "First non-confidential release".[3] Arm also runs a registration page and an email address for organizations that want to contribute feedback.[3][4]
On 16 October 2026 Arm promoted the framework on X with a video, inviting viewers to "Hear from @AnaxiLabs, @McKinsey and @Lenovo on why industry alignment matters".[7]
Design principles
The framework document gives three key principles:[3]
| Principle | What the document says |
|---|---|
| Future-proof | The framework is anchored in capabilities, behaviors, system properties, operating assumptions and assurance expectations, so that new technologies such as foundation models or new sensing methods change how capabilities are realized without redefining the model. |
| Implementation- and architecture-agnostic | It does not prescribe hardware, processor or instruction-set architecture, software frameworks, algorithms, AI models, middleware or toolchains, nor whether intelligence runs on the robot, at the edge, on-premise or in the cloud. |
| Embodiment-agnostic | The same capability model is meant to apply to a fixed industrial robot, an autonomous mobile robot, a drone, a humanoid, a quadruped, a surgical robot or a soft robot. |
The manifesto adds six guiding principles proposed "as a starting point for discussion": build trust through clarity; describe capability, not implementation; preserve innovation and differentiation; reflect the diversity of robotics; evolve with the industry; and build together.[4]
The six levels
The levels form the framework's horizontal axis. Arm states that they are not meant to "rank robots in a simplistic way, nor to imply that every system should aim for the highest level"; a robot built for a narrow, safety-critical or cost-sensitive task may be entirely appropriate at a low level.[3] The document describes each level through system behavior, typical output and the capability foundation it requires.[3]
| Level | Name | Typical output | Description in the framework | Example use cases given by Arm |
|---|---|---|---|---|
| RL0 | Reactive | Command execution | Reacts to immediate stimuli or direct commands using fixed rules and low-level control, with little or no memory or learning. Arm says RL0 is not an immature level but the deterministic execution foundation that higher levels depend on. | Line-following robots, simple IR-activated vacuum robots, basic conveyors, fixed pick-and-place units |
| RL1 | Deliberative | Task execution | Executes predefined plans, task sequences or workflows using rule-based logic such as state machines, scripts or symbolic planning, without substantially adapting from experience. | AGVs in structured warehouses, mobile robots on fixed routes, industrial robots running programmed sequences |
| RL2 | Adaptive | Optimization | Adjusts execution from feedback within predefined objectives using task-specific (narrow) AI. Arm calls it the last level where intelligence stays task-specific, deterministic and bounded before foundation and generative models enter at RL3. | Industrial robots tuning grasp or motion parameters, drones replanning around obstacles, AMRs adapting local paths |
| RL3 | Contextual | Contextual action selection | Interprets situational context and intent and chooses among behaviors, combining context awareness, semantic grounding, episodic memory and short-horizon reasoning. The document says the non-deterministic behavior of AI models at this level introduces new challenges such as AI safety and repeatability. | Urban delivery robots adjusting around crowds, in-home assistants adapting to user intent, mobile manipulators reacting to object state |
| RL4 | Cognitive | Plans and justified actions | Reasons persistently over multiple goals, constraints and trade-offs using world models, longer-term memory and hierarchical planning from task to skill to motion, and can explain its choices. | Co-working robots that schedule with humans, humanoid robots across multiple industrial or consumer interactions, robots explaining why they chose an action |
| RL5 | Self-improving | Strategy generation and refinement | Improves behavior over time under governance, through meta-learning, fleet learning or continual policy evolution. Arm states that RL5 "does not mean unconstrained autonomy or uncontrolled self-modification". | Drone swarms adapting mission logic, fleets sharing learned strategies, long-life space systems, general-purpose humanoids improving under explicit governance |
The document treats progression as cumulative. A robot at RL4 or RL5 "still needs reactive safety mechanisms, deterministic control loops, local perception triggers, emergency stop behavior and bounded fallback modes".[3] It singles out two transitions as qualitative breaks rather than steps on a smooth scale: RL3 to RL4, where the system moves from selecting a contextually appropriate action to deliberating over goals, alternatives and consequences, and RL4 to RL5, where improvement itself becomes a governed capability that needs validation gates, rollback, continuous attestation and accountability for behavior that changes over time.[3]
Capability taxonomy
The capability model forms the vertical axis. Arm defines a capability as "a stable, solution-agnostic ability that a robotic system may need to possess"; what changes from level to level is not whether a capability exists but the sophistication, assurance expectations and autonomy horizon required of it.[3] Capabilities fall into three groups:[3]
| Group | Capabilities | Role |
|---|---|---|
| Robotics-specific | Perception; Localization & Mapping; Physical Action; Decision-Making; Learning & Adaptation; Interaction; Safety & Trust Governance | What the robot must do to operate intelligently in the physical world |
| General-compute | Compute execution, workload management, determinism and timing, memory, connectivity, monitoring and diagnostics, resilience, software lifecycle and updateability, rollback, safety mechanisms, cybersecurity | The platform properties that make robotics capabilities dependable, maintainable and deployable |
| Ecosystem-facing | Interoperability; System Integration; Stability; Scalability | The properties needed to integrate, interoperate and scale across products, vendors and deployments |
Each robotics-specific capability is defined with a definition, scope, primary objective and boundary. For example, Perception is the capability that "transforms sensor data into actionable observations", while persistent map truth belongs to Localization & Mapping; the boundary entries repeatedly state that the framework does not prescribe the sensors, models, algorithms, planners or deployment location used.[3] The governance capability is called "Safety & Trust Governance" in the taxonomy and "Governance Policy Control" in other parts of the same document; it covers the operating envelope within which autonomy is allowed to act, including runtime enforcement, fallback rules, audit, decision provenance, attestation and rollback.[3]
Safety and security are not separate robotics capabilities in the framework. They are treated as cross-cutting assurance expectations on every capability, while functional safety mechanisms (diagnostics, fault detection, redundancy, watchdogs, safe-state enforcement) are treated mainly as a dependency on the compute and platform foundation. Arm says this avoids "a separate safety/security taxonomy that would duplicate existing standards".[3] The document also argues that a system "cannot credibly claim higher levels of robotic sophistication if the compute foundation cannot support the required latency, isolation, observability, updateability, security, evidence and fallback expectations".[3]
Capability-level matrix
The central matrix of the document (its Figure 3) describes how each capability is expected to behave at each level. A selection of its rows:[3]
| Capability | RL0 Reactive | RL1 Deliberative | RL2 Adaptive | RL3 Contextual | RL4 Cognitive | RL5 Self-improving |
|---|---|---|---|---|---|---|
| Decision-making | Direct stimulus-response logic, no planning | Rule-based logic, finite-state decisions | Task-level planning, supervised adaptation | Probabilistic reasoning with context, memory, intent and goal understanding | Persistent multi-goal deliberation with bounded, world-model-guided cognition | Meta-learning and self-improving reasoning with validated adaptation of strategies and policies |
| Perception | Simple event or threshold detection | Simple vision or object triggers | Multimodal perception, object detection and segmentation | Foundation-model based perception with semantic understanding | Semantically and temporally grounded multimodal perception, predictive scene understanding | Lifelong refinement of perception and world models from accumulated experience |
| Safety and trust governance | Deterministic execution, emergency stop, hard safety limits | Basic physical safety (joint limits, E-stop) | Runtime monitoring and anomaly detection | Bounded behavior with runtime monitoring, interrupt and recovery ("AI safety island") | Governed, trusted execution with explainability, provenance and bounded recovery | Adaptive governance that constrains and validates self-modification |
| Representative AI architectures | Reactive controllers, finite-state machines, deterministic control loops | Classical planning (A*, D*), SLAM | Learning-based pipelines (ML, RL, adaptive control) | Foundation model systems (LLMs, VLMs plus retrieval) | Agentic AI systems (world models, VLAs, planners) | Self-improving AI systems (meta-learning, digital twins, AutoML) |
System 1, System 2 and System 3
A third axis groups capabilities by behavioral role rather than by where they run. The document borrows the System 1 and System 2 distinction "widely adopted in cognitive science" and adds a third layer:[3]
| Layer | Nature | Function described by Arm | Deployment |
|---|---|---|---|
| System 1 (Reflex) | Fast, automatic, stimulus-driven | Immediate responses such as obstacle avoidance, reflexive safety stops and stabilizing actions; deterministic, possibly hard real-time control | Predominantly on the robot, close to sensors and actuators |
| System 2 (Tactical autonomy) | Context-aware, mission-bounded reasoning | Decides how to act now within an active mission: planning, adapting and coordinating within bounded horizons, and resilient to loss of higher-level services | On the robot, on a shared edge node, or as a distributed service |
| System 3 (Strategic autonomy) | Strategic, cross-agent, system-level | Learning and training across robots, missions and time, producing artefacts such as trained policies, updated constraints and shared knowledge for System 2 to consume; it does not generate low-level actions | Inside one robot, across a cohort of robots, or on shared edge or cloud infrastructure |
The document stresses that on-robot, edge and cloud are deployment models, not architectural layers, and that one capability can span all three systems. Its example is perception that includes a System 1 obstacle detector, a System 2 semantic scene interpreter and a System 3 fleet-level model improvement pipeline, which might run on one chip or across robot, edge and cloud.[3] Losing System 3 is meant to degrade optimality and coordination, "not basic operability".[3]
Capability profiles
Because capabilities can sit at different levels, the framework describes a system as a capability profile tied to a use case and operating context. The document calls a bare statement such as "this robot is RL4" less meaningful than a structured one, giving the example: "for this use case and operating context, the system demonstrates RL4 decision-making and perception, RL3 interaction and motion, and RL2 learning, with RL1/RL0 safety fallbacks".[3] It says profiles should not be averaged into a single maturity score and are drawn as spider-web charts with one axis per capability.[3]
Appendix B works through a warehouse logistics assistant in four variations, from structured goods transport (mostly RL1) to a cognitive warehouse coordinator whose decision-making and governance reach RL4. The fully developed example, profile C, is a robot moving goods through a semi-structured warehouse shared with people and vehicles, under operational supervision with safe-stop and operator-intervention fallbacks:[3]
| Capability | Target level in profile C | Reason given |
|---|---|---|
| Perception | RL3 Contextual | Must judge the significance of people, vehicles, goods and blocked aisles, not just detect objects |
| Localization & Mapping | RL2 Adaptive | The warehouse is mapped; local rerouting is enough |
| Physical Action | RL2 Adaptive | Transport and trajectory adjustment are physically bounded |
| Decision-Making | RL3 Contextual | Must weigh traffic, urgency, human presence and task intent |
| Learning & Adaptation | RL2 Adaptive | Task-scoped adaptation is sufficient |
| Interaction | RL1 Deliberative | Workers mainly need commands, status and warnings |
| Safety & Trust Governance | RL3 Contextual | The permitted autonomy envelope needs contextual runtime enforcement |
Applying the framework
The document lays out a flow from market need to engineering choice: (1) use case, (2) functions, (3) mapping to the capability taxonomy, (4) RL0 to RL5 profiling of each relevant capability, (5a) differentiation strategy and product positioning, (5b) applicable standards, (6) testable requirements, and (7) technology hypotheses.[3] It states that the framework "does not define the normative safety, security, regulatory or compliance obligations" for a use case; product teams must map the standards that apply, such as functional safety, SOTIF, cybersecurity, machinery safety, collaborative robot safety or medical device rules.[3]
Adopters may declare that a system, product, requirement set or roadmap is aligned with a given level. Arm says such a declaration "should be understood as an alignment or conformance statement, not as formal certification", adding that "Certification may become future work".[3] A declaration is expected to show terminology alignment, structural alignment (tracing the claim from use case to capabilities) and capability-level alignment that names the use case, environment, human role, supervision model and fallback assumptions.[3] The document says future versions may add level-specific "objectives" for each capability and measurable "primitives" that provide observable indicators those objectives have been met.[3]
Reception
As of October 2026, Arm's framework page carried partner statements from 15 organizations: Anaxi Labs, ANYbotics, Bosch Robotics, Cambridge Consultants, Cyber Risk Insights, FMC³ Robotics, Galbot, Gravis Robotics, Infineon Technologies, Lenovo, McKinsey & Company, PSYONIC, QNX, Robotec.ai and STRADVISION.[1] Examples include:
- Christian Gehring, co-founder of ANYbotics, called the framework "an important step toward building that common understanding".[1]
- Tim Ensor of Cambridge Consultants said the industry "still lacks a common way to describe what robots can actually do" and that similar capability claims "can mean very different things".[1]
- Yuli Zhao, chief strategy officer of Galbot, said Galbot sees "immense value in establishing a common language framework".[1]
- Jan Schneider-Kraus of Bosch Robotics said a demonstration robot and one running in a plant every day "are often described in the same words".[1]
- Peter Armstrong of Cyber Risk Insights said consistent capability language helps "insurers and risk owners assess exposure".[1]
- Ryan Luke Johns of Gravis Robotics described "A standardized Robotics Capability Framework" as "a common benchmark for real-world execution", wording that goes further than Arm's own description of a framework that does not standardize performance or implementation.[1]
The manifesto adds a regulatory comment from Rubén Lirio of DEKRA, who argued that without a common reference point "every jurisdiction keeps reinventing its own taxonomy".[4] Independent coverage from AI News and ForkLog reported the launch, the tiered level structure (ForkLog specified six levels, RL0 to RL5) and the 80-plus-company Total Design program; ForkLog noted that Arm stresses the framework is not meant to standardize robot performance, architecture or implementation.[5][6]
See also
References
- ^1 ^2 ^3 ^4 ^5 ^6 ^7 ^8 ^9Arm. "Robotics Capability Framework". arm.com. arm.com/...robotics-capability-framework
- ^1 ^2 ^3 ^4 ^5Henry, Drew. "Arm brings the ecosystem together to build and define the next phase of physical AI". Arm Newsroom, 8 September 2026. newsroom.arm.com/...lity-framework-for-physical-ai
- ^1 ^2 ^3 ^4 ^5 ^6 ^7 ^8 ^9 ^10 ^11 ^12 ^13 ^14 ^15 ^16 ^17 ^18 ^19 ^20 ^21 ^22 ^23 ^24 ^25 ^26 ^27Arm. "Robotics Capability Framework" (document 112293, Issue 1.0). Arm Limited, September 2026. arm.com/...robotics-capability-framework.pdf
- ^1 ^2 ^3 ^4 ^5 ^6 ^7 ^8 ^9 ^10Grisenthwaite, Richard. "Robotics Capability Framework: A common foundation for the next era of intelligent robotics" (manifesto). Arm, 2026. arm.com/...tics-capability-framework-manifesto.pdf
- ^1 ^2Daws, Ryan. "Arm launches Total Design for Physical AI and robotics framework". AI News, 8 September 2026. artificialintelligence-news.com/...otics-framework
- ^"Arm Unites 80 Companies to Establish Common Robotics Standards". ForkLog, 8 September 2026. forklog.com/...establish-common-robotics-standards
- ^Arm (@Arm). Post on X, 16 October 2026. x.com/...2111157467224723949
- ^International Federation of Robotics. "World Robotics 2025 report: Industrial Robots released by IFR". IFR press release, 25 September 2025. ifr.org/...mand-in-factories-doubles-over-10-years
Improve this article
Add missing citations, update stale details, or suggest a clearer explanation. Every suggestion is reviewed for sourcing before it goes live.
2 revisions · v2 · 3,196 words · full history
Fact-checks are independent of edits: a reviewer re-verifies the article against its sources and stamps the date. How we verify
Research and drafting on this wiki are AI-assisted, under named human editorial standards. How AI is used here
Reviewer note: Independent verification 2026-10-17 (xg19 V5): framework PDF levels/matrix/examples and all 15 partner quotes checked; 5 minor fixes applied incl. updated IFR figures.
Cite this page: AI Wiki. "Robotics Capability Framework." aiwiki.ai, updated 16 Oct 2026, fact-checked 16 Oct 2026. CC BY 4.0. https://aiwiki.ai/wiki/arm_robotics_capability_framework