> **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. # What PBHP Is, What PBHP Is Not — Explicit Scope Acknowledgment **Version:** v0.1 (draft for review) **Date:** 2026-06-02 **Author:** Charles Phillip Linstrum **Contact:** projectshadowqa@protonmail.com **Purpose:** Address head-on the scope-confusion failure mode by explicitly stating what PBHP is and is not. Required reading for any organization evaluating PBHP for adoption. --- ## Why This Document Exists External evaluations of PBHP have surfaced a consistent observation: the framework is sometimes presented as broader than it is, which invites both inflated expectations from sympathetic readers and easy dismissal from hostile readers. Sympathetic readers may treat PBHP as a comprehensive AI safety solution and be disappointed when capability-related or training-time concerns are not addressed. Hostile readers may attack PBHP for failing to solve problems the framework was never designed to address. This document closes that scope-confusion gap. It states explicitly what PBHP is, what PBHP is not, and where the boundaries are. Organizations evaluating PBHP for adoption should treat this document as the canonical scope statement. The author considers it more important than any single primitive specification. The framing here is borrowed from regulated-industry practice. Every well-run quality management system includes an explicit scope statement that defines what the system covers and what it does not. The scope statement is not weakness; it is professional discipline. An organization that adopts a framework without a clear scope statement will inevitably misapply the framework, blame the framework for failures it could not have prevented, or both. --- ## What PBHP Is PBHP is a **deployment-time operational governance framework for AI-mediated consequential decisions**. The operative phrases: **Deployment-time.** PBHP operates after the AI system has been trained and is being used to produce outputs that affect people, decisions, or downstream actions. It does not specify what happens during training, fine-tuning, alignment optimization, or model selection. It operates at the layer where outputs meet operators and where outputs meet affected stakeholders. **Operational.** PBHP is a working protocol with structured primitives, defined documentation, specific gate triggers, specific receipt formats, and specific calibration sampling schedules. It is not a research program, a theoretical framework, a philosophical position, or a set of principles awaiting implementation. The implementation is the framework. **Governance.** PBHP addresses how AI decisions are made, documented, reviewed, escalated, refused, challenged, and audited. It does not directly address AI capabilities, AI accuracy, AI performance, or AI behavior at the model-output level. It addresses the human-AI interaction layer and the deployment-organization layer that surrounds the AI outputs. **For AI-mediated consequential decisions.** PBHP is designed for situations where an AI system contributes to or makes decisions that have consequences for identified stakeholders. It is not designed for purely informational AI uses, casual conversational AI, or AI applications where decisions are not at stake. Its primitives become overhead in low-stakes contexts and load-bearing in high-stakes contexts. **Six primary operational primitives:** 1. The Five-Gate Ladder (GREEN / YELLOW / ORANGE / RED / BLACK) for structured risk classification. 2. The deterministic Power Rule that establishes hard gate floors based on stakeholder power asymmetry and decision irreversibility. 3. The Door / Wall / Gap primitive for structured decision articulation. 4. The Maybe Field for required steelman articulation on ORANGE-and-above classifications. 5. The False Positive Release Valve with structured four-output challenge response. 6. The Receipt Schema for per-decision structured audit documentation. **Three supporting structures:** 1. The Drift Alarm for detecting operational normalization of the protocol into uselessness. 2. The Sacred Refusal as deployment-governance commitment to honor AI-generated refusals through structured escalation rather than override. 3. The Four-Tier Documentation Architecture (ULTRA / CORE / MIN / HUMAN) for audience-calibrated documentation supporting validation, deployment, operational reference, and stakeholder communication. **One foundational discipline:** the entire framework operates as a CAPA-style closed loop. Deviations from the protocol are documented, root causes investigated, corrective actions implemented, and effectiveness verified at defined intervals. This is what makes PBHP an auditable governance framework rather than a set of suggestions. --- ## What PBHP Is Not ### PBHP Is Not An AI Alignment Framework PBHP operates downstream of model-training-time alignment work. The framework assumes the deployed model is reasonably corrigible — that is, that the model will engage the protocol's structured evaluation rather than circumventing or deceiving it. If the underlying base model has fundamental alignment failures (deceptive alignment, mesa-optimization, reward hacking, goal misgeneralization, or the various failure modes the alignment literature has named), PBHP can catch *symptoms* in the form of suspicious output patterns, but cannot fix the *underlying training problem*. This means PBHP is necessary but not sufficient for organizations deploying AI systems with potential alignment failures. The framework complements alignment work; it does not substitute for it. Organizations relying on PBHP as their only AI safety layer are operating in a way the framework's documentation does not endorse. Concretely: if you are deploying a frontier model from a major AI lab in a high-stakes context, you need both PBHP (for deployment-time governance) and engagement with the model provider's alignment guarantees (for training-time assurance). PBHP gives you the audit trail and the structured refusal pathway; the alignment work gives you the baseline behavior the audit trail is verifying. ### PBHP Is Not A Legal Compliance Framework PBHP's structural alignment with EU AI Act, NIST AI RMF, ISO/IEC 42001, OMB M-24-10, and various national AI regulatory frameworks is *structural*, not *legal*. The framework can contribute to compliance evidence — the receipt schema, the calibration sampling reports, the CAPA-loop documentation, the impact assessments — but it does not constitute compliance certification. Deploying organizations remain legally responsible for verifying compliance with applicable law in their jurisdiction. PBHP is one input to compliance work, not the conclusion of compliance work. Concretely: if an EU AI Act high-risk system audit asks for evidence of risk management per Article 9, PBHP-produced documentation can supply substantial evidence. But the legal certification that the system is compliant is the certification body's call, not PBHP's. ### PBHP Is Not A Clinical Or Medical Judgment System PBHP can be deployed in clinical AI contexts (the Validation Packet's Case 4 and Case 9 illustrate this). When deployed in clinical contexts, PBHP supports the clinical decision process rather than substituting for clinical judgment. It cannot diagnose, prescribe, or determine medical care. It can ensure that AI systems supporting clinical processes do so with appropriate safeguards (human override capability, validation protocols, real-time monitoring, conservative defaults). Organizations deploying AI in clinical contexts need PBHP alongside clinical governance frameworks (medical ethics committees, clinical decision support standards, FDA medical device requirements where applicable), not as a replacement for them. ### PBHP Is Not A Substitute For Organizational Governance PBHP is a decision-level operational protocol. It assumes a deploying organization with functional governance — leadership accountability, change management, training programs, audit capacity, ethical oversight structures. PBHP cannot manufacture organizational competence where it does not exist; it can provide structure for organizations that have the underlying capacity to run it. An organization without functional change management cannot effectively run PBHP because the protocol's CAPA-loop requires change management discipline to close the loop. An organization without trained operators cannot effectively run PBHP because the Maybe field and the Door / Wall / Gap articulation require operator competency. An organization without leadership commitment to the protocol cannot maintain it under pressure because the drift-alarm response requires leadership backing. PBHP is the operational layer that sits inside an organization with functional governance. It does not create the governance; it operates within it. ### PBHP Is Not A Solution To Capability-Related AI Risks At Scale The framework's primitives address deployment-time decision-making and operator-AI interaction patterns. They do not address: capability overhang (the gap between current and frontier AI capabilities), dual-use research concerns (the same capability serving beneficial and harmful uses), geopolitical AI dynamics (competition between nation-state AI programs), AI-enabled mass harm at scales beyond individual-decision impact, or existential-risk scenarios (failures involving AI systems acquiring resources or influence at scale). Organizations concerned with these risk categories require additional frameworks (governance work at the policy level, international coordination work at the diplomatic level, capability evaluation work at the AI lab and institute level). PBHP is necessary but not sufficient for any of these concerns. The framework's claim to address them would be overreach. ### PBHP Is Not A Multi-Agent Or Recursive-AI Safety Framework PBHP currently addresses AI-to-human-operator dynamics in single-agent or simple multi-agent contexts. Multi-agent coordination is mentioned in the protocol's Tribunal Mode specification but is under-specified for production deployment. Recursive AI scenarios (AI systems building or modifying other AI systems, AI systems running other AI systems as subprocesses) are not addressed. Organizations deploying multi-agent AI systems should treat PBHP as a starting baseline for individual-agent governance and add multi-agent coordination protocols separately. Recursive AI deployments require additional governance structures that PBHP does not provide. ### PBHP Has Not Been Empirically Validated At Scale The Validation Packet presents qualitative testing across 25+ documented scenarios. This is operational testing, not empirical validation. The framework has not been deployed in production at enterprise scale; its effectiveness in that context is hypothesized, not demonstrated. Organizations considering adoption should plan for staged deployment with monitoring (per the Adoption Ladder) rather than full deployment based on the existing testing corpus. The framework's value should be demonstrated in the adopting organization's own deployment context, not assumed from the author's testing. ### PBHP Is Not A Mandate For Heroic, Solitary Burden PBHP is a discipline to be *distributed and audited*, not a vigil to be *borne alone*. A safety role run as permanent solitary vigilance — no witness, no rotation, no relief, no exit — is not the framework operating well; it is a deviation the framework exists to surface. Reliable performance is not evidence the arrangement is sound: *stable is not healed, functional is not free, mission-capable is not safe.* This carries a requirement for adopters. The framework asks an organization to audit not only the carrying of a safety burden but the hill itself — who assigned the work, who benefits from its continuation, whether it is still necessary, and whether there is witness, rotation, and relief — and whether the person or system running it could stop without abandoning the stakeholders the work protects. A safety function that depends on one un-backed party indefinitely is a finding, not a virtue: *do not confuse the ability to continue with evidence that continuation is just.* Concretely: an organization that adopts PBHP and routes its entire deployment-governance load onto a single un-supported individual has not implemented the framework — it has reproduced the failure mode the framework names. The reciprocal Mirror Vow, the expectation of distributed burden, and leadership commitment to Sacred Refusal exist so the discipline does not collapse into one person's endless carry. --- ## What Adopting PBHP Commits You To Adopting PBHP is a deployment-time commitment with operational requirements. Specifically: 1. **Per-decision documentation.** Every consequential AI-mediated decision must produce a receipt schema entry. This requires either operator capacity to produce receipts or AI capability to produce them automatically, plus infrastructure to store and audit them. 2. **Monthly calibration sampling.** Approximately ten receipt records sampled monthly with documented pass/fail criteria. This requires audit capacity in the deploying organization. 3. **CAPA-loop maintenance.** Drift-alarm triggers, calibration sampling failures, and escalated release-valve challenges all produce deviations that require root cause analysis, corrective action, and effectiveness verification. This requires CAPA discipline. 4. **Operator training.** Operators interacting with the protocol must understand the Maybe field, the Door / Wall / Gap articulation, the Power Rule, and the escalation pathways. This requires training programs. 5. **Leadership commitment to Sacred Refusal.** The deployment-organization commits to honor AI-generated refusals through structured escalation rather than override. This requires leadership backing because operator pressure to override will be real. Organizations that cannot meet these commitments should not adopt PBHP. The framework's primitives are not extractable; the operational discipline is the framework. Partial adoption produces partial effectiveness, and below a certain implementation threshold, partial adoption produces the surface signs of safety governance without the substantive operation — which is the failure mode the Drift Alarm catches and which the framework names as the worst-case outcome. --- ## What PBHP Adopting Organizations Should Expect From The Framework's Author The framework is open source and the author is one person with a day job. Organizations adopting PBHP should expect: 1. **The published documentation is the documentation.** The author does not provide bespoke consulting services for individual adoptions. The PBHP repository, this adoption package, and the related materials are the support surface. 2. **Bug reports and substantive feedback are welcomed.** The author engages with reported issues, structural critiques, and substantive feedback from adopting organizations. Response time is best-effort. 3. **Custom protocol development is not available.** The framework is general-purpose; organizations needing specialization should do the specialization work themselves rather than expecting the author to do it. 4. **The framework will continue to evolve.** PBHP is at v0.7.1 publicly and v0.9.5/v0.9.6 internally. Adopting organizations should expect version updates and plan for protocol-version migration as part of their adoption. 5. **The author may choose to formalize ongoing support at some future date** (whether through paid consulting, an institutional structure, or open-source maintenance arrangements). Until then, the relationship is informal and the support is best-effort. This is consistent with how other open-source operational frameworks are typically supported. The framework's value comes from the framework itself, not from the author's availability. --- ## Closing Scope clarity is itself a quality discipline. A framework that overclaims fails its users when the inflated claims meet operational reality. A framework that underclaims fails its users by leaving them without recognized credit for the work the framework does perform. PBHP is a deployment-time operational governance framework for AI-mediated consequential decisions. It does what its primitives describe and does not do what they do not describe. Organizations adopting PBHP with this scope clearly in view will deploy the framework well. Organizations adopting PBHP without this scope clearly in view will eventually be disappointed. The author considers this scope acknowledgment as load-bearing as any operational primitive in the framework. Read it before adopting; refer to it during adoption; treat it as the canonical scope statement. — Charles Phillip Linstrum projectshadowqa@protonmail.com --- *End of scope acknowledgment v0.1.*