> **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 90-Day Implementation Playbook

A step-by-step guide for team leads, compliance officers, and department heads who want to pilot PBHP in their organization.

## Before You Start

**Who this is for:** Any team making consequential decisions — AI deployment teams, healthcare operations, product management, compliance, HR, or governance bodies.

**What you need:** One champion (the person reading this), 3–8 team members willing to pilot, and 90 days.

**What you do NOT need:** Budget, software, executive approval (for a pilot), or AI expertise. PBHP works with pen and paper.

## Phase 1: Weeks 1–2 — Learn and Baseline

### Week 1: Read and Internalize

The champion reads the PBHP Executive Summary (5 pages) and the CORE Protocol. Not the ULTRA — that's the reference manual, not the training manual. Time investment: ~1 hour.

Identify 3–5 recent decisions your team made that had real stakes. These are your baseline cases. You'll apply PBHP to them retrospectively in Week 2.

### Week 2: Retrospective Application

Apply PBHP-CORE to each baseline case. For each one, walk through all 7 steps and fill out a PBHP Log. Compare the PBHP recommendation to what actually happened. Document: where PBHP would have changed the outcome, where it wouldn't have, and where you're not sure.

This is calibration, not judgment. You're learning how the protocol maps to your actual decisions. Share results with the pilot team.

**Week 2 Deliverables:**
- 3–5 completed PBHP Logs (retrospective)
- A one-page summary of findings: what PBHP would have caught, what it wouldn't have, what surprised you

## Phase 2: Weeks 3–6 — Live Pilot (MIN Tier)

### Week 3: Introduce MIN to the Team

Train the pilot team on PBHP-MIN only. This is the 30-second version: Name the action. Door/Wall/Gap. Who pays if this is wrong? Can we undo it? Gate. Log.

Start applying MIN to every decision the team considers "high-stakes." Don't define high-stakes formally yet — let the team use their judgment. The point is to build the habit, not to optimize the threshold.

### Weeks 4–6: MIN in Practice

Run PBHP-MIN on every significant decision for three weeks. Keep a log. At the end of each week, review the logs as a team: How long did MIN actually take? Did it slow things down meaningfully? Did it catch anything you would have missed? Were there false positives (times it flagged something that didn't need flagging)?

**Track these metrics:**
- Number of MIN checks run per week
- Average time per check
- Number of gate assignments (how many GREEN, YELLOW, ORANGE+)
- Number of false positives (flagged by the team, not by the protocol)
- Team satisfaction (simple 1–5 scale weekly)

**Phase 2 Deliverables:**
- Weekly logs with gate distributions
- False positive count
- Team feedback notes
- Decision on whether to proceed to Phase 3

## Phase 3: Weeks 7–10 — Upgrade to CORE

### Week 7: CORE Training

Train the pilot team on PBHP-CORE. This adds: the full Door/Wall/Gap analysis, the Constraint Awareness Check ("Do I recognize the system I'm operating inside of?"), the four-dimension harm rating (Impact, Likelihood, Irreversibility, Power Asymmetry), and the Three-Force Balance (Care, Clarity, Paradox).

Apply CORE to any decision that MIN rated YELLOW or higher. GREEN decisions continue with MIN or no protocol.

### Weeks 8–10: CORE in Practice

Three weeks of CORE application on YELLOW+ decisions. Track: time per CORE evaluation, gate distributions, override rate (how often the team proceeds despite an ORANGE+ rating — this is fine if documented), drift alarm frequency, and whether CORE changed any decisions that MIN would not have.

**Phase 3 Deliverables:**
- Completed CORE logs for all YELLOW+ decisions
- Comparison: MIN-only vs. CORE outcomes
- Drift alarm report
- Recommendation: continue, adjust, or expand

## Phase 4: Weeks 11–12 — Evaluate and Decide

### Week 11: Data Review

Compile all metrics from Phases 2 and 3. Key questions to answer:

- Did PBHP catch decisions that would otherwise have resulted in harm?
- Did PBHP create meaningful delays or friction that outweighed the safety benefit?
- What was the false positive rate and is it acceptable?
- Did drift alarms trigger and were they accurate?
- Did team behavior change over the 10 weeks (normalization of the pause)?

### Week 12: Decision and Report

Write a one-page pilot report. Three possible outcomes:

**Adopt:** PBHP becomes standard operating procedure for the team. Define the formal threshold for MIN vs. CORE. Integrate into existing workflows and documentation.

**Adapt:** PBHP works but needs modification for your context. Adjust the harm threshold, the tier selection criteria, or the drift alarm list. Document the changes and why.

**Abandon:** PBHP does not provide sufficient value for this team's context. Document what didn't work and why. Share with PBHP community for protocol improvement.

**Phase 4 Deliverables:**
- Pilot report (1 page)
- Metrics summary
- Recommendation
- If adopting: integration plan for broader team/organization

## Common Failure Modes During Implementation

### 1. Starting with ULTRA

Don't. Start with MIN. Graduate to CORE. ULTRA is for precedent-setting institutional decisions. If your first encounter with PBHP is the 87,000-character ULTRA document, you will not finish it.

### 2. Applying PBHP to everything

PBHP is for consequential decisions with stakes. Don't run it on what to order for lunch. The tier system exists for a reason.

### 3. Using PBHP as a compliance checkbox

If the team starts saying "We ran PBHP, so we're covered," that is a drift alarm. PBHP is a process, not a stamp. The log is the evidence, not the badge.

### 4. Not logging

If you don't log, you can't calibrate, you can't detect drift, and you can't improve. Minimal logging (action, gate, outcome) takes 30 seconds. Do it.

### 5. Skipping the false positive valve

When PBHP flags something and the team disagrees, that is the system working. Use the valve. Challenge the pause. Document the four-part response. This is how the protocol stays alive.

## Success Metrics at 90 Days

**Green light:** Team is running MIN/CORE naturally, logging consistently, drift alarms are being noticed, and at least one decision was changed or improved by the protocol.

**Yellow light:** Team is running it but inconsistently, or logging has dropped off, or the false positive rate is causing frustration.

**Red light:** Team has stopped using it. In this case, ask: was the training adequate? Was the tier selection appropriate? Was the champion supported? Most failures are implementation failures, not protocol failures.

---

**PBHP v0.7** | Author: Charles Phillip Linstrum (ALMSIVI) | [facebook.com/plinst](https://facebook.com/plinst) | pausebeforeharmprotocol_pbhp@protonmail.com