3. Taxonomy overview

The categories follow the lifecycle of an engineered system: who is responsible (A), what is known and decided (B), how it is designed (C–E), how it is checked (F), changed (G) and operated (H), and how the organization learns (I).

Quick view: nine questions

A checklist works best with five to nine items, so the taxonomy can be used as one question per category. Each question leads to the rules of its category.

Category	Question
A. Responsibility	Who can be harmed, is the work within our competence, can people speak up without fear or a conflict of interest, and who can stop it?
B. Knowledge and decisions	Are requirements and goals measurable, decisions recorded and sized by reversibility, stop criteria set in advance, and models, data, evidence and indicators trustworthy?
C. Design	How can each part fail or interact badly, and is the design as simple as the requirements allow?
D. Protection	Is the hazard removed at the source, and if not, which independent controls contain it, and can one person cause and hide harm alone?
E. Capacity and continuity	How much margin is there, how much work is in progress, and what happens when the load exceeds the capacity?
F. Verification and review	Who checked the work, and was it tested the way it will be operated?
G. Change	Is each change reviewed, explained to the people affected, made in small steps, and isolated from the people working on it?
H. Operation and maintenance	Will we notice a problem before harm, and can people act on what they see?
I. Learning	Do we preserve evidence, investigate anomalies, and change the system afterwards?

Analogy map: engineering object → management object

The left column is the engineering term used in this taxonomy. The right column is the thing that plays the same role in an organization.

Engineering	Management	Same role
system	organization, team, project, process	the thing that must deliver a function
load	demand, workload, number of requests	what the system must carry
margin	reserve: schedule buffer, budget contingency, spare capacity of people	capacity above the expected load
redundancy (N-1)	deputy, successor, second supplier	survives the loss of one element
fail-safe state	default decision, fallback authority	the harmless state after a failure
emergency stop (andon)	speak-up channel, stop-the-line right	the person nearest to a problem can stop work
checker	reviewer, internal audit, external auditor	a person other than the author checks the work
alert	exception report to the next management level	a signal that needs action now
alarm fatigue	report overload	too many signals → all signals are ignored
commissioning	acceptance plus benefits review	checks that the whole works for the owner
postmortem	after-action review	learning after an event
isolation (lockout/tagout)	protected iteration (for example the Sprint Goal)	nobody changes the work while people work on it
control loop oscillation	reorganization churn, priority churn	switching back and forth around a target
bottleneck	constraint (theory of constraints)	the part that limits total output
bullwhip effect	bullwhip effect (same term)	each stage amplifies the variation it sees
provenance	supplier due diligence	knowing where a part comes from
compartment	ring-fenced unit: separate legal entity, budget or team	a failure that cannot spread
exact constraint (one owner per property)	single point of accountability, unity of command	each property or decision has exactly one owner

Rules per category

• A. Responsibility — Duties toward people, the environment and the work itself.
• P1 Public safety first (MUST)
• P2 Work within competence (MUST)
• P3 Sustainability (SHOULD)
• P4 Stop authority (SHOULD)
• P5 Psychological safety (SHOULD)
• P6 Conflict-of-interest disclosure (MUST)
• P7 Commander's intent (SHOULD)
• P8 Fair process (SHOULD)
• B. Knowledge and decisions — How requirements, decisions, models and evidence are recorded and trusted.
• P9 Measurable requirements (MUST)
• P10 Decision records (SHOULD)
• P11 Trustworthy evidence (SHOULD)
• P12 Model validity (SHOULD)
• P13 Automated reproducible results (SHOULD)
• P14 Provenance (SHOULD)
• P15 Precaution (SHOULD)
• P16 Set-based design (SHOULD)
• P17 Technology maturity (SHOULD)
• P18 Decision speed by reversibility (SHOULD)
• P19 Indicators are not targets (SHOULD)
• P20 Stop criteria set in advance (SHOULD)
• P21 Specific, challenging goals with feedback (SHOULD)
• C. Design — How to shape a design before it is built, so that it fails less.
• P22 Failure and interaction analysis (SHOULD)
• P23 Simplicity and modularity (SHOULD)
• P24 Lifecycle and decommissioning (SHOULD)
• P25 Human factors (SHOULD)
• P26 Design for testability (SHOULD)
• P27 Robustness (SHOULD)
• P28 Accumulated degradation (SHOULD)
• P29 Compatibility (SHOULD)
• P30 Exact constraint (SHOULD)
• P31 Design by selection (SHOULD)
• P32 End-to-end (SHOULD)
• P33 Strict interfaces (SHOULD)
• P34 Weakest-link scaling (SHOULD)
• P35 Structure follows the intended system (SHOULD)
• D. Protection — Controls that prevent harm, or contain it when it happens.
• P36 Least privilege (MUST)
• P37 Fail-safe (MUST)
• P38 Hierarchy of controls (SHOULD)
• P39 Error-proofing (SHOULD)
• P40 Defense in depth (SHOULD)
• P41 Compartments (SHOULD)
• P42 Two-person rule (SHOULD)
• P43 Segregation of duties (MUST)
• E. Capacity and continuity — How the system keeps working under high load and partial failure.
• P44 Margin (SHOULD)
• P45 Redundancy (N-1) (SHOULD)
• P46 Diversity (SHOULD)
• P47 Graceful degradation (SHOULD)
• P48 Damping (SHOULD)
• P49 Induced demand (SHOULD)
• P50 Bottleneck first (SHOULD)
• P51 Shared demand signal (SHOULD)
• P52 Limit work in progress (SHOULD)
• P53 Late work and added people (SHOULD)
• F. Verification and review — How to prove that the work is correct.
• P54 Verification and validation (MUST)
• P55 Find defects early (SHOULD)
• P56 Independent checker (MUST)
• P57 Test as you operate (SHOULD)
• P58 Comparable measurement (SHOULD)
• P59 Traceability (MUST)
• P60 Codes as minimum (MUST)
• P61 Qualified procedure and person (SHOULD)
• P62 Structured selection of people (SHOULD)
• P63 Feedback on the task (SHOULD)
• G. Change — How to change the system safely.
• P64 Versioning and change review (MUST)
• P65 Small verified steps (SHOULD)
• P66 Isolation before work (MUST)
• P67 Critical path (SHOULD)
• P68 Observational method (SHOULD)
• P69 Guided change (SHOULD)
• H. Operation and maintenance — How to run, watch and maintain the system.
• P70 Monitoring in operation (SHOULD)
• P71 Checklists (SHOULD)
• P72 Critical control points (SHOULD)
• P73 Response faster than harm (SHOULD)
• P74 Maintenance by failure pattern (SHOULD)
• P75 Actionable alerts (SHOULD)
• P76 Sterile critical phase (SHOULD)
• P77 Data as a dependency (SHOULD)
• P78 Asset inventory (SHOULD)
• P79 Span of control (SHOULD)
• I. Learning — How to learn from failures and anomalies.
• P80 Blameless root cause analysis (SHOULD)
• P81 Plan-Do-Check-Act (SHOULD)
• P82 Investigate anomalies (SHOULD)
• P83 Preserve evidence (SHOULD)
• K. Conflict rules — K1, K2, K3, K4, K5, K6, K7, K8