77 accidents. 93 injuries. One pattern.

In 2024, researchers at North Carolina State University and the University of Leeds published the first comprehensive analysis of robot-related workplace injuries using OSHA Severe Injury Reports. The dataset covered 2015 to 2022. The numbers are small enough to fit on a single card — and large enough to define a pattern.

77 accidents. That's the total number of robot-related incidents identified in OSHA's Severe Injury Reports over eight years. Of those, 54 involved stationary industrial robots and 23 involved mobile robots.

93 injuries. The 54 stationary robot accidents resulted in 66 injuries — predominantly finger amputations and fractures to the head and torso. The 23 mobile robot accidents caused 27 injuries, mainly fractures to the legs and feet. Combined: 93 injuries across 77 incidents.

Over 60% caused by unexpected activation. A separate comprehensive analysis of 303 human-robot interaction accident reports, published in Safety Science in 2025, identified seven distinct incident archetypes. Archetype 1 — unexpected activation — dominated across all time periods, accounting for over 60% of all incidents. The pattern is consistent: the robot moved when the worker believed it was stopped.

This is not a statistical abstraction. It describes a specific physical scenario: a worker enters what they believe is a safe zone, and the robot activates — either because a lockout procedure was incomplete, a sensor triggered unexpectedly, or a software state change occurred that the worker didn't anticipate.

The Sanders et al. study found that the most common injury was partial finger amputation — the worker's hand was in the wrong place when the robot moved. The second most common was fractures from being struck or pinned. These injuries don't come from robots doing something complex. They come from robots doing something simple — moving — at a moment when the human expected stillness.

Hardware-enforced safety exists to make this pattern impossible. If the safety layer is independent of the control software — operating at the hardware level with its own power domain — it doesn't matter whether the software state is "stopped" or "running." The physical actuator cannot move unless the hardware safety channel confirms it is safe to do so. That's the difference between a software flag and a physical interlock.