Capability Awareness for Surgical Robotics
by Nick Clark | Published March 27, 2026
Surgical robots operate within physical precision envelopes that vary based on tool wear, calibration status, patient anatomy, and the specific demands of each procedure. Current surgical robots report their general specifications but do not maintain real-time awareness of their actual capability relative to the specific procedure being performed. Capability awareness provides surgical robots with first-class capability state that tracks current precision, reach, force limits, and temporal executability, enabling the robot to refuse tasks beyond its current envelope and negotiate capability constraints with the surgical team in real time. This article positions surgical robotics against the AQ capability-awareness primitive disclosed under provisional 64/049,409.
1. Regulatory and Compliance Framework
Surgical robotics is among the most heavily regulated classes of medical device. In the United States, the Food and Drug Administration regulates surgical robots under 21 C.F.R. Part 820 (Quality System Regulation) and, for most platforms with a software component that drives or controls instrument motion, classifies them as Class II or Class III devices subject to 510(k) premarket notification or De Novo classification under 21 U.S.C. § 360c. The FDA's October 2023 Final Guidance on "Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence/Machine Learning-Enabled Device Software Functions" and the May 2024 "Considerations for the Use of Artificial Intelligence to Support Regulatory Decision-Making for Drug and Biological Products" together establish that any AI-enabled element of a surgical robot, including capability assessment, must be governed by a documented change-control plan and a real-world performance monitoring regime. IEC 60601-1 (general safety), IEC 60601-1-9 (environmentally conscious design), IEC 62304 (medical-device software lifecycle), IEC 62366-1 (usability engineering), and ISO 14971 (risk management) are the harmonized standards under which submissions are evaluated. ISO 13482 (personal care robots) and the emerging ISO/TR 23482 series for medical electrical equipment with autonomous functions add explicit obligations on autonomy-level declaration.
In the European Union, Regulation (EU) 2017/745 ("MDR") classifies most surgical robots as Class IIb or Class III, requires notified-body conformity assessment, and imposes Article 10 general obligations on manufacturers including risk-based design, post-market surveillance under Article 83, and Periodic Safety Update Reports under Article 86. The Artificial Intelligence Act (Regulation (EU) 2024/1689) classifies AI-enabled medical devices as high-risk under Annex III and imposes Articles 9 (risk management), 10 (data governance), 12 (record-keeping), 13 (transparency), 14 (human oversight), and 15 (accuracy, robustness, cybersecurity) — every one of which presupposes that the device can articulate the boundary of its competence. The IEEE 7009-2024 standard on fail-safe design of autonomous and semi-autonomous systems, the IEC 80601-2-77 particular requirements for robotically assisted surgical equipment, and the IMDRF Software as a Medical Device "Possible Framework" risk categorization provide the technical scaffolding that submissions reference.
Tort and product-liability exposure compound the regulatory regime. In the United States, surgical-robot manufacturers face Restatement (Third) of Torts: Products Liability § 2 design-defect and § 2(c) failure-to-warn claims, with the warning duty extending to capability limitations the manufacturer knew or should have known. In the EU, the Product Liability Directive recast (Directive (EU) 2024/2853) explicitly extends strict liability to software and AI components and shifts the burden of proof when the defendant fails to disclose technical information. Hospital risk managers, in turn, increasingly require contractual representations that the device will refuse operations outside its validated envelope.
2. Architectural Requirement
Distilled across these regimes, a conforming surgical robot must satisfy six architectural conditions. First, the device must maintain a real-time, structured representation of its current capability — precision, reach, force, latency, sensor fidelity — derived from observable state (servo tracking error, vibration, thermal drift, tool-wear counters, calibration age) rather than from a static specification sheet. Second, every commanded operation must be evaluated against the current capability envelope before actuation; operations outside the envelope must be refused, deferred, or executed only under an explicit override credentialed to the supervising clinician. Third, the device must forecast capability evolution over the planned procedure horizon, so that capability degradation that will occur before procedure completion is surfaced at planning time, not at the moment of failure.
Fourth, capability state, capability evaluations, and capability-driven refusals must be recorded as evidentiary lineage admissible in MDR Article 83 post-market surveillance, FDA MDR (Medical Device Reporting) submissions, and litigation discovery. Fifth, the device must support human oversight under AI Act Article 14 by exposing the capability envelope, the procedure's capability requirement, and the gap between them in a form the surgeon can read and act on in real time. Sixth, the architecture must be technology-neutral and forward-portable — capability awareness cannot be coupled to a single vendor's tool family or a single hospital's IT stack — because device lifetimes exceed platform lifetimes by a wide margin.
These requirements compose into a single architectural condition: the robot must hold capability as a first-class governed state variable, evaluate every actuation against it, forecast its evolution, record its history, and expose it to human oversight — and the mechanism that does this must be a primitive of the device's architecture, not a feature bolted onto its UI.
3. Why Procedural Compliance Fails
The surgical-robot industry has, for the most part, attempted to satisfy these obligations procedurally rather than architecturally — and the procedural approach has reached its limits. Periodic preventive maintenance establishes that the device met specification at the last service interval but says nothing about its capability now; tool-life counters trigger replacement on usage rather than on observed degradation; calibration verification at procedure start is a point estimate that does not survive a four-hour operation. The surgeon's experiential judgment about whether the device "feels right" is not a substitute for a structural capability assessment, and it is not the kind of evidence that AI Act Article 14 human-oversight obligations contemplate.
Telemetry-based predictive maintenance has improved the picture but does not close it. Vendor cloud platforms collect tracking-error and vibration data and flag fleet-wide degradation trends, but the alerting pathway is asynchronous to the procedure: the robot does not refuse the next motion command on the basis of its own current state. ML-based anomaly detection identifies outliers but does not produce a procedure-conditioned capability assessment; an anomaly is interesting only if it lies outside the capability envelope required by the operation actually being performed. None of these mechanisms produces the closed loop that the regulatory regime is converging toward — capability state, capability requirement, structured comparison, governed refusal.
Procedural overlays cannot satisfy the AI Act's combined Articles 9, 13, and 14 obligations because those articles presuppose a device that can articulate its competence boundary and expose it to oversight in real time. Procedural overlays cannot satisfy the FDA's predetermined change control plan obligations because those obligations require that the device's behavior under capability change be specified ex ante, not interpreted ex post. And procedural overlays cannot satisfy Restatement § 2(c) failure-to-warn duties when the manufacturer knew its device could degrade silently into operations beyond its validated envelope. The regulatory floor has risen above procedural compliance; capability awareness has become an architectural requirement rather than a product feature.
4. What the AQ Capability-Awareness Primitive Provides
The Adaptive Query capability-awareness primitive disclosed under USPTO provisional 64/049,409 specifies that a governed actuator hold its capability as a structured, first-class state object — a capability envelope — composed of bounded dimensions (precision, reach, force, latency, fidelity, autonomy class) with each dimension carrying its current value, its measurement provenance, its credentialed authority, and its temporal forecast. Every commanded operation is paired with a procedure-specific capability requirement, and the primitive evaluates the requirement against the envelope before actuation. The evaluation produces a graduated outcome from a defined mode set — execute, execute with monitoring, defer pending replenishment, refuse, or escalate to supervisor override — rather than a binary go/no-go.
Capability state is updated continuously from observation streams credentialed to their sources: servo trackers, tool-condition sensors, vibration accelerometers, thermal sensors, calibration verifiers. Each observation enters as an authority-credentialed input under the AQ governance-chain primitive, weights into the envelope under a published composition policy, and contributes to the temporal forecast that projects how each dimension will evolve under the procedure's expected load and duration. The forecast is itself a credentialed assertion that the surgical team can inspect at planning time; deviations between forecast and observation re-enter the chain as governance signals.
The primitive is technology-neutral. It admits any sensor topology, any forecasting algorithm, and any actuation substrate; what it fixes architecturally is the structural condition that capability is held as governed state, evaluated against every operation, forecast over the horizon, recorded as lineage, and exposed to oversight. The inventive step is the use of capability as a first-class governed state variable in the actuation loop, with graduated mode-set outcomes and recursive re-entry of capability observations into the governance chain — converting capability from a specification-sheet metadata into a structural property of the device's behavior.
5. Compliance Mapping
FDA Quality System Regulation 21 C.F.R. § 820.30 design-controls obligations map to the capability envelope as a documented design output: the envelope's dimensions, measurement provenance, and evaluation policy are part of the device master record. The October 2023 Predetermined Change Control Plan guidance maps to the envelope's published policy; capability-evaluation behavior under specified change scenarios is documented ex ante and subject to real-world performance monitoring. FDA Medical Device Reporting under 21 C.F.R. Part 803 is supported by the lineage record: capability-driven refusals and overrides are reportable events with structured provenance.
MDR Article 10 general manufacturer obligations and Article 83 post-market surveillance map to the lineage of capability evaluations across the device fleet. AI Act Article 9 risk management is satisfied by the envelope's risk-bounded mode set; Article 10 data governance is satisfied by the credentialed observation streams that feed the envelope; Article 12 record-keeping is satisfied by the lineage record; Article 13 transparency is satisfied by the inspectable envelope and forecast; Article 14 human oversight is satisfied by the envelope's exposure to the surgeon during planning and execution; Article 15 accuracy and robustness are satisfied by the envelope's measurement provenance and forecast verification. IEC 60601-1 and IEC 80601-2-77 essential-performance and risk-control obligations map directly onto the graduated mode-set outcome.
Product-liability exposure under Restatement § 2 and Directive (EU) 2024/2853 is reduced by structural argument: the device refused operations outside its validated envelope, recorded the refusals, and exposed the boundary to the supervising clinician. Hospital risk-management contractual representations become demonstrable rather than promised. Notified-body conformity assessment is shortened because the architectural property the regulator is looking for is visible as a primitive rather than reconstructed from procedural documentation.
6. Adoption Pathway
Adoption is incremental and does not require platform replacement. A surgical-robotics manufacturer integrates the capability-awareness primitive as a substrate beneath its existing motion-control stack: capability dimensions are populated from sensors the device already carries, evaluation logic is inserted at the actuation boundary, lineage is emitted to a record that integrates with the manufacturer's existing post-market surveillance pipeline. A first deployment scope might be a single procedure family — for example, microsurgical anastomosis — where capability requirements are well-defined and the regulatory benefit of structural refusal is clearest. Additional procedures and additional capability dimensions are added as the deployment matures.
The commercial structure is an embedded substrate license to the device manufacturer, with sub-licensing to hospital operators as part of the platform subscription. Pricing is per-platform or per-credentialed-authority rather than per-procedure, which aligns with how manufacturers price platforms today and avoids per-use economics that would create perverse incentives at the actuation boundary. The manufacturer's connector library, motion-control IP, and clinical-application portfolio remain the differentiated layer; the primitive operates beneath them as substrate, providing the architectural property the regulatory regime requires without disturbing the differentiated stack above it.
The forward posture is decisive. Manufacturers that adopt the primitive obtain a structural answer to AI Act Articles 9–15, FDA Predetermined Change Control Plan obligations, and Directive (EU) 2024/2853 product-liability exposure — and they obtain it as a property of their device rather than as a clause in their service agreement. Hospital operators obtain devices that refuse operations outside their validated envelope and record the refusals for risk management. Surgical teams obtain a collaboration partner whose capability boundary is legible in real time. Regulators obtain the architectural floor on which the next generation of surgical autonomy can be safely authorized. Capability awareness is the primitive that makes the trajectory toward greater surgical autonomy compatible with the patient-safety discipline that the entire regulatory regime exists to enforce.
