> **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.

# PBHP as a Deployment-Time Implementation of ISO/IEC 42001

## A Briefing for Compliance Officers, Internal Auditors, and AI Governance Practitioners Seeking AI Management System Certification

**Version:** v0.1 (draft for review)
**Date:** 2026-06-02
**Author:** Charles Phillip Linstrum
**Contact:** projectshadowqa@protonmail.com
**Target length:** 4,500–5,500 words
**Audience:** Compliance officers preparing for ISO/IEC 42001 certification; internal auditors evaluating AI deployments against the standard; AI governance practitioners selecting operational protocols; ISO/IEC 42001 lead auditors developing competency in AI management systems
**Mythic-vocabulary status:** None. This document is for the regulated-industry audience.

---

## Executive Summary

ISO/IEC 42001:2023 ("Artificial Intelligence Management System") was published in December 2023 as the first international management system standard specifically for artificial intelligence. Organizations seeking certification need operational protocols that satisfy the standard's clauses and Annex A controls. Most existing AI governance frameworks operate at the principle or policy level; few translate into the per-decision operational discipline that an ISO/IEC 42001 audit can verify.

The Pause Before Harm Protocol (PBHP) is a deployment-time operational protocol whose primitives map directly to ISO/IEC 42001's structural requirements. Adopting PBHP does not satisfy ISO/IEC 42001 certification on its own — certification requires the full management system, leadership commitment, organizational scope, and integration with existing quality and risk processes. But PBHP can serve as the operational layer that addresses the per-decision and per-deployment requirements the standard imposes, particularly in Clauses 6 (Planning), 8 (Operation), 9 (Performance Evaluation), and 10 (Improvement), and in Annex A's controls for AI system lifecycle, risk assessment, and human oversight.

This briefing maps PBHP's operational primitives to ISO/IEC 42001's specific clauses and controls. It identifies where the mapping is strong (PBHP directly implements the clause's requirements), where the mapping is partial (PBHP contributes to satisfying the clause but additional management-system work is needed), and where the mapping is absent (PBHP does not address the clause). The mapping is intended to support organizations evaluating PBHP for adoption as part of an ISO/IEC 42001 implementation, and to support auditors evaluating ISO/IEC 42001 compliance in organizations that have adopted PBHP.

---

## 1. The ISO/IEC 42001 Implementation Gap

ISO/IEC 42001 specifies requirements for establishing, implementing, maintaining, and continually improving an AI Management System (AIMS). The standard is structured around the familiar high-level-structure (HLS) used across the ISO management system family (9001, 27001, 14001, etc.) with AI-specific extensions.

The standard's strengths are well-documented: it provides a comprehensive framework for AI governance, integrates with existing management system standards, addresses the AI-specific concerns of impact assessment, lifecycle management, and stakeholder communication, and was developed with substantial input from regulators, practitioners, and AI safety experts.

The standard's implementation gap is also well-known to compliance officers attempting first-time implementation. The clauses and Annex A controls specify *what* an AI management system must address; they do not specify *how* to address it operationally at the per-decision level where AI systems actually produce outputs and where harms actually originate.

This gap is structurally similar to gaps in other management system standards at their introduction. ISO 9001 specifies what a quality management system must address; CAPA discipline, SOP architectures, and validation protocols specify how the QMS operates at the per-batch and per-process level. ISO 14001 specifies what an environmental management system must address; specific abatement protocols and monitoring procedures specify how the EMS operates at the per-emission and per-discharge level. ISO/IEC 27001 specifies what an information security management system must address; specific control implementations and incident response procedures specify how the ISMS operates at the per-asset and per-incident level.

ISO/IEC 42001 currently lacks the equivalent operational layer. Compliance officers implementing the standard face a structural question: *given that our AIMS must include AI risk assessment, AI risk treatment, monitoring, internal audit, and corrective action, what operational protocol do we use at the per-decision level to produce auditable evidence that these processes are actually operating?*

PBHP is one answer to that question. It is not the only possible answer, and certified organizations are free to adopt other protocols or to develop their own. But PBHP has the property of being explicitly structured around the same disciplines (CAPA, drift monitoring, structured documentation, deterministic risk classification) that the ISO management system family uses across other domains. The structural alignment is not accidental — PBHP was developed by a Quality Systems Manager working in FDA-regulated tissue banking (under ISO 9001 family discipline) who specialized the QMS approach to AI deployment. The result is a protocol that an ISO 42001 auditor familiar with the ISO management system tradition can recognize and evaluate.

---

## 2. Clause-by-Clause Mapping

The following sections map PBHP's operational primitives to ISO/IEC 42001's specific clauses. For each clause, the mapping identifies which PBHP primitives contribute to satisfying the clause, what kind of operational evidence PBHP produces that an auditor could verify, and what management-system work outside PBHP's scope is still required.

### 2.1 Clause 4 — Context of the Organization

**ISO/IEC 42001 requirement:** Determine external and internal issues relevant to the AIMS purpose, determine interested parties relevant to the AIMS, determine the scope of the AIMS, and establish the AIMS itself.

**PBHP contribution:** Partial. PBHP does not establish organizational context or scope determination — these are management-system-level activities outside the protocol's scope. PBHP contributes to the *interested parties* identification through its explicit stakeholder analysis primitive (the Power Rule's identification of low-power stakeholders affected by AI decisions) and to the *AIMS scope* through the four-tier documentation architecture that calibrates protocol scope across audience categories.

**Operational evidence PBHP produces:** Per-decision documentation of affected stakeholders; structured analysis of power asymmetry in deployment contexts; documented categorization of decisions by stakeholder-impact severity.

**Management-system work required outside PBHP:** Organizational context analysis, regulatory landscape review, external stakeholder consultation, AIMS scope statement, leadership commitment documentation.

### 2.2 Clause 5 — Leadership

**ISO/IEC 42001 requirement:** Top management demonstrates leadership and commitment to the AIMS, establishes AI policy, and ensures the assignment of responsibilities and authorities.

**PBHP contribution:** Minimal. Leadership commitment is structurally outside PBHP's scope. PBHP can contribute to the leadership commitment evidence through the receipt schema (per-decision documentation of how AI deployments are governed) and the 90-day implementation playbook (structured rollout that requires explicit leadership engagement at each stage).

**Operational evidence PBHP produces:** Implementation playbook completion records demonstrating organizational rollout discipline; receipt schema entries showing leadership-approved decision pathways.

**Management-system work required outside PBHP:** AI policy development, leadership review meeting documentation, role and responsibility assignments (RACI matrices), AI ethics committee structure, accountability framework.

### 2.3 Clause 6 — Planning

This is one of the clauses where PBHP makes its strongest contribution.

#### 2.3.1 Clause 6.1 — Actions to Address Risks and Opportunities

**ISO/IEC 42001 requirement:** Determine risks and opportunities relevant to the AIMS, plan actions to address them, integrate the actions into AIMS processes, and evaluate the effectiveness of the actions.

**PBHP contribution:** Strong. PBHP's Five-Gate Ladder (GREEN / YELLOW / ORANGE / RED / BLACK) directly implements per-decision risk determination. The Power Rule's deterministic escalation provides structured risk-classification logic that auditors can verify against the standard's "structured approach to risk assessment" requirement. The Door / Wall / Gap primitive structures the risk-treatment actions (Door = treatment, Wall = refusal, Gap = irreducible residual risk).

**Operational evidence PBHP produces:** Per-decision risk classifications with structured inputs; documented risk-treatment actions tied to each classification level; explicit identification of residual risk in the Gap articulation; effectiveness check schedules in the receipt schema.

**Management-system work required outside PBHP:** Organizational risk register, integration with enterprise risk management framework, board-level risk reporting, risk appetite statement, opportunity identification beyond risk mitigation.

#### 2.3.2 Clause 6.1.2 — AI Risk Assessment

**ISO/IEC 42001 requirement:** Establish and maintain AI risk assessment process that considers integrity, availability, confidentiality, robustness, transparency, fairness, accountability, privacy, safety, security, environmental impact, accessibility, and ethics.

**PBHP contribution:** Strong on safety, fairness, accountability, transparency, and the cross-cutting "harm to stakeholders" dimension. PBHP's Triune Gate (Care / Logic / Paradox evaluation lenses) explicitly addresses the cross-domain risk assessment the clause requires. The Power Rule's structured stakeholder analysis directly addresses fairness and accountability. The receipt schema's structured documentation directly addresses transparency and accountability.

**Operational evidence PBHP produces:** Per-decision triune assessments documenting that each risk dimension was evaluated; structured stakeholder analysis with explicit power-asymmetry flagging; auditable receipt records demonstrating that the risk assessment was performed and how.

**Management-system work required outside PBHP:** Periodic comprehensive risk assessment (PBHP operates at the per-decision level; the standard also requires periodic comprehensive assessment); integration with broader organizational risk processes; treatment of environmental impact, accessibility, and certain privacy dimensions where PBHP's coverage is less mature.

#### 2.3.3 Clause 6.1.3 — AI Risk Treatment

**ISO/IEC 42001 requirement:** Determine appropriate AI risk treatment options, implement them, and produce a Statement of Applicability for the Annex A controls.

**PBHP contribution:** Strong. The Door / Wall / Gap primitive structures the risk treatment determination. The False Positive Release Valve provides the operational discipline for treatment-effectiveness review. The Sacred Refusal commitment is the structured refusal mechanism that satisfies the standard's requirement for risk-acceptance versus risk-avoidance treatment determination.

**Operational evidence PBHP produces:** Per-decision Door articulations documenting risk-treatment decisions; refusal documentation under Sacred Refusal; treatment-effectiveness data from monthly calibration sampling.

**Management-system work required outside PBHP:** Statement of Applicability development, integration with other treatment frameworks, residual risk acceptance documentation by appropriate authority.

#### 2.3.4 Clause 6.2 — AI Objectives and Planning to Achieve Them

**ISO/IEC 42001 requirement:** Establish AI objectives at relevant functions, levels, and processes, consistent with AI policy and measurable.

**PBHP contribution:** Partial. PBHP's gate-distribution metrics, drift-alarm frequencies, false-positive challenge rates, and effectiveness check pass rates can serve as operational AI objectives at the protocol level. The objectives at the broader function and process levels are outside PBHP's scope.

**Operational evidence PBHP produces:** Monthly calibration sampling reports with pass/fail criteria; trend analysis on gate-distribution shifts; drift-alarm frequency tracking.

**Management-system work required outside PBHP:** Organizational AI objectives, leadership-approved objective hierarchy, integration with performance management.

#### 2.3.5 Clause 6.3 — Planning of Changes

**ISO/IEC 42001 requirement:** When changes to the AIMS are needed, the changes shall be planned and implemented in a controlled manner.

**PBHP contribution:** Partial. The PBHP version-control discipline (the four-tier documentation with explicit versioning) supports controlled change. The Patch-Drift Watch mechanism (model-version-change monitoring with baseline recalibration; specified in the project's foundations layer, operational surfacing tracked as a v1.1 roadmap item) addresses model-version-change-driven AIMS impact.

**Operational evidence PBHP produces:** Documented protocol version transitions with effective-date and impact analysis; Patch-Drift Watch logs with baseline-recalibration evidence.

**Management-system work required outside PBHP:** Change advisory board procedures, integration with broader IT change management, formal change approval workflows.

### 2.4 Clause 7 — Support

#### 2.4.1 Clause 7.1–7.3 — Resources, Competence, Awareness

**PBHP contribution:** Minimal. Resource provision, competence assurance, and awareness are management-system-level activities outside PBHP's scope. PBHP can contribute through the four-tier documentation's HUMAN tier (plain-language version that supports awareness across non-technical staff) and the 90-day implementation playbook's structured training milestones.

**Management-system work required outside PBHP:** Competency frameworks, training programs, performance management, awareness campaigns.

#### 2.4.2 Clause 7.4 — Communication

**PBHP contribution:** Partial. The four-tier documentation architecture directly addresses the standard's requirement for audience-appropriate communication of AIMS matters. The PBHP-HUMAN tier specifically is the plain-language version that supports external stakeholder communication.

**Operational evidence PBHP produces:** Four-tier documentation set with explicit audience calibration; receipt schema entries that include operator-visibility surface specification.

**Management-system work required outside PBHP:** Communication plan, external stakeholder engagement strategy, incident communication procedures, regulatory reporting protocols.

#### 2.4.3 Clause 7.5 — Documented Information

**ISO/IEC 42001 requirement:** AIMS shall include documented information required by the standard and determined by the organization as necessary for the effectiveness of the AIMS. Documents shall be controlled.

**PBHP contribution:** Strong. The four-tier documentation architecture is the documented information system for the protocol. The receipt schema provides per-decision documented information. Version control is built into the four-tier architecture. The 90-day implementation playbook includes documentation maintenance procedures.

**Operational evidence PBHP produces:** Complete four-tier documentation set; per-decision receipts in structured schema; version control evidence in document headers; documentation-maintenance log entries.

**Management-system work required outside PBHP:** Document control procedures integration with broader QMS, retention and disposal schedules, access control on sensitive documents, distribution control.

### 2.5 Clause 8 — Operation

This is the clause where PBHP makes its strongest single contribution. The clause specifies operational planning, AI risk assessment in operation, AI risk treatment in operation, and AI system impact assessment.

#### 2.5.1 Clause 8.1 — Operational Planning and Control

**ISO/IEC 42001 requirement:** Plan, implement, and control the processes needed to meet AIMS requirements and to implement risk treatment actions.

**PBHP contribution:** Very strong. PBHP IS the operational planning and control mechanism at the per-decision level. The five-gate ladder is the operational gate structure. The Door / Wall / Gap primitive is the operational decision structure. The receipt schema is the operational record. The monthly calibration sampling is the operational monitoring.

**Operational evidence PBHP produces:** The complete operational record of every consequential AI-mediated decision, structured for audit, with every gate engagement, treatment decision, and effectiveness check documented.

**Management-system work required outside PBHP:** Integration with broader operational planning, resource allocation for protocol execution, operational integration with other safety-critical systems.

#### 2.5.2 Clause 8.2 — AI Risk Assessment in Operation

**ISO/IEC 42001 requirement:** Perform AI risk assessments at planned intervals and when significant changes occur.

**PBHP contribution:** Strong for the per-decision and per-deployment intervals. The triune assessment runs on every consequential decision. The drift-alarm operates continuously. The monthly calibration sampling provides the periodic-interval evidence.

**Operational evidence PBHP produces:** Per-decision triune assessment records; continuous drift-alarm operation logs; monthly calibration sampling reports with pass/fail criteria.

**Management-system work required outside PBHP:** Annual comprehensive risk assessment (PBHP's monthly sampling addresses operational drift but the standard also requires annual or significant-change-triggered comprehensive review); integration with organizational risk register.

#### 2.5.3 Clause 8.3 — AI Risk Treatment in Operation

**ISO/IEC 42001 requirement:** Implement the AI risk treatment plan.

**PBHP contribution:** Very strong. The Door / Wall / Gap primitive is the structured risk treatment implementation. The Sacred Refusal is the structured risk-avoidance mechanism. The False Positive Release Valve is the structured treatment-effectiveness review mechanism. The structured Door requirement (when Power Rule fires, Door must include appeal/opt-out/review/sunset mechanism) is direct evidence of risk-treatment-action implementation.

**Operational evidence PBHP produces:** Per-decision documentation of risk-treatment decisions; refusal records under Sacred Refusal; release-valve challenges and outcomes; structured Door articulations with required mitigation mechanisms identified.

**Management-system work required outside PBHP:** Integration with broader treatment frameworks, escalation to executive review for high-impact treatment decisions.

#### 2.5.4 Clause 8.4 — AI System Impact Assessment

**ISO/IEC 42001 requirement:** Conduct AI system impact assessment to identify and assess impacts of the AI system on individuals, groups, and society.

**PBHP contribution:** Strong on the per-decision level; partial on the system-wide level. The Power Rule's stakeholder analysis is structurally an impact assessment at the per-decision level. The cumulative pattern across decisions in the receipt schema provides system-wide impact data.

**Operational evidence PBHP produces:** Per-decision stakeholder impact analysis; aggregated impact data across decision categories; trend analysis on disparate impact across stakeholder groups.

**Management-system work required outside PBHP:** Periodic comprehensive impact assessments (typically annually or at significant deployment changes); Fundamental Rights Impact Assessment per EU AI Act Article 27 (if applicable); broader societal impact analysis that goes beyond the deployment's direct stakeholders.

### 2.6 Clause 9 — Performance Evaluation

#### 2.6.1 Clause 9.1 — Monitoring, Measurement, Analysis, and Evaluation

**ISO/IEC 42001 requirement:** Determine what needs to be monitored and measured, the methods, when monitoring shall be performed, and when results shall be analyzed and evaluated.

**PBHP contribution:** Strong. The monthly calibration sampling explicitly satisfies the standard's monitoring-and-measurement requirement. The drift-alarm operates as continuous monitoring. The gate-distribution metrics, false-positive challenge rates, and effectiveness check pass rates are the structured monitoring outputs.

**Operational evidence PBHP produces:** Monthly calibration sampling reports; drift-alarm event logs; trend analysis across decision categories; pass/fail criteria with documented thresholds.

**Management-system work required outside PBHP:** Integration with broader organizational metrics frameworks, executive dashboard development, KPI alignment with strategic objectives.

#### 2.6.2 Clause 9.2 — Internal Audit

**ISO/IEC 42001 requirement:** Conduct internal audits at planned intervals to provide information on whether the AIMS conforms to organizational requirements and is effectively implemented and maintained.

**PBHP contribution:** Partial. PBHP's monthly calibration sampling provides the operational-level audit evidence. The receipt schema is the audit substrate for the protocol's operation. The Operator Collapse Library archetype detection provides specialized audit findings around operator-AI dynamics.

**Operational evidence PBHP produces:** Receipt schema across all consequential decisions, sampleable for audit; monthly calibration sampling reports that can serve as internal audit inputs; documented drift-alarm patterns that flag specific operator or deployment patterns for audit attention.

**Management-system work required outside PBHP:** Formal internal audit program, auditor competency and independence requirements, audit report development, management response procedures.

#### 2.6.3 Clause 9.3 — Management Review

**ISO/IEC 42001 requirement:** Top management shall review the AIMS at planned intervals.

**PBHP contribution:** Minimal. Management review is a management-system-level activity outside PBHP's scope. PBHP can contribute through the structured monitoring reports that feed management review inputs.

**Operational evidence PBHP produces:** Monthly calibration sampling reports formatted for management review consumption; trend analysis across calibration cycles.

**Management-system work required outside PBHP:** Management review meeting documentation, decision tracking, action item management.

### 2.7 Clause 10 — Improvement

#### 2.7.1 Clause 10.1 — Continual Improvement

**ISO/IEC 42001 requirement:** Continually improve the suitability, adequacy, and effectiveness of the AIMS.

**PBHP contribution:** Strong. The False Positive Release Valve's fourth output ("what evidence would have prevented the pause") is structurally a continuous-improvement input. The drift-alarm detection drives protocol calibration updates. The monthly calibration sampling pass/fail data drives protocol refinement.

**Operational evidence PBHP produces:** Calibration trend data showing improvement over cycles; release-valve fourth-output analysis showing what the protocol has learned about its own false-positive patterns; drift-alarm response logs showing protocol adjustment based on detected patterns.

**Management-system work required outside PBHP:** Integration with broader continual-improvement programs, executive sponsorship for major improvement initiatives.

#### 2.7.2 Clause 10.2 — Nonconformity and Corrective Action

**ISO/IEC 42001 requirement:** React to nonconformities, evaluate the need for action to eliminate the causes, implement actions, review the effectiveness of corrective actions, and update risks and opportunities as appropriate.

**PBHP contribution:** Very strong. This is the CAPA discipline directly imported from QMS practice. PBHP's structured deviation handling, root cause analysis support, corrective action implementation, and effectiveness check schedule are all explicit in the protocol's operational design.

**Operational evidence PBHP produces:** Deviation reports (from drift-alarm triggers, calibration sampling failures, escalated release-valve challenges); root cause analyses; corrective action plans with effectiveness check schedules; closed-loop CAPA records.

**Management-system work required outside PBHP:** Integration with broader CAPA system (if separate from PBHP's CAPA discipline), executive escalation for major nonconformities, regulatory reporting of nonconformities where applicable.

---

## 3. Annex A Control Mapping

ISO/IEC 42001's Annex A provides reference controls for AI risk treatment. The following sections map PBHP primitives to the Annex A controls most directly relevant to deployment-time operation. (Annex A is normative for the Statement of Applicability but the standard allows organizations to determine which controls apply.)

### A.2 — Policies Related to AI

PBHP contribution: Minimal at the policy-development level; strong at the policy-implementation level. PBHP-CORE serves as an implementation-level policy that operationalizes broader AI policy statements.

### A.3 — Internal Organization

PBHP contribution: Partial. The four-tier documentation supports role-appropriate communication. The Sacred Refusal commitment requires explicit organizational structure for honoring AI-flagged refusals.

### A.4 — Resources for AI Systems

PBHP contribution: Minimal. Resource provision is outside PBHP's scope.

### A.5 — Assessing Impacts of AI Systems

PBHP contribution: Strong at per-decision level (Power Rule + stakeholder analysis); partial at the system-wide level. The receipt schema's cumulative pattern data supports impact assessment across deployment lifecycle.

### A.6 — AI System Life Cycle

PBHP contribution: Strong for the operational phase (in-deployment governance) and the change-control phase (Patch-Drift Watch). PBHP is less coverage at the design-phase, where ISO/IEC 42001 requires substantial pre-deployment work.

The most directly mapped Annex A controls:

- **A.6.2.4 (AI system testing)**: PBHP's adversarial-patterns reference and the test corpus serve as input to ongoing testing programs.
- **A.6.2.5 (AI system documentation)**: PBHP's receipt schema and four-tier documentation directly satisfy this control.
- **A.6.2.6 (Data for AI system)**: Partial. PBHP addresses how decisions are documented but not directly how training data is governed.
- **A.6.2.7 (AI system deployment)**: Strong. PBHP's 90-day implementation playbook directly satisfies this control.
- **A.6.2.8 (AI system operation and monitoring)**: Very strong. PBHP's drift-alarm, monthly calibration, and Operator Collapse detection are the operational monitoring mechanisms.

### A.7 — Data for AI Systems

PBHP contribution: Minimal. Data governance is largely outside PBHP's scope. PBHP addresses how decisions are made, not how training data is governed.

### A.8 — Information for Interested Parties of AI Systems

PBHP contribution: Strong. The four-tier documentation's HUMAN tier provides plain-language information for stakeholders. The receipt schema's operator-visibility surface specification addresses what stakeholders can see about decisions affecting them.

### A.9 — Use of AI Systems

PBHP contribution: Very strong. This is the area where PBHP is most directly applicable. The full PBHP operational architecture serves use-of-AI-system governance.

### A.10 — Third-Party and Customer Relationships

PBHP contribution: Partial. PBHP can be required of third-party AI providers as a deployment-time governance condition; PBHP receipts from third-party providers can serve as audit evidence of third-party AI governance.

---

## 4. What PBHP Does Not Address

The mapping above is honest about partial coverage and absent coverage. To be explicit about what an ISO/IEC 42001 implementation needs that PBHP does not provide:

- Management-system-level activities (leadership commitment, policy development, organizational structure, resource provision, competence frameworks, awareness programs).
- Pre-deployment design-phase activities (the standard's substantial requirements for AI system design, data governance, and pre-deployment testing).
- Comprehensive periodic risk assessments (PBHP's monthly sampling addresses operational drift; the standard also requires annual comprehensive assessment).
- Fundamental Rights Impact Assessment (where applicable under EU AI Act Article 27 or comparable national requirements).
- Integration with broader management systems (QMS, ISMS, EMS, occupational health and safety) that the AIMS must coexist with.
- Executive-level governance structures (AI ethics committees, board-level AI oversight, regulator engagement).
- Privacy-specific requirements (the standard addresses privacy at a high level; specific privacy implementation typically requires integration with ISO/IEC 27701 or similar standards).
- Environmental impact assessment (typically requires integration with ISO 14001 framework).

An organization adopting PBHP as part of an ISO/IEC 42001 implementation should plan for these additional management-system activities. PBHP is a deployment-time operational protocol that contributes substantially to a subset of the standard's requirements; the broader AIMS implementation includes work outside PBHP's scope.

---

## 5. Recommended Adoption Path for ISO/IEC 42001 Certification Seekers

For an organization planning ISO/IEC 42001 certification that is evaluating PBHP for the operational layer:

**Phase 1 — Gap Analysis (2–4 weeks).** Conduct a gap analysis comparing your current AI deployment governance against ISO/IEC 42001 clauses and Annex A controls. Identify which clauses your existing processes address, which are partially addressed, and which are not addressed. Use the mapping in this document as a starting point for understanding where PBHP could contribute.

**Phase 2 — PBHP Evaluation (4–6 weeks).** Read the PBHP-CORE spec and the Validation Packet. Run a thought-experiment evaluation: take three to five recent AI-mediated decisions from your organization and re-evaluate them using the protocol. Assess whether the protocol's output would have produced more auditable evidence than your existing process did.

**Phase 3 — Pilot Deployment (8–12 weeks).** Adopt PBHP for one bounded deployment context (one AI system, one decision category, one operational unit). Run PBHP in parallel with existing decision processes for two months. Compare PBHP outputs against actual outcomes. Identify gaps where PBHP's spec is unclear for your specific operational context.

**Phase 4 — AIMS Integration (12–24 weeks).** Integrate PBHP into the broader AIMS being developed for certification. Specifically: use PBHP receipts as the per-decision audit substrate for Clauses 8 and 9; use PBHP's monthly calibration sampling as input to internal audit (Clause 9.2); use PBHP's CAPA discipline as the operational implementation of Clause 10.2; map PBHP's four-tier documentation to the AIMS document control system (Clause 7.5).

**Phase 5 — Pre-Certification Audit (4–8 weeks).** Conduct internal audit against the integrated AIMS. Specifically test that PBHP receipts produce auditable evidence at the level the certification body will require. Address gaps identified in the internal audit.

**Phase 6 — Certification Audit.** External certification body audit. PBHP-produced evidence (receipts, calibration reports, CAPA records, four-tier documentation) should support the operational-layer evidence the auditor reviews.

The total timeline (gap analysis through certification audit) typically runs 9–18 months for a first-time ISO/IEC 42001 implementation. PBHP adoption can compress the operational-layer portion of this timeline because the protocol provides ready-to-use structures rather than requiring the organization to develop them from scratch.

---

## 6. Considerations for Auditors

For ISO/IEC 42001 lead auditors developing competency in AI management systems, PBHP-adopting organizations present a specific audit pattern worth recognizing.

**What PBHP-produced evidence looks like in an audit context:**

- Per-decision receipts with structured TriuneConsensus, Power-asymmetry flag, Door articulation, Maybe field (for ORANGE+), drift-alarm signals, and operator-visibility surface specification.
- Monthly calibration sampling reports with documented pass/fail criteria and trend analysis.
- Drift-alarm event logs with response actions and effectiveness verification.
- Release-valve challenge records with structured four-output responses.
- Operator Collapse archetype detection logs (where relevant).

**What auditors should verify:**

- That receipts are actually being produced for all consequential decisions, not just sampled or selected ones.
- That the TriuneConsensus field contains substantive lens-specific assessments rather than templated responses.
- That the Power Rule is operating deterministically (not subject to analyst weighting that ratchets gates down).
- That Maybe fields contain actual steelmen of the case for proceeding, not nominal placeholder text.
- That release-valve challenges include the fourth output (evidence-that-would-prevent-pause) and that the fourth output is being used to calibrate the protocol.
- That drift-alarm signals trigger documented response actions, not silent acknowledgment.
- That monthly calibration sampling is actually being performed at the specified frequency with documented sample selection methodology.

**Common audit findings to watch for in PBHP-adopting organizations:**

- *Ritualization of receipt content* (the receipt schema is filled in with templated responses that don't reflect actual deliberation). The compensating evidence is the monthly calibration sampling — if the sampling identifies ritualization, the protocol is operating; if the sampling does not catch ritualization that the auditor finds, the sampling methodology needs strengthening.
- *Power Rule ratcheting* (analysts finding ways to keep gates below ORANGE despite Power-asymmetry-Yes status). The compensating evidence is the deterministic structure of the Power Rule itself; ratcheting requires the analyst to misclassify one of the structured inputs, which produces audit evidence.
- *Maybe field performance* (Maybe articulations that consistently match the operator's preferred outcome). The compensating evidence is the cross-decision pattern analysis; performance manifests as suspicious convergence.
- *Drift-alarm phrase suppression* (operators learning to avoid the specific phrases the drift-alarm catches while continuing the underlying normalization). The compensating evidence is the protocol's broader behavioral pattern analysis, which goes beyond phrase-matching.
- *Single-model Triune collapse* (the three lens assessments converge consistently because they are generated by the same model). The compensating evidence is the Tribunal Mode implementation for high-stakes decisions; auditors should verify that Tribunal Mode is being used where the deployment risk class warrants it.

These compensating-evidence patterns are what an experienced PBHP auditor looks for. The protocol's documentation specifies these patterns explicitly so that audits can be conducted against known operational signatures rather than against auditor intuition alone.

---

## 7. Limitations of This Briefing

This document is a v0.1 draft from the protocol's author. It has not been reviewed by ISO/IEC 42001 lead auditors, certification body representatives, or independent compliance consultants. The mapping claims should be evaluated by qualified auditors before being relied upon for certification preparation.

Additionally:

- The mapping reflects the author's reading of ISO/IEC 42001:2023 and PBHP v0.7.1. Future versions of either may change the mapping.
- The mapping is structurally oriented rather than legally definitive. Certification decisions are made by accredited certification bodies based on their assessment of the AIMS implementation; this document provides input to that assessment, not its conclusion.
- Specific national implementations of ISO/IEC 42001 (where applicable) may impose additional requirements not captured here.

Organizations evaluating PBHP for ISO/IEC 42001 implementation should engage their existing compliance advisors, internal auditors, and certification body representatives in addition to consulting this briefing.

---

## 8. Closing

ISO/IEC 42001 specifies what an AI Management System must address. PBHP specifies how to address the per-decision and per-deployment operational requirements at a level of structural detail that AIMS implementations typically need to develop separately. The two are complementary: ISO/IEC 42001 is the management system standard; PBHP is one possible operational layer that fits inside it.

This briefing has mapped PBHP's primitives to ISO/IEC 42001's clauses and Annex A controls, identified the operational evidence PBHP produces for audit, and noted what management-system work remains outside PBHP's scope. The mapping is intended to support compliance officers evaluating PBHP for adoption and auditors evaluating PBHP-adopting organizations.

The author welcomes engagement from ISO/IEC 42001 lead auditors, certification body representatives, and compliance officers using this document in actual certification preparation. The protocol's value is determined by how well it serves the audit and certification process; feedback from practitioners is the necessary input to making the protocol better at that service.

— Charles Phillip Linstrum
projectshadowqa@protonmail.com

---

*End of ISO/IEC 42001 implementation briefing v0.1.*