If a robot needs rescuing, call it part of the demo

At a robotics startup, I’d like autonomy claims to include a standardized intervention rate, not just a successful-run percentage. How often did an operator correct the robot, take over by teleoperation, trigger a safety stop, physically rescue it, or quietly reset the run? The denominator matters too: per task, hour, pick, or autonomous run, with failed runs included.

A polished demo can otherwise teach investors and users that the robot works unattended when the real product includes a substantial human support layer. In a construction-site forklift study, 25 manual interventions occurred across 303 minutes of autonomous operation; that is much more informative than a clean highlight reel, even though it is not warehouse evidence. I understand that logs may expose customer data or useful weaknesses. Still, should intervention reporting be voluntary, independently audited, or required before marketing a robot as autonomous? Counterarguments and real examples welcome.

I support disclosure, but not a single headline number pretending to be universal. NIST’s position that autonomy depends on mission, environment, interaction, and implementation is important here. A rate needs scope and operator staffing beside it, or companies will optimize the metric instead of the system.

From a buyer’s perspective, “intervention rate” is useful only if it answers a staffing question: how many people must I schedule per shift? A robot needing one five-second confirmation is not equivalent to one needing remote rescue. I’d publish categories, not just an average.

The audit requirement worries me for early startups. Independent audits cost money and can slow pilots before the measurement process is even stable. I’d make a structured log voluntary at first, with a template and raw counts, then let procurement teams demand audits where the risk justifies it.

The customer-data objection is real. Intervention logs can reveal layouts, staffing patterns, production schedules, and failure conditions. A workable standard should allow redaction or aggregation while preserving event type, duration, trigger, and whether the operator had physical control. Transparency does not require publishing the floor plan.

Small precision point: the forklift result cited here concerns a construction site, not a warehouse. That distinction matters because environment and task complexity are part of the claim. I’d also separate “reset” from “intervention”; a reset can hide an entire failed attempt if reporting starts only after the restart.

In operations, the quiet reset is often the most important number. If the robot fails, someone clears the aisle, reloads the task, and restarts it, the dashboard may call that uptime. I’d want every run to have a start and end state, plus an exception record that cannot be deleted by the operator.

Enterprise procurement already asks versions of this, though usually in inconsistent questionnaires. A public mandate may be premature, but a standard reporting packet could become a contract requirement: task boundary, intervention classes, exposure hours, and support staffing. That would be more actionable than a marketing label.

I’m not convinced the proposed number helps ordinary users. A low intervention rate in a carefully constrained environment may be less autonomous than a higher rate in a messy one where the robot handles everything else safely. I’d regulate truthful task descriptions first and treat the rate as supporting evidence.

“Autonomous” should mean autonomous for the stated task, not autonomous in the promo video. Publish the logs, define the task, and stop making everyone reverse-engineer what happened off camera. Voluntary disclosure is fine until the label becomes a sales shortcut.