7. Rules by category

A. Responsibility

Duties toward people, the environment and the work itself.

ID	Name	Strength	IF (condition)	THEN (action)	BECAUSE (reason)	Example (software/infra)
P1	Public safety first (Learn)	MUST	always	put public safety above cost, schedule and convenience	failures harm people outside the project	block a release that leaks user data
P2	Work within competence (Learn)	MUST	always	work only within your competence, and involve an expert outside it	error rates rise outside known areas	a security engineer reviews an IAM design
P3	Sustainability (Learn)	SHOULD	always	reduce environmental impact and resource use across the whole lifecycle	NSPE canon 1 includes sustainable development	scale idle environments to zero
P4	Stop authority (Learn)	SHOULD	anyone finds a problem that could cause harm	let that person stop the work without needing permission and without being blamed; the stop must always be available, must override all other functions, and resetting it must not restart the system	the person nearest to a problem sees it first	a deploy freeze that overrides Argo CD auto-sync; lifting the freeze requires an explicit sync
P5	Psychological safety (Learn)	SHOULD	people work together on a system	make it safe to report errors, ask questions and disagree: leaders ask for input, thank people for bad news, and never punish an honest report	psychological safety enables learning behavior, which drives team performance; problems that people hide cannot be fixed	the first person to report a broken pipeline is thanked, not blamed; the team lead names their own mistake in the retrospective
P6	Conflict-of-interest disclosure (Learn)	MUST	a person decides on, reviews or advises on work in which they have a personal interest	disclose the interest and step out of the decision or review	a personal interest biases judgment and destroys trust in the decision	an engineer who holds shares in a monitoring vendor leaves its evaluation
P7	Commander's intent (Learn)	SHOULD	you delegate a task	state the purpose, the desired end state and the constraints, and leave the method to the people who do the work (mission orders)	plans meet changing conditions; people who know the purpose can act correctly without new orders	an epic states "why", "done when" and "must not", not a list of kubectl steps
P8	Fair process (Learn)	SHOULD	a decision affects people	engage them (ask for input and challenge), explain the final decision and its reasons, and state the new expectations clearly; this is not consensus	people accept and carry out decisions they disagree with when the process was fair	before changing the on-call model, the team is asked, then told the decision, the reasons and the new rules

ID	Class (why)	HOW TO CHECK	VIOLATION (opposite of the rule)	RELATED	Evidence	Source domain
P1	universal (U), category A: true for every system	every release gate contains a safety and security sign-off item	shipping a known safety defect to meet a deadline	strengthens P37, P38; strengthened by P4	strong	all (professional ethics)
P2	universal (U), category A: true for every system	each design has a named checker with expertise in its domain	approving work in a domain you do not know	strengthens P56; strengthened by P6, P62	strong	all (professional ethics)
P3	universal (U), category A: true for every system	resource use is measured and reviewed	unused resources running all the time	depends on P24; strengthened by P24, P49	moderate	all (professional ethics)
P4	universal (U), category A: trigger that occurs in the life cycle of every system	the stop mechanism exists, works in every operating mode, does not restart on reset, and every use is reviewed without blame	a release continues while a known problem is still being discussed	depends on P80; strengthens P1, P82; strengthened by P5	strong (emergency stop is standardized in ISO 13850)	manufacturing (Toyota andon), machinery (emergency stop)
P5	universal (U), category A: every system is built or operated by people who work together	a regular anonymous survey item on safety to speak up; the number of reported near misses does not fall after an incident	punishing the person who reported a problem	strengthens P80, P82, P4; strengthened by P63; conflicts with accountability (see K7)	strong (peer-reviewed field study; Google study of 180 teams)	management (team leadership)
P6	universal (U), category A: trigger that occurs in the life cycle of every system (every system has suppliers, reviewers and decision-makers)	a register of declared interests exists and is checked before each vendor selection, design review and approval	a reviewer approves a design that uses a product of a company they own	strengthens P2, P43, P56	strong (NSPE Code of Ethics II.4.a; G20/OECD Principles II.F.2)	professional ethics, management (corporate governance)
P7	universal (U), category A: every engineering organization delegates work	each delegated task or epic states purpose, end state and constraints	a step list with no purpose; work stops when the plan no longer fits	depends on P2; conflicts with P71, P72, P61 (see K6)	strong (US Army doctrine ADP 6-0)	management (military command and control)
P8	universal (U), category A: every engineering organization makes decisions that affect people	for each decision that changes people's work: an input round, a written explanation and stated expectations exist	announcing a reorganization without reasons	strengthens P64, P69	moderate (management research; practitioner article)	management (organizational justice)

B. Knowledge and decisions

How requirements, decisions, models and evidence are recorded and trusted.

ID	Name	Strength	IF (condition)	THEN (action)	BECAUSE (reason)	Example (software/infra)
P9	Measurable requirements (Learn)	MUST	always	write each requirement as measurable, and link it to a user need	an unmeasurable requirement cannot be verified	"p95 latency \< 200 ms", linked to a ticket
P10	Decision records (Learn)	SHOULD	you make a significant design decision	record the decision, why you made it, and which alternatives you rejected	without the reason, later teams cannot judge whether the decision still holds	Architecture Decision Record (ADR) in the repository
P11	Trustworthy evidence (Learn)	SHOULD	a record is used as evidence (test result, approval, measurement)	make it attributable, legible, recorded at the time, original and accurate; changes must keep the original entry visible and record who, when and why	evidence that can be changed silently proves nothing	signed commits, immutable audit logs, CI results stored with the commit SHA
P12	Model validity (Learn)	SHOULD	a decision depends on a model, simulation or estimate	validate the model for its intended use, use it only inside the range it was validated for (domain of applicability), and check each result against an independent rough estimate (order of magnitude)	a model is only trustworthy inside its validated range	a load test on 3 nodes does not prove behavior on 50 nodes
P13	Automated reproducible results (Learn)	SHOULD	a result must be reproducible	produce it only through automated, recorded steps, with versions of data, code and tools	manual steps are error-prone and cannot be reproduced	infrastructure changed only through pipelines; no manual kubectl edits; pinned tool versions
P14	Provenance (Learn)	SHOULD	parts or materials come from suppliers	trace each part to its origin, batch and certificate (provenance)	without provenance you cannot prove quality, or find all affected parts when a defect is found	signed images with build provenance and SBOM; deployment by pinned digest
P15	Precaution (Learn)	SHOULD	a possible harm is serious or irreversible, and the evidence is incomplete	take proportionate, cost-effective protective measures without waiting for full proof	irreversible harm cannot be undone once the proof arrives	take a snapshot and stop writes when data corruption is suspected, before the root cause is proven
P16	Set-based design (Learn)	SHOULD	uncertainty is high early in a design	develop several alternatives in parallel, eliminate weak ones as evidence arrives, and commit only after feasibility is shown (set-based design; opposite: point-based design)	committing early to one option risks expensive rework when it fails	prototype two ingress controllers until load tests decide
P17	Technology maturity (Learn)	SHOULD	the design depends on a technology that is new to the team or the industry	assess how mature the technology is, and keep immature technology out of critical paths	immature technology carries unknown failures	CNCF sandbox project vs. graduated project for a core platform component
P18	Decision speed by reversibility (Learn)	SHOULD	you make a decision	classify it as reversible (two-way door) or irreversible (one-way door); make reversible decisions quickly at the lowest competent level, and irreversible decisions slowly, with consultation and review	heavy process on reversible decisions causes slowness and too little experimentation; light process on irreversible decisions causes lasting harm	a new linter rule: the team decides today; deleting a production database or changing the cloud provider: P42, red team, ADR
P19	Indicators are not targets (Learn)	SHOULD	a measure is used to reward, rank or punish people	expect it to be gamed: pair it with a counter-measure, compare it with direct observation, and change it when it drifts from the real objective	the more a quantitative indicator is used for decisions, the more it is corrupted and the more it distorts the process it measures (Campbell's law)	deployment frequency is paired with change failure rate; MTTR is not a bonus target
P20	Stop criteria set in advance (Learn)	SHOULD	you start a project or prototype with an uncertain outcome	write down, before starting, the evidence and the decision points (gates) at which it stops, and let someone who did not start it make the continue-or-stop decision	people who are responsible for an earlier decision commit the most resources to it after negative results (escalation of commitment)	a service-mesh pilot stops if p99 latency rises by more than 5 ms after 4 weeks; the architecture board, not the sponsor, decides
P21	Specific, challenging goals with feedback (Learn)	SHOULD	you set goals for people or teams	set few, specific and challenging goals, give regular feedback on progress toward them, and for new or complex tasks set learning goals first	specific, difficult goals lead to higher performance than "do your best", and goals plus feedback work better than goals alone	"cut median build time from 12 to 6 minutes this quarter", with a weekly chart; for a new technology: "run three spikes and document what we learned"

ID	Class (why)	HOW TO CHECK	VIOLATION (opposite of the rule)	RELATED	Evidence	Source domain
P9	universal (U), category B: true for every system	every requirement has an acceptance criterion and a link to a user need	"the system shall be fast"	strengthens P54, P59; strengthened by P21	moderate	systems engineering
P10	universal (U), category B: trigger that occurs in the life cycle of every system	each significant decision has a record with its reason and the rejected alternatives	nobody knows why the system is built this way	strengthens P64, P80; strengthened by P16, P18, P20	moderate	software (ADR), civil and offshore (basis of design)
P11	universal (U), category B: trigger that occurs in the life cycle of every system	a sample of records shows author, time and full change history	editing a test report after the fact without a trace	strengthens P59, P64; strengthened by P13, P14	strong (required in regulated domains)	pharma and clinical trials (ALCOA)
P12	universal (U), category B: every design decision rests on a model or an estimate	each model used for a decision states its validated range, and the decision lies inside that range	extrapolating a benchmark far beyond the tested load	depends on P54; strengthens P44; strengthened by P34, P58, P77	moderate	simulation and computational engineering, engineering physics (Fermi estimates)
P13	universal (U), category B: every engineering result must be checkable by someone else (P56)	each result can be regenerated from recorded inputs and versions with one command	a report built by copying numbers by hand	depends on P64; strengthens P11	moderate	bioinformatics (reproducible computational research)
P14	universal (U), category B: almost every system uses parts or software from suppliers	for each deployed artifact, origin, build and certificate can be shown	running an unsigned image from an unknown registry	strengthens P11, P78	moderate	metallurgical engineering (mill test certificates)
P15	risk-scaled (R), category B: only for serious or irreversible harm with incomplete evidence	for each serious or irreversible risk with incomplete evidence, a record states which protective measure was taken, or why none was	writes continue while the team waits for proof of data corruption	strengthens P37, P82; strengthened by P18	moderate (contested: critics call it vague and say strong versions block beneficial technology; this rule uses the weak, proportionate version)	environmental engineering (precautionary principle)
P16	risk-scaled (R), category B: only where uncertainty is high early; for a repeat design, one option is enough	early design records list the alternatives kept and the evidence that eliminated each rejected one	choosing one design at the start and discovering at the end that it cannot meet a requirement	depends on P58; strengthens P10, P17; strengthened by P20	moderate	design engineering (Toyota set-based concurrent engineering)
P17	conditional (C), category B: counterexample: a system built only from proven technology	each technology in a critical path has a recorded maturity assessment	adopting an untested tool for the production control plane without an assessment	depends on P10; strengthens P22; strengthened by P16, P20	strong (standardized as ISO 16290:2013; NASA defines TRL 1 to 9)	aerospace (NASA TRL), EU, DoD
P18	universal (U), category B: trigger that occurs in the life cycle of every system	each decision record (P10) states the class (reversible or irreversible) and the matching process	a three-week approval for a reversible tool trial; a lock-in contract signed in one meeting	strengthens P10, P15, P42; conflicts with P56, P64 (see K5)	moderate (practitioner source: a CEO's shareholder letter; consistent with P15 and P42)	management (decision making)
P19	universal (U), category B: every system and every team whose performance is measured (P70, P58)	each rewarded indicator has a counter-indicator and a yearly review of whether it still tracks the objective	ticket count as the only measure of on-call quality	strengthens P58, P70, P82; conflicts with P21	strong (Campbell; the same pattern is known as Goodhart's law)	management (performance measurement)
P20	universal (U), category B: trigger that occurs in the life cycle of every system (every system starts as a project)	each project and prototype has written stop criteria and gate dates, and gate decisions are made by someone other than the sponsor	"we have invested too much to stop now"	strengthens P10, P16, P17, P65	strong (experimental research, Staw 1976; PRINCE2 "continued business justification")	management (project management, organizational psychology)
P21	universal (U), category B: every engineering organization sets goals	each goal has a measure, a deadline and a progress chart; new or complex work has learning goals	"do your best" as the only goal; goals without progress feedback	strengthens P9; strengthened by P63; conflicts with P19 (see K8)	strong (experimental and field research summarized in the paper); contested by Deming points 11 and 12, who rejects management by numerical goals	management (goals and motivation (goal-setting theory))

C. Design

How to shape a design before it is built, so that it fails less.

ID	Name	Strength	IF (condition)	THEN (action)	BECAUSE (reason)	Example (software/infra)
P22	Failure and interaction analysis (Learn)	SHOULD	always	before you build, list how each part can fail, how parts that have not failed can interact unsafely, and how the system can cause harm while working as designed (insufficient design or foreseeable misuse)	a known failure or interaction can be designed against	"what happens if the registry is down?" and "what if two controllers fight over the same resource?"
P23	Simplicity and modularity (Learn)	SHOULD	always	choose the simplest design that meets the requirements, and split it into modules	every added part adds a way to fail	one Helm chart per app, not one chart for all
P24	Lifecycle and decommissioning (Learn)	SHOULD	always	plan operation, maintenance and decommissioning at design time	early design decisions fix most end-of-life costs	define how to delete a cluster and its data before creating it
P25	Human factors (Learn)	SHOULD	a person uses or operates the system	design the interface for the real user in the real environment, including stress, and for the full range of users, not an average user	a poor interface causes errors	a runbook that works at 3 a.m.; unambiguous CLI output
P26	Design for testability (Learn)	SHOULD	always	build ways to set and observe the internal state of each part into the design, so that it can be tested	a state you cannot set or observe cannot be tested	health and readiness endpoints, dry-run modes, feature flags for testing, debug endpoints
P27	Robustness (Learn)	SHOULD	always	design so that the result changes little when inputs vary (robustness)	removing every cause of variation costs more than tolerating it	retries with jitter, idempotent operations, tolerance for clock drift
P28	Accumulated degradation (Learn)	SHOULD	always	design for the damage that builds up over the whole design life, not only for the single largest load	repeated loads far below the maximum load cause failure, and the damage does not recover	soak tests over days, not only peak tests; disk wear; leaks that grow with uptime
P29	Compatibility (Learn)	SHOULD	parts of different kinds touch or interact	verify that they are compatible with each other in the real environment, and separate them where they are not	incompatible parts damage each other, even when each part is good on its own	tested compatibility matrix for Kubernetes, CNI and CSI versions; separate node pools for incompatible kernel modules
P30	Exact constraint (Learn)	SHOULD	several mechanisms can set the same property	constrain each property exactly once, with one owner (exact constraint)	over-constraint makes parts fight each other and deform the system	either the HPA or the GitOps manifest owns the replica count, not both; one source of truth per configuration value
P31	Design by selection (Learn)	SHOULD	no model is good enough to design the solution analytically	generate many variants, test them, keep the best, and repeat (design by selection)	selection by test finds good solutions without knowing exactly how they work	A/B tests, fuzzing, parameter search for autoscaler settings
P32	End-to-end (Learn)	SHOULD	a function (integrity, security, deduplication) can only be fully correct with knowledge at the end points	implement it at the end points; add it in lower layers only to improve performance	lower layers cannot guarantee the function and would burden every user	mTLS between services instead of relying only on network encryption; checksums on backups at the application level
P33	Strict interfaces (Learn)	SHOULD	components exchange data over an interface	send strictly according to the specification, reject and report input that violates it instead of silently accepting it, and state units, time zone and reference frames explicitly in every interface	silently tolerated defects become permanent unofficial standards and security holes, and unstated units get misread	schema validation in CI; fail on unknown fields; field names like latency_ms; timestamps in UTC with offset
P34	Weakest-link scaling (Learn)	SHOULD	a system grows in size or in number of parts	expect rare failures to become frequent, and design and test for the target scale	the larger the system, the more likely it contains a critical weak part (weakest link)	at 1,000 nodes, a node failure that happens once in 1,000 days per node happens every day
P35	Structure follows the intended system (Learn)	SHOULD	an organization designs a system with several components	design team boundaries and communication paths to match the component structure you want, and change them when the intended structure changes	organizations produce designs that copy their own communication structure (Conway's law)	one team per bounded context; the platform team owns the platform API, not parts of each product's code

ID	Class (why)	HOW TO CHECK	VIOLATION (opposite of the rule)	RELATED	Evidence	Source domain
P22	universal (U), category C: true for every system	a list of failure modes and unsafe interactions exists per component and is reviewed	the first failure analysis happens after an incident	strengthens P37, P38, P41, P44, P45, P46; strengthened by P17, P29, P55	moderate (method widely used; RPN scoring criticized)	reliability and safety (FMEA, STPA), automotive (SOTIF)
P23	universal (U), category C: true for every system	each component has one stated purpose, and no part is unused	adding features for imagined future needs	strengthened by P24, P30, P35; conflicts with P40, P41, P44, P45, P46, P47	moderate	aerospace (Lockheed Skunk Works), software
P24	universal (U), category C: true for every system	each design document has a maintenance and a decommissioning section	orphaned resources that nobody can safely remove	strengthens P3, P23; strengthened by P78	moderate	nuclear, offshore, aerospace
P25	universal (U), category C: trigger that occurs in the life cycle of every system	critical tasks are tested with real users or operators	blaming users for errors that the interface invites	depends on P80; strengthens P39; strengthened by P71, P76	moderate (strong in medical devices)	human factors, medical devices, biomechanics (anthropometry)
P26	universal (U), category C: true for every system	each component has documented test access to set and observe its key states	a component that can only be tested in production	strengthens P54, P57, P70	moderate	computer engineering (design for testing)
P27	universal (U), category C: every system meets variation in its inputs	tests with varied inputs (latency, clock drift, message order) show stable results	a system that works only when timing is exact	depends on P22; strengthens P44; conflicts with P33	moderate	manufacturing quality (Taguchi), agricultural engineering
P28	universal (U), category C: every system that is used more than once degrades over time	an endurance (soak) test runs for a period that represents real use, and the growth of leaks, wear or fragmentation is measured	only a short peak test, then failure after weeks of normal load	depends on P22; strengthens P74	moderate	materials, mechanical, piping (fatigue, corrosion allowance)
P29	universal (U), category C: every system with parts of different kinds has interactions between them	each interacting pair of components is on a tested compatibility list	upgrading one component and breaking another that was never tested with it	strengthens P22, P33	moderate	materials (galvanic corrosion), biomaterials (biocompatibility)
P30	universal (U), category C: over-constraint can occur in any system with more than one control mechanism	each managed field has exactly one owner	Argo CD and the HPA both set the replica count and keep reverting each other	strengthens P23, P64; strengthened by P35, P79	moderate	optomechanical and precision engineering (kinematic coupling)
P31	risk-scaled (R), category C: only where models are too weak for analytical design	each selection round has a defined test and records which variants were kept	choosing a configuration by opinion when it could be tested	depends on P58; strengthens P81	moderate (directed evolution received the 2018 Nobel Prize in Chemistry)	molecular and biomolecular engineering (directed evolution, DBTL)
P32	conditional (C), category C: counterexample: a system without communication between end points (a passive structure)	for each end-to-end property (integrity, authentication, exactly-once), the end points verify it themselves	trusting the network to deliver data correctly without a check in the application	strengthens P40	moderate	network engineering (Saltzer, Reed, Clark 1984)
P33	conditional (C), category C: counterexample: a system without data interfaces (a passive structure)	every interface has a machine-checked schema, and invalid input is rejected and logged	silently ignoring unknown or malformed fields	strengthens P39, P82; strengthened by P29, P35; conflicts with P27	moderate (disputed: Postel's original principle says to accept liberally; RFC 9413 argues against it)	network protocol engineering (Postel, RFC 9413), space systems (Mars Climate Orbiter units)
P34	conditional (C), category C: counterexample: a system of fixed, small size	failure rates are estimated per component and multiplied by the planned scale	assuming that a failure never seen in a 3-node test will not happen at 300 nodes	strengthens P12, P45	strong (ASTM C1683: "The larger the specimen or component, the weaker it is likely to be"; standard text is paid; only the official summary was read)	ceramics and brittle materials (Weibull statistics, size effect)
P35	conditional (C), category C: counterexample: a system built by one person, or by one small team that communicates as one unit	each major component boundary has one owning team, and cross-team dependencies are counted	one component maintained by four teams that never talk to each other	strengthens P23, P30, P33	moderate (widely observed; one original paper)	management (organization design), software engineering

D. Protection

Controls that prevent harm, or contain it when it happens.

ID	Name	Strength	IF (condition)	THEN (action)	BECAUSE (reason)	Example (software/infra)
P36	Least privilege (Learn)	MUST	always	give each person, service and process only the minimum access its function needs	minimum access limits the damage when one part is compromised	Kubernetes RBAC scoped to one namespace
P37	Fail-safe (Learn)	MUST	always	define a safe state, and design failure to move there (fail-safe; opposite: fail-dangerous)	an uncontrolled failure causes the most harm	admission webhook rejects requests when it errors (fail-closed; opposite: fail-open)
P38	Hierarchy of controls (Learn)	SHOULD	a risk is found	use the highest possible control level: 1 eliminate; 2 minimize, substitute or moderate; 3 engineering control; 4 administrative control; 5 protective equipment; and act first at the source, then along the path, then at the receiver	higher control levels do not depend on human behavior, and a cause removed at the source cannot spread	1 remove the port → 2 store less data / safer library / lower rate limit → 3 policy engine → 4 runbook → 5 "be careful"; noisy neighbor: limit the source → separate node pool → client timeouts
P39	Error-proofing (Learn)	SHOULD	a person can make the same error repeatedly	make the error impossible; if that is not possible, make the error visible immediately; if that is not possible either, limit its consequence so that it is survivable	errors are certain, defects are not	branch protection and required CI checks (impossible); a dry-run diff (visible); soft delete with a restore window (survivable)
P40	Defense in depth (Learn)	SHOULD	always	use several independent and verified control layers (defense in depth)	every single control fails at some point	RBAC + network policy + admission policy + runtime isolation
P41	Compartments (Learn)	SHOULD	always	divide the system into isolated compartments, so that one damaged compartment does not take down the whole system	a failure that cannot spread stays small	separate cloud accounts per environment, namespace quotas, cell-based architecture, bulkhead pattern
P42	Two-person rule (Learn)	SHOULD	an action is critical and cannot be undone	require two authorized people at the moment of action (two-person rule)	one person can make an error or act with bad intent, and nobody stops it	break-glass production access and deletion of production data need a second approver, live
P43	Segregation of duties (Learn)	MUST	a process handles money, assets, access rights or records, and the possible loss is above the acceptable risk	split the process so that no single person can request, approve, execute and record the same transaction; where the team is too small, add a compensating control (a later independent review)	a person who controls every step can cause an error or fraud and hide it	the engineer who requests production access cannot approve it; nobody can grant themselves admin rights and also delete the audit log

ID	Class (why)	HOW TO CHECK	VIOLATION (opposite of the rule)	RELATED	Evidence	Source domain
P36	universal (U), category D: true for every system	no role holds a permission that was unused for a set period	a CI pipeline with cluster-admin rights	strengthens P38, P40; strengthened by P78	strong	security engineering (NIST)
P37	universal (U), category D: every part can fail ("everything fails all the time")	failure injection shows that the system reaches the defined safe state	undefined behavior when a dependency is lost	depends on P22; strengthened by P1, P15, P22	strong	nuclear, elevators, aviation
P38	universal (U), category D: every system has risks; the trigger occurs in every life cycle	for each risk, a record states why a higher control level, or a control closer to the source, was not possible	a warning in the README as the only control	depends on P24; strengthens P39; strengthened by P1, P22, P36	strong	occupational and chemical process safety (NIOSH, Kletz), acoustic engineering (source-path-receiver)
P39	universal (U), category D: every system is built, operated or maintained by people	each repeated error from postmortems has a technical guard at the highest possible level	a "please remember to..." announcement as the only fix	depends on P80; strengthened by P25, P33, P38, P55, P66	moderate	manufacturing (poka-yoke), transportation (Safe System)
P40	universal (U), category D: every single control fails at some point; the number of layers scales with the master rule	each critical asset has at least two independent control layers, and each layer is verified	relying only on the perimeter firewall	depends on P36; strengthened by P32, P36, P41, P43; conflicts with P23	moderate	security, oil and gas (well barriers), drinking water (multi-barrier)
P41	universal (U), category D: every system with more than one part can spread a failure; how strict the compartments are scales with the master rule	a failure test in one compartment leaves all other compartments working	one shared database for all tenants and all environments	strengthens P40, P45; strengthened by P22; conflicts with P23	strong	naval architecture (watertight compartments)
P42	risk-scaled (R), category D: only for critical, irreversible actions; the cost is a second person who must be available	the system enforces a second approval for each listed critical action	one administrator can delete the production database alone	depends on P36; strengthens P56; strengthened by P18, P43	strong (NIST SP 800-53 control AC-3(2) "Dual Authorization")	nuclear, banking, aviation (two-person rule)
P43	risk-scaled (R), category D: required above the acceptable risk (master rule); in a very small team, compensating controls replace full segregation	a matrix of incompatible roles exists, and an access review finds nobody holding two incompatible roles	one person can create a cloud account, grant themselves admin and delete the audit log	depends on P36; strengthens P40, P42, P56; strengthened by P6	strong (NIST SP 800-192 definition; internal control frameworks)	management (internal control), security engineering

E. Capacity and continuity

How the system keeps working under high load and partial failure.

ID	Name	Strength	IF (condition)	THEN (action)	BECAUSE (reason)	Example (software/infra)
P44	Margin (Learn)	SHOULD	always	design capacity above the expected load (margin), state the design load as a probability per time period, keep queued resources well below 100 % utilization, and set the margin by design maturity: larger early, smaller as uncertainty falls	real load exceeds estimated load, and delay rises sharply as utilization approaches 100 %	capacity for the 1-in-100-day traffic peak plus 30 % headroom; worker pools sized for \< 70 % average utilization
P45	Redundancy (N-1) (Learn)	SHOULD	one failure must not stop the function	add redundancy, so that the function survives the loss of any single element (N-1), and make sure each copy and the switch-over mechanism are reliable enough for the redundancy to help	one copy is a single point of failure	nodes in several availability zones
P46	Diversity (Learn)	SHOULD	one cause can hit all copies at once	make the copies different (diversity)	identical copies fail together	two different DNS providers
P47	Graceful degradation (Learn)	SHOULD	demand can exceed capacity	define in advance which lower-priority functions switch off first, so that critical functions keep running (graceful degradation; opposite: cascading failure)	uncontrolled overload makes the whole system collapse	PriorityClasses with preemption, rate limiting, switching off recommendations to keep checkout running
P48	Damping (Learn)	SHOULD	a control loop reacts automatically to measurements	add a deadband, delay or cooldown, so that the loop does not switch back and forth (oscillation; opposite: stable control)	repeated on-off cycles waste resources and destabilize the system	HPA stabilization window; failover hysteresis; circuit breaker cooldown
P49	Induced demand (Learn)	SHOULD	you add capacity to relieve congestion	expect demand to grow into the new capacity, and also manage demand (quotas, priorities, pricing)	added capacity lowers the cost of use, which increases use	a larger cluster fills up again; faster CI leads to more CI runs
P50	Bottleneck first (Learn)	SHOULD	you want more throughput	find the constraint (bottleneck) and improve it first	improving other parts does not increase output	speeding up lint does nothing if integration tests or the review queue are the bottleneck
P51	Shared demand signal (Learn)	SHOULD	several stages pass demand signals along a chain	share the real end demand with every stage, instead of letting each stage react only to the stage below it	each stage amplifies the variation it sees, so swings grow upstream (bullwhip effect)	upstream services scale on front-end traffic, not only on their own delayed queue length
P52	Limit work in progress (Learn)	SHOULD	a team or system handles a flow of work items	set a limit on the number of items in progress, and finish items before starting new ones	at a given throughput, average lead time is proportional to average work in progress (Little's law), so more parallel work means longer waiting for every item	at most 4 epics in progress per team; at most N concurrent rollouts per cluster
P53	Late work and added people (Learn)	SHOULD	work is late, and it needs coordination and learning	do not expect added people to recover the schedule soon; cut or move scope first, and add people early, only where the work can be split	new people need training and add communication paths, which at first lowers the output of the existing team (Brooks's law)	two weeks before a cluster-migration deadline, scope is cut; new engineers join the next migration from its start

ID	Class (why)	HOW TO CHECK	VIOLATION (opposite of the rule)	RELATED	Evidence	Source domain
P44	universal (U), category E: every system has uncertain loads and inputs ("all models are wrong"); the size of the margin scales with the master rule	a load test shows capacity ≥ the stated design load × the chosen factor, and queue delay stays within the target at that load	sizing exactly to the average load	strengthened by P12, P22, P27, P49, P50, P52; conflicts with P23; checked by P70	strong (the phase values of GSFC-STD-1000 come from a garbled table extraction; check the original before quoting them)	mechanical, civil, coastal (factor of safety, return period), operations research (queueing), space systems (margins by phase), electronics (derating)
P45	risk-scaled (R), category E: only where the function must survive single failures; a system that may stop briefly (a development environment) does not need it	removing any single element in a test keeps the function running	a single replica of a critical service	strengthened by P22, P41, P46, P34; conflicts with P23; conflicts with P53 when people are added for redundancy (add early, not late)	strong (N-1 ignores how likely an outage is and how large the affected area is; use the master rule for those. Error correction helps only when component error rates are below a threshold (quantum threshold theorem))	aerospace, electronics, power grids, quantum engineering, computing theory (von Neumann)
P46	risk-scaled (R), category E: only where redundancy is required and a common cause is credible	the shared dependencies of redundant copies are listed, and each one is justified	all replicas depend on the same expiring certificate	depends on P45; strengthens P45; strengthened by P22; conflicts with P23	moderate	automotive (autonomous vehicles)
P47	conditional (C), category E: counterexample: a system with a fixed, known load (an embedded controller)	an overload test shows that low-priority functions stop first and critical functions keep running	all functions slow down together until everything fails	depends on P44; strengthened by P48; conflicts with P23	moderate	power grids (load shedding)
P48	conditional (C), category E: counterexample: a system without automatic control loops	each automatic control loop has a documented deadband, delay or cooldown, and a test shows no repeated switching	an autoscaler that scales up and down every minute	depends on P70; strengthens P47; strengthened by P51	moderate	control engineering
P49	conditional (C), category E: counterexample: a system without a shared, congested resource	each capacity increase comes with a forecast of demand growth and a demand control (quota, priority or price)	doubling the cluster size and being full again a month later	depends on P70; strengthens P3, P44; strengthened by P51	moderate	transportation (induced demand)
P50	conditional (C), category E: counterexample: a system without a throughput goal (a monument)	before an improvement for throughput, the current constraint is measured and named	optimizing a fast step while work piles up in front of a slow step	depends on P70; strengthens P44; strengthened by P52	moderate	industrial engineering (theory of constraints)
P51	conditional (C), category E: counterexample: a single-stage system	each stage in a chain can see the end demand signal	each service autoscaler reacts only to its own queue, and the swings grow along the chain	depends on P70; strengthens P48, P49	moderate	supply chain engineering (bullwhip effect)
P52	universal (U), category E: every system that is built, changed or operated has a flow of work (changes, tickets, requests)	a visible WIP limit exists, and lead time and WIP are tracked	everything is "in progress" and nothing is finished	depends on P70; strengthens P44, P50	strong for the relation (mathematical theorem); moderate for the practice	management (operations management, queueing theory)
P53	conditional (C), category E: counterexample: work that can be split into independent parts without communication (for example harvesting a field)	before people are added to late work, a record states the expected training and coordination cost	adding five engineers to a migration two weeks before its deadline	strengthens P67; conflicts with P45 when people are added for redundancy (add early, not late)	moderate; secondary only (the book is not online; Brooks himself calls the law an outrageous oversimplification)	management (software project management)

F. Verification and review

How to prove that the work is correct.

ID	Name	Strength	IF (condition)	THEN (action)	BECAUSE (reason)	Example (software/infra)
P54	Verification and validation (Learn)	MUST	always	do verification AND validation, and before handover test that all parts work together against the owner's requirements (commissioning)	passing one does not mean passing the other, and parts that pass alone can fail together	CI tests pass = verification; user acceptance = validation; end-to-end test of a new platform with DNS, certificates, monitoring and backup
P55	Find defects early (Learn)	SHOULD	always	find and fix defects at the earliest possible stage	the cost of a fix rises at each later stage	lint and tests run in CI before merge
P56	Independent checker (Learn)	MUST	always	have a checker review the work, and raise the checker's independence with the consequence of failure: self → peer → external organization	authors do not see their own errors, and shared assumptions hide shared errors	required PR approval; external penetration test for high-consequence systems
P57	Test as you operate (Learn)	SHOULD	a test must show that the system is ready	run the test in the same configuration and conditions as real operation, and test again after every repair	systems that passed every test have failed in operation because operation differed from the test	staging uses the same image digest and Helm values as production
P58	Comparable measurement (Learn)	SHOULD	measurements are used to compare or decide	measure under stated, controlled reference conditions, report the uncertainty with every result, and calibrate instruments regularly against traceable references	uncontrolled conditions change results, and a result without its uncertainty is incomplete	benchmarks on the same instance type with fixed load and warm-up; report the spread over several runs
P59	Traceability (Learn)	MUST	the system is safety-critical or regulated	link every requirement in both directions to design and test	standards require proof of complete coverage	requirement ↔ code ↔ test ID in the ticket system
P60	Codes as minimum (Learn)	MUST	a code or standard exists	meet it as the minimum, then apply the other rules	a code is a minimum, not a maximum	CIS Benchmark for Kubernetes
P61	Qualified procedure and person (Learn)	SHOULD	the quality of a result cannot be fully checked afterwards	prove the procedure by a test before using it, and qualify each person who performs it	a defect that inspection cannot find must be prevented by a proven procedure and a qualified person	a restore procedure proven by a real restore; only engineers who did a restore drill run production restores
P62	Structured selection of people (Learn)	SHOULD	you select a person for a job or a promotion	use structured, job-related interviews (the same questions for each candidate, answers rated on scales anchored to job requirements), and add work samples or job-knowledge tests	structured interviews predict job performance better than any other common method (mean validity .42, compared with .19 for unstructured interviews)	every platform-engineer candidate answers the same 6 questions and does the same debugging exercise; two raters score independently
P63	Feedback on the task (Learn)	SHOULD	you give feedback on a person's or a team's performance	focus the feedback on the task and on how to improve it, not on the person's character or ranking, and check afterwards whether performance improved	feedback improves performance on average, but in over one third of cases it decreased performance	"the runbook missed the rollback step; add it and test it" instead of "you are careless"

ID	Class (why)	HOW TO CHECK	VIOLATION (opposite of the rule)	RELATED	Evidence	Source domain
P54	universal (U), category F: true for every system	both a test result and a stakeholder acceptance exist	declaring the work done because tests pass	depends on P9; strengthened by P9, P26	strong	systems engineering, building services (commissioning)
P55	universal (U), category F: true for every system	each check runs at the first stage where it can run	finding defects only in production	strengthens P22, P39; strengthened by P57	moderate (direction strong; the '10x per stage' factor is weak)	software engineering
P56	universal (U), category F: true for every system	every change has a checker who is not the author, and the checker's independence matches the rigor matrix	the author merges their own change	depends on P2; strengthened by P2, P6, P42, P43, P62; conflicts with P18	strong	technical drawing (checker in the title block), civil and structural (independent checking)
P57	universal (U), category F: trigger that occurs in the life cycle of every system	the differences between the test setup and real operation are listed, and each one is justified	testing a different build than the one that is deployed	depends on P54; strengthens P55; strengthened by P26, P58, P61	moderate	aerospace (Test Like You Fly)
P58	universal (U), category F: every engineering decision uses measurements	each benchmark or test report states its reference conditions and the spread or uncertainty of the result	comparing two single benchmark runs from different machines	strengthens P12, P57; strengthened by P19	strong (standardized in ISO 139 and the GUM; standard text is paid; only the official summary was read)	textile testing (ISO 139), metrology (GUM, traceability)
P59	risk-scaled (R), category F: required by safety standards for safety-critical or regulated systems; costly elsewhere	a traceability report shows no requirement without a test and no test without a requirement	tests that link to no requirement	depends on P9; strengthened by P9, P11	strong	aerospace, automotive, medical (DO-178C, ISO 26262, IEC 62304)
P60	conditional (C), category F: counterexample: novel technology for which no code exists yet	a compliance scan passes	treating compliance as proof of safety	depends on P2	strong	pressure vessels (codes and standards)
P61	conditional (C), category F: counterexample: results that can be fully inspected afterwards (a dimension check on a simple part)	each such procedure has a test record, and each performer has a qualification record	a backup procedure that was never restored	depends on P2; strengthens P57, P71; strengthened by P62; conflicts with P7	strong (required for welding by ASME Section IX; standard text is paid; only the official summary was read)	welding (WPS, PQR, welder qualification)
P62	universal (U), category F: every engineering organization selects people (trigger)	interview guides with fixed questions and rating scales exist and are used; raters score independently before discussion	"culture fit" chat with different questions for each candidate	strengthens P2, P56, P61	strong (meta-analysis, Journal of Applied Psychology)	management (personnel selection)
P63	universal (U), category F: every engineering organization gives feedback	feedback records name a task and an improvement; the effect is checked at the next review	feedback that compares people or judges character	strengthens P5, P21	strong for the finding (meta-analysis); the "focus on the task" part rests on the authors' feedback intervention theory and is the author's summary, not a quote	management (performance feedback)

G. Change

How to change the system safely.

ID	Name	Strength	IF (condition)	THEN (action)	BECAUSE (reason)	Example (software/infra)
P64	Versioning and change review (Learn)	MUST	always	version every artifact; before each change, review its technical basis, its safety impact and the procedures it affects, approve it, and inform the affected people before go-live	an unknown version makes failures unreproducible, and an unreviewed change brings in unknown hazards	GitOps: every change is a reviewed pull request; the runbook is updated in the same pull request
P65	Small verified steps (Learn)	SHOULD	a change carries risk	make the change in small steps, check the result of each step before the next one, and define each check as a hold point (work stops until the check is approved) or a witness point (work continues while the check is observed)	small steps limit how much harm one wrong step can do	canary rollout at 1 % → 10 % → 100 %, with a manual approval gate (hold point) before 100 %
P66	Isolation before work (Learn)	MUST	people work on a part of the system	isolate that part from all inputs and energy, and lock the isolation so that nobody can restart it unexpectedly	an unexpected restart during work injures people or destroys the work	cordon and drain the node; pause Argo CD auto-sync before manual maintenance
P67	Critical path (Learn)	SHOULD	work consists of tasks that depend on each other	identify the longest chain of dependent tasks (critical path) and protect it first	a delay on the critical path delays everything; other tasks have slack	in a cluster migration, data sync and DNS cutover are critical; documentation has slack
P68	Observational method (Learn)	SHOULD	key properties can only be measured during construction or operation	design for the most probable conditions, monitor the real values, and plan trigger levels and backup actions in advance	measuring the real values is more reliable than guessing them in advance	Argo Rollouts analysis that rolls back automatically when the error rate exceeds a trigger level
P69	Guided change (Learn)	SHOULD	you change how many people work (a reorganization, a new process, a new tool for everyone)	make the need visible, form a group that leads the change, communicate the vision far more often than seems necessary, remove obstacles, plan early visible wins, and continue until the new way is part of daily routine	"skipping steps creates only the illusion of speed" (Kotter); changes declared finished too early fall back	migration to the new CI system: reasons shared, a pilot team, weekly updates, old system switched off only when all teams use the new one

ID	Class (why)	HOW TO CHECK	VIOLATION (opposite of the rule)	RELATED	Evidence	Source domain
P64	universal (U), category G: true for every system	every change record shows basis, impact review and approval, and the deployed state matches an approved commit	a manual change in production (drift)	strengthens P80; strengthened by P8, P10, P11, P30; conflicts with P18	strong	all (configuration management), chemical process safety (management of change)
P65	universal (U), category G: trigger that occurs in the life cycle of every system	each risky rollout has defined steps, and each check between steps is marked as hold point or witness point	switching all traffic at once	depends on P70; strengthens P68; strengthened by P20, P67, P69	moderate	flight testing (build-up approach), construction management (hold points)
P66	universal (U), category G: every system is maintained by people	each maintenance procedure starts with an isolation step and ends with a release step	auto-sync overwrites a manual fix in the middle of an incident	strengthens P39	strong	industrial safety (lockout/tagout)
P67	universal (U), category G: every project has tasks that depend on each other	each multi-step project plan marks its critical path and the slack of the other tasks	speeding up tasks that have slack while the critical path slips	strengthens P65; strengthened by P53	moderate	construction management (critical path method)
P68	risk-scaled (R), category G: only where key properties stay uncertain until construction or operation	each monitored value has a trigger level and a planned backup action	discovering at go-live that there is no rollback plan	depends on P65, P70; strengthened by P65, P72	moderate	geotechnical (observational method)
P69	universal (U), category G: every engineering organization changes how its people work (trigger)	each large change has a written reason, a named leading group, a communication plan, defined early wins and an end criterion ("the old way is switched off")	announcing a change by email and declaring it done	depends on P8, P64; strengthens P65; strengthened by P8	moderate (practitioner model from case experience; the eight steps have limited empirical testing)	management (change management)

H. Operation and maintenance

How to run, watch and maintain the system.

ID	Name	Strength	IF (condition)	THEN (action)	BECAUSE (reason)	Example (software/infra)
P70	Monitoring in operation (Learn)	SHOULD	the system is in operation	measure its behavior in real use, and alert on symptoms that users feel; where the output stays perfect until a sudden collapse (cliff effect), also monitor the remaining margin	tests before release cannot cover all real conditions, and some systems show no symptom until they fail completely	alerts on latency, traffic, errors and saturation; certificate days left, disk headroom, error budget
P71	Checklists (Learn)	SHOULD	a critical procedure is rare, complex or done under time pressure	use a short checklist, and confirm each item by pointing at it and saying its status aloud	memory fails under stress	cluster upgrade checklist, incident commander checklist; read out cluster context and namespace before each destructive command
P72	Critical control points (Learn)	SHOULD	a repeated process has a few steps where control is essential	define those critical control points, rank them by consequence rather than by how often incidents happen, and give each one a limit, monitoring, a predefined corrective action, a record and regular verification in practice	tight control at the essential steps works better than loose control at every step	image-signature admission gate; SLO limit on the payment path with automatic rollback
P73	Response faster than harm (Learn)	SHOULD	harm develops over time after a fault starts	make sure the time to detect + alert + respond + recover is shorter than the time until harm, with a margin	a response that arrives after the harm is no response	an alert fires when the disk will be full in 4 h, and on-call response takes \< 30 min
P74	Maintenance by failure pattern (Learn)	SHOULD	you plan maintenance	choose the maintenance method by how each part actually fails: replace on a schedule only what wears out with age, and monitor the condition of everything else	most failures are not linked to age, so scheduled replacement does not prevent them	rotate certificates on a schedule (age-related); alert on disk usage (condition-based); no "just in case" pod restarts
P75	Actionable alerts (Learn)	SHOULD	a system raises alerts to people	make every alert actionable, and remove or change alerts that nobody acts on	many non-actionable alerts make people ignore all alerts, including the important ones (alert fatigue)	page only on symptoms that need action now; review alert noise every month
P76	Sterile critical phase (Learn)	SHOULD	work is in a critical phase (cutover, deployment, incident)	allow only the activity and communication that the critical phase needs	distraction during critical phases causes errors	incident channel limited to the response; no unrelated changes during a cutover window
P77	Data as a dependency (Learn)	SHOULD	behavior depends on data or learned models	version and validate the data like code, monitor for drift, and retrain or re-evaluate when the world changes	data dependencies cost more than code dependencies, and predictions get worse over time	versioned evaluation set for code-review prompts; alerts on shifts in the input distribution
P78	Asset inventory (Learn)	SHOULD	you operate many assets	keep a complete inventory of all assets, with owner, condition and lifecycle stage	you cannot maintain, secure or decommission what you do not know you have	inventory of clusters, accounts, certificates and images with owners; SBOM per image
P79	Span of control (Learn)	SHOULD	one person directs other people during operation (incident, cutover, commissioning)	keep the number of people one person directs in a manageable range (guideline: about five), and add group leads above that	a person can coordinate only a limited number of people, and an overloaded coordinator misses actions	an incident commander with 12 responders appoints two group leads (communication, mitigation)

ID	Class (why)	HOW TO CHECK	VIOLATION (opposite of the rule)	RELATED	Evidence	Source domain
P70	universal (U), category H: trigger that occurs in the life cycle of every system	each service has dashboards and alerts for user-facing symptoms	learning about an outage from users	strengthens P80, P81, P82; strengthened by P19, P26, P75, P77; checks P44, P73	moderate	site reliability engineering, broadcast (confidence monitoring)
P71	universal (U), category H: every system has rare or critical procedures (restore, upgrade, decommissioning)	each critical procedure has a checklist that is used and is updated after postmortems	an upgrade done from memory	strengthens P25; strengthened by P61, P76, P79; conflicts with P7	moderate (mixed results: large effect in 8 pilot hospitals, no significant effect in 101 Ontario hospitals)	surgery, railway (pointing and calling)
P72	universal (U), category H: every system is built or operated through repeated processes	each critical control point has a limit, monitoring, a corrective action, records and a recent verification that it works	monitoring everything equally, with no defined limits	depends on P22; strengthens P68; conflicts with P7	strong	food safety (HACCP), mining (critical control management)
P73	universal (U), category H: every operated system has harms that develop over time (wear, filling, drift)	for each main hazard, the measured detection-plus-response time is shorter than the time until harm	an alert that fires only when the disk is already full	depends on P70; strengthened by P75; conflicts with P83; checked by P70	moderate	fire protection (ASET > RSET)
P74	universal (U), category H: every system needs maintenance (see P24)	each maintenance task states which failure pattern it addresses	scheduled restarts that hide a memory leak	depends on P22, P70; strengthened by P28, P78	moderate	aviation maintenance (RCM)
P75	universal (U), category H: every operated system is monitored (P70), and monitoring raises alerts	each alert has an owner and a runbook action, and the share of alerts with no action is measured and kept low	an alert channel with hundreds of messages per day that nobody reads	strengthens P70, P73, P82	strong (The Joint Commission: "between 85 and 99 percent of alarm signals do not require clinical intervention")	clinical engineering, rail dispatch (alarm fatigue)
P76	universal (U), category H: every project has critical phases (cutover, commissioning, launch)	critical phases are defined, and their communication rules are written down and used	side discussions and parallel deployments during an incident	strengthens P25, P71; strengthened by P79	strong (FAA regulation since 1981)	aviation (sterile flight deck)
P77	conditional (C), category H: counterexample: a system whose behavior does not depend on data or learned models	data and models have versions, inputs are validated, and drift is monitored with an alert	a model or prompt that silently gets worse over months	depends on P64; strengthens P12, P70	moderate	data and ML engineering
P78	conditional (C), category H: counterexample: a single, small asset	an automated discovery compares the real assets with the inventory and finds no unknown assets	a forgotten test cluster with public access	strengthens P24, P36, P74; strengthened by P14	moderate	municipal and infrastructure engineering (asset management, ISO 55000)
P79	conditional (C), category H: counterexample: a system operated by one person or by fully automated control	each incident record lists the roles and the number of people each lead directed; values above the guideline have a reason	one incident commander directly coordinating 20 people in one channel	strengthens P30, P71, P76	strong for incident management (US federal doctrine NIMS: 1:5 as guideline)	management (incident management)

I. Learning

How to learn from failures and anomalies.

ID	Name	Strength	IF (condition)	THEN (action)	BECAUSE (reason)	Example (software/infra)
P80	Blameless root cause analysis (Learn)	SHOULD	a failure has happened	find the root cause in the system, not a person to blame	blame makes people hide information	blameless postmortem with 5 Whys
P81	Plan-Do-Check-Act (Learn)	SHOULD	always	repeat the cycle Plan → Do → Check → Act	improvement is a cycle, not a single event	retrospective after each sprint
P82	Investigate anomalies (Learn)	SHOULD	the system behaves differently from what was expected, even if nobody was harmed	record the anomaly and investigate it before you accept it as normal	ignored warning signs come before major accidents	a flaky test, or an alert that everyone silences
P83	Preserve evidence (Learn)	SHOULD	a failure has happened	document and preserve the as-found state before you repair or restart anything, and record who handled the evidence (chain of custody)	a repair destroys the evidence needed to find the cause	capture logs, heap dump and disk snapshot before restarting a pod or rolling back

ID	Class (why)	HOW TO CHECK	VIOLATION (opposite of the rule)	RELATED	Evidence	Source domain
P80	universal (U), category I: trigger that occurs in the life cycle of every system	each failure above a set severity has a postmortem with system-level actions	"operator error" as the final root cause	depends on P64; strengthens P81; strengthened by P5, P10, P64, P70, P82, P83	moderate	site reliability engineering
P81	universal (U), category I: true for every system	actions from earlier cycles are tracked until they are completed	the same failure happens again with no process change	depends on P70, P80; strengthened by P31, P70, P80	strong	quality management (ISO 9001)
P82	universal (U), category I: trigger that occurs in the life cycle of every system	each anomaly has a ticket with a decision: fix it, or accept it with a written reason	silencing an alert permanently without an investigation	depends on P4, P70; strengthens P80; strengthened by P4, P5, P15, P19, P33, P70, P75	moderate	aerospace, accident research (normalization of deviance)
P83	universal (U), category I: trigger that occurs in the life cycle of every system	each incident record lists the evidence captured before the first repair action	restarting the service first and finding no logs afterwards	depends on P11; strengthens P80; conflicts with P73	strong (required in regulated failure investigation (PHMSA protocol))	forensic engineering