Foundations of Rules Integrity · Chapter 18
Case Studies
Rules Integrity becomes concrete when a rule system is reconstructed from evidence: what authority existed, what people and systems understood, where meaning changed, how failure propagated, and which interventions restored justified reliance.
Chapter summary
A case study reveals the rule system that documents, systems, and organizational narratives conceal when examined separately
Rules rarely fail in isolation. A defective outcome may appear to originate in one ambiguous sentence, one outdated procedure, one software condition, or one unauthorized exception. Closer examination usually reveals a chain: an authoritative source was interpreted; the interpretation became policy; policy was translated into procedure or code; local actors adapted it; evidence was fragmented; review mechanisms observed only portions of the system. The visible event is therefore not the whole failure. It is the point at which accumulated weakness became consequential.
Case studies are essential to Rules Integrity because they connect abstract principles to institutional reality. They show how authority, language, scope, hierarchy, ownership, traceability, implementation, exception, monitoring, and change interact over time. They also discipline diagnosis. An organization cannot responsibly conclude that “training failed,” “the policy was unclear,” or “the system made an error” without identifying the evidence, the causal pathway, the competing explanations, and the control conditions under which the event occurred.
The six cases in this chapter are composite instructional cases. They do not describe named organizations or claim to reproduce a single historical event. Each combines recurring patterns observed across rule-dependent environments so the structural problem can be studied without confusing illustration with adjudicated fact. The cases cover consumer lending, clinical care, manufacturing, public administration, cybersecurity, and contracting. Their sectors differ, but their deeper lessons converge: local plausibility is not system integrity; document approval is not implementation; an exception without lineage becomes a new rule; automated consistency can amplify an incorrect interpretation; and remediation is incomplete until authority, operation, evidence, and learning are reconnected.
Working definition
What is a Rules Integrity case study?
A Rules Integrity case study is a bounded, evidence-based reconstruction of how a rule system produced, prevented, detected, or corrected a consequential outcome, with explicit attention to authority, meaning, scope, relationships, implementation, decision behavior, evidence, governance, change, and alternative explanations.
The word bounded matters. No case can represent an entire organization. The investigator must define the decision domain, time period, rule population, locations, systems, actors, and outcomes included. The word reconstruction also matters. Case analysis does not merely repeat the organization’s current account. It rebuilds the state of the rule system as it existed when decisions were made, including superseded versions, informal practices, local interpretations, system configurations, and evidence that may conflict with official descriptions.
Cases may examine failure, near misses, successful controls, disciplined exception handling, or effective recovery. Positive cases reveal how integrity was preserved under pressure and distinguish controls that merely exist from controls that actually work.
Why case studies matter
Cases convert principles into observable relationships, choices, and consequences
Reveal causal structure
Show how authority, drafting, implementation, local adaptation, automation, and assurance combined to produce an outcome.
Develop professional judgment
Train practitioners to distinguish symptoms from causes, evidence from assertion, and corrective action from cosmetic response.
Improve institutional decisions
Provide decision-makers with a concrete basis for assigning ownership, prioritizing remediation, and testing whether controls are sufficient.
Build comparative knowledge
Allow recurring patterns to be identified across sectors while preserving the differences that make each operating context significant.
Many material defects are relational: a clear policy may conflict with a contract; a system may implement an incorrect specification; a sensible local procedure may exceed authority; and timely review may examine a version frontline staff never use. Cross-layer reconstruction exposes conditions that isolated artifacts conceal.
Case-study method
A disciplined case proceeds from scope and evidence to reconstruction, diagnosis, intervention, and verification
Define the decision, outcome, period, entities, systems, and rule families under examination.
Secure contemporaneous documents, versions, configurations, logs, records, communications, and testimony.
Identify governing sources, hierarchy, applicability, approvals, interpretations, and effective dates.
Trace approved rules into procedures, training, forms, systems, vendors, equipment, and actual decisions.
Sequence changes, signals, exceptions, incidents, reviews, escalations, and response decisions.
Evaluate contributing conditions, counterfactuals, alternative explanations, and control dependencies.
Correct immediate risk and the rule-system weaknesses that allowed the condition to arise or persist.
Confirm implementation, monitor outcomes, test recurrence risk, and preserve transferable knowledge.
The stages are iterative. New evidence may change the boundary, timeline, or causal theory. Revisions should remain auditable: changing a conclusion in response to evidence is sound analysis; changing it without recording why creates a new traceability defect.
Evidence and causal discipline
A credible case separates what was prescribed, what was represented, what was configured, and what actually occurred
What should have governed
Laws, contracts, standards, policies, approved interpretations, authority matrices, specifications, and effective versions.
What the organization built
Procedures, training, forms, decision tables, code, configurations, interfaces, vendor instructions, equipment settings, and release records.
What people and systems did
Transactions, logs, case files, overrides, work records, observations, communications, and decision rationales.
What resulted
Errors, harms, delays, complaints, incidents, financial effects, safety conditions, service outcomes, and near misses.
What oversight knew and decided
Approvals, reviews, issue logs, committee records, escalations, risk acceptances, audits, and corrective actions.
What conditions shaped the case
Workload, staffing, incentives, technology constraints, emergency conditions, local practice, organizational change, and third-party dependence.
Evidence should be weighted by relevance, contemporaneity, independence, completeness, and provenance. A later interview can explain a practice but cannot by itself establish what a system displayed months earlier. A policy repository can show an approved version but not necessarily what a branch downloaded. A configuration record can show intended deployment but not successful operation. A case should state these limitations directly rather than convert uncertain evidence into categorical fact.
Causation requires restraint. Cases often involve multiple contributing conditions. Analysis should test whether the outcome would likely have differed without the defect, whether another control should have detected it, and whether context increased exposure. “Root cause” should not force a complex system into one convenient explanation.
Anatomy of rule-system failure
The visible event is often the final expression of weakness distributed across the rule lifecycle
An unclear source, undocumented interpretation, incomplete inventory, informal exception, or disconnected implementation is created.
Policy, procedure, training, code, forms, or local practice reproduce the condition without preserving its uncertainty or rationale.
Repeated use, apparent success, performance pressure, or lack of challenge converts a temporary workaround into accepted practice.
A new customer, unusual patient, equipment state, jurisdiction, cyber incident, contract, or workload makes the weakness consequential.
Monitoring, review, complaint, incident, audit, or frontline challenge either identifies the issue or misclassifies it as an isolated event.
Remediation either reconnects the rule system or addresses only the visible symptom, leaving recurrence pathways intact.
Composite case 01 · Consumer lending
A temporary underwriting exception becomes an undeclared product rule
Allow a narrowly defined class of applicants to document variable income through an alternative verification method during a service disruption.
Applicants with similar circumstances receive different decisions across channels, and some adverse-action explanations do not match the operative criteria.
An emergency exception lost its scope, effective period, ownership, and traceability as it spread into local procedure and decision logic.
Reconstruction
A lending organization experienced a temporary interruption in a third-party income-verification service. Credit leadership approved a thirty-day exception permitting specified applicants to use two alternative records. The approval identified the affected product and minimum evidence, but it did not state whether the exception applied to automated, branch, and broker channels; who would terminate it; or how decisions made under it should be identified. Operations issued an email summary. One region converted the email into a desk procedure. A technology analyst, seeking consistency, added a decision-table branch that accepted one of the records for a broader applicant population. The change ticket cited the email rather than the approval memorandum.
The service returned after three weeks, but no owner retired the exception. Branch staff gradually returned to the standard method; the decision engine did not. Six months later, complaint analysis found inconsistent outcomes. What first appeared to be employee noncompliance proved to be an expanded, obsolete system interpretation.
Integrity diagnosis
- The exception was approved as a temporary operational measure but was not represented as a governed rule object with scope, owner, start date, end condition, and affected implementations.
- The translation from approval to email, procedure, and code introduced progressively broader applicability.
- No trace connected the decision-table condition to the controlling memorandum or recorded the analyst’s interpretation.
- Monitoring compared employees with system outcomes rather than comparing both with current authority.
- Adverse-action language was maintained separately, producing explanations inconsistent with the actual decision pathway.
Corrective architecture
Immediate correction required suspending the obsolete logic, reviewing affected decisions, and aligning explanations. Durable remediation created a controlled exception record linked to products, channels, decision tables, procedures, notices, testing, and retirement criteria. Emergency approvals could no longer be implemented from summary communications alone. Deployment required source verification, defined ownership, test cases across channels, and a scheduled termination review. The lesson was not that exceptions are inherently unsafe. It was that an exception becomes a rule the moment people or systems rely upon it, and it must therefore receive rule-level governance.
Composite case 02 · Clinical care
Two valid protocols conflict at the point of medication administration
Reduce treatment delay for a time-sensitive condition while preserving renal-dose safeguards.
A clinician receives mutually inconsistent instructions from an emergency protocol and an electronic medication alert.
Each protocol was valid within its own governance pathway, but no authority relationship or conflict-resolution rule connected them.
Reconstruction
A hospital’s emergency-care committee approved a protocol directing administration of a medication within a narrow time window. Separately, the pharmacy committee maintained renal-adjustment rules embedded in the electronic ordering system. Both were evidence-based and appropriately approved. The emergency protocol referred generally to “standard contraindications” but did not identify the renal rule or specify whether urgency altered the normal approval pathway. The electronic alert advised dose reduction and required acknowledgement, while the printed emergency checklist displayed the full dose.
Experienced clinicians called pharmacy. During a high-volume period, a newly credentialed clinician followed the checklist, overrode the alert, and continued treatment. No lasting injury occurred, but review showed that the institution had placed the clinician inside an unresolved conflict and then treated personal judgment as the missing control.
Integrity diagnosis
- Protocol approval occurred in separate committees without a shared dependency review.
- The phrase “standard contraindications” concealed material operational content and assumed shared knowledge.
- The electronic alert and checklist had different owners, review cycles, and release processes.
- Override data recorded individual action but did not distinguish justified conflict resolution from disregard of a warning.
- No escalation rule defined who had authority when treatment urgency and dosage safeguards appeared to compete.
Corrective architecture
The organization created a cross-protocol dependency map for high-consequence medications, established a joint clinical-pharmacy approval pathway, and revised the emergency protocol to state the renal conditions, permitted alternatives, and escalation route. The order set and checklist were released as linked implementations of one approved rule package. Override categories were redesigned so monitoring could identify recurring conflicts rather than merely count acknowledgements. The case demonstrated that professional judgment is strongest when rule architecture makes the point of judgment explicit; it is weakest when the organization uses judgment to compensate for contradictions it has not governed.
Composite case 03 · Manufacturing
A maintenance workaround survives the equipment change that justified it
Maintain production safely while a replacement component is unavailable.
Operators continue using a temporary inspection interval after new equipment is installed, creating unnecessary shutdowns and inconsistent records.
A temporary technical control was embedded in local work instructions but omitted from formal change-impact analysis and retirement.
Reconstruction
A facility discovered abnormal wear in a pump assembly. Engineering authorized an interim inspection every eight operating hours until a redesigned assembly could be installed. The temporary instruction was attached to a maintenance work order and copied into a shift checklist. Months later, the redesigned assembly was installed under a capital project. Project documentation validated the new component but did not inventory temporary operating rules associated with the old equipment. The work order closed; the shift checklist remained unchanged.
Operators continued the inspections. One shift skipped one because the new assembly was believed to make it unnecessary; another recorded it. Audit called the inconsistency noncompliance, but interviews revealed three unsupported beliefs: the rule remained mandatory, expired automatically, or could be waived by supervisors.
Integrity diagnosis
- The interim rule lacked a durable identifier and explicit termination condition tied to equipment state.
- The capital change process examined physical and safety effects but not the complete population of temporary rules.
- The checklist became an independent rule source after its originating work order closed.
- Supervisory practice varied because authority to retire or waive the instruction was undefined.
- Audit assessed record completion without first determining whether the recorded requirement remained valid.
Corrective architecture
The facility linked temporary technical instructions to asset identifiers, conditions, owners, and termination events. Management of change required a search for rules, permits, training, checklists, alarms, and vendor instructions connected to affected equipment. Local checklists could reference controlled rules but could not silently reproduce them. The obsolete inspection was formally retired, the decision and effective time were communicated, and sampling confirmed that all shifts used the revised checklist. The case showed that physical change and rule change are one system problem; treating them as separate disciplines allows obsolete controls to survive the conditions that created them.
Composite case 04 · Public administration
An eligibility rule is implemented consistently but without its statutory qualification
Automate a high-volume eligibility determination and reduce processing delay.
Applicants in a protected transitional category are denied because the system applies a general limit without the qualifying exception.
The automated rule was internally consistent and thoroughly tested against its specification, but the specification was incomplete.
Reconstruction
A public agency modernized an eligibility system. Policy staff translated legislation and implementing guidance into business requirements. The general rule imposed a resource limit. A transitional provision allowed a defined group to exclude one asset for a limited period. The provision appeared in a legal interpretation memorandum but not in the requirements table used by the implementation team. Test cases were derived from that table and all passed. Notices accurately described the system’s decision but omitted the transitional basis because the notice library used the same incomplete taxonomy.
Community advocates identified a denial pattern. Staff first suspected rare manual error because testing showed perfect conformance. Investigation found that automation had made the error consistent: the system, notices, quality review, and reports all inherited the same missing qualification.
Integrity diagnosis
- Legal interpretation and business requirements were treated as adjacent documents rather than traceable transformations.
- Completeness review focused on requirements quality after extraction, not whether every material obligation, exception, and time condition had been extracted.
- Testing proved conformity to the specification but not conformity of the specification to governing authority.
- Quality sampling used expected outcomes generated by the same rule table, eliminating independent challenge.
- Appeal and complaint information was not connected to rule-level monitoring.
Corrective architecture
The agency corrected affected cases, revised notices, and added the transitional provision. More importantly, it established bidirectional traceability from source provisions to interpretations, requirements, decision logic, tests, notice language, and monitoring. High-impact rules required independent legal-to-test review, including boundary and exception cases. Appeal outcomes were classified by rule so recurring interpretive defects could be detected. The case demonstrated that deterministic execution is not the same as justified execution. Automation increases the value of precise rules, but it also increases the reach of a missing qualification.
Composite case 05 · Cybersecurity
Emergency access is technically controlled but institutionally ungoverned
Restore critical services rapidly during a major identity-platform outage.
Temporary privileged accounts remain active after recovery, and review cannot determine which emergency actions were authorized.
Technical procedures defined how to create access, but organizational rules did not define activation authority, duration, evidence, or closure.
Reconstruction
A company maintained a “break-glass” procedure for identity-service failure. The document described commands for creating local administrator accounts and required strong passwords. During an outage, several teams used the procedure. The incident commander verbally authorized broad action, but no rule specified whether that authority extended to every environment, whether dual approval was required for sensitive systems, or when accounts had to be removed. Service restoration took priority and the procedure succeeded technically.
Weeks later, a scan found active emergency accounts, some used for maintenance. Security could see creation and activity but not approval, scope, owner, or termination. A proposed thirty-day expiration reduced persistence but did not resolve excessive duration, authorization, or review.
Integrity diagnosis
- The procedure governed technical execution but not the full emergency-access rule.
- Incident command authority was assumed rather than mapped to system sensitivity and segregation-of-duty requirements.
- Access objects were not linked to incidents, approvals, accountable users, purpose, or closure criteria.
- Logs showed behavior without establishing whether the behavior was permitted.
- Recovery completion did not trigger rule retirement and credential reconciliation.
Corrective architecture
The organization defined emergency access as a governed exception class. Activation authority varied by environment; every account required an incident identifier, accountable owner, purpose, maximum duration, and immutable activity logging. High-sensitivity systems required retrospective independent review when dual approval was impossible during immediate response. Recovery closure automatically generated reconciliation tasks, and unresolved emergency access prevented formal incident closure. The case showed that technical control can be strong while rule integrity remains weak. Security depends not only on restricting capability, but on making the authority for exceptional capability explicit and reviewable.
Composite case 06 · Contracting and procurement
A local purchasing rule defeats a negotiated supplier obligation
Standardize low-value purchases and shorten approval time.
A site purchases a substitute component from an unapproved source despite a contract requiring designated suppliers and traceable materials.
Procurement thresholds were treated as complete authorization even though product-specific contractual and quality constraints remained controlling.
Reconstruction
A company introduced a simplified purchasing policy allowing site managers to approve transactions below a monetary threshold. The policy stated that purchases remained subject to “applicable agreements and standards,” but the purchasing interface displayed only the threshold and budget authority. A facility needed a replacement component urgently. The approved supplier quoted a longer lead time, while a local distributor had an apparently equivalent part. The manager approved the purchase within the threshold.
The master agreement and quality standards required designated sources and material traceability, but neither was connected to the item master or approval workflow. The substitute passed inspection yet lacked provenance. A customer documentation request exposed the issue, requiring containment. The manager had followed the visible purchasing rule, not the complete rule system.
Integrity diagnosis
- The policy’s general savings of “applicable agreements and standards” was not operationally resolvable at the point of purchase.
- Monetary authority and source-qualification authority were collapsed into one approval concept.
- Contract obligations were managed by supplier and document, while purchasing operated by item and transaction; no trace linked the models.
- Urgency created an implicit exception pathway without defined authorization or evidence.
- Incoming inspection verified physical characteristics but could not substitute for contractual provenance.
Corrective architecture
The company separated spend authority from technical and contractual authorization. Item records identified qualified-source rules, provenance requirements, and controlled alternatives. Urgent substitutions required a bounded deviation approved by procurement, quality, and the accountable product owner, with customer or contractual review where necessary. The purchasing system displayed the controlling constraint rather than a generic warning. The case demonstrated that a rule stated elsewhere is not operationally effective merely because employees are expected to remember it. Material dependencies must appear where the governed decision is made.
Cross-case findings
Different sectors repeatedly expose the same structural weaknesses
Exceptions become rules through reliance
Temporary, emergency, or local deviations require the same identity, scope, ownership, traceability, and retirement discipline as ordinary rules.
Agreement among downstream artifacts can conceal a shared source defect
Systems, tests, notices, and reports may align perfectly because all inherited the same incomplete interpretation.
Generic references do not create operational integration
Phrases such as “subject to applicable policy” fail when the controlling rule cannot be resolved at the decision point.
Lifecycle events must include rule impact
Equipment, product, law, contract, technology, and organizational changes can activate, alter, or retire rules even when no document owner initiates a revision.
Monitoring can reinforce error
Controls that compare behavior with an incorrect system or specification may classify correct challenge as noncompliance.
Remediation must reconnect the system
Editing one document or retraining one group is insufficient when authority, implementation, evidence, and governance remain disconnected.
These findings do not mean every defect has the same cause. They identify recurring mechanisms that should be tested, not presumed. A case study is valuable precisely because it combines pattern recognition with contextual restraint. The analyst asks whether a familiar structure is present and then proves or rejects it using the evidence of the particular case.
Transfer and limits
The lesson of a case should transfer at the level of mechanism, not by copying its surface solution
A hospital should not copy a bank’s approval matrix merely because both experienced exception drift. A factory should not adopt a cybersecurity account-expiration period as the model for temporary technical instructions. Transfer occurs by identifying the mechanism: temporary authority lacked an end condition; a dependency was invisible at the decision point; testing shared the same source as implementation; change control omitted the rule population. Each organization then designs a response suited to its own consequence, authority, timing, technology, and professional practice.
Structural questions
What controlled? Where did meaning change? Which dependency was absent? What event should have triggered review or retirement? Which evidence would have exposed the defect earlier?
Control design
Approval levels, review frequency, technical safeguards, documentation, escalation, independence, retention, and acceptable residual risk.
Outcome assumptions
That the same intervention will produce the same effect, that one sector’s risk tolerance is appropriate, or that a case establishes prevalence beyond its boundary.
Case studies also have epistemic limits. They can establish that a mechanism occurred within the examined boundary; they do not by themselves establish how common it is. Comparative case research can strengthen theory by examining repeated mechanisms across settings, but claims of prevalence require broader empirical methods. The discipline should resist both extremes: dismissing cases as “anecdotal” when they reveal rigorously documented mechanisms, and generalizing from one compelling case as though it proves a universal rate or remedy.
Practical review
Eighteen questions for evaluating a Rules Integrity case
- Boundary: Is the decision domain, period, rule population, system, location, and affected population explicit?
- Outcome: Is the event or condition described without assuming its cause?
- Authority: Are the governing sources, hierarchy, applicability, approvals, and effective versions established?
- Transformation: Can the movement from source to policy, procedure, system, training, and decision be reconstructed?
- Contemporaneity: Does the evidence show what existed at the time rather than only what exists now?
- Provenance: Are documents, configurations, logs, testimony, and datasets traceable to reliable origins?
- Implementation: Is actual behavior compared with approved authority rather than only with another downstream artifact?
- Timeline: Are changes, exceptions, warnings, decisions, and responses sequenced accurately?
- Alternative explanations: Were plausible competing causes investigated and recorded?
- Counterfactual: Is there a reasoned account of how the outcome might have differed without the identified condition?
- Control interaction: Did multiple controls fail, conflict, depend on one another, or share a defective source?
- Local rationality: Why did the actions appear reasonable to the people or systems involved?
- Governance: Who had authority and ownership, and where were those responsibilities absent, divided, or misunderstood?
- Detection: Which signal exposed the issue, and which earlier signals were missed or misclassified?
- Immediate response: Was current harm contained and were affected decisions or populations identified?
- Systemic remediation: Did corrective action address authority, rule content, implementation, evidence, lifecycle, and assurance?
- Verification: Was the intervention tested in operation, including edge cases and recurrence pathways?
- Transfer: Is the lesson stated as a mechanism with clear limits rather than an unsupported universal claim?
Institutional use
Case studies should become part of education, governance, assurance, and organizational memory
A case should not disappear when corrective actions close. Its durable value lies in preserving the reasoning that connects evidence, diagnosis, intervention, and verification. Organizations can use structured cases in author training, change-review exercises, governance workshops, control design, audit planning, onboarding, and simulation. Cases are particularly effective when learners must identify missing evidence, argue alternative explanations, and design proportionate controls rather than merely read the final answer.
Governance bodies can use cases to test whether formal frameworks survive real operating conditions. A maturity assessment may state that traceability is established; a case can reveal whether traceability reaches the decision engine, the local checklist, or the vendor instruction. Metrics may show timely review; a case can test whether review detects shared-source defects. Assurance functions can build case libraries organized by mechanism—exception drift, incomplete transformation, hidden dependency, obsolete implementation, authority conflict, monitoring inversion—so recurring weaknesses become visible across organizational boundaries.
Ethical use requires protection of personal information, privilege, security-sensitive detail, and fair treatment without destroying the structure needed for learning. Anonymization must not distort causation. Cases should neither default to individual blame nor erase materially relevant authority, knowledge, and choice. The purpose is accurate institutional learning.
Failure cases
Case-study practice fails when narrative replaces evidence or when closure replaces learning
Outcome-first storytelling
The investigator begins with a preferred explanation and selects facts that support it. Contradictory evidence, alternative causes, and uncertainty disappear from the account.
Single-document diagnosis
A policy sentence is treated as the complete rule system, while implementation, local practice, code, contracts, and authority relationships remain unexamined.
Person-centered blame
The case ends with “human error” or “failure to follow procedure” without asking why the action was plausible, whether the procedure was current, or which controls should have prevented or detected the condition.
Shared-source validation
Implementation is declared correct because it matches tests, notices, or reviews derived from the same incomplete specification.
Corrective-action substitution
The existence of a remediation plan is treated as proof that causation was understood and recurrence risk was reduced.
Unbounded generalization
A compelling local event is presented as evidence that all units, industries, or rule types behave the same way.
Conclusion
A mature discipline learns from cases by reconstructing systems, not by collecting stories
Case studies give Rules Integrity its practical depth. They reveal how rules move from authority into language, procedures, systems, decisions, evidence, and change. They show why each layer can appear reasonable while the system as a whole becomes unreliable. They also demonstrate that failure is rarely corrected by one edit, one training session, one technical patch, or one new approval. Durable correction requires the relationships among rule elements to be restored and then verified in operation.
The six composite cases illustrate recurring mechanisms: temporary exceptions acquire permanence; independently valid rules conflict; physical change leaves obsolete instructions behind; automation faithfully executes an incomplete interpretation; emergency capability lacks institutional authority; and transactional approval obscures contractual constraints. Their common value is not that every organization should adopt identical controls. It is that each organization should ask the same disciplined questions about source, scope, transformation, implementation, evidence, ownership, lifecycle, and consequence.
A case study earns trust when its boundary is clear, its evidence is traceable, its uncertainty is visible, its causal claims are proportionate, and its corrective lessons are verified rather than asserted. When cases are preserved as institutional knowledge, they become more than post-event reports. They become instruments for design, education, governance, assurance, and prevention.
Foundational principle: A Rules Integrity case study should reconstruct the complete rule pathway from authority to outcome, distinguish evidence from narrative, test causal mechanisms and alternatives, and treat remediation as complete only when the corrected rule system is implemented, verified, and capable of preserving what was learned.
Selected references
Sources informing this chapter
- Yin, Robert K. Case Study Research and Applications: Design and Methods. Sixth edition. SAGE Publications, 2018. A foundational treatment of case-study design, evidence, validity, explanation, and analytic generalization.
- National Transportation Safety Board. The investigative process. An institutional model for preserving evidence, developing factual records, analyzing causal conditions, issuing findings, and supporting safety improvement.
- U.S. Government Accountability Office. Standards for Internal Control in the Federal Government, 2025 Green Book. A framework connecting objectives, risk, control design, implementation, information, monitoring, deficiency evaluation, and remediation.
- National Institute of Standards and Technology. Cybersecurity Framework. A technology-neutral structure for governance, protection, detection, response, recovery, and learning across cybersecurity outcomes.
- Occupational Safety and Health Administration. Process Safety Management. Guidance integrating process information, procedures, training, mechanical integrity, incident investigation, management of change, and audit.
- World Health Organization. Global Patient Safety Action Plan 2021–2030. A system-oriented framework emphasizing leadership, high-reliability processes, learning, information, and reduction of avoidable harm.
- Basel Committee on Banking Supervision. Principles for operational resilience. Principles addressing governance, mapping, dependencies, disruption, response, recovery, testing, and lessons learned in banking.
- International Organization for Standardization. ISO 31000 Risk management. Principles and guidance for integrating risk-based decision-making, evaluation, treatment, monitoring, communication, and continual improvement.
These sources reflect complementary traditions in case-study research, investigation, internal control, cybersecurity, process safety, patient safety, operational resilience, and risk management. Together they support the chapter’s emphasis on bounded inquiry, evidence provenance, system reconstruction, causal restraint, corrective action, verification, and organizational learning.