Model 1 · Defences and latent conditions
Swiss Cheese Model
What the model explains
Reason’s model represents safety as multiple defensive layers. Weaknesses in those layers, together with active failures and latent conditions, can align and permit a hazard to reach a harmful outcome. It shifted attention away from treating front-line actions as a complete explanation.
Potential SToC contribution
SToC can organise relevant conditions across Safety, Technology and Organisational Culture, then ask how they interacted in the specific case. +RC and +RRC add explicit prompts about the pace of operational or technological change and the pace and adequacy of regulatory response.
Where the comparison is useful
Use the Swiss Cheese Model to examine defence in depth and how weaknesses can align. Use SToC alongside it to trace how a technological limitation, a safety control and an organisational norm may reinforce or constrain one another, and whether those relationships changed over time. This is an added structure for analysis; Reason’s work already recognises latent organisational conditions and the wider system.
Question for a case: Which conditions weakened or bypassed a defence, and how did Safety, Technology and Organisational Culture shape that pathway together?
Foundational source: Reason, J. (1990). “The contribution of latent human failures to the breakdown of complex systems.” Philosophical Transactions of the Royal Society B, 327(1241), 475–484. DOI: 10.1098/rstb.1990.0090.
Model 2 · System structure and accident potential
Normal Accident Theory
What the theory explains
Perrow analyses how interactive complexity and tight coupling can combine to create system accidents that are difficult to anticipate and contain. The framework directs attention to system structure and the propagation of unexpected interactions, rather than only to a single component or operator.
Potential SToC contribution
SToC can connect structural risk to the case’s safety arrangements, technology capabilities and limitations, and organisational conditions. +RC and +RRC make it possible to ask how that risk profile changes as technology, operations and regulatory responses evolve.
Where the comparison is useful
Use Normal Accident Theory to consider whether interaction complexity and coupling make failure propagation difficult to control. Use SToC to examine the mechanisms and contextual conditions that shape those interactions, including how controls, training, authority, incentives and technology influence exposure or recovery. SToC does not, by itself, confirm or refute Perrow’s argument about the normality or inevitability of accidents in particular system types.
Question for a case: What was tightly coupled or interactively complex, and how did controls, technology and organisational practice affect the ability to detect, manage or recover from a disturbance?
Foundational source: Perrow, C. (1984). Normal Accidents: Living with High-Risk Technologies. Basic Books. See also the updated Princeton University Press edition: publisher page.
Model 3 · Functions, variability and resonance
Functional Resonance Analysis Method (FRAM)
What the method explains
FRAM models how functions in complex socio-technical work depend on one another. It examines performance variability in everyday work and how variability across coupled functions can combine in ways that produce outcomes that are difficult to predict from a simple linear chain. It can be used to study both how work succeeds and how it fails.
Potential SToC contribution
SToC can provide a complementary set of questions for interpreting FRAM functions and couplings: what is at stake for Safety, what capabilities and limitations belong to Technology, and how Organisational Culture shapes work. +RC and +RRC prompt examination of change and regulatory response around that functional picture.
Where the comparison is useful
FRAM offers a way to represent functions, dependencies and variability; SToC offers a cross-domain lens for examining the conditions shaping them. An analyst could use SToC to classify or discuss mechanisms emerging from a FRAM study, while retaining FRAM’s own model of functions and variability. This pairing may help compare cases without reducing a dynamic process to a list of isolated factors.
Question for a case: Which functions varied, how were they coupled, and what safety, technological and cultural conditions shaped that variability?
Foundational source: Hollnagel, E. (2012). FRAM: The Functional Resonance Analysis Method: Modelling Complex Socio-technical Systems. Ashgate / Routledge. Publisher page.
Model 4 · Human–automation interaction
Bainbridge’s “Ironies of Automation”
What the analysis explains
Bainbridge describes how automation can leave people responsible for monitoring a system and intervening in unusual situations, even as routine manual engagement and opportunities to maintain skill are reduced. Automation also leaves design and allocation decisions with human consequences; it does not remove the human role from the system.
Potential SToC contribution
SToC can place automation reliance within an explicit Technology domain while tracing how safety assurance, training, supervision, workload, authority and operating norms shape the human–automation relationship. +RC and +RRC provide prompts for examining how that relationship changes as systems and rules change.
Where the comparison is useful
Bainbridge gives a focused account of automation’s human-factors consequences. SToC can widen the case analysis around it: how design assumptions and interfaces interact with safety controls and organisational decisions about competence, staffing and acceptable reliance. This can help connect cockpit or control-room experience to wider organisational and regulatory conditions without losing the detail of the automation problem.
Question for a case: What tasks were automated, what work remained for people, and how did design, training, operational practice and assurance affect the ability to understand and intervene?
Foundational source: Bainbridge, L. (1983). “Ironies of automation.” Automatica, 19(6), 775–779. DOI: 10.1016/0005-1098(83)90046-8.
Model 5 · Classification of human factors
Human Factors Analysis and Classification System (HFACS)
What the system explains
HFACS provides a structured taxonomy for classifying human factors in accidents and incidents. Its commonly used four levels are unsafe acts, preconditions for unsafe acts, unsafe supervision and organisational influences. It was developed from Reason’s active and latent failure perspective and gives investigators a consistent vocabulary for coding contributing factors.
Potential SToC contribution
SToC can complement classification by asking how factors coded at different HFACS levels interact across Safety, Technology and Organisational Culture, and how case context shapes those interactions. +RC and +RRC provide distinct prompts for considering change and regulatory response that may not be captured by a code alone.
Where the comparison is useful
HFACS is valuable when structured classification and comparison of coded factors are required. SToC can help develop a connected explanation from those factors: how a precondition, supervisory practice, technical capability and safety arrangement combined in this case. It should not replace HFACS coding where that taxonomy is required, and the comparison should respect the definitions and version of HFACS actually used.
Question for a case: Beyond identifying the relevant HFACS categories, how did the coded factors interact across domains and over time to shape the event or the system’s resilience?
Foundational sources: Wiegmann, D. A., & Shappell, S. A. (2001). A Human Error Analysis of Commercial Aviation Accidents Using the Human Factors Analysis and Classification System (HFACS). FAA Office of Aerospace Medicine, Report DOT/FAA/AM-01/3. FAA report. See also Wiegmann & Shappell (2003), A Human Error Approach to Aviation Accident Analysis.