Robotic Capability Assessment Before Commitment

Regulatory framework

ISO 10218-1:2025 and ISO 10218-2:2025 redefine the safety architecture for industrial robots and integrated robot cells. Beyond the long-standing requirements for protective stops, safe speed, and safety-rated monitored stop, the 2025 revision elevates the requirement that a robot evaluate the feasibility of an instructed task against its safety functions before initiating motion, and that this evaluation be reproducible and inspectable. ISO/TS 15066 defines biomechanical force and pressure thresholds for collaborative operation; a collaborative task is only permissible if the robot can establish that the planned motion will remain within those thresholds for the duration of the task and not only at the start.

ISO 22166 governs modular robot architectures and explicitly contemplates capability declarations as machine-readable artifacts that travel with the module. ISO 13482 governs personal care robots, including mobile servant, physical assistant, and person-carrier classes, and requires hazard identification specific to each operational profile the robot enters. The IEEE 7000-series, including 7000, 7001 transparency, 7007 ontologies, and 7009 fail-safe design, treat capability transparency and graceful failure as ethical and design obligations.

RIA R15.06 codifies the U.S. industrial robot safety baseline; R15.08 extends safety requirements to industrial mobile robots and addresses dynamic environment navigation, task allocation, and safety-rated speed in shared spaces. ROS-Industrial and OPC UA Robotics, particularly the OPC UA Companion Specification for Robotics, define the interoperability layer over which capability declarations and task commitments are exchanged between robots, cell controllers, and MES systems.

In medical robotics, FDA guidance on AI/ML-enabled Software as a Medical Device, including the predetermined change control plan framework, demands that the device characterize its operational envelope, monitor for drift, and refuse to operate outside that envelope. The EU Machinery Regulation 2023/1230 brings autonomous and self-evolving machinery under a CE marking regime that explicitly requires the manufacturer to define and maintain the safety-relevant operational limits of the system across its lifecycle.

Architectural requirement

The architectural requirement that unifies these standards is a capability envelope: a structured, real-time representation of what the robot can do given its current physical state, environmental conditions, and uncertainty, evaluated against the joint requirements of the task. The envelope is not a static datasheet. It is a dynamic artifact that contracts when a gripper wears, when battery state of health declines, when a sensor degrades in humidity, when payload increases, when ambient lighting reduces vision confidence, and when planned motion approaches force or pressure limits set by ISO/TS 15066.

A capability envelope must support three operations. First, pre-commitment evaluation: given a candidate task, can the envelope contain the task trajectory, including its temporal duration, with adequate margin against uncertainty? Second, in-flight monitoring: as the task executes, does the actual envelope continue to contain the remaining work, or has degradation reduced capability below requirement? Third, declaration and negotiation: can the envelope be exposed to peer robots, cell controllers, and orchestrators in a machine-readable form so that task allocation and decomposition can occur on capability grounds rather than by static role.

This is the architecture that converts "the robot tried and failed" into "the robot declined and the system recovered." The shift is not optional under ISO 10218-1:2025, the EU Machinery Regulation, or FDA SaMD guidance; it is the substantive content of safety in autonomy.

Why procedural compliance fails

Procedural compliance in robotics today consists of static specification matching, individual constraint checks, and post-hoc safety validation. A task scheduler queries a robot registry, finds a robot whose datasheet payload exceeds the task payload, whose datasheet range exceeds the task distance, and whose datasheet supported tasks list contains the task type. The scheduler dispatches. The robot accepts.

This procedural pipeline fails for three structural reasons. First, datasheet capability is the manufacturer's nominal capability for a new, calibrated, ideally maintained unit. Real robots in real cells have worn end effectors, drift in joint encoders, accumulated thermal expansion, partially depleted batteries, dust on lidar covers, and vision systems calibrated weeks ago. None of these factors appear in the registry. The robot that the registry says can lift 12 kg may, today, reliably lift 9 kg.

Second, individual constraint checks compose incorrectly. Sufficient payload AND sufficient battery AND sufficient reach do not imply sufficient combined capability. The robot may have enough battery for the distance at zero load, enough payload capacity at zero distance, and enough reach at zero payload, while having insufficient battery for the payload over the distance. The joint condition fails although every individual condition passes. Sequential procedural checks cannot detect this; only joint envelope evaluation can.

Third, temporal feasibility is rarely modeled. A task that is feasible at task start may not be feasible at task minute thirty, because battery state of charge, motor temperature, ambient conditions, or payload heat have shifted. Procedural systems treat feasibility as a snapshot. Real autonomy is a trajectory. ISO 10218-1:2025 and ISO/TS 15066 explicitly require duration-aware safety analysis; procedural matching does not provide it.

The consequence is the now-familiar pattern of mid-task abort, failed delivery, mobilization-and-retreat, and, in the worst cases, safety incidents in collaborative cells where biomechanical limits are exceeded because the robot's force capability at minute twenty was not what its specification claimed at minute zero.

What the AQ primitive provides

The Adaptive Query capability-awareness primitive provides the capability envelope as a first-class governed artifact and the pre-commitment evaluation, in-flight monitoring, and inter-agent negotiation operations that act on it. The envelope is constructed from real-time state, including joint torque margins, battery state of health and state of charge, end-effector wear estimates, sensor confidence, environmental observations, and accumulated uncertainty. It is bounded by the safety functions defined in ISO 10218-1, the biomechanical thresholds of ISO/TS 15066 where collaboration is contemplated, and the operational design domain declared under FDA SaMD or EU Machinery Regulation conformity.

Pre-commitment evaluation takes a candidate task, projects the trajectory of the envelope across the task duration, and returns accept, decline, or decompose. Acceptance produces a capability commitment that the orchestrator can rely on. Decline returns the limiting factor in structured form, enabling the orchestrator to retry with a different robot, a reduced payload, a shorter route, or a delayed start when conditions improve.

Decomposition is the most powerful operation. A task that exceeds any single robot's envelope can often be split into segments each within a different robot's envelope: a long-range mobile robot ferries to a transfer point, a high-payload manipulator performs the lift, a precision robot performs the insertion. The decomposition is negotiated through capability declarations exchanged over the OPC UA Robotics or ROS-Industrial layer, not assigned by static role.

In-flight monitoring continuously checks that the remaining task fits within the contracting envelope. If degradation reduces capability below remaining requirement, the robot triggers a governed handoff or graceful abort consistent with IEEE 7009 fail-safe design before it executes a motion that would exceed limits. The handoff produces a structured remaining-task artifact that another robot can evaluate for acceptance.

The primitive also produces the inspection and audit record that ISO 10218-1:2025, the EU Machinery Regulation, and FDA SaMD demand. Every accept, decline, decompose, and handoff is recorded with the envelope state and the limiting factors at decision time, providing a structural record that the autonomy operated within its declared operational design domain.

Compliance mapping

Capability awareness maps directly onto the standards stack. For ISO 10218-1:2025 and ISO 10218-2:2025, the envelope provides the pre-motion feasibility check and the duration-aware safety analysis. For ISO/TS 15066, the envelope encodes the biomechanical thresholds as hard envelope boundaries and refuses tasks whose projected force or pressure trajectories would cross them, including under degraded conditions.

For ISO 22166, the capability declaration is the machine-readable artifact that travels with the module and enables capability-based composition. For ISO 13482, the envelope encodes the operational profile transitions, ensuring that a personal care robot moving from supervised to unsupervised operation re-evaluates feasibility against the stricter envelope of the new profile.

For RIA R15.06 and R15.08, the envelope provides the dynamic safety-rated speed and separation analysis required for shared spaces, and the structural basis for safety-rated monitored stop decisions in mobile applications. For ROS-Industrial and OPC UA Robotics, the capability declaration is exposed through the standard companion-specification information model so that orchestration can occur on capability grounds across heterogeneous fleets.

For FDA AI/ML SaMD, the envelope is the operational design domain made executable; refusal to operate outside declared bounds is the structural realization of the predetermined change control plan boundary. For the EU Machinery Regulation 2023/1230, the envelope provides the lifecycle-maintained safety-relevant operational limits that the manufacturer's technical documentation must establish and that ongoing conformity must preserve.

For the IEEE 7000-series, the envelope and its decision record provide the transparency artifact required by IEEE 7001 and the fail-safe behavior required by IEEE 7009.

Adoption pathway

Adoption begins with envelope instrumentation. Each robot is equipped to expose its current capability envelope in the OPC UA Robotics or ROS-Industrial information model. Initial envelopes can be conservative and derived from datasheet capability minus health-derived discounts. The instrumentation phase produces immediate value: the orchestrator gains a real-time view of fleet capability that no static registry has previously provided.

The second phase is pre-commitment gating on safety-relevant tasks. Collaborative operations under ISO/TS 15066, mobile operations in shared human spaces under R15.08, and SaMD operations under FDA oversight require envelope-passing acceptance before motion. Tasks the envelope cannot contain are declined with structured limiting factors, and the orchestrator either reassigns or defers. Mid-task aborts in this category drop sharply; safety incidents drop with them.

The third phase is decomposition and negotiation. Heterogeneous fleets begin to perform tasks that no single robot's envelope would have accepted, by exchanging capability declarations and assembling segment-level commitments. Throughput increases without expanding the fleet, because capability is now matched to task at segment granularity.

The fourth phase is governance integration. The capability envelope and its decision record become the substrate over which CE marking technical documentation, FDA SaMD predetermined change control evidence, ISO 10218-2:2025 integrator validation, and customer audit responses are assembled. The robot fleet becomes inspectable in the way that modern safety regulation requires, and the autonomy story the manufacturer tells is supported by structural record rather than by narrative assertion.

Programs that complete this pathway operate fleets that decline the tasks they cannot finish, decompose the tasks no single member can finish, and produce the audit record that the 2025 standards stack now treats as the substantive content of safe autonomy.