Standfirst: A cancellation acknowledgement establishes a software disposition, not a physical stop; substantiate the robot’s subsequent behaviour with controller records, corroborated motion measurements and stated uncertainty.
Executive takeaways
- Define the promise before testing it. Cancelling a task may require controlled deceleration, completion at a safe holding point or another documented response; it is not automatically an emergency stop.
- Examine operational behaviour and safety functions separately. Correlate cancellation requests, action-server disposition, controller and safety-function states, and corroborated motion observations; verify any claimed safety function under its own criteria.
- Retain the evidence for risk decisions. Keep tested configurations, exceptions and trace provenance for deployment reviews and insurer questions, without asserting coverage or pricing benefits.
The deployment decision must turn on observed behaviour
Before accepting a claim that robot cancellation produces a defined physical response, leadership should require documented operating limits and measured evidence from the installed machine. A console may display cancelled while the robot continues to move. The decision is whether to rely on the claim for deployment or procurement—not whether a software acknowledgement exists. A software acknowledgement alone cannot establish deceleration, stopping distance or payload stability. This matters when approving operation near people or valuable property, and when explaining controls to purchasers or insurers. Establishing the operational response does not by itself establish that cancellation is a safety function.
Continued motion after cancellation is not automatically a failure. The required response might be controlled deceleration, movement to a defined holding point, or a different documented action. The test is whether observed behaviour meets criteria established in advance for the actual robot and environment. The same evidentiary issue can arise in robots using conventional planning rather than artificial intelligence. Which response is appropriate depends on the hazard. A fast stop shortens travel towards a person or obstacle but can destabilise a load; a gentler deceleration can protect the load but lengthens travel. The choice belongs in the machine’s risk assessment (the structured evaluation of its hazards), not in the cancellation software alone.
This article concerns how evidence for a cancellation claim is examined. It is not machine-safety guidance and does not set safety requirements, stopping distances or test parameters. Those must come from the applicable standards, the machine’s risk assessment and a qualified safety engineer.
The ROS 2 Actions design does not establish a physical stop
Robot Operating System 2 (ROS 2) Actions support goal-oriented tasks with progress feedback, a result and optional cancellation. Its design distinguishes the request to cancel, the transition of an eligible goal into CANCELING, and later terminal outcomes such as CANCELED, SUCCEEDED or ABORTED. The action server is responsible for handling the application-side execution and any supported cancellation. [1]
The Jazzy CancelGoal service definition distinguishes accepted cancellation requests from rejected requests, unknown-goal outcomes and goals already in terminal states. A successful response indicates that one or more goals have transitioned to CANCELING; it is not proof that cancellation has completed or that physical motion has stopped. [2]
That design article describes communication and goal management, not actuator braking, measured stopping distance, payload stability or a particular robot’s safety integrity. An accepted cancellation request therefore does not itself prove a physical stop. Nor should a user-interface label be assumed to correspond to a particular action-state transition without inspecting the application implementation. The exact response codes require checking against the deployed ROS 2 release.
The ROS 2 Jazzy CancelGoal.srv definition was subsequently verified directly against the official ROS 2 rcl_interfaces source repository on 6 November 2026. The service distinguishes accepted cancellation requests from rejected requests, unknown goal identifiers and goals already in terminal states. An accepted request identifies goals that have entered CANCELING; it does not establish a terminal CANCELED result or a measured physical stop. Actual behaviour must still be established for the deployed implementation and robot configuration. [2]
Physical safety requirements belong to the relevant system type, operating environment and safety functions. ISO 3691-4:2023 specifies safety requirements and verification for driverless industrial trucks and explicitly includes autonomous mobile robots among its examples. It excludes trucks guided solely by mechanical means and remotely controlled trucks. Its applicability still depends on the actual machine and use; not every robot marketed as an AMR necessarily meets the defined scope. [3] The ISO scope and public preview were inspected, not the full normative requirements. No stopping threshold, conformity or certification conclusion is inferred. ISO 12100 supplies general machinery risk-assessment context, but this article does not examine a completed machine-specific risk assessment.
ISO 10218-1:2025 addresses industrial robots, but its publicly listed scope excludes specified mobility of robots or manipulators on driverless industrial trucks or mobile platforms. [4] Its stopping-function provisions cannot simply be transferred to mobile robot travel; the applicable standard and function must first be established for the actual machine. Application-level goal cancellation is a task-management operation, not by itself a verified safety function. The distinction is architectural: an assessor must establish where the cancellation command enters the control chain, whether it is outside or within the safety-related parts, whether it initiates a separate protective function, and which evidence demonstrates the required fault behaviour and integrity. ISO 13849-1 and IEC 62061 provide machinery-control functional-safety context, with requirements that depend on the applicable system and risk assessment; no Performance Level (PL) or Safety Integrity Level (SIL) is assigned here. A cancellation message must not be represented as, or substituted for, a protective or emergency stop merely because the resulting motion looks similar. The ROS 2 Actions design article examined makes no functional-safety claim for cancellation. [1]
Other standards may apply, depending on the machine and market. ANSI/RIA R15.08-1-2020 sets safety requirements for the design of industrial mobile robots in the United States [5]. IEC 60204-1 distinguishes stop category 0 (an uncontrolled stop by removing actuator power), category 1 (a controlled stop, followed by actuator-power removal) and category 2 (a controlled stop with power remaining available). These describe control/power behaviour, not an observed stopping distance or a guarantee of immediate standstill. Emergency-stop implementation uses category 0 or 1 as applicable to the machine and risk assessment. These descriptions were checked against secondary technical guidance, not the licensed IEC text. [6] Which standards govern a given robot is for a qualified safety engineer to establish.
Four linked observations make a cancellation claim examinable
ODA3 Institute’s proposed examination design, not yet applied to a deployed robot, separates four observation points, each with an identifiable source and time basis:
- Request: the client sends cancellation for an identified goal; record the goal identifier and request time.
- Server disposition: the action server accepts, rejects or otherwise disposes of the request; record the response and later goal status without treating them as motion measurements.
- Controller transition and safety-function state: retain commanded motion or holding response, operating mode, drive-enable and brake-command/feedback where present, plus separate, timestamped records for any relevant safety controller, protective-field state, fault and stop-function activation. The source and time base for each record matter: a stop triggered independently by a safety function must not automatically be attributed to cancellation.
- Physical outcome: independent or adequately cross-validated measurements establish velocity, position, stopping distance, load response and the uncertainty of those observations over the relevant interval.
Onboard wheel odometry and inertial measurements can be useful cross-checks, but should not automatically be called independent when they share sensing, software, clock or power dependencies with the control chain under examination. External tracking is a candidate for stronger corroboration: NIST has used optical tracking as position ground truth for a mobile manipulator on a cart [7]. For a cancellation trial, calibrated optical tracking, laser tracking or suitably timed video with reference markers may be candidates, not endorsed methods. Independence must be established from the measurement architecture, including shared power, clocks, network and software; external placement alone is insufficient. Each system needs a recorded calibration basis, sampling/latency analysis, traceable event alignment and an uncertainty budget appropriate to the stated tolerance. NIST’s example is not a stopping-performance validation.
Not every clock is synchronised, every sensor independent, or every event observable. A useful examination specifies clock alignment, timestamp provenance, sampling limits and unresolved intervals. It also checks whether logging continues through rejected, unknown-goal and late cancellation requests, terminal-state outcomes, faults, controller resets and disputed events.
Trace integrity, access, retention and version provenance are distinct from physical measurement accuracy. Without an adequate motion trace, the physical proposition remains unknown; that does not show that the system failed.
Testing should occur in an authorised and appropriately controlled environment. The test matrix should cover cancellation during different execution phases, including near-completion races, rejected and late requests, representative loads and surfaces, foreseeable degraded conditions and changes to the controller or firmware that might alter the response. Rejected requests should be tested against their specified software disposition rather than incorrectly treated as accepted cancellations. Acceptable continuation or stopping behaviour must be predefined from the applicable risk assessment; failures, incomplete trials and exceptions belong in the same record as successes. Tests of ordinary goal cancellation cannot be substituted for verification of a separate protective or emergency-stop function.
Testing cancellation behaviour can introduce physical hazards. A competent machine-safety owner would be expected to establish and approve a machine-specific test plan and risk assessment. For editorial examination purposes, relevant questions include how the plan controls access and load stability, provides an abort path independent of the cancellation under test, assigns supervisor authority, and records protective-function interventions rather than attributing them to cancellation. This article does not prescribe a safe test procedure or authorise a trial.
Evidence questions for executives, examiners and insurers
| Decision question | Evidence to examine | What it can establish | What remains uncertain |
|---|---|---|---|
| What does cancellation promise? | Requirements, operator display definition, risk assessment and controller interface specification | Defined physical behaviour and tolerances for a stated use case | Whether the requirement covers every hazard and operating condition |
| What was acknowledged? | Goal identifier, request/response records, goal-status history | Recorded software disposition and ordering | Whether the drive controller changed state at that time |
| What did the robot do next? | Controller mode and commands correlated with independent motion and load measurements | Observed transition, elapsed time and distance in tested trials | Clock error, sensor limitations and untested configurations |
| What happened when cancellation was rejected, unknown, late or raced completion? | Service response codes, terminal-state records, complete test register, exception records and retained unsuccessful trials | Whether tested outcomes matched the defined response | Rare event sequences not sampled or logged |
| Can a risk-transfer statement be substantiated? | Tested scope, version/configuration history, exceptions, loss and incident records | What the organisation can responsibly disclose about the control | Insurer-specific evidence requirements, loss frequency, liability and contract response |
Illustrative scenario — synthetic, not based on an examined system
An autonomous mobile robot carrying a pallet receives a cancellation request while its controller is executing a trajectory. The action server accepts the request, but the controller continues the current segment before beginning a controlled deceleration. The operator interface displays cancelled before independent tracking shows zero velocity.
If the approved operating specification requires deceleration within a defined interval and that interval is met, the continued movement may be consistent with the control design. If measurement exceeds the applicable tolerance, the trial may contradict the documented requirement. If controller logs exist but the motion trace is absent, the physical outcome is unknown. Those are three different conclusions. Meeting a stated operational tolerance does not establish that the tolerance adequately controls the hazards; that requires a separate risk assessment and any applicable safety-function validation. None alone proves injury, financial loss, legal liability or insured coverage.
Insurance relevance rests on a specific loss pathway, not an assumed rule
The underwriting relevance begins with an operational question: what physical response does the organisation claim for a cancellation, and what can the measured record substantiate? A robot’s unexpected continuation could, depending on the environment, contribute to collision, payload damage or injury. Financial effects might include damage to the organisation’s own property, interruption of operations, or a claim by someone else. Legal responsibility would require additional facts about design, integration, maintenance, instructions, conduct and applicable law. Whether property, business interruption, public/general liability, product liability or technology professional-liability insurance might apply is a policy-specific examination question, not a coverage determination.
There is relevant, but limited, market context. In China, a 19 May 2026 article republished by Shanghai’s official financial authority reports a payment of RMB 5,976.87 after a rented robot tipped over and damaged its camera equipment. The report describes claims documentation and the involvement of the insurer and manufacturer.
The report also attributes to a rental-platform executive concerns about distinguishing hardware, software and site-related fault, and reports a representative of PICC Property and Casualty, the insurer describing a shortage of third-party loss-assessment and repair bodies. These are reported market-participant observations, not independently established findings or evidence that cancellation telemetry would settle liability. The report does not attribute that event to ROS 2, a cancellation request or a stopping-control failure. It reports a robot-damage insurance payment, not evidence of the cancellation mechanism proposed here. [8]
In Japan, trade press reported on 26 October 2026 that Tokio Marine & Nichido Fire Insurance will begin offering “AI robot insurance” from November 2026 for autonomous mobile robots with physical AI, including wheeled, quadruped and humanoid types. As reported, it covers repair or replacement after physical damage, the insured company’s legal liability for injury or property damage to others, and business-continuity costs such as replacement staff or rental robots. Cyber-incident losses are excluded, and terms are set case by case after assessing intended use and operating environment. [9] This was an announcement, not evidence that a policy had been issued or a claim paid, nor that the insurer requires cancellation traces.
UK industry reporting says standard warehouse policy sections, including property, stock, employers’ liability and public liability, were not written with autonomous mobile robots in mind. Its suggested renewal questions cover safety sensor type, software ownership, data capture, maintenance structure and prior declinature; none concerns cancellation behaviour. [10] These examples concern China, Japan and the UK respectively; their insurance products and legal implications depend on local law, policy wording and market practice, and do not automatically transfer to another market, including India.
These sources support a plausible but unverified connection to underwriting: the loss classes are plausible and actual robot-insurance activity is documented or reported, but the particular evidentiary connection remains ODA3 Institute’s analysis. A prospective insurer could ask what physical response the enterprise claims and what the underlying measurements substantiate. The enterprise could supply a scoped test record rather than an unsupported assurance statement. The UK report’s questions about software ownership, data capture and maintenance provide relevant context, but do not establish demand for cancellation traces. No reviewed source establishes that doing so improves eligibility, pricing, limits, retentions or claim outcomes. A shared controller, software update or fleet configuration could create correlated losses across units or insureds, but such an accumulation is a scenario here, not an observed incident.
Management should own the claim and its supporting evidence
| Action | Accountable owner | Decision, evidence and trigger for reassessment |
|---|---|---|
| Define the cancellation response and distinguish it from safety functions such as emergency and protective stops | Head of robotics safety | Approve risk-assessment-based requirements; reassess for new operating limits, sites or changed safety architecture |
| Require measured trials before approving a physical-response claim | Chief Operating Officer | Review test register including exceptions and uncertainty; reconsider after changed load limits or deployment conditions |
| Retain trace provenance, access controls and rejected or failed trials | Chief Information Security Officer | Confirm integrity and availability of records; reassess after software, firmware or logging changes |
| Clarify what evidence an insurer actually requests | Head of insurance / risk transfer | Check proposal questions, policy wording and broker feedback; revisit at renewal or material changes |
| Review representations to purchasers and insurers | General Counsel | Check that external statements match tested scope and contracts; revisit when representations, wording or material system configurations change |
| Review unresolved exceptions before deployment expansion | Board Risk Committee chair | Require the next release’s exception register and management disposition; escalate unresolved boundary breaches |
The operating and safety engineering leads—not the CISO alone—must own the distinction between operational cancellation and safety functions. Management owns the controls, the operating decision and its representations.
Financial consequences remain conditional on an actual incident and loss; operational consequences concern evidence availability and release decisions; liability is fact- and jurisdiction-dependent; reputational consequences should not be asserted absent a specific disclosure or event.
Independent examination may verify stated behaviours within the tested scope; it cannot guarantee every future response. An insurer makes its own underwriting decisions, and coverage depends on the contract, relevant facts and applicable law.
Notably Absent
- No examined deployment: No named robot, installed controller, independently captured motion trace or measured stopping-distance distribution was reviewed or tested by ODA3 Institute.
- No demonstrated cancellation-caused loss: The Shanghai payment concerns a reported tip-over, not a cancellation failure. No cancellation-linked loss record was established from the sources checked.
- No verified insurer demand for cancellation traces: Neither a specific insurer’s underwriting manual nor a policy condition requiring the proposed four observations was verified. Market reporting cannot establish universal practice.
- No loss denominator or actuarial effect: The reviewed material provides no cancellation-failure frequency, validated severity distribution, premium differential or impact on claims acceptance.
- No completed functional-safety examination or certification: The ISO 3691-4 preview identifies relevant subjects only; the ISO 10218-1 public scope listing does not establish requirements for the travel of mobile platforms. Full requirements, installed-system applicability and conformity were not assessed; ROS 2 documentation is not a safety certificate.
- No proven fleet accumulation: Common components provide a plausible correlated-loss mechanism, but no such event or portfolio effect was established in this review.
- No jurisdiction-wide legal conclusion: Responsibility, enforceability of obligations and coverage must be evaluated against specific facts and policy wording. No ODA3 client engagement or independent assurance opinion occurred.
The decision for leadership
Leadership can require a robot-cancellation claim to identify the promised physical response, tested configuration, observed motion and unresolved uncertainty before relying on it. Such evidence supports a bounded deployment decision and may inform an insurer’s questions; it cannot settle loss likelihood, liability or coverage. The unresolved insurance question is whether a particular insurer considers that evidence material to its own assessment.
References
[1] Biggs, G., Perron, J., Loretz, S. “Actions.” ROS 2 Design, written March 2019; modified May 2020. https://design.ros2.org/articles/actions.html (accessed 29 October 2026).
[2] ROS 2, rcl_interfaces, Jazzy branch. “CancelGoal.srv” (action_msgs/srv/CancelGoal.srv). Official ROS 2 source repository. https://github.com/ros2/rcl_interfaces/blob/jazzy/action_msgs/srv/CancelGoal.srv (source inspected 6 November 2026). The official Jazzy service definition specifies cancellation response codes and the goals_cancelingfield. The deployed ROS 2 version, action-server implementation and physical robot response were not examined.
[3] International Organization for Standardization. “ISO 3691-4:2023 — Driverless industrial trucks and their systems.” Preview/contents, June 2023. https://www.iso.org/standard/83545.html (official scope and preview, accessed 29 October 2026; full requirements not reviewed).
[4] International Organization for Standardization. “ISO 10218-1:2025 — Robotics — Safety requirements — Part 1: Industrial robots.” Edition 3, February 2025. https://www.iso.org/standard/73933.html (official ISO publication and publicly available scope, verified 6 November 2026; full normative requirements not reviewed).
[5] Robotic Industries Association (RIA), Association for Advancing Automation (A3). “New R15.08 Part 1 American National Standard for Industrial Mobile Robot Safety Requirements Published by Robotic Industries Association.” 26 January 2021. https://www.automate.org/robotics/news/new-r15-08-part-1-american-national-standard-for-industrial-mobile-robot-safety-requirements-published-by-robotic-industries-association/aph (official industry-association announcement; publication date verified 6 November 2026; full ANSI/RIA R15.08-1-2020 standard not reviewed).
[6] Control Design. “Standards and options for e-stops.” 2021 (per URL). https://www.controldesign.com/articles/2021/standards-and-options-for-e-stops (accessed 29 October 2026). Secondary description of IEC 60204-1 stop categories and ISO 13850; the standards were not reviewed.
[7] National Institute of Standards and Technology. “Performance Measurement of a Mobile Manipulator-on-a-Cart and Coordinate Registration Methods for Manufacturing Applications.” NIST Advanced Manufacturing Series 100-45, 2021. https://www.nist.gov/node/1688746 (accessed 29 October 2026). Abstract reviewed.
[8] Shangguan News, republished by Shanghai municipal financial authority. “一台机器人意外摔倒获赔5976元，全国首例机器人保险理赔在沪落地.” 19 May 2026. https://jrj.sh.gov.cn/BX182/20260519/702838a8864045129d1e1680b3e524d2.html (accessed 29 October 2026).
[9] Lobo, G. “Tokio Marine to launch insurance for AI-enabled robots.” (Re)in Asia, 26 October 2026. https://reinasia.com/tokio-marine-to-launch-insurance-for-ai-enabled-robots/ (accessed 29 October 2026). Reports a company announcement; the original press release was not located, but three Japanese outlets (Logi Today, SBbit, BSR) report the same 26 October announcement.
[10] Sellers, M. “Britain’s warehouses are filling up with Chinese robots. Insurers aren’t ready for them.” Insurance Business UK, 3 August 2026. https://www.insurancebusinessmag.com/uk/news/breaking-news/britains-warehouses-are-filling-up-with-chinese-robots–insurers-arent-ready-for-them-584674.aspx (accessed 29 October 2026).
Methodology note
Document-based examination of ROS 2 task cancellation and potential physical-response evidence, with an explicitly synthetic illustrative scenario and bounded insurance-market reporting. No deployed robot or safety function independently examined.
Notably Absent
No examined deployment or motion trace; no demonstrated cancellation-caused loss; no verified insurer demand for cancellation traces; no loss denominator or actuarial effect; no completed functional-safety examination or certification; no proven fleet accumulation; no jurisdiction-wide legal conclusion; no ODA3 client engagement or independent assurance opinion.
