The Software Safety Ceiling: Why Physical AI Cannot Be Made Safe in Software Alone

Physical AI systems control actuators that can cause physical harm. Current safety practice in this domain leans heavily on software mechanisms: monitors, watchdogs, redundant channels, and formal methods. This paper argues that software-only safety has a fundamental architectural limit. The mechanism is fate-sharing: a software safety monitor and the components it monitors share a substrate — CPU, memory, operating system, firmware, power, clock, supply chain, and design assumptions. Failures in any shared resource can affect both the monitor and the monitored. The probability of correlated failure can be reduced by careful engineering, but cannot be eliminated by software design alone.

Three high-stakes physical domains have, by formal decision, mandated hardware-isolated safety mechanisms: aviation (DO-178C / DO-254 / ARP4754A, 1990s onward), nuclear (IEC 60880, 1986; IEC 61513), and rail (EN 50128 / EN 50129, 2001 onward). Each domain converged on this conclusion independently, after evidence that software-only approaches did not provide assurance equivalent to physical safety requirements. Physical AI exhibits the three features that drove this convergence: high-stakes physical outcomes, complex software stacks, and adversarial environments. The historical base rate predicts the same architectural conclusion.

This paper names the limit — the Software Safety Ceiling — and the underlying mechanism — fate-sharing. It addresses five common objections and finds each insufficient. The implication is direct: hardware-level safety mechanisms are necessary for Physical AI, not optional, not nice-to-have, not a future research direction.