From research-skills
Apply Charles Perrow's Normal Accident Theory to analyze complex systems for interactive complexity, tight coupling, and accident potential. Use when the user wants to review system architecture, diagnose incidents, assess risk in high-risk systems, or invokes /perrow-system-safety.
How this skill is triggered — by the user, by Claude, or both
Slash command
/research-skills:perrow-system-safetyThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Based on Charles Perrow's *Normal Accidents: Living with High-Risk Technologies* (1984). Apply these frameworks when analyzing systems for safety, diagnosing incidents, or reviewing architecture.
Based on Charles Perrow's Normal Accidents: Living with High-Risk Technologies (1984). Apply these frameworks when analyzing systems for safety, diagnosing incidents, or reviewing architecture.
In systems with interactive complexity AND tight coupling, accidents are inevitable ("normal"). They arise from unanticipated interactions of multiple small failures, not from single catastrophic failures.
Classify any system on two axes to assess accident potential:
INTERACTION
Linear ◄─────────► Complex
┌─────────────────┬─────────────────┐
Loose │ Quadrant I │ Quadrant II │
COUPLING │ Low risk │ Moderate risk │
│ e.g. Auto │ e.g. University│
│ manufacturing │ research lab │
├─────────────────┼─────────────────┤
Tight │ Quadrant III │ Quadrant IV │
│ Moderate risk │ HIGHEST RISK │
│ e.g. Hydro │ e.g. Nuclear │
│ electric dam │ power, chemical│
│ │ plants, aviation│
└─────────────────┴─────────────────┘
Quadrant IV systems (complex + tight) are where normal accidents occur. Most high-profile disasters live here.
A system has high interactive complexity if it has:
| Factor | Complex (score +1) | Linear (score 0) |
|---|---|---|
| Proximity | Components in close proximity, shorting possible | Spatially segregated subsystems |
| Common-mode connections | Shared connections that couple subsystems | Dedicated, independent connections |
| Interconnected subsystems | Tight interconnections between subsystems | Subsystems can operate independently |
| Substitutability | Limited ability to substitute components or roles | Easy to substitute supplies/equipment/personnel |
| Feedback loops | Multiple, unfamiliar feedback loops | Few feedback loops, all understood |
| Controls | Multiple controls per function | Single-purpose controls |
| Information | Indirect, inferred information | Direct, observable information |
| Understanding | Unfamiliar, unexpected sequences | Well-understood production sequences |
Scoring: 0-3 = Linear; 4-6 = Moderately Complex; 7-8 = Highly Complex
A system is tightly coupled if:
| Factor | Tight (score +1) | Loose (score 0) |
|---|---|---|
| Timing | Delays not possible, must proceed on schedule | Can delay, hold, or pause processes |
| Sequence | Invariant sequence required | Multiple valid sequences possible |
| Methods | Only one way to achieve goal | Multiple methods available |
| Slack | No slack/buffer between components | Some buffer exists between stages |
| Buffers | No designed-in buffers | Fortuitous buffers can absorb failures |
Scoring: 0-2 = Loose; 3 = Moderate; 4-5 = Tight
When diagnosing any failure or incident, systematically examine six components:
| Characteristic | System Accident | Component Failure |
|---|---|---|
| Number of failures | Multiple, interacting | Single point of failure |
| Predictability | Unanticipated sequences | Expected failure mode |
| Root cause | Interactive complexity + tight coupling | Design flaw, wear, operator error |
| Post-incident blame | Often misattributed to "operator error" | Correctly attributed to component |
| Prevention | Redesign for loose coupling / linearity | Redundancy, maintenance, training |
Some systems are structurally configured to induce errors and defeat attempts at error reduction. Key indicators:
Key insight: In error-inducing systems, improving any single component may be inconsequential because other components will be allowed to express more risk. Only wholesale reconfiguration can make the system error-avoiding.
Perrow distinguishes three types of systems by how they transform inputs:
| Type | Description | Risk Profile |
|---|---|---|
| Transformation | Changes the nature of materials (nuclear, chemical) | Highest risk — poorly understood dynamics, unobservable processes |
| Fabricating | Assembles components into products (manufacturing) | Lower risk — linear, well-understood sequences |
| Additive | Moves things without changing them (transport) | Variable — depends on complexity/coupling |
Aviation is largely additive but becomes transformational at high speed/altitude ("exceeding the buffet boundary"), where it takes on the dangerous characteristics of transformation systems.
Production pressures are a systemic force, not individual greed. Assess:
When reviewing any system (software architecture, organizational process, physical plant):
When an incident occurs:
Perrow proposes classifying high-risk systems along two dimensions: net catastrophic potential and cost of alternatives. This yields three action categories:
Systems where inevitable risks outweigh reasonable benefits:
Systems we cannot easily do without, but where risks should be reduced:
Systems that are partially self-correcting and can be further improved:
Perrow argues that conventional risk assessment is flawed because it:
Key insight: "Ultimately, the issue is not risk, but power; the power to impose risks on the many for the benefit of the few."
"In tightly coupled systems, failures can cascade rapidly, and there is little slack or buffer to absorb them."
"Complex systems produce more unfamiliar sequences than are actually displayed in any given accident."
"Operator error is a convenient catch-all for mishaps whose real cause is uncertain, complex, or embarrassing to the system."
"There is no organizational structure that we would or should tolerate that could prevent [system accidents in nuclear power]."
"The issue is not risk, but power; the power to impose risks on the many for the benefit of the few."
npx claudepluginhub mason-1011/mason_skills --plugin analysis-skillsCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.