Systems break—it is an inevitable reality of engineering. But as we increasingly integrate artificial intelligence into high-stakes domains, from emergency medicine to financial trading, the question shifts from "how do we prevent failure" to "how do we fail the right way?" Dr. Dan Dworkis argues that the deliberate contemplation of failure—what the Stoics called premeditatio malorum—is a design necessity, not just a theoretical exercise.

Dworkis proposes three axes to define failure: direction, timing, and extent. "Failing toward" involves identifying secondary points of stability, such as defaulting to human control when AI systems falter. Conversely, "failing away" helps steer the system to avoid high-risk areas, similar to how an aircraft executes a go-around maneuver if a landing sequence becomes unstable. By clearly defining these vectors, developers can build guardrails that keep systems functional even when core components go offline.

The timing of failure—early versus late—is equally vital to system longevity. Failing early often preserves resources, allowing teams to pivot before committing to an irreversible, faulty path. However, failing late is necessary when utilizing finite, mission-critical resources like oxygen in a hospital setting. The key here is not simply waiting for the end, but ensuring that the system provides clear, early warning signals so that the "late" failure is controlled and transparent rather than catastrophic.

Next is the distinction between partial and complete failure. A system that suffers a partial failure—like a video laryngoscope that loses its camera but still functions as a manual tool—remains useful. In contrast, "complete failure" is a strategic choice used to prevent dangerous cascading consequences, such as shutting down a bridge after an earthquake. Distinguishing between these allows engineers to build redundancy that maintains operability during unexpected events.

This framework is particularly pressing for human-AI teams, where the stakes of disagreement are high. When a machine and a human operator have differing intuitions about how a system should fail, friction is inevitable during a crisis. If one agent tries to "fail toward" human control while the other pushes to "fail late" to extract more value, the result is chaos. Explicitly programming and discussing these failure models beforehand is the only way to ensure cohesive, safe performance under pressure.

Systems break—it is an inevitable reality of engineering. But as we increasingly integrate artificial intelligence into high-stakes domains, from emergency medicine to financial trading, the question shifts from "how do we prevent failure" to "how do we fail the right way?" Dr. Dan Dworkis argues that the deliberate contemplation of failure—what the Stoics called premeditatio malorum—is a design necessity, not just a theoretical exercise.

Dworkis proposes three axes to define failure: direction, timing, and extent. "Failing toward" involves identifying secondary points of stability, such as defaulting to human control when AI systems falter. Conversely, "failing away" helps steer the system to avoid high-risk areas, similar to how an aircraft executes a go-around maneuver if a landing sequence becomes unstable. By clearly defining these vectors, developers can build guardrails that keep systems functional even when core components go offline.

The timing of failure—early versus late—is equally vital to system longevity. Failing early often preserves resources, allowing teams to pivot before committing to an irreversible, faulty path. However, failing late is necessary when utilizing finite, mission-critical resources like oxygen in a hospital setting. The key here is not simply waiting for the end, but ensuring that the system provides clear, early warning signals so that the "late" failure is controlled and transparent rather than catastrophic.

Next is the distinction between partial and complete failure. A system that suffers a partial failure—like a video laryngoscope that loses its camera but still functions as a manual tool—remains useful. In contrast, "complete failure" is a strategic choice used to prevent dangerous cascading consequences, such as shutting down a bridge after an earthquake. Distinguishing between these allows engineers to build redundancy that maintains operability during unexpected events.

This framework is particularly pressing for human-AI teams, where the stakes of disagreement are high. When a machine and a human operator have differing intuitions about how a system should fail, friction is inevitable during a crisis. If one agent tries to "fail toward" human control while the other pushes to "fail late" to extract more value, the result is chaos. Explicitly programming and discussing these failure models beforehand is the only way to ensure cohesive, safe performance under pressure.