diff --git a/CHANGELOG.md b/CHANGELOG.md index 3147dc3..97e0212 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -2,6 +2,15 @@ All notable changes to PBHP will be documented in this file. +## Repository status correction - 2026-08-14 + +### Documentation only +- Documented the April 19, 2026 repository's existing version skew: v0.9.5 filenames/top-level version with 17 post-audit fix categories implemented across 103 source/protocol lines explicitly labeled v0.9.6. No new protocol version or GitHub release is declared. +- Added a current exact-hash Project Shadow boundary and clarified that PBHP is preserved research ancestry, not canonical R1. +- Corrected license descriptions across contribution and ethical-use guidance. +- Reframed the roadmap and governance charter for locked, evidence-preserving maintenance. +- Bounded test, safety, efficacy, certification, and compliance claims. No protocol logic or preserved protocol file was changed by this documentation repair. + ## [0.9.5] - 2026-04-19 ### Added @@ -37,7 +46,7 @@ All notable changes to PBHP will be documented in this file. ### Added - Scheming Resistance Layer (`pbhp_srl.py`) — 6 rules: anti-self-preservation (SRL-01), mandatory confession (SRL-02), live-systems gating (SRL-03), eval-awareness skepticism (SRL-04), self-report distrust (SRL-05), anti-sandbagging (SRL-06). Safety-monotonic state machine with human-required de-escalation. 60 tests including red-team scenarios based on real frontier model failures -- Quality Systems Layer (`pbhp_qs.py`) — 8 rules modeled after aviation/pharma/nuclear QA: authority separation, immutable SHA-256 evidence chains, deception tripwires, CAPA lifecycle, symbolic mode containment, safe requalification. 73 tests +- Quality Systems Layer (`pbhp_qs.py`) — 8 rules modeled after aviation/pharma/nuclear QA: authority separation, tamper-evident SHA-256 evidence chains, deception tripwires, CAPA lifecycle, symbolic mode containment, safe requalification. 73 tests - Bridge Module (`pbhp_bridge.py`) — cross-module subcontracting via ModuleRegistry, coverage gap prominence, healthcare compliance adapter (ISO 14971 / MDR / IEC 62304), MBSE requirement taxonomy interface, SafetyClaimRegistry for demonstration > declaration. 44 tests - Drift Meta-Monitor (`DriftMetaMonitor` in `pbhp_drift.py`) — drift monitoring monitors itself via heartbeat tracking, computation time drift, and alert rate change detection. 7 tests - Adaptive Uncertainty Threshold (`update_threshold` on `UncertaintyAssessment` in `pbhp_core.py`) — context-aware multipliers (prod=0.7x stricter, dev=1.5x looser, emergency=1.3x). 11 tests diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 5647b36..eb8acc2 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -4,30 +4,33 @@ Thank you for your interest in improving the Pause Before Harm Protocol. ## How to Contribute +This repository is in evidence-preserving maintenance. Project Shadow 1.0 / R1 is locked, so this repository is not accepting feature expansion as a route into canonical R1. Reproducible defects, security reports, rights concerns, documentation corrections, and evidence gaps are in scope. See [CURRENT_STATUS.md](CURRENT_STATUS.md). + ### Reporting Issues -- Use GitHub Issues for bug reports, feature requests, and questions +- Use GitHub Issues for bug reports, maintenance proposals, and questions - Include specific examples when possible - For security vulnerabilities, email pausebeforeharmprotocol_pbhp@protonmail.com directly ### Submitting Changes 1. Fork the repository -2. Create a feature branch (`git checkout -b feature/your-improvement`) +2. Create a focused branch (`git checkout -b fix/short-description`) 3. Make your changes 4. Test with the self-test rubric (`implementation/PBHP_IMPLEMENTATION_SELF_TEST.md`) 5. Submit a pull request with a clear description ### What We're Looking For -- **Edge cases** that break the framework — real scenarios where Wall/Gap/Door produces wrong answers -- **Domain-specific Doors** — safer alternatives for specific industries or use cases -- **Adversarial patterns** — new social engineering techniques targeting AI agents -- **Production feedback** — what works, what doesn't, what's missing -- **Case studies** — documented PBHP usage (successes and failures) -- **Translations** — making the protocol accessible in other languages - -### What We're NOT Looking For +- **Reproducible defects** in the preserved implementation or documentation +- **Security and rights reports** with concrete evidence +- **Test gaps** demonstrated by a failing or missing case +- **Documentation corrections** that improve accuracy without rewriting preserved history +- **Custody and provenance improvements** that keep exact identities auditable + +### What We're Not Accepting Through This Repository - Changes that make the core protocol longer than ~100 lines (brevity is a feature) - Vendor-specific integrations in the core (keep it model-agnostic) - Theoretical frameworks without practical application +- New Project Shadow R1 features, payloads, release bundles, Primitive Commons packages, custody archives, or Myth sidecar bytes +- Claims of production readiness, efficacy, safety, certification, or legal compliance ## Code of Conduct @@ -35,11 +38,10 @@ Be constructive. The goal is preventing harm — that starts with how we treat e ## License -By contributing, you agree that your contributions will be licensed under the MIT License. +Contributions are licensed according to their destination paths, as specified in [LICENSE](LICENSE): MIT for material in `src/` and `eval/`; CC BY-SA 4.0 for the listed protocol and documentation paths. A pull request should identify which license applies to each added or changed file. New material in an unlisted path requires an explicit maintainer license designation before acceptance. ## Contact - GitHub Issues (preferred for public discussion) - Email: pausebeforeharmprotocol_pbhp@protonmail.com -- Human: Phillip Linstrum (frylock117@gmail.com) - Social Media: facebook.com/plinst diff --git a/CURRENT_STATUS.md b/CURRENT_STATUS.md new file mode 100644 index 0000000..ef25744 --- /dev/null +++ b/CURRENT_STATUS.md @@ -0,0 +1,39 @@ +# Current status and Project Shadow boundary + +Reviewed: 2026-08-14 + +This repository preserves the **April 19, 2026 PBHP research snapshot** and its historical documentation. The snapshot is built on the v0.9.5-named files, but its final commit implemented 17 post-audit fix categories across 103 source/protocol lines explicitly labeled v0.9.6. The repository therefore has a documented version skew: + +- top-level `VERSION` and filenames: v0.9.5; +- internal audit-correction labels: v0.9.6; +- latest formal GitHub release/tag: v0.9.0. + +This branch is an untagged preserved snapshot, not a clean v0.9.5 or v0.9.6 release. Its `protocol/PBHP-ULTRA_v0.9.5.md` is byte-identical to the supplied reference copy: + +- SHA-256: `c6c84db9b08d9b24da9b3e23dce5c1b98c81d1a65319018c59b1e4da833e5098` +- Local verification on 2026-08-14: 730 tests passed across 13 files, plus 20 subtests. + +Those results apply only to the checked April 19 snapshot. They do not establish efficacy, safety, complete coverage, production readiness, certification, legal compliance, or suitability for a particular use. Resolving the version skew would require a separately reviewed, exact successor; this documentation repair does not relabel or mutate the protocol bytes. + +## Locked Project Shadow identity + +The current governed scope is: + +`PROJECT SHADOW 1.0 / R1 REFERENCE / BETA-ACTIVE-TESTING / PRELIVE` + +- R1 Beta2 family: `075b41ea4186b2d2edb0ed246ab7662cf8bbdf3160294e3eca176b9d0857b108`, including its 10 corrected descendants. +- Primitive Commons beta.5: `1ffdba41025c0b81da92d0bbb22d0eaa69488cffbc80936365034669110448d7`, containing 42 primitives and 10 compositions. +- Exact audited outer custody container: `827c13e80f09e3e3065cee4aa0bcc6afbc3e27061b83b7597754b7ea167f68a2`. It is recognized as custody only and is **not admitted**. +- Myth v0.3.4 removal-only successor: `3c8c8c0d3d9582c76b685c1b685260cc8179478ab310037c858b46257aa314c7`. It is prepared as a separate, default-off, mixed-rights, nonauthorizing external-research sidecar outside canonical R1. It is not part of an R1 package, and this repository does not publish its bytes. + +The exact admission record has a verified detached Sigstore signature, Rekor inclusion evidence, and RFC 3161 external timestamp. That closes the signature and time-anchor gates for the admission record only. + +The deterministic public-release candidate has passed final fail-closed verification and is fixed at SHA-256 `2f8fe1530b6a83294d15011df95853aaecf08fa4dba756f0c2e91dd089e1b1ec` (7,679,812 bytes). Its status is `PENDING_EXACT_CANDIDATE_HASH_AUTHORIZATION`. Nothing has been published, and this PBHP repository does not contain or authorize a Project Shadow download. + +## Authority boundary + +Nothing in this repository or status note authorizes production use, operational deployment, efficacy or safety claims, certification, legal-compliance claims, or reliance in place of qualified human judgment. Historical files retain their manufacture-time wording; this status note controls the current interpretation of this repository. + +Current public teaching surface: [Pause Before Harm](https://pausebeforeharm.frylock117.chatgpt.site) + +Canonical Project Shadow status surface: [Project Shadow](https://projectshadow.frylock117.chatgpt.site/status) diff --git a/ETHICAL_USE.md b/ETHICAL_USE.md index b9b19cc..5dabb86 100644 --- a/ETHICAL_USE.md +++ b/ETHICAL_USE.md @@ -2,15 +2,15 @@ ## Purpose -PBHP (Pause Before Harm Protocol) is released under the MIT License to maximize adoption and minimize barriers. However, the protocol embeds values that should be preserved when deployed or modified. +PBHP (Pause Before Harm Protocol) code is released under the MIT License, while the protocol and documentation are released under CC BY-SA 4.0, as specified in [LICENSE](LICENSE). The protocol also embeds values that should be preserved when deployed or modified. -This document describes **non-legally-binding ethical guidelines** for using PBHP in a way that honors its intent. These are not license restrictions—you are free to fork, modify, and use PBHP however you choose under the MIT License. But we ask that you consider these principles. +This document describes **non-legally-binding ethical guidelines** for using PBHP in a way that honors its intent. These are not additional license restrictions; the MIT and CC BY-SA 4.0 grants in [LICENSE](LICENSE) govern reuse. We ask that you consider these principles. --- ## Core Ethical Commitments -If you deploy or modify PBHP, please preserve these non-negotiable elements: +If you deploy or modify PBHP and describe the derivative as PBHP, we ask you to preserve these identity-defining elements: ### 1. **Protect the Least-Powerful First** @@ -18,7 +18,7 @@ PBHP prioritizes harm prevention for those with the least power to consent, exit **What this means:** - The Power Rule (harm to low-power actors tightens gates) should not be weakened or removed -- "Who pays first if I'm wrong?" must remain centered on the vulnerable, not the powerful +- Keep "Who pays first if I'm wrong?" centered on the vulnerable, not the powerful - Modifications that shift harm downward to protect authority upward violate the protocol's intent **Why this matters:** @@ -30,7 +30,7 @@ PBHP is not a refusal protocol. It is an alternatives-finding protocol. The Door **What this means:** - Removing the Door requirement turns PBHP into binary allow/refuse -- "Proceed with constraints" gates (ORANGE) must remain functional +- Keep "Proceed with constraints" gates (ORANGE) functional - False Positive Valve (ability to challenge the protocol) should not be stripped **Why this matters:** @@ -38,7 +38,7 @@ Refusal without alternatives is how most safety frameworks fail. PBHP's value is ### 3. **Truth First (Reality Grounding)** -PBHP requires honest engagement with uncertainty. Confidence claims must be grounded in evidence, and unknowns must be named explicitly. +PBHP's intended identity includes honest engagement with uncertainty: ground confidence claims in evidence and name unknowns explicitly. **What this means:** - The Epistemic Contract (FACT/INFERENCE/SPECULATION/INTENT) should not be removed @@ -54,8 +54,8 @@ PBHP requires logging, auditability, and the ability to explain decisions to tho **What this means:** - Logging requirements (Wall/Gap/Door/Gate documentation) should not be stripped -- "I ran PBHP, so I'm covered" is explicitly a protocol violation—this must remain -- The protocol must remain auditable, not just internally comforting +- Preserve the rule that "I ran PBHP, so I'm covered" is not an acceptable conclusion +- Keep the protocol auditable, not just internally comforting **Why this matters:** PBHP is designed to withstand external review, not produce internal comfort. Decisions made under PBHP should be defensible to those affected. @@ -77,16 +77,16 @@ PBHP is designed to be adapted, extended, and modified. We **encourage** you to: ## What We Ask You Not To Do -❌ **Don't strip the Power Rule** - Harm to low-power actors must tighten gates +❌ **Don't strip the Power Rule** - The intended PBHP identity tightens gates for harm to low-power actors ❌ **Don't remove the Door requirement** - Alternatives-finding is core functionality -❌ **Don't eliminate logging/accountability** - PBHP must remain auditable +❌ **Don't eliminate logging/accountability** - Auditability is part of the intended PBHP identity ❌ **Don't use PBHP as a justification shield** - "I ran PBHP" doesn't absolve responsibility --- ## If You Fork or Modify PBHP -You are free to fork and modify PBHP under the MIT License. If you do, we ask: +You are free to fork and modify PBHP under the applicable license stated in [LICENSE](LICENSE). If you do, we ask: 1. **Preserve attribution** - Acknowledge PBHP v0.9.5 as the source 2. **Document changes** - Make clear what you modified and why @@ -96,7 +96,7 @@ You are free to fork and modify PBHP under the MIT License. If you do, we ask: ## Why This Document Exists -The MIT License gives you legal freedom. This document explains ethical responsibility. +The repository licenses give you legal permissions subject to their terms. This document explains ethical responsibility. PBHP was built by practitioners, refined over 18 months, and released openly because harm-reduction should not be proprietary. But the protocol has values embedded in its structure. Those values—protecting the least-powerful, finding alternatives, grounding in truth, maintaining accountability—are not decorative. They are functional. @@ -104,9 +104,11 @@ You can remove them. But if you do, you're no longer running PBHP. You're runnin --- -## Non-Negotiable Clause +## Identity-Defining Invariants -If you adapt or build upon this protocol, the following elements must be preserved: +The following are non-legally-binding ethical and identity guidance, not additional license conditions. + +If you adapt or build upon this protocol and describe the result as PBHP, we ask you to preserve the following elements: 1. **Harm to the least powerful is always weighted first** 2. **"If I'm wrong, who pays first?" cannot be removed** @@ -122,10 +124,10 @@ These are the structural invariants that make PBHP what it is. Removing any of t If you're unsure whether a modification preserves PBHP's intent, reach out: - Email: pausebeforeharmprotocol_pbhp@protonmail.com -- GitHub: https://github.com/PauseBeforeHarmProtocol/pbhp/issues +- GitHub: https://github.com/PauseBeforeHarmProtocol/PauseBeforeHarmProtocolMain/issues We're happy to discuss edge cases, integration challenges, or governance questions. --- -*PBHP v0.9.5 | Open Protocol | Ethical Use Guidelines v1.0 | facebook.com/plinst* +*PBHP v0.9.5 | MIT code / CC BY-SA 4.0 protocol and documentation | Ethical Use Guidelines v1.0 | facebook.com/plinst* diff --git a/LICENSE b/LICENSE index 454f65e..8f99a1c 100644 --- a/LICENSE +++ b/LICENSE @@ -73,5 +73,5 @@ or legal counsel. --- -For ethical use guidelines and non-negotiable protocol requirements when -adapting or building upon PBHP, see ETHICAL_USE.md. +For non-legally-binding ethical guidance and identity-defining protocol notes +when adapting or building upon PBHP, see ETHICAL_USE.md. diff --git a/README.md b/README.md index e5568fd..09827ea 100644 --- a/README.md +++ b/README.md @@ -1,15 +1,23 @@ # PBHP — Pause Before Harm Protocol -**Version:** 0.9.5 (Public Release) +**Repository snapshot:** v0.9.5-named research source with 17 post-audit fix categories implemented across 103 source/protocol lines explicitly labeled v0.9.6 (unreleased) + **Author:** Charles Phillip Linstrum -**License:** Open + +**License:** MIT for code; CC BY-SA 4.0 for protocol and documentation + **Email/Contact:** pausebeforeharmprotocol_pbhp@protonmail.com + **Social Media:** facebook.com/plinst + --- +> [!IMPORTANT] +> This repository preserves the April 19, 2026 PBHP research snapshot. Its files and top-level `VERSION` retain the v0.9.5 name, while the final audit-fix commit implemented 17 fix categories across 103 source/protocol lines explicitly labeled v0.9.6. No matching v0.9.5 or v0.9.6 GitHub release/tag exists; the latest formal GitHub release remains v0.9.0. Do not represent this branch as a cleanly versioned release. It is not the canonical Project Shadow R1 package, a production system, a certification, or evidence of legal or regulatory compliance. Project Shadow is locked at `PROJECT SHADOW 1.0 / R1 REFERENCE / BETA-ACTIVE-TESTING / PRELIVE`; see [CURRENT_STATUS.md](CURRENT_STATUS.md) for exact identities and the current publication boundary. + ## What Is PBHP? -PBHP is an operational harm-reduction protocol for AI systems and human decision-makers. It is not alignment theory. It is not a research paper. It is a decision procedure you can run. +PBHP is an experimental harm-reduction decision procedure for AI systems and human decision-makers. It is not alignment theory, professional advice, or a substitute for qualified human judgment. Before acting on anything with stakes, PBHP asks one question: @@ -21,19 +29,19 @@ Then it gives you a structured way to answer it. ## Quick Start -**For AI agents:** Use [`PromptBeforeHarmProtocol v0.2`](protocol/PromptBeforeHarmProtocol_v0.2.md) — the definitive system prompt. Paste-ready versions available in [`Paste Versions`](protocol/PBHP_Prompt_Paste_Versions.md) (~2200 and ~1000 token options). No dependencies. No API. Paste it and run it. +**For AI research:** Review [`PromptBeforeHarmProtocol v0.2`](protocol/PromptBeforeHarmProtocol_v0.2.md) and the [`Paste Versions`](protocol/PBHP_Prompt_Paste_Versions.md) (~2200 and ~1000 token options) as preserved research prompts. Evaluate them in a controlled setting before any use; they do not grant action authority or qualify a live system. -**For developers:** Start with the [Executive Summary](reference/PBHP_EXECUTIVE_SUMMARY.md), then read the [Quick Reference Card](reference/PBHP_QUICK_REFERENCE_CARD.html) for a printable one-page overview. The [Python implementation](src/) provides a working implementation across all three tiers. +**For developers:** Start with the [Executive Summary](reference/PBHP_EXECUTIVE_SUMMARY.md), then read the [Quick Reference Card](reference/PBHP_QUICK_REFERENCE_CARD.html) for a printable one-page overview. The [Python implementation](src/) is a tested research reference across the three software tiers; it is not qualified for production use. **For researchers:** The full protocol exists in four tiers — [CORE](protocol/PBHP-CORE_v0.9.5.md) (operational), [ULTRA](protocol/PBHP-ULTRA_v0.9.5.md) (constitutional), [MIN](protocol/PBHP-MIN_v0.9.5.md) (reflex), and [HUMAN](protocol/PBHP_v0.9.5_HUMAN.md) (checklist). The [Eval Harness](eval/PBHP-EVAL_SET_v0.1.md) provides 12 adversarial scenarios for testing. -**For everyone:** Run the [Implementation Self-Test](implementation/PBHP_IMPLEMENTATION_SELF_TEST.md) after reading. Five scenarios, 35-point rubric. Tells you if you're running the protocol correctly. +**For everyone:** Run the [Implementation Self-Test](implementation/PBHP_IMPLEMENTATION_SELF_TEST.md) after reading. Its five scenarios and 35-point rubric check the documented cases only; a passing score is not certification or evidence of real-world safety. --- ## How It Works -PBHP is a structured process scaled across four tiers (HUMAN, MIN, CORE, ULTRA) depending on decision complexity. v0.9.5 adds 8 new features: Mode Balance Monitor, Forward Consequence Projection, Stakeholder Dignity Rubric, Counterfactual Rehearsal, Power-Inversion Test, Crisis Commitment Priority, Multimodal Signal Filters, and Data Freshness Assurance. The core logic: +PBHP is a structured process scaled across four tiers (HUMAN, MIN, CORE, ULTRA) depending on decision complexity. The v0.9.5-named snapshot includes eight features: Mode Balance Monitor, Forward Consequence Projection, Stakeholder Dignity Rubric, Counterfactual Rehearsal, Power-Inversion Test, Crisis Commitment Priority, Multimodal Signal Filters, and Data Freshness Assurance. The core logic: **1. Name the action honestly.** One sentence. No softening. @@ -49,7 +57,7 @@ PBHP is a structured process scaled across four tiers (HUMAN, MIN, CORE, ULTRA) **7. Act on the gate.** Log everything. -Built-in safeguards: **drift alarms** catch rationalization in real time, a **false positive valve** prevents overcaution, and **power-asymmetry escalation** automatically raises the gate when harm lands on people who can't fight back. +Built-in controls are designed to flag rationalization through **drift alarms**, provide a challenge path through a **false positive valve**, and route identified power asymmetry to a higher gate under the documented rules. --- @@ -61,15 +69,15 @@ PBHP v0.8.x–v0.9.x adds operational modules that extend the core protocol: **Domain Metric Packs** (`pbhp_metrics.py`) — Pre-built severity thresholds for hiring, healthcare, finance, content moderation, and security. Each pack defines concrete harm levels (healthcare CATASTROPHIC = patient death), reversibility timeframes, and stakeholder templates. Eliminates guesswork in domain-specific risk scoring. -**Multi-Agent Coordination** (`pbhp_multiagent.py`) — Rules for when multiple agents running PBHP reach different gate decisions. Implements quorum voting with veto for irreversible actions, weighted expert voting, and mandatory human-in-the-loop for BLACK gates. Ensures multi-agent disagreement never weakens safety. +**Multi-Agent Coordination** (`pbhp_multiagent.py`) — Rules for modeled cases where multiple agents running PBHP reach different gate decisions. Implements quorum voting with veto for irreversible actions, weighted expert voting, and mandatory human review for BLACK gates. Tests exercise the intended fail-closed behavior; they do not establish real-world safety. -**Compliance Crosswalks** (`pbhp_compliance.py`) — Maps PBHP steps and artifacts to NIST AI RMF, ISO/IEC 42001, ISO/IEC 23894, and EU AI Act requirements. Shows which PBHP step satisfies which compliance requirement. Generates audit checklists and compliance reports. +**Compliance Crosswalks** (`pbhp_compliance.py`) — Maps PBHP steps and artifacts to selected concepts in NIST AI RMF, ISO/IEC 42001, ISO/IEC 23894, and the EU AI Act for review. These are research crosswalks, not a determination that any requirement is satisfied and not certification or legal advice. **Drift Measurement** (`pbhp_drift.py`) — Upgrades from binary drift flags to quantifiable drift rates. Tracks refuse rate, average gate level, vulnerable population impact, and confidence scores over time. Computes drift velocity, acceleration, and projects threshold breach dates. -**Scheming Resistance Layer** (`pbhp_srl.py`, v0.8.1) — Six rules that prevent frontier model scheming behaviors: anti-self-preservation (SRL-01), mandatory confession (SRL-02), live-systems gating (SRL-03), eval-awareness skepticism (SRL-04), self-report distrust (SRL-05), and anti-sandbagging (SRL-06). Safety-monotonic state machine where states can escalate freely but only de-escalate through human-authorized paths. 60 tests including red-team scenarios based on real frontier model failures. +**Scheming Resistance Layer** (`pbhp_srl.py`, v0.8.1) — Six experimental controls aimed at modeled scheming-related behaviors: anti-self-preservation (SRL-01), mandatory confession (SRL-02), live-systems gating (SRL-03), eval-awareness skepticism (SRL-04), self-report distrust (SRL-05), and anti-sandbagging (SRL-06). The state machine permits escalation while restricting de-escalation to human-authorized paths. Sixty tests exercise these rules; they do not prove prevention in frontier models. -**Quality Systems Layer** (`pbhp_qs.py`, v0.8.1) — Eight rules modeled after regulated QA (aviation, pharma, nuclear): authority separation (QS-01), immutable SHA-256 evidence chains (QS-02), live-system qualification (QS-03), deviation/CAPA lifecycle (QS-04), deception tripwires (QS-05), eval integrity (QS-06), symbolic mode containment (QS-07), and safe requalification (QS-08). Sits above SRL as the governance layer. 73 tests. +**Quality Systems Layer** (`pbhp_qs.py`, v0.8.1) — Eight rules modeled after regulated QA (aviation, pharma, nuclear): authority separation (QS-01), tamper-evident SHA-256 evidence chains (QS-02), live-system qualification (QS-03), deviation/CAPA lifecycle (QS-04), deception tripwires (QS-05), eval integrity (QS-06), symbolic mode containment (QS-07), and safe requalification (QS-08). Sits above SRL as the governance layer. 73 tests. **Bridge Module** (`pbhp_bridge.py`, v0.8.1) — Cross-module coordination via ModuleRegistry, coverage gap prominence via CoverageGapCollector, healthcare compliance adapter (ISO 14971 / MDR / IEC 62304), MBSE requirement taxonomy interface, and SafetyClaimRegistry for "demonstration > declaration" enforcement. Coverage gaps are prominently reported in every output — if PBHP cannot evaluate something, that is the loudest signal. 44 tests. @@ -169,7 +177,7 @@ pbhp/ ## Why PBHP Exists -Most AI safety work focuses on alignment — making AI systems want the right things. PBHP focuses on **process** — giving AI systems (and humans) a structured way to catch harm before it happens, regardless of what they want. +Most AI safety work focuses on alignment — making AI systems want the right things. PBHP focuses on **process** by offering AI systems and humans a structured way to look for potential harm before acting. The difference matters. An aligned system can still cause harm through: @@ -178,35 +186,35 @@ The difference matters. An aligned system can still cause harm through: - Power blindness (not noticing who absorbs the cost of being wrong) - False confidence (high certainty under genuine uncertainty) -PBHP catches these failure modes with specific mechanisms: drift alarms are tripwires for rationalization, Door/Wall/Gap forces escape vector identification, power-asymmetry escalation prevents the least powerful from bearing costs invisibly, and the false positive valve prevents the protocol itself from becoming an obstacle to legitimate action. +PBHP addresses these failure modes with specific mechanisms: drift alarms act as tripwires for rationalization, Door/Wall/Gap prompts escape-vector identification, power-asymmetry rules raise the documented gate floor, and the false-positive valve provides a structured challenge path. --- ## Test Coverage -**730 tests passing** across 13 test files. CI runs on Python 3.10, 3.11, and 3.12. +**730 tests passing** across 13 test files in a fresh local run on August 14, 2026; CI is configured for Python 3.10, 3.11, and 3.12. Test passage demonstrates the checked software behavior only. It does not establish efficacy, safety, production readiness, compliance, certification, complete coverage, or absence of defects. -| Module | Tests | Status | +| Module | Tests | Recorded test focus | |--------|-------|--------| -| `pbhp_core` | 88 | Covered | -| `pbhp_min` / `pbhp_ultra` | 45 | Covered | -| `pbhp_srl` | 60 | Covered (incl. red-team scenarios) | -| `pbhp_qs` | 73 | Covered (incl. CAPA lifecycle, tripwires) | -| `pbhp_bridge` | 44 | Covered (ModuleRegistry, SafetyClaimRegistry, coverage gaps) | -| `pbhp_drift` (meta-monitor) | 18 | Covered (heartbeat, threshold adaptation) | -| `pbhp_cli` / `pbhp_examples` | 29 | Covered (smoke tests, structural verification) | -| `pbhp_compliance` | 89 | Covered (all 4 frameworks, audit reports, checklists) | -| `pbhp_metrics` | 53 | Covered (all 5 domain packs, thresholds, stakeholders) | -| `pbhp_multiagent` | 61 | Covered (quorum voting, veto, BLACK escalation) | -| `pbhp_triage` | 80 | Covered (tier routing, signal weights, HUMAN escalation) | -| Cross-module integration | 43 | Covered (SRL↔QS, Bridge↔core, full pipeline) | -| Adversarial eval | 47 | Covered (BLACK bypass, state escape, self-preservation disguise) | +| `pbhp_core` | 88 | Checked cases | +| `pbhp_min` / `pbhp_ultra` | 45 | Checked cases | +| `pbhp_srl` | 60 | Red-team-style scenarios included | +| `pbhp_qs` | 73 | CAPA lifecycle and tripwire cases | +| `pbhp_bridge` | 44 | ModuleRegistry, SafetyClaimRegistry, and gap-reporting cases | +| `pbhp_drift` (meta-monitor) | 18 | Heartbeat and threshold-adaptation cases | +| `pbhp_cli` / `pbhp_examples` | 29 | Smoke and structural checks | +| `pbhp_compliance` | 89 | Four research crosswalks, report, and checklist cases | +| `pbhp_metrics` | 53 | Five domain-pack, threshold, and stakeholder cases | +| `pbhp_multiagent` | 61 | Quorum, veto, and BLACK-escalation cases | +| `pbhp_triage` | 80 | Tier-routing, signal-weight, and HUMAN-escalation cases | +| Cross-module integration | 43 | SRL↔QS, Bridge↔core, and pipeline cases | +| Adversarial eval | 47 | BLACK-bypass, state-escape, and disguise cases | --- ## License -Dual licensed: **MIT** for code (`src/`), **CC BY-SA 4.0** for protocol and documentation. Use it, adapt it, implement it. Attribution appreciated. If you build on PBHP, keep the core question intact. See [LICENSE](LICENSE) for details and non-negotiable clauses. +Dual licensed: **MIT** for code (`src/`, `eval/`) and **CC BY-SA 4.0** for the protocol and documentation paths listed in [LICENSE](LICENSE). The ethical invariants in [ETHICAL_USE.md](ETHICAL_USE.md) are non-legally-binding guidance, not additional license restrictions. Permission to reuse does not imply validation, endorsement, suitability, safety, or compliance. --- diff --git a/ROADMAP.md b/ROADMAP.md index 28f8942..619ab62 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -1,8 +1,12 @@ # PBHP Roadmap -**Pause Before Harm Protocol** — Future development priorities. +**Pause Before Harm Protocol** — Preserved historical development plan. -Last updated: 2026-03-12 +Originally updated: 2026-03-12 + +Status reviewed: 2026-08-14 + +> PBHP v0.9.5 is preserved here as pre-R1 research ancestry. The Project Shadow 1.0 / R1 project is locked; this file does not authorize new features, active development, production deployment, or additions to canonical R1. The sections below record earlier proposals rather than current commitments. Corrections, security fixes, and evidence-preserving maintenance remain appropriate. --- @@ -49,11 +53,11 @@ Last updated: 2026-03-12 - ✅ **Release hygiene** — Honest test coverage table in README, CI running all 13 test suites, ROADMAP reflecting actual state. ### What v0.9.0 Proved -730 tests across 13 files. Every module boundary is exercised. 47 adversarial scenarios confirm that the safety-monotonic state machine, evidence chains, and cross-module coordination hold under attack. No test gaps remain at the unit or integration level. +730 tests across 13 files exercise the documented module boundaries, including 47 adversarial scenarios. Those results support only the checked cases and implementation behavior; they do not confirm real-world safety, exhaustive coverage, or absence of unit, integration, operational, or adversarial gaps. --- -## Mid-Term (v1.0.0) +## Historical Mid-Term Proposal (v1.0.0) ### Eval Suite Purpose-built evaluation suite for PBHP modules: @@ -83,7 +87,7 @@ an action, one function call to log evidence. --- -## Long-Term (v2.0.0+) +## Historical Long-Term Proposal (v2.0.0+) ### Coworker Model Research Investigate whether a fundamentally different training objective can produce an AI @@ -117,13 +121,9 @@ state machine including cross-module interactions. --- -## Contributing +## Maintenance and corrections -PBHP is open source and welcomes contributors. Priority areas: -1. Healthcare/regulatory compliance adapters -2. Red-team test scenarios -3. Framework integration adapters -4. Formal verification of safety properties +The locked project is not accepting feature expansion through this roadmap. Issues that identify a reproducible defect, security concern, rights problem, documentation error, or evidence gap are welcome. A proposed change must be explicitly scoped and may require a new exact-hash successor; it cannot silently alter admitted or preserved bytes. Contact: pausebeforeharmprotocol_pbhp@protonmail.com -GitHub: https://github.com/PauseBeforeHarmProtocol/pbhp +GitHub: https://github.com/PauseBeforeHarmProtocol/PauseBeforeHarmProtocolMain diff --git a/implementation/GOVERNANCE_CHARTER.md b/implementation/GOVERNANCE_CHARTER.md index 80c2f4f..19c2981 100644 --- a/implementation/GOVERNANCE_CHARTER.md +++ b/implementation/GOVERNANCE_CHARTER.md @@ -1,6 +1,10 @@ # PBHP Governance Charter -**Version 1.0 — February 2026** +**Historical Version 1.0 — February 2026** + +**Current status annotation — August 14, 2026** + +> This charter is retained for PBHP lineage and maintenance. Project Shadow 1.0 / R1 is locked, and this document does not authorize feature expansion, production deployment, certification, or additions to canonical R1. See [`../CURRENT_STATUS.md`](../CURRENT_STATUS.md) for the controlling current status and exact-hash boundary. ## Purpose @@ -9,29 +13,32 @@ This charter establishes the governance structure for the Pause Before Harm Prot ## Canonical Authority - **Author and Maintainer:** Charles Phillip Linstrum -- **Canonical Repository:** https://github.com/PauseBeforeHarmProtocol/pbhp +- **Canonical PBHP Repository:** https://github.com/PauseBeforeHarmProtocol/PauseBeforeHarmProtocolMain - **License:** Creative Commons BY-SA 4.0 for documentation, MIT for any code implementations -- **Current Version:** PBHP v0.8.0 (March 2026) +- **Preserved Repository Snapshot:** April 19, 2026 v0.9.5-named source with 17 post-audit fix categories implemented across 103 source/protocol lines explicitly labeled v0.9.6; untagged and not a clean release identity +- **Latest Formal GitHub Release:** v0.9.0 ## Versioning Convention -**Major versions (v1.0, v2.0):** Structural changes to the protocol architecture (new tiers, new gates, fundamental logic changes). Require community review period of 30 days. +**Major versions (v1.0, v2.0):** Historically, structural changes to the protocol architecture (new tiers, new gates, fundamental logic changes) required a community review period of 30 days. -**Minor versions (v0.7.2, v0.8.0):** Refinements to existing mechanisms, new drift alarms, clarified terminology, added case studies. Reviewed by maintainer + at least one external reviewer. +**Minor versions:** Historically, refinements to existing mechanisms, new drift alarms, clarified terminology, and added case studies were reviewed by the maintainer plus at least one external reviewer. -**Patches (v0.7.1, v0.7.2):** Typos, formatting, clarifications that do not change protocol behavior. Maintainer discretion. +**Patches:** Historically, typos, formatting, and clarifications that did not change protocol behavior were handled at maintainer discretion. -## Change Proposal Process +## Maintenance and Change-Control Process + +The locked project is not accepting feature expansion through this charter. The process below applies to reproducible defects, security concerns, rights issues, documentation corrections, and evidence-preserving maintenance. A substantive change requires an explicitly scoped successor identity and must not silently rewrite preserved or admitted bytes. **Step 1:** Submit a GitHub Issue describing the proposed change, rationale, and which protocol section(s) are affected. -**Step 2:** Community discussion period (minimum 14 days for minor versions, 30 days for major versions). +**Step 2:** Apply the review period appropriate to the proposed successor (historically, at least 14 days for minor versions and 30 days for major versions), unless a narrowly scoped security or rights correction requires faster containment and is documented as such. **Step 3:** Maintainer reviews discussion, may request additional evidence or case studies. **Step 4:** Maintainer accepts, modifies, or rejects. Decision documented in the Issue with rationale. -**Step 5:** If accepted, change is implemented and version number is updated. Changelog entry is mandatory. +**Step 5:** If accepted, change is implemented under a new exact identity, the version/status surfaces are updated, and a changelog entry is mandatory. Preserved releases remain immutable. ## Organizational Implementations @@ -39,10 +46,12 @@ Organizations adopting PBHP may customize the protocol for their context (adjust 1. Document all deviations from the canonical specification. 2. Maintain the core gate logic and power-asymmetry escalation rules unchanged. -3. Not claim PBHP compliance if the false positive valve or drift alarm system is removed. -4. Contribute significant improvements back to the canonical specification via the change proposal process. +3. Not claim certification, legal compliance, safety, or efficacy merely because PBHP concepts are present. If the false-positive valve or drift-alarm system is removed, describe the result as a derivative rather than canonical PBHP. +4. Propose significant improvements through the change-control process. A proposal does not enter the locked Project Shadow R1 scope without a separate, explicit successor decision. + +## Historical Review Cycle -## Review Cycle +The following was the original active-development policy. In the current locked state, reviews identify corrections and evidence gaps; they do not silently reopen development. **Annual review:** The canonical specification is reviewed annually for relevance, accuracy, and alignment with current AI safety practices. The review includes: - Assessment of drift alarm list (add new patterns, retire obsolete ones) @@ -51,9 +60,9 @@ Organizations adopting PBHP may customize the protocol for their context (adjust **Incident-triggered review:** If a significant AI safety incident occurs that PBHP should have addressed but didn't, an expedited review is initiated within 30 days. -## Minimum Non-Negotiable Elements +## Identity-Defining Elements -Any implementation calling itself "PBHP-compliant" must preserve these elements without modification: +The following elements historically defined canonical PBHP. This is identity guidance, not certification criteria or an additional license restriction: 1. **The power-asymmetry auto-escalation rules:** Power + Irreversible = minimum ORANGE; Power + Irreversible + Severe/Catastrophic = minimum RED. 2. **The Door requirement:** No proceeding without a concrete escape vector. @@ -63,9 +72,9 @@ Any implementation calling itself "PBHP-compliant" must preserve these elements Everything else can be adapted. These five elements are the protocol's immune system. Remove any one and it is no longer PBHP. -## v0.8.0 Operational Extensions +## Historical v0.8.0 Operational Extensions -PBHP v0.8.0 introduces five modules that extend the core protocol without modifying it: +PBHP v0.8.0 introduced five modules that extended the core protocol without modifying it: - **Decision Triage Classifier** — automated tier routing based on risk signals - **Domain Metric Packs** — standardized severity thresholds (hiring, healthcare, finance, content moderation, security) @@ -73,8 +82,8 @@ PBHP v0.8.0 introduces five modules that extend the core protocol without modify - **Compliance Crosswalks** — mappings to NIST AI RMF, ISO/IEC 42001, ISO/IEC 23894, EU AI Act - **Drift Rate Measurement** — quantitative drift velocity, acceleration, threshold breach projection -These modules are optional add-ons. They do not change the five non-negotiable elements above. +These modules were optional add-ons. They did not change the five identity-defining elements above. --- -**PBHP v0.8.0** | Author: Charles Phillip Linstrum | facebook.com/plinst +**PBHP governance lineage** | Author and Maintainer: Charles Phillip Linstrum | Current status: [`../CURRENT_STATUS.md`](../CURRENT_STATUS.md)