Adaptive Capacity and Residuality

Core Concepts

The Four Cornerstones of Resilience Engineering

Erik Hollnagel's resilience engineering framework organizes adaptive capacity into four interdependent cornerstones. They are not stages in a sequence. They operate simultaneously, and deficiency in any single one limits the whole.

Fig 1

Anticipate means the ability to forecast threats before they materialize. This is not prediction in the strict sense — it is scenario planning, horizon scanning, and recognizing emerging patterns. Anticipatory capacity draws from historical incident data and from understanding evolving system pressures: regulatory changes, partner dependencies, traffic profile shifts.

Monitor is the continuous observation of system functioning across multiple levels — individual task performance, team coordination, organizational processes, and system-wide metrics. Effective monitoring enables early detection of anomalies before they escalate. The engineering challenge is balancing sensitivity to real anomalies against alert fatigue, which dulls the organization's ability to detect genuine threats.

Respond is the capacity to adjust operations when unexpected variation occurs. Effective response has two layers: planned responses for anticipated failure modes, and adaptive flexibility to construct novel responses for situations that fall outside those plans. Response depends on frontline workers having authority to make rapid adjustments, on clear cross-level communication, and on psychological safety that removes the fear of blame for taking corrective action.

Learn at the organizational level is more than post-incident reviews. It is a collective, multilevel, multidimensional process — sharing knowledge, understanding the system, and redesigning system properties based on experience. It extends to learning from normal operations and successful adaptations, not just failures.

---

Safety-II: Learning from What Goes Right

Safety-I, the traditional paradigm, is reactive: incidents are investigated after they occur, root causes are identified, and mitigations are deployed to prevent recurrence. This is valuable but structurally limited — it can only generate learning from accidents that have already happened.

Safety-II flips the temporal orientation. Instead of asking "why did this fail?" it asks "why does this succeed, most of the time, under varying conditions?" The data source is everyday operations, not incident queues.

Things do not go well because people follow procedures and work as imagined. Things go well because people make sensible adjustments according to the demands of the situation.

This distinction has structural consequences. Safety-II studies the adaptive mechanisms that workers and systems deploy to handle unexpected challenges — the improvisation, the informal workarounds, the knowledge-sharing that doesn't appear in documented procedures. These adaptations are not deviations from correct behavior; they are often the mechanism by which safety is maintained.

The observable gap this surfaces is between work-as-imagined (what procedures and architecture diagrams describe) and work-as-done (what people actually do to get outcomes). Safety-II treats that gap as a signal worth investigating, not a compliance problem to eliminate.

---

Human Variability: Liability or Resource?

The contrast between Safety-I and Safety-II maps directly onto how human variability is framed.

Safety-I treats variability as a problem. Humans deviate from procedures; those deviations cause incidents; the fix is tighter procedures and controls. The human is an error-prone component to be constrained.

Safety-II treats variability as a resource. Human performance variability has both positive and negative effects. The goal is to amplify the positive effects — the adaptive responses, the situational awareness, the expert judgment — while adding controls that mitigate genuinely harmful variation. The human is an adaptive agent whose expertise is a primary mechanism for sustained safe performance.

This isn't a philosophical preference. Organizations build resilience by cultivating diversity in expertise and fostering knowledge sharing. Frontline workers and domain specialists hold practical knowledge that is critical for recognizing and adapting to unexpected change. Safety Differently — the practitioner wing of Safety-II — advocates devolving decision-making authority to frontline workers, treating them as the primary source of safety insight rather than the primary source of safety risk.

---

Safety Is Not a Stable State

A foundational claim in resilience engineering: safety is not a static property but an emergent dynamic capability that must be actively sustained. You cannot design safety in once and consider it done. It requires ongoing vigilant monitoring, rapid response, learning from successes and near-misses, and proactive anticipation of emerging threats.

This has immediate implications for distributed systems. The safety constraints defined at design time may be violated during operation due to changing environmental conditions, mission creep, staffing changes, or organizational pressures. A system that was safe at launch drifts toward risk over time through the accumulation of small operational decisions that individually seem harmless.

---

STAMP: A Systems-Theoretic Alternative to Root Cause Analysis

Nancy Leveson's Systems-Theoretic Accident Model and Processes (STAMP) addresses the limits of traditional linear accident models. Root-cause analysis — tracing a failure back to a single defective component or human error — implicitly assumes that complex systems fail through simple causal chains. STAMP rejects this assumption.

STAMP focuses on system properties and interactions rather than isolated component failures. It is explicitly designed for software-intensive, sociotechnical systems where safety emerges from the control relationships between components. An accident in STAMP terms is a failure of control: a system drifted into a state where a safety constraint was violated because the control hierarchy failed to prevent it.

Critically, STAMP accounts for temporal drift: systems migrate toward heightened risk through both design and operational choices over their lifetime. This is not a bug introduced at a single point in time — it is the cumulative effect of small decisions that push the system's operating envelope toward its edges.

Contemporary safety research treats NAT, HRO, Resilience Engineering, and STAMP as complementary lenses rather than competing theories. They address different temporal scales and aspects of system safety. STAMP contributes the mechanism-level view of how control failures propagate through sociotechnical architectures.

---

Residuality Theory: Architectures Trained, Not Designed

Residuality theory, developed by Barry O'Reilly, is a methodology for discovering resilient software architectures through stress-testing rather than upfront design. The core claim: architectures should be trained, not designed.

Traditional architecture practice relies on requirements elicitation, upfront modeling, and design patterns selected by experienced architects. The assumption is that architects can foresee the problems a system needs to handle. Residuality challenges this assumption in complex, uncertain environments: the range of actual stressors that will affect a production system is broader than any design exercise can enumerate.

The basic method:

1. Start with a naive (baseline) architecture that satisfies functional requirements.
2. Enumerate plausible environmental stressors through conversations with domain experts: market shifts, regulatory changes, partner failures, scale events, security threats.
3. For each stressor, ask: what survives? How does the system reconfigure? The surviving configuration is the residue.
4. Across all stressors, identify components and patterns that appear consistently in residues. These are the critical elements — the architecture cannot shed them and still function.
5. Identify components that disappear under specific stressors. These are contingent on specific environmental assumptions that may not hold.

The accumulated residues define the actual resilient architecture.

Attractors are where stressors drive the architecture: stable or semi-stable regions in the system's configuration space. This concept is borrowed from complexity science and dynamical systems theory. By identifying attractors and their associated residues, architects understand not just which components survive, but the regions of the design space the system gravitates toward under different pressure profiles.

Technical debt, reframed: residuality treats accumulated architectural debt not as a code hygiene problem but as a complexity problem — a symptom of incomplete stress-testing and failure to discover what architectures truly survive in production. The debt accumulated because the design phase did not expose the architecture to the full range of environmental pressures it would face.

Theoretical roots: the methodology draws explicitly from two sources. Stuart Kauffman's NK fitness landscape model from complexity science models how changing one component has cascading effects depending on the state of related components — residuality applies this insight to reveal true interdependency structure. And biological evolution: organisms that survive stressors pass traits forward; those that don't perish. Architecture patterns are evaluated by their ability to survive, not their elegance.

---

How Organizations Lose Adaptive Capacity

Adaptive capacity does not erode in a single moment. It degrades through compounding organizational dynamics:

Organizational rigidity develops as institutional norms and culture — initially sources of strength — become rigid and maladaptive. Institutional isomorphism accelerates this: organizations tend to adopt prevailing industry norms and practices, gradually reducing their distinctive adaptive flexibility. The result is systemic inertia that slows response to dynamic environments.

Prevention-only focus narrows organizational attention. Three mechanisms can prevent strategic drift: early warning systems, strategic resilience cultivation, and structural/cultural flexibility. Organizations that focus only on preventing known failure modes — the Safety-I posture — skip the monitoring and anticipation investments that would surface novel threats.

Decline in innovation during the decline cycle. Organizational decline can function as a stimulus for renewal when organizations channel pressure toward adaptive responses — but this only happens when adaptive capacity exists to convert urgency into experimentation. Organizations without adaptive capacity persist in defensive strategies, making the underlying rigidity worse.

Crisis as diagnostic. Crisis situations reveal pre-existing gaps in adaptive capacity that were present before the crisis, not caused by it. The crisis simply exceeds the organization's coping mechanisms, making the gap visible. This means post-crisis resilience work must address the structural conditions — distributed decision-making, learning systems, leadership vision — that allowed the gap to develop.

---

Thought Experiment

You are a staff engineer at a payment processing company. Your platform handles checkout flows for thousands of merchants. It has been running reliably for three years. You have runbooks, incident playbooks, and SLO dashboards.

A new VP of Engineering declares that your on-call procedures are "too loose." She institutes mandatory escalation after five minutes, a new change approval board for any deployment touching payment paths, and a policy requiring written root-cause analysis for every P2 incident. All incidents are now tracked in a shared spreadsheet for monthly executive review.

Consider these questions:

On the four cornerstones: Which cornerstone does the new regime invest in most heavily? Which does it risk degrading? What would a monitor-and-anticipate investment look like instead?

On human variability: The runbooks your most experienced on-call engineers have built up over three years include dozens of informal annotations — "if this alert fires on weekends it's usually the batch job, check X first." Where does this knowledge live under the new regime? What happens when those engineers leave?

On work-as-imagined vs. work-as-done: The change approval board reviews change descriptions. The actual deployments are often more complex than descriptions capture. What is the safety model implicitly assumed by the board? What are its failure modes?

On residuality: The platform has never been stress-tested against a major payment network outage, a regulatory audit freeze on schema changes, or a large merchant leaving suddenly. Under each of these stressors, which components of your architecture would survive? Which would require renegotiation of assumptions? Do you know?

There are no correct answers. The thought experiment is complete when you can articulate a concrete tradeoff the VP's approach makes, and what you would add or change to restore a specific weakened cornerstone.

---

Worked Example

Applying Residuality Methodology to an E-commerce Checkout Service

Baseline architecture (naive): An e-commerce checkout service with synchronous dependencies: inventory service (checks stock), payment gateway (charges card), notification service (sends order confirmation email), and fraud detection service (real-time scoring).

Step 1: Enumerate stressors (domain expert conversations)

A stressor enumeration session with the product, operations, and finance leads surfaces:

• Payment gateway goes down for 30 minutes during peak traffic (happened once at a competitor)
• Fraud detection service latency spikes to 8 seconds per request under load
• Notification service vendor deprecates the API with 48 hours notice
• A regulatory audit freezes all deployments for two weeks during a high-traffic season
• A key third-party inventory data supplier fails to renew contract

Step 2: Identify residues for each stressor

Gateway outage: The residue is a checkout service that holds payment intent and retries asynchronously. Inventory reservation and fraud check can happen but the payment step becomes eventually consistent. Components that survive: inventory, fraud detection, cart state. Components that must change assumption: synchronous payment confirmation in the UX.

Fraud detection spike: The residue requires either a timeout-and-accept policy or a cached/async scoring model. The 8-second synchronous path breaks user experience. Surviving components: payment, inventory, notifications. The real-time fraud guarantee must be relaxed or decoupled.

Notification vendor deprecation: This stressor only affects the notification service. The residue shows notifications are not in the critical payment path — the checkout can complete without them. This clarifies that notification coupling in the current design is an assumption, not a requirement.

Regulatory freeze: No deployments for two weeks. The residue is the system as it existed at freeze time, serving traffic without any changes. This stressor surfaces implicit assumptions about deployment frequency: are there operational tasks (certificate rotations, config updates) that require deployment? If yes, the freeze creates a new failure mode.

Inventory supplier failure: The residue requires either a stale-cache model (serve last-known inventory, oversell risk) or graceful degradation (show products as available, handle backorders post-checkout). Either residue is a different business contract than "always show accurate inventory."

Step 3: Identify attractors

Across all stressors, certain patterns appear in most residues:

• Cart state must be durable and locally owned (not dependent on any single external service)
• Payment processing must tolerate async completion
• Each integration point must have an explicit degradation policy

Components that appear only in some residues:

• Real-time fraud scoring (disappears under latency spike stressor)
• Synchronous inventory confirmation (disappears under supplier failure stressor)

Step 4: The discovered architecture

The residue analysis reveals the resilient architecture: durable cart state, async payment with retry, eventually consistent inventory, decoupled notifications, and explicit timeout-and-degrade policies for fraud detection. This is not radically different from the baseline — but the dependencies are now explicit, the contingent assumptions are named, and the team knows which parts they cannot lose.

On technical debt: the naive architecture had implicit real-time coupling everywhere. That coupling is the debt — not messy code, but incomplete modeling of which synchronous guarantees actually survive in production.

---

Compare & Contrast

Safety-I vs. Safety-II: The Practical Distinction

Dimension	Safety-I	Safety-II
Primary question	Why did this fail?	Why does this succeed?
Data source	Incident reports, near-misses	Normal operations, everyday work
Temporal orientation	Reactive, post-event	Proactive, ongoing
Human variability	Liability to be constrained	Resource to be cultivated
Learning target	Prevent recurrence of known failures	Understand and reinforce adaptive capacity
Procedure model	Procedures define correct behavior; deviations are errors	Procedures are starting points; adaptation is normal
Frontline role	Source of risk	Source of knowledge

The practical approach integrates both: Safety-I provides defenses and hazard controls for known risks; Safety-II provides methods for learning from successful performance and managing variability in complex, adaptive systems. Running only Safety-I leaves adaptive capacity unmeasured and unmaintained.

STAMP vs. Root-Cause Analysis

Dimension	Root-Cause Analysis	STAMP
Model of causation	Linear chains, proximate and root causes	System properties, control failures, emergent behavior
Scope	The specific incident	The system's safety constraint structure over time
Temporal lens	Point-in-time failure	Drift over operational lifetime
Unit of analysis	Component failures	Control relationships between components
Primary output	Corrective actions for identified causes	Analysis of inadequate control structures
Human framing	Human error as a cause	Human decisions within a control hierarchy

STAMP does not replace root-cause analysis for simple systems with linear failure modes. It is most valuable when the same accident pattern recurs despite corrective actions, or when failure involves the interaction of components rather than the failure of a single one.

Residuality Theory vs. Traditional Architecture Design

Dimension	Traditional upfront design	Residuality
Starting point	Requirements and functional specifications	Naive architecture satisfying functional requirements
Primary activity	Pattern selection, modeling, review	Stressor enumeration, residue identification
Discovery mechanism	Architect expertise and foresight	Stress-testing against plausible environmental shocks
Technical debt framing	Code quality and design choices	Incomplete modeling of complex interdependencies
Output	Designed architecture	Discovered architecture (residues across stressors)
Uncertainty handling	Risk registers, mitigation plans	Stressor enumeration, attractor analysis

Residuality does not claim to replace all design practice — it addresses the gap between designed behavior and production behavior in environments where the range of possible stressors exceeds what upfront analysis can enumerate.