A robot incident is rarely a single moment.
The visible part may be a stopped mobile base, a dropped tote, a pinched cable, a blocked aisle, an emergency stop, a collision with a cart, or a human who stepped back faster than expected. The useful story usually starts earlier. A map changed. A route became crowded. A sensor slowly lost clarity. A maintenance check slipped. A software update changed speed behavior. An operator learned that the fastest way to keep production moving was to restart the robot without writing down why it stopped.
Incident review is the discipline of finding that useful story without turning every event into blame. It belongs next to Robot Safety because safety is not finished when the risk assessment is signed. It belongs next to Robot Observability and Field Logs because the review can only learn from evidence the system preserved. Most of all, it belongs in daily operations because near misses are warnings that still leave time to improve.
Near Misses Are Evidence, Not Embarrassment
A near miss is an event that could have become harm, damage, or serious disruption under slightly different conditions. A robot stopped inches before a person entered its path. A manipulator brushed a fixture but did not knock it over. A gripper dropped a lightweight empty container instead of a full one. A worker pulled a cart away just before the robot turned. A robot entered the wrong aisle but was noticed before it blocked a forklift lane.
These events are easy to minimize because nothing dramatic happened. That is exactly why they matter. Near misses show the edge of the system before the system crosses it. They reveal weak cues, confusing interfaces, drifted maps, crowded routes, training gaps, and recovery habits that would otherwise stay hidden until an incident is more expensive.
A good safety culture does not ask operators to pretend every near miss is catastrophic. It asks them to treat near misses as practical evidence. The review should make it easier to report the next one, not harder. If workers learn that every report triggers punishment, downtime, or a lecture, the robot fleet will keep moving while the real risk moves underground.
Preserve The Scene Before It Disappears
Physical incidents decay quickly. The cart is moved. The box is picked up. The floor is cleaned. The robot is restarted. People leave for the next task. By the time an engineer reads a ticket, the scene may no longer explain anything. A useful incident process gives operators permission to preserve the minimum evidence before the site returns to motion.
That does not always mean freezing an entire work area. The response should match the event. A severe safety concern may require a stop and formal escalation. A minor near miss may need a photo of the layout, the robot’s event bundle, the task identifier, the time, the software version, and a short account from the people nearby. The important habit is to capture the physical arrangement before it is normalized away.
Robot Failure Recovery explains how a robot gets unstuck and returns to service. Incident review asks whether return-to-service happened too quickly to learn from the stop. Restarting a robot can be reasonable. Restarting it without preserving why it needed rescue is how the same problem becomes routine.
The Timeline Comes First
The first artifact of a review should be a timeline, not a verdict. The robot accepted a job, left the dock, took a route, slowed at an intersection, entered a shared aisle, detected an obstacle, changed mode, received an operator command, retried a recovery, or triggered a protective stop. Around that machine timeline sit human actions and site conditions. A person moved a cart. A tote was staged outside the expected area. A door stayed open. A cleaning crew changed floor traction. A supervisor asked for a manual override.
Timelines protect the review from the loudest fact. The dramatic moment may be the collision, but the decisive fact may be that the robot had already issued repeated localization warnings at that corner for two weeks. The visible mistake may be an operator override, but the deeper cause may be an interface that gave no useful explanation for why the robot was waiting. The robot may have touched an object, but the root problem may be a fixture that lets parts drift out of the defined work envelope.
Robot Operator Interfaces matter here because many incidents include a human-machine communication failure. The operator did what the interface made reasonable. If the interface hid uncertainty, used vague alerts, or offered a risky command too casually, the review should treat that as part of the system.
Blame Is Too Small For Robotics
Robots fail across layers. Hardware, software, sensing, maps, controls, maintenance, task design, site layout, training, and human workflow can all contribute to one event. Blame usually lands on the person closest to the incident because that is easiest to see. Robotics needs a wider lens.
An operator may have restarted the robot, but perhaps restarts were the only way to clear a false obstacle alert during a busy shift. A technician may have missed a dirty sensor, but perhaps the maintenance schedule never reflected how dusty the aisle became after a process change. A developer may have shipped a planner update, but perhaps the validation lane did not include the tight turn where the incident happened. A site manager may have allowed a cart staging area to creep into a route, but perhaps the robot’s route boundaries were never marked clearly enough for workers to know what mattered.
This does not remove accountability. It makes accountability useful. The review should identify decisions, controls, and missing feedback loops that can change. A review that ends with “operator error” but changes no interface, training, route, maintenance check, or robot behavior has not learned much.
Severity Needs More Than Damage
The severity of a robot event should not be judged only by what broke. A low-damage event can reveal a high-risk condition. A robot that nearly enters a pedestrian path at speed may leave no damage because someone moved. A gripper that drops an empty tote may be harmless that day but alarming if the same task sometimes carries heavy parts. A navigation fault in an empty aisle may be minor until the same aisle becomes crowded during shift change.
Severity should consider potential harm, exposed people, payload, speed, tool hazard, recoverability, confusion, repeatability, and whether existing controls worked as intended. It should also consider trust. A robot that startles workers repeatedly can degrade cooperation even when every event is technically low speed and low force. People who stop trusting the robot may take unsafe shortcuts around it.
Robot Operational Design Domains offers a useful frame. An incident may show that the robot left its supported domain, or that the domain was described too broadly. The answer may not be a bigger model. It may be a narrower route, lower speed in one zone, a clearer refusal behavior, better staging discipline, or a new validation case before the robot is allowed back into that condition.
Corrective Actions Should Be Testable
Many incident reviews end with soft actions: retrain the team, remind operators, monitor the issue, or improve communication. Those phrases can be appropriate, but they are weak unless they produce a testable change. A better corrective action changes the environment, the robot behavior, the interface, the maintenance routine, the map, the task definition, the escalation path, or the acceptance test in a way that can be checked later.
If a robot almost collided at a blind corner, a testable action may include a route change, speed limit, mirror, floor marking, sensor coverage check, intersection behavior update, and a repeat trial under realistic traffic. If an arm dropped a part after a gripper pad wore down, the action may include an inspection interval, wear indicator, force threshold, spare-part stock, and a replay of the failure case after replacement. If remote support restarted robots without local awareness, the action may include a visible session state and approval step.
Robot Task Design and Acceptance Tests becomes more valuable after incidents. The incident should update the task’s acceptance evidence. A failure case discovered in the field should not remain folklore. It should become part of how the robot is tested before future releases, site expansions, or route changes.
Return To Service Is A Decision
After an incident, pressure builds to restart the robot. That pressure is understandable. Robots are deployed because people need work done. But return-to-service should be a decision with conditions, not a reflex. The team should know what evidence was reviewed, what risk remains, what temporary controls are in place, who approved the restart, and what signs would trigger another stop.
Sometimes the right answer is a narrow return. The robot may resume on one route but not another. It may run at lower speed until a map correction is validated. It may operate with local supervision until an interface fix ships. It may handle empty totes but not loaded ones until a gripper issue is understood. These partial returns are often better than the false choice between full shutdown and pretending nothing happened.
Robot Fleet Management adds another layer. One robot’s incident may reveal a fleet condition. If three robots share the same map, dock design, software version, or maintenance pattern, the review should ask whether the corrective action belongs to one unit or the whole fleet.
Reviews Need A Memory
An incident process that lives only in meetings will fade. The organization needs a memory of events, causes, actions, approvals, and follow-up evidence. That memory should be searchable enough to reveal patterns without becoming a surveillance system. Repeated near misses at one intersection, repeated docking failures after cleaning, repeated operator overrides after a software update, or repeated dropped objects from one fixture are more important than any one ticket.
Pattern review is where near misses become especially powerful. A single report may be ambiguous. A cluster is harder to ignore. The cluster may point to a route, shift, object type, robot model, map version, training gap, or maintenance task that needs attention. The point of documentation is not to fill an archive. It is to make recurrence visible before people start calling it normal.
Robots that work around people need this habit. The machine will keep encountering changed rooms, tired operators, worn parts, imperfect maps, confusing handoffs, and novel objects. A near-miss review does not make the system flawless. It makes the system harder to fool twice in the same way. That is a serious form of progress in physical AI.
