Safety-II

For decades, the field of safety has been preoccupied with one central question: why do things go wrong? This "Safety-I" approach, focused on analyzing failures and eliminating their root causes, has made our world demonstrably safer. However, it leaves a critical puzzle unsolved: in highly complex and dynamic environments like hospitals or flight decks, where procedures are constantly adapted and plans rarely unfold perfectly, why do things almost always go right? This gap in understanding points to a need for a new perspective.

This article introduces ​​Safety-II​​, a revolutionary paradigm that shifts the focus from preventing failures to understanding and ensuring success. Instead of viewing human adaptation as a liability, Safety-II recognizes it as the most vital resource for creating resilient systems. In the following sections, we will delve into this transformative concept. First, we will explore the core ​​Principles and Mechanisms​​ of Safety-II, dissecting the roles of performance variability, resilience, and a Just Culture. Subsequently, we will examine its ​​Applications and Interdisciplinary Connections​​, discovering how this philosophy is being used to redesign healthcare systems, build safer AI, and create new ways to measure what truly matters—the capacity for success.

Imagine you are in charge of safety for a busy system—perhaps a hospital, an airline, or a power plant. What is your job? For a long time, the answer seemed obvious: your job is to make sure as few things as possible go wrong. If there is an accident, you investigate, find the broken part or the mistaken person, and you fix it or create a new rule to prevent it from happening again. This is the world of ​​Safety-I​​. It defines safety as the absence of negatives. It is a philosophy of finding and fixing failures.

This approach is sensible and has made our world remarkably safe in many ways. We learn from tragedy. When a medication error harms a patient, we conduct a Root Cause Analysis, perhaps discovering a confusing label or a lapse in procedure. The solution? Add a checklist, redesign the label, implement a double-check. In this view, we measure safety by counting failures—the number of adverse events per thousand patient-days, for instance (, ). The goal is to drive that number down, ideally to zero. The underlying assumption is that our systems are fundamentally safe, and they only become unsafe when a component—human or technical—malfunctions.

But a curious puzzle emerges when you look closely at complex systems. If you spend time in a bustling Emergency Department, you will notice that things almost never go according to plan. A patient's data is missing from the computer, a crucial piece of equipment is in use elsewhere, a key lab result is delayed, and the team is dealing with an unexpected surge of patients. Yet, somehow, almost all the time, the team pulls through. Patients are treated effectively, care is delivered, and success is achieved.

This observation is the gateway to a profound shift in thinking. It leads us to ask a different question. Instead of asking "Why do things go wrong?", we start to ask, "Why do things go right?". This is the world of ​​Safety-II​​.

The central insight of ​​Safety-II​​ is that in complex systems, success is not the result of perfect, unwavering adherence to procedure. It is the result of constant, skillful adaptation. Think about driving a car. The "procedure" might be "stay in your lane at the speed limit." But to actually do this, you are making thousands of tiny, continuous adjustments to the steering wheel and pedals, responding to the curve of the road, bumps, wind, and the behavior of other drivers. This continuous adjustment is ​​performance variability​​.

From a rigid Safety-I perspective, this variability is the enemy. It is a deviation from the plan, a source of error to be stamped out with stricter rules and automation. But from a Safety-II perspective, this variability is not a bug; it is the essential feature. It is the very resource that people use to close the gap between the neat, tidy "work-as-imagined" in the procedure manual and the messy, unpredictable "work-as-done" in the real world (``).

Procedures and plans, no matter how detailed, can never fully specify the correct action for every possible contingency in a dynamic environment like a hospital or a chemical reactor (``). When faced with an unexpected situation—a "disturbance" in the workflow—it is the adaptive capacity of people that allows the system to succeed. In this light, successes and failures are not fundamentally different kinds of events. They are both outcomes of the same process: human and system adaptation in the face of uncertainty. An adaptation that works is a success. An adaptation that doesn't is a failure. Safety, then, is not the absence of variability, but the presence of the capacity to make that variability successful.

If adaptive variability is the secret ingredient, how do we cultivate it? The answer lies in building ​​resilience​​. Resilience is not just about being tough or having backup equipment. It is a dynamic, system-level capability. Resilience engineering, a practical application of Safety-II, tells us that resilient systems excel at four key things: anticipating, monitoring, responding, and learning (``).

• ​​Anticipate​​: Resilient systems don't just look backward at past failures; they look forward. They ask, "What could happen next? What are our vulnerabilities?". This is why proactive measures, like running in-situ simulations of rare airway emergencies or documenting an explicit "Plan B" before a procedure, are powerful indicators of a system's resilience (``).

• ​​Monitor​​: Resilient systems have a deep "sensitivity to operations" (``). They are attuned to subtle signs that things are drifting towards a boundary of unsafe performance. This isn't just about alarms; it's about the team's shared awareness and their reluctance to simplify what they are seeing.

• ​​Respond​​: When a disturbance happens—a sudden surge in patient census, a critical data feed going down—how does the system react? A brittle system grinds to a halt. A resilient system adapts. It might flex its staffing, re-prioritize tasks, or use clever workarounds to maintain its core functions. A key measure of this is not whether a disturbance occurred, but how quickly the system recovered its function afterwards (``).

• ​​Learn​​: A Safety-I system learns from failure. A Safety-II system learns from everything. It asks why a shift went so smoothly despite being short-staffed. It treasures near-miss reports not as evidence of failure, but as free lessons in successful recovery. A resilient system has mechanisms to ensure these lessons are converted into actual changes (``).

In this view, resilience is an ​​epistemic resource​​—a form of collective knowledge continuously generated and updated by the team about how to make the system work under all kinds of conditions (``).

This philosophical shift from preventing failure to ensuring success demands a new way of measuring. While tracking failures remains important, it's like trying to understand health by only studying disease. Safety-II gives us a new set of lenses.

The change can be captured quite beautifully with a little bit of formalism. A Safety-I approach focuses on reducing the overall probability of failure, let's call it $\mathbb{P}(F)$. A Safety-II approach is more nuanced. It focuses on increasing the probability of success, $S$, given that the system is experiencing variability or disturbance, $V$. It wants to maximize $\mathbb{P}(S|V)$ (``).

An even more powerful way to think about it is through the lens of robustness. Imagine you have a performance function, $r(s)$, that measures how well your system is doing in any given state $s$, which is influenced by the context $x$ (like workload or staffing). A simple approach is to maximize the average performance across all contexts, $\mathbb{E}[r(s)]$. But this could hide a critical weakness: your system might perform brilliantly in easy contexts but catastrophically in difficult ones. A resilient, Safety-II approach is different. It aims to maximize the worst-case performance. Mathematically, it seeks to solve $\max \inf_{x} \mathbb{E}[r(s)|x]$ (``). This means you are trying to make your system as good as it can be even on its worst day. That is the essence of resilience.

In practice, this means we develop new metrics. Instead of only counting adverse events, we can use the rich data from electronic health records to measure resilience directly. For every "disturbance" in a workflow—say, an alert for a drug allergy—we can check if a successful adaptation occurred (the order was canceled or changed). This gives us a powerful new metric: the rate of successful adaptations (). We can even make it more sophisticated by weighting each disturbance by its potential severity, creating a **severity-weighted resilience ratio** (). These are the vital signs of a healthy, adaptive system.

Finally, where do people fit in? Safety-II is not about ignoring mistakes. It's about understanding them. Human error theory distinguishes between different types of unintended actions (``). A ​​slip​​ is when you have the right plan but your hand fumbles—you intend to click "Save" but accidentally click "Delete." A ​​lapse​​ is a memory failure—you get interrupted and forget to complete the final step in a sequence. A ​​mistake​​, however, is different; it's when you do exactly what you intended, but your plan was wrong from the start.

Understanding these differences is crucial because they point to different solutions. Slips often point to poor interface design. Mistakes point to faulty mental models or incorrect information. Lapses point to systems that are vulnerable to interruption.

This leads us to the concept of a ​​Just Culture​​ (``). A just culture is not a "no-blame" culture. It is a culture of fairness and learning. It draws a clear line between blameless human error (an unintentional slip), at-risk behavior (taking a shortcut that seems reasonable), and reckless behavior (a conscious disregard for safety). Human error should be consoled, and the system should be examined. At-risk behavior warrants coaching to understand why the shortcut was taken. Only reckless behavior warrants punitive action.

This is the bedrock on which Safety-II is built. To understand why things go right, we need people to feel safe enough to tell us how work is really done—with all its messy adaptations and creative workarounds. A just culture creates the psychological safety that fuels the reporting and learning engine of a truly resilient organization. It allows us to move beyond simply preventing the worst from happening and toward creating systems where success is the normal, expected, and resiliently engineered state of affairs.

When we learn to ride a bicycle, how do we do it? Do we create an exhaustive catalog of every fall, analyzing the precise angle of impact and the velocity at the moment of failure? Of course not. We learn by succeeding. We learn from the thousands of tiny, almost unconscious adjustments of balance, the subtle shifts in weight and steering that keep us upright. The story of learning to ride a bike is overwhelmingly a story of continuous, successful adaptation, punctuated by a few rare failures.

This simple observation is the heart of a profound shift in thinking known as Safety-II. The previous section laid out its core principles, contrasting it with the traditional view of safety, which is almost exclusively concerned with studying failures. Now, we will see how this new perspective is not merely an academic curiosity but a powerful, practical tool that is reshaping our world. We will journey through hospital wards, engineering labs, and executive boardrooms to see how the simple idea of “learning from what goes right” is fostering remarkable innovations in everything from medical ethics to artificial intelligence.

For decades, the response to an accident in any complex system, be it an airplane crash or a medication error, has followed a familiar script. An investigation is launched to hunt for the “root cause.” Like a detective story, the goal is to find the single culprit—the broken component, the faulty procedure, the one person who made a critical mistake. This linear, cause-and-effect model is the cornerstone of methods like Root Cause Analysis (RCA).

Safety-II proposes a radically different lens. It begins with the recognition that complex systems are never static. They are in a constant state of flux, and the people within them are constantly adjusting and adapting to changing conditions—higher workload, ambiguous information, unexpected interruptions. The astonishing truth is that most of the time, these countless, everyday adaptations are precisely why things go right. From this viewpoint, a catastrophic failure is not the result of a single broken part or a rogue error. Instead, it is often an unlucky, emergent outcome of normally variable performances resonating in just the wrong way. This systemic view is the basis of powerful analytical techniques like the Functional Resonance Analysis Method (FRAM), which models how success and failure both arise from the same wellspring of everyday performance variability (``).

This change in perspective has profound implications that extend far beyond technical accident reports, reaching into the very heart of medical ethics and communication. When a medical error or a "near miss" occurs, the traditional approach is to disclose the failure and apologize. While necessary, this is incomplete. A Safety-II approach transforms this conversation. Imagine a scenario where a patient nearly received the wrong medication, but a nurse caught the error at the last second. The disclosure would not only acknowledge what almost went wrong but would also explain what went right. It would illuminate the built-in resilience of the system—the cross-checks, the cognitive aids, and the sharp-eyed expertise of the team that ultimately protected the patient. This type of disclosure respects the patient’s autonomy by giving them a richer, more honest picture of the complex reality of healthcare. It reframes the narrative from one of isolated failure to one of systemic resilience, building trust by revealing the very mechanisms that work tirelessly to ensure safety (``).

If we can understand the ingredients of success, can we design systems that make success more likely? This is where Safety-II moves from analysis to synthesis, providing a blueprint for engineering more robust and adaptive systems.

Consider the growing crisis of clinician burnout, often exacerbated by poorly designed technology. Imagine a hospital where an AI system generates alerts for a life-threatening condition. Let's say alerts arrive at a rate of $\lambda$ per hour, and a clinician can handle them at a rate of $\mu$ per hour. In the world of operations science, the workload is represented by the ratio $\rho = \lambda / \mu$. As long as $\rho$ is comfortably less than 1, the system is stable. But now, suppose a "silent" update makes the AI behave unpredictably. Clinicians, experiencing this "automation surprise," must spend more time verifying every alert. Their effective service rate, $\mu$, plummets. If $\lambda$ stays the same, the workload $\rho$ can quickly soar past 1. At this point, the system becomes unstable. The backlog of alerts grows without bound, and with it, the clinician's cognitive load and stress. This is not a personal failing; it is a mathematical certainty of an overloaded system.

A Safety-II approach to design tackles this head-on. It focuses on building "resilience features" that support the human operator. This includes making the AI's reasoning transparent to avoid surprise, but also designing the system to manage its own workload. For instance, it can implement adaptive throttling to intelligently manage the alert rate ($\lambda$) during spikes, ensuring the workload ratio $\rho$ remains in a safe, stable zone. It creates a partnership where the technology adapts to support the human, preventing the downward spiral into burnout (``).

We can go even further. Instead of merely preventing overload, can we build systems that actively learn from human expertise? Picture a system that doesn't just flag deviations from a standard procedure but recognizes when a deviation is actually a moment of brilliance—a clever, safe workaround to an unexpected problem. A Safety-II learning system is designed to do just that. It captures the context ($C$), the adaptive action ($A$), and the successful outcome ($O=1$). By applying statistical methods like Bayesian updating, the system can estimate the probability of that adaptation's success in a similar future context, $P(O=1 \mid C, A)$. It systematically builds a knowledge base of proven, successful strategies—a true playbook for resilience that can be shared across an entire organization, allowing everyone to learn from the expertise of the best (``).

This principle extends to the frontier of AI safety. As we deploy ever-more powerful AI, a central question is how to grant it autonomy safely. The traditional approach relies on rigid, pre-programmed rules. Safety-II inspires a more elegant solution: "adaptive guardrails." An AI might start with very limited autonomy, requiring human confirmation for all its actions. The system then carefully monitors its performance. In specific contexts ($X$) where the AI repeatedly demonstrates successful outcomes ($Y=1$), the system's confidence in the AI's performance in that context, represented by the probability $p(Y=1 \mid X)$, grows. Once this confidence crosses a pre-defined safety threshold, the guardrails can be selectively loosened, granting the AI more autonomy only in situations where it has earned it through proven, reliable success. It is a system that learns to trust, based on verifiable evidence of things going right (``).

A skeptic might listen to all this and ask, "This sounds like a nice philosophy, but can you measure it? Is 'resilience' a real, quantifiable property?" The answer is an emphatic yes. Making the abstract concepts of Safety-II concrete and measurable is a critical and active area of work.

Let's return to the hospital. Imagine a clinical AI system that suffers from intermittent network outages, leaving clinicians without its guidance for short periods. A traditional Safety-I analysis would focus on counting the adverse events that occurred during these downtimes. A Safety-II analysis asks a more insightful question: "How well did the team cope, and what did they do to succeed despite the disruption?"

We can design metrics to answer this directly. For instance, we can define a primary resilience outcome, $R$, as the probability that essential care was still delivered within a safe time window, $\tau$, even during an outage ($U=1$), so $R = P(T \le \tau \mid U=1)$. But we can also measure the adaptive process itself. By analyzing electronic health record logs, we can quantify a "compensatory action rate," $C$, which measures how often clinicians used proactive workarounds—like ordering medications based on their own judgment or increasing communication with colleagues—during an outage. Using robust statistical tools like Interrupted Time Series (ITS) and Statistical Process Control (SPC) charts, we can monitor these metrics over time. This allows us to move beyond anecdotes and obtain a rigorous, quantitative understanding of a system's resilience, enabling us to see if our efforts to improve it are actually working (``).

Adopting this new philosophy is not a solitary endeavor; it requires a coordinated, interprofessional effort. It changes how organizations structure their teams and manage improvement projects.

Consider a hospital seeking to implement a major new informatics intervention. To succeed through a Safety-II lens, a collaborative leadership team is essential. The ​​Chief Information Officer (CIO)​​ provides the foundational IT strategy, ensuring the infrastructure is robust, secure, and interoperable. The ​​Chief Medical Information Officer (CMIO)​​, a physician leader, serves as the bridge to clinical practice, ensuring the technology fits the messy reality of patient care, championing safety, and managing the crucial human side of change. In the middle is the ​​informaticist​​, the expert translator who turns clinical needs into working code, builds the measurement instruments to study "work-as-done," and analyzes the results.

This team doesn't just "launch" a project. They engage in iterative Plan-Do-Study-Act (PDSA) cycles. In each cycle, they don't just ask, "Did we reduce failures?" They also ask, "Did we enable more successes? What are the clever ways our colleagues are using this new tool to create good outcomes?" This focus on learning from everyday success, from the frontline "work-as-done," becomes the engine of continuous, resilient improvement (``).

From the way we analyze accidents to the way we design intelligent systems and structure our organizations, the principles of Safety-II offer a unified and, ultimately, more optimistic path forward. It sees the variability and adaptability inherent in people not as a liability to be controlled, but as the most vital resource for resilience. By understanding, supporting, and amplifying this capacity for success, we don't just make our complex world safer—we make it work better.