> **PUBLIC-SURFACE BOUNDARY / 2026-08-03** > This dated artifact is preserved for inspection. Its original document date remains historical; public access was reviewed August 3, 2026. It is not current certification, an open license, causal proof, or permission to deploy. Check the live Versions and Evidence pages for the current claim boundary. # From Quality Systems to AI Safety: A Regulated-Industry Perspective **Draft v0.1 — for review** **Author:** Phillip Linstrum **Target length:** 2,000–2,500 words (this draft: ~2,400) **Source files:** professional resume (eye-bank QA role), `PBHP-ULTRA_v0.7.1.md` (Drift Alarm, Monthly Calibration, Documentation), `PBHP_STANDARDS_MAPPING.md`, `CHIMessay.docx` **Target audience:** Quality professionals considering AI safety; AI safety researchers unfamiliar with regulated industries **Suggested venues:** *Quality Progress* (ASQ), *Harvard Business Review* (online), *IEEE Software*, ASQ Audit Division newsletter --- I have spent my career making sure tissue doesn't kill people. The frameworks I use every day, the ones I run audits against, write SOPs around, and train operators on — those frameworks are the ones AI safety keeps trying to invent from scratch. I am currently the Quality Systems Manager at an FDA-regulated eye bank in Indianapolis, supporting compliance with FDA 21 CFR Part 1271 and the Eye Bank Association of America Medical Standards. I oversee donor eligibility documentation, internal audits, deviation and CAPA management, training and competency programs, equipment control, and the cross-functional corrective and preventive actions that keep ocular tissue safe to transplant. Before this role I spent two and a half years as Assistant Center Manager at a high-volume plasma-collection center — roughly one hundred donors a day — and before that, five years as a Quality Specialist on the same site doing CAPA tracking, change management, and trend reporting. I came up through phlebotomy. I have done this work at every level of the operational stack. I am also the author of the Pause Before Harm Protocol (PBHP), an open-source AI safety framework now at v0.9.5 with a four-tier documentation architecture (ULTRA / CORE / MIN / HUMAN). I built PBHP in my off hours because I kept reading AI safety material and recognizing the patterns. I recognized them because I run them in production every week. This essay is about what the AI safety field is missing by not picking up the tools that regulated industries already use. It is not a comprehensive review. It is a punch list of seven specific things that QA does, that AI safety mostly does not yet do, and that AI safety needs to do if it wants to ship safety frameworks that survive contact with deployment. ## 1. CAPA Is Not Optional. It Is The Discipline. Corrective and preventive action — CAPA — is the bedrock of every regulated quality system. The discipline goes like this: when something goes wrong, you do not just fix the immediate problem. You investigate the root cause, you implement a corrective action that addresses the immediate problem, you implement a preventive action that addresses the systemic conditions that allowed the problem to occur, and you run an *effectiveness check* at a defined interval afterward to verify that the preventive action actually prevented recurrence. The effectiveness check is the part the AI safety field most consistently lacks. Most AI safety frameworks have *some* response to incidents — model patches, fine-tuning runs, RLHF adjustments, prompt updates. Very few of them have a defined effectiveness check that says, at thirty days and ninety days after the corrective action, here is the metric we will check, here is the threshold that means the preventive action worked, and here is what we do if the threshold is not met. Without effectiveness checks, what you have is reactive patching. Every incident gets a patch, the patch is assumed to work, and the next incident is treated as a new incident rather than as evidence that an earlier patch was ineffective. The pattern is invisible because nobody is looking for the pattern. CAPA is the mechanism by which you look for the pattern. PBHP requires effectiveness checks as a default. Every drift-alarm trigger, every monthly calibration review, every adversarial-test failure is logged with a corrective action and a defined re-check interval. The framework does not assume its own patches work. The framework assumes the patches need to be verified, the same way every regulated facility assumes its CAPA actions need to be verified. ## 2. Validation Before Production. Always. In regulated healthcare, no piece of equipment enters production use without IQ / OQ / PQ validation — Installation Qualification, Operational Qualification, Performance Qualification. The installation is verified, the operation is verified against specification, the performance is verified under production conditions. The validation documentation is reviewed, signed, archived, and audited. In AI deployment, the standard practice is closer to "passes the eval set, ship it." Even relatively mature deployment pipelines often lack the equivalent of a Performance Qualification step — a structured run against production-representative inputs with defined pass / fail criteria documented before the run. The reason is partly cultural (the field grew up under "move fast and break things") and partly structural (the iteration loop is so tight that formal validation feels like overhead). The cost of skipping PQ-equivalent validation shows up later, in production, when the model encounters input distributions that the eval set did not cover. The validation discipline that regulated industry has refined over decades exists precisely to surface those gaps before the equipment is in the field. AI deployment does not yet have the equivalent vocabulary, the equivalent documentation, or the equivalent audit expectation. PBHP's contribution here is the four-tier documentation architecture. The PBHP-ULTRA tier is the equivalent of full validation documentation: every spec passage, every risk class, every gate trigger, every escalation criterion. The PBHP-CORE tier is the deployable spec — what an engineering team needs to actually run the protocol. The PBHP-MIN tier is the compressed operational reference. The PBHP-HUMAN tier is the plain-language version that a non-technical stakeholder can read and understand. The four-tier structure exists so that the validation evidence is available in the form each audience needs. This is not a documentation flex. It is how every regulated quality system structures its documentation, because audit, training, deployment, and stakeholder communication are four different documentation needs and one document cannot serve all of them. ## 3. Drift Monitoring Is The Job. Not An Optional Add-On. Every quality system monitors for drift. In medical-device manufacturing, drift is the gradual shift in calibration that turns a piece of equipment from compliant to non-compliant over time without any single point of failure. In donor screening, drift is the gradual normalization of borderline eligibility judgments that turns the screening threshold into something looser than the SOP specifies. In CAPA execution, drift is the gradual erosion of effectiveness-check rigor that turns the closed loop into a paperwork exercise. Drift monitoring is the response. You measure the metric continuously, you set the threshold, you trigger the alarm when the threshold is crossed, and you respond to the alarm with a defined investigation pathway. The discipline is not exotic. Every well-run plasma center, eye bank, and medical-device manufacturing facility does it as a matter of course. AI safety has begun to recognize drift in the form of model drift (distribution shift in inputs) and concept drift (the target concept changing over time). Both of these are well-documented in the ML literature. What is less well-recognized — and what PBHP names explicitly — is *operational drift*: the gradual erosion of how rigorously the safety protocol itself is being applied. The PBHP v0.7.1 drift alarm reads: > Treat as a failure state if you hear: "We ran PBHP, so we're covered." "PBHP says it's allowed." "We just need to pass the checklist." "That's above PBHP's scope." These are not edge cases. They are the predictable language operators develop as they normalize a safety protocol into the background. A protocol without a drift alarm pointed at its own operational use will degrade through these phrases over six to twelve months. A protocol with one will catch the degradation while it is correctable. PBHP also requires monthly calibration sampling — approximately ten logs sampled per month, pass criteria documented, failure response specified. This is borrowed directly from the QA practice of internal audit sampling on operator competency and SOP compliance. It is not novel work. It is standard work that has not yet been imported into AI safety. ## 4. Documentation Is Evidence, Not Decoration. A piece of documentation in a regulated system has a specific function: it produces evidence that an action was taken, by whom, under what conditions, with what result. The documentation is what makes the action auditable after the fact. The documentation is what allows the FDA inspector to verify that the deviation was investigated and the CAPA was effective. The documentation is what the operator's competency file proves about their training. In AI safety, documentation is more often treated as deliverable — a model card, a system card, a published report. These are good and necessary, but they are not the same as auditable per-decision evidence. A regulated facility does not get to publish a one-time model card; it gets to produce the daily, per-batch, per-deviation, per-CAPA documentation that, when sampled by an inspector at any point in the lifecycle, produces evidence that the system was operating in compliance. PBHP's receipt schema is the equivalent. Every gate trigger, every challenge to a pause, every escalation, every override is recorded with the structured fields that make the deliberation auditable after the fact. The TriuneConsensus field, which logs the Logic / Care / Paradox assessment of each consequential decision, is the per-decision audit evidence. This is borrowed from regulated industry's discipline of producing per-action documentation, not from anywhere in AI safety's current vocabulary. The point of per-decision documentation is not that anyone will read every record. The point is that the records *exist*, that they are uniformly structured, that sampling produces statistically valid quality signals, and that the sampling itself is a documented practice. None of those properties are present in deployments that rely on "if something goes wrong, we'll investigate" as their documentation strategy. ## 5. The Auditor Has To Be Someone Who Wasn't In The Room. The single most important property of a regulated audit is that the auditor is independent of the operation being audited. An internal audit run by the same team that built the SOP is, in regulated industry, considered a self-assessment — useful for continuous improvement but not sufficient as an audit. The real audit is conducted by someone outside the operation, against the same evidence, with no obligation to agree with the team's interpretation. In AI safety, the field has begun to develop external audit practices (Anthropic's red-team work, METR evaluations, the various AI safety institutes' evaluations). What is less developed is the routine internal-audit-with-external-reviewer pattern that regulated facilities run continuously. An eye bank does not wait for the EBAA accreditation visit to verify SOP compliance. It runs internal audits monthly and external (third-party) audits annually as standard practice. The internal audit catches the issues; the external audit verifies the internal audit is itself rigorous. PBHP's adversarial-pattern reference and red-team requirement build toward this. The v0.7.1 spec requires red-team review for ORANGE, RED, and BLACK risk classes and recommends it whenever power asymmetry or public impact is present. The red team is structured to attempt all of: how it could go wrong, who could misuse it, how it could expand or be repurposed, whether the action and its harms could be described plainly to the people who would be harmed. The discipline is borrowed from the formal CAPA investigation process, which requires that the investigator be someone who was not directly involved in producing the deviation. The reasoning is the same: the person who built the system cannot reliably audit it because their cognitive frame is the frame that produced the gap in the first place. AI safety needs to internalize this as routine practice rather than as something that happens at quarterly red-team events. ## 6. The Operator Is A First-Class Stakeholder, Not An Implementation Detail. Every operator in a regulated facility has a competency file. The file documents that the operator was trained on the SOP, that the training was verified by a defined competency assessment, that the assessment was repeated at the required interval, and that any competency gap was addressed with re-training and documented in the file. The reason the operator is treated as a first-class stakeholder is that the operator is the point at which the safety system meets reality. An SOP that the operators do not understand, cannot remember, or do not believe will produce non-compliance regardless of how well-written the SOP is. The training and competency program is the bridge between the document and the practice. In AI safety, the equivalent stakeholder is the engineer deploying the model, the analyst running the eval, the moderator handling the flagged output, the human-in-the-loop reviewer. Almost none of these roles have anything resembling a competency file. The training is informal, the assessment is ad hoc, the gap-closure is unstructured. PBHP's HUMAN tier is the response. The PBHP-HUMAN document is the version of the protocol an operator can read and understand without an engineering background. The 90-day implementation playbook structures the rollout so that operators come up to competency on a defined schedule. The monthly calibration sampling is the equivalent of the recurring competency check. This is not a feature anyone in AI safety asks for. It is a feature that anyone who has run a regulated operation knows is non-optional, because the operator who doesn't understand the protocol is the operator who routes around it. ## 7. The Field Is Not Starting From Scratch. It Just Acts Like It Is. The most important thing I would say to AI safety researchers who have never worked in a regulated industry is this: you are not the first people to face the problem of getting humans to consistently apply a safety discipline under production pressure. The field of quality assurance has been solving this problem at scale for over fifty years. The vocabulary exists. The tools exist. The patterns of failure exist and have been categorized. The patterns of success exist and have been documented. The reason AI safety keeps reinventing the wheel is partly cultural — the field grew up adjacent to ML research, where the dominant vocabulary is about model architecture and training dynamics, not about operational discipline. It is also partly structural — the people who build AI systems are mostly not the people who run regulated facilities, and the cross-pollination has been minimal. PBHP is one attempt to bridge that gap. It is built by someone who works in FDA-regulated healthcare, and it shows. Every primitive in PBHP — the deterministic gate ladder, the false-positive release valve, the power-asymmetry escalation, the drift alarm, the monthly calibration sampling, the four-tier documentation, the receipt schema with structured audit fields — has a parallel in regulated quality systems. None of them are novel. All of them are necessary. The AI safety field has been working without them. The bridge needs to be walked from both sides. AI safety researchers should learn what QA already knows — by reading the ISO 9001 family, the FDA Quality System Regulation, the ASQ body of knowledge, the regulated-industry CAPA literature. QA professionals should learn what AI safety actually needs — by engaging with the public AI safety corpus, the ML deployment failure cases, the model behavior literature. Both sides have something to teach. Neither side currently knows what the other knows. I am one practitioner. I built one protocol in my off hours. The work I did is small relative to what is needed. But the protocol exists, it is published, the methodology is documented, and the bridge it represents is available to anyone willing to walk it. If you are an AI safety researcher and you have read this far, the most useful thing you can do this month is find a CAPA specialist at a regulated facility near you and ask them how they prevent operators from routing around the protocol. They will tell you. Their answer will be the answer the field has been looking for. If you are a QA professional and you have read this far, the most useful thing you can do this month is read one AI safety paper that the field considers foundational — Anthropic's Constitutional AI paper, the AI Index Report, the most recent AI Safety Institute evaluation — and ask yourself how the methodology compares to a Type 1 inspection at a Class III medical device manufacturer. Your gut response will be informative. The two fields need each other. The bridge does not yet exist. It can. — Phillip Linstrum projectshadowqa@protonmail.com --- **On voice and attribution.** This is in my voice and uses my actual professional history (an Indianapolis eye bank, a prior plasma-collection center, the certifications and standards I work under). PBHP spec language is from v0.7.1. The "make tissue not kill people" opening is mine and is the same opening I used in the *Essay Seeds* document. The seven-point structure is original to this draft. **For Phillip — review notes.** Three things: (1) The Anthropic / METR / AI Safety Institute mentions in section 5 ground the essay in current field practice — keep, or strip for venue-neutrality? (2) The professional credentialing in the opening paragraph is doing a lot of work; I made the call that the venue list (ASQ, HBR, IEEE Software) rewards establishing the bona fides up front. (3) This is the easiest of the three priority essays to ship — it doesn't require the reader to engage with mythic vocabulary or trust the framework on its own terms. It establishes you as a credentialed practitioner before any reader has to evaluate PBHP as a framework. I'd ship this one first, and let Essays 1 and 2 follow.