GOPEL: The Code Behind the Policy

How a Non-Cognitive Governance Agent Went from Specification to Working Software, and Why the Claim That AI Governance Infrastructure Cannot Be Built Is No Longer Defensible

This article serves as the proof-of-concept record for the AI Provider Plurality Congressional Package. The repository is public at github.com/basilpuglisi/HAIA under Creative Commons Attribution-NonCommercial 4.0 International license.

The Agent Code for GOPEL is here: https://github.com/basilpuglisi/HAIA/tree/main/haia_agent

The Claim That Required Testing

The AI governance conversation has a recurring pattern. Specifications get written. Principles get endorsed. Frameworks get announced. Patent applications get filed. And the conversation stays exactly where it started: theoretical. The persistent claim, sometimes stated and sometimes implied, is that governance infrastructure for multi-AI systems is too complex to build, too fragile to trust, or too early to fund. The conversation defaults to waiting.

The AI Provider Plurality Congressional Package proposes that the United States government build GOPEL (Governance Orchestrator Policy Enforcement Layer) as national AI infrastructure. The specification describes an agent that performs seven deterministic operations and no others: dispatch, collect, route, log, pause, hash, and report. The agent performs zero cognitive work. The security rationale is that if the agent cannot evaluate content, it cannot be manipulated through adversarial inputs, prompt injection, or model poisoning.

That is one proposed path. Others may emerge. But the question that matters right now is not whether this specific architecture is the final answer. The question is whether governance infrastructure of this kind can be built at all. If the answer is yes, then the conversation about how to move forward can proceed on evidence. If the answer is no, then the waiting is justified.

So it was built.

GOPEL v0.6.1 is a working reference implementation of the governance architecture described in the Congressional Package. It runs. It passes 183 tests across nine test suites. Seven independent AI platforms reviewed the code adversarially, each with no visibility into what the others found. Every critical and high-severity implementation vulnerability they identified has been fixed and verified. Architectural limitations inherent to deterministic systems are documented separately and cannot be resolved through code changes. The non-cognitive constraint holds across all 14 source modules.

This is not a claim that GOPEL is the solution. This is evidence that solutions are buildable, testable, and verifiable. The claim that governance infrastructure cannot be built is no longer defensible. The question shifts from whether to when and how.

This article documents what was built, why each piece exists, how seven AI platforms tried to break it, what they found, and what remains open. The repository is public. The code is the argument.

Why Non-Cognitive Design Is a Security Architecture Decision

Every AI governance framework in the current market puts a cognitive system between the human and the AI platforms being governed. The orchestration layer evaluates responses, ranks them, filters content, or makes routing decisions based on semantic understanding. This creates an attack surface that grows with the capability of the systems being governed. A sufficiently advanced AI platform can manipulate any cognitive intermediary because the intermediary must, by design, process and respond to the content passing through it.

GOPEL eliminates this attack surface by refusing to understand anything. The framework copies a prompt string identically to multiple platform endpoints. It collects responses as opaque payloads. It verifies transport integrity through SHA-256 hash comparison. It scans for injection patterns using regex pattern matching, a structural operation that looks for character sequences without comprehending meaning. It routes collected responses to a Navigator platform for synthesis, a cognitive task performed by an external AI, not by GOPEL. It packages everything for human review at checkpoint gates that will not advance without human approval. It logs every operation in a tamper-evident, hash-chained audit trail. And it counts things: approval rates, reversal rates, breach severity thresholds.

Seven operations. Zero judgment. The framework performs only deterministic pattern matching on prompts, not semantic evaluation. It cannot be manipulated through semantic prompt injection because it never interprets content. It cannot be socially engineered because it has no beliefs to manipulate. It cannot be corrupted by a superintelligent platform because there is no cognition to corrupt. The non-cognitive constraint removes semantic manipulation paths. Transport, adapter, operating system, and hardware layers remain attack surfaces addressed through standard infrastructure security, not governance architecture. The attack surface for the governance layer itself is reduced to message transport and cryptographic operations, both of which are deterministic and amenable to formal verification.

This is the architectural claim the Congressional Package makes. The code shows it holds under adversarial conditions.

What the Repository Contains

The implementation spans 14 Python modules organized into five functional layers, with a test suite of 183 tests distributed across nine test files.

The core pipeline executes a 14-step governance sequence: operator authentication, request logging, platform selection via cryptographic rotation seed, prompt hashing for tamper detection, dispatch to multiple AI platforms, response collection with transport integrity verification, injection and breach detection, Navigator routing for synthesis, structural validation of Navigator output, checkpoint packaging for human review, arbitration recording, and decision logging with hash chain binding. The base pipeline exists for reference. The secure pipeline wires all security, breach detection, and sentinel systems into the execution path.

The security layer provides HMAC-SHA256 operator identity with timing-attack-resistant signature verification, AES-128-CBC audit encryption with explicit fallback warning when the cryptography library is unavailable, external hash witness files for whole-file replacement attack detection, cryptographic rotation seeds preventing adversarial prediction of platform selection, and file-level locking for concurrent access protection.

The breach detection system classifies threats across five severity levels: NOMINAL, ADVISORY, WARNING, CRITICAL, and HALT. Ten detection categories cover injection patterns, transport integrity, Navigator format anomalies, confidence inflation, logger health, response statistical outliers, Unicode homoglyphs, delimiter injection, metadata channel exploitation, and security warning escalation. A circuit breaker halts the pipeline when configurable thresholds are exceeded.

The enterprise governance runtime enforces five layers of authorization before any operation proceeds. Role-based authorization determines who can act. Action permissions determine what they can do. Evidence gates determine what proof they must provide, with typed submissions including rationale, scope statements, risk assessments, and second-approver signatures. The policy engine aggregates verdicts with single-veto blocking. The escalation engine enforces ratchet-only posture changes from NORMAL through ELEVATED, HIGH, and LOCKDOWN, requiring explicit authority and justification for any de-escalation.

The anti-impersonation sentinel provides cryptographic pipeline identity. HMAC-signed alerts prevent rogue agents from sending false NOMINAL reports. Monotonic sequence verification detects heartbeat replay attacks. A dead-man’s switch triggers when the heartbeat stops, alerting external monitors that the governance layer itself may have been compromised.

Every module in the framework was verified by the non-cognitive static analyzer, which scans all source files for patterns indicating cognitive operations: model inference calls, embedding lookups, classification operations, content-dependent branching, NLP library imports, sentiment analysis functions. Fourteen source files. Zero violations. The analyzer itself enforces a path boundary check as of v0.6.1, refusing to process files outside the framework directory even if its scan targets are modified.

How Seven Platforms Tried to Break It

The adversarial review process followed the same provider plurality principle the framework is designed to enforce. Each AI platform received the codebase and review prompt independently. No platform’s findings were shared with any other platform before all reviews were collected. The findings were compared for convergence and addressed in priority order.

The first six platforms (Claude, ChatGPT, Gemini, Grok, Kimi, DeepSeek) reviewed the code across eight passes spanning versions 0.3.0 through 0.6.0. The seventh platform (MiniMax) reviewed the published v0.6.0 codebase post-release.

The process produced a specific, verifiable dataset. What follows is what happened.

What DeepSeek found first. The governance context defaulted to NOMINAL severity at the start of every transaction, regardless of what had happened in prior transactions. This meant that a CRITICAL breach in transaction N had no effect on the governance decision in transaction N+1. The policy rule that was supposed to block execution during active breaches was dead code. It checked a field that was always clean. DeepSeek flagged this as CRITICAL. ChatGPT confirmed it independently. The fix was to carry persistent breach state across transactions: severity, injection count, and platform failure count all feed forward into the governance context for the next execution.

What Gemini found first. The second-approver evidence gate accepted a bare operator ID string. Anyone who knew another operator’s ID could claim their approval without cryptographic proof. Gemini flagged this as CRITICAL. DeepSeek caught the same issue independently at MEDIUM severity. The fix was to require HMAC-SHA256 signatures from the approving operator’s signing key, verified against the operator registry.

What Kimi found first. The logger health check verified only that the audit file existed and had content. It did not verify that the content was valid JSON or that the hash chain was intact. A corrupted audit file passed the health check. Kimi flagged this as HIGH. DeepSeek caught the same issue independently at LOW severity. The fix was to add JSON parse and chain integrity verification to the health check.

What Gemini found alone. The encrypted audit file wrapper carried no integrity protection over its outer JSON envelope. An attacker could modify wrapper fields, specifically removing the “encrypted” flag, to force the system to load encrypted data through the unencrypted path, producing garbage records. The fix was to add HMAC verification over the wrapper before trusting any of its fields.

What Claude found after the fixes. The persistent breach state fix (T1-A) introduced a deadlock. Once breach severity reached CRITICAL, the governance policy blocked all pipeline execution. But the only way to update breach state was through a successful pipeline execution. The system was permanently stuck. No operator, regardless of authorization level, could resume operations. The fix was to add an acknowledge_breach() method requiring specific ACKNOWLEDGE_BREACH governance authorization to clear the breach state while preserving the escalation posture. The separation is deliberate: acknowledging a breach lets the pipeline run again, but the governance posture remains elevated until explicitly de-escalated through a separate authorization path.

What MiniMax found post-publication. Twelve findings. Five already documented. Seven new. Zero security vulnerabilities. The new findings were code quality improvements: explicit warning when the cryptography library falls back to weaker obfuscation (previously silent), per-transaction witness override for high-value operations (previously fixed interval only), static analyzer path boundary enforcement (previously relied on allowlist without explicit boundary check), and observations about module size, import organization, type annotation completeness, and test documentation.

The pattern is clear. Early adversarial reviews caught structural vulnerabilities. Later reviews surfaced code quality refinements. The critical security issues were found and fixed by platforms that did not coordinate with each other. The seventh platform confirmed that the fixes hold.

What No Platform Found

Seven AI platforms reviewed the code. None of them asked the question that the human operator asked during the build process: what happens if the Navigator lies?

The Navigator is the only cognitive component in the architecture. GOPEL sends collected platform responses to a designated AI platform for synthesis. That platform produces a summary of convergence and divergence across the platforms, which the human reviews at the checkpoint. GOPEL validates the Navigator output structurally: Did it reference all platforms? Did it flag disagreements? Did it preserve dissent? These are format checks, not content evaluation.

But a corrupted Navigator could produce a structurally valid synthesis that subtly misrepresents what the platforms actually said. It could overstate consensus, suppress a dissenting view, or frame divergence as agreement. The structural validator would not catch this because the output format is correct. The breach detector would not catch it because there are no injection patterns, no transport anomalies, no statistical outliers.

Three defenses exist today. The structural validator catches gross failures: a Navigator that silently drops a platform or fabricates a section. The checkpoint package contains all individual platform responses alongside the synthesis, so the human can compare the raw evidence against the Navigator’s summary. And Navigator rotation means a different platform serves as Navigator across transactions, preventing a single platform from consistently shaping the synthesis.

The defense that doesn’t yet exist is Navigator plurality: dispatching the same Navigator task to multiple platforms simultaneously and cross-validating their syntheses. If two Navigator platforms produce materially different summaries of the same set of responses, the divergence is itself a governance signal. This applies the same provider plurality architecture that the framework uses for primary prompt dispatch. It is documented as a development target in v0.6.1.

As the number of platforms or the length of responses grows, the assumption that the human can review all raw evidence strains. Sampling strategies, exception reporting, and structured divergence highlighting are development targets for scaling the checkpoint without abandoning it.

The point is not that the architecture has a gap. Every architecture has gaps. The point is that seven AI platforms reviewed the code and none of them identified this as a concern. The human operator did. That is checkpoint-based governance working as designed. The human at the checkpoint is the only trusted authority in the system. The framework exists to make sure that human has all the evidence needed to catch what the machines miss.

What the Non-Cognitive Constraint Actually Means

A common misreading of the non-cognitive claim is that GOPEL contains no intelligence. That isn’t the claim. The claim is that GOPEL performs no cognitive operations. The distinction matters.

GOPEL contains sophisticated engineering. Hash chain verification, HMAC signature validation, regex-based injection detection, statistical threshold comparison, cryptographic rotation seeding, five-layer governance authorization. These are complex deterministic operations. But none of them evaluate meaning, quality, relevance, or truth. They check structure. They compare numbers. They verify signatures. They count patterns.

The static analyzer enforces this boundary by scanning all 14 framework source files for patterns that would indicate cognitive operations. It flags model inference calls, embedding lookups, classification operations, NLP library imports, and content-dependent branching. Every file must pass clean. Every file does pass clean. The analyzer itself cannot be tricked into scanning untrusted external files because it enforces a path boundary check that rejects anything outside the framework directory.

The test suite includes explicit proof that the non-cognitive constraint creates a real limitation. Test cases demonstrate that a well-crafted lie, one that contains no injection patterns, no Unicode anomalies, no delimiter tricks, and passes all structural checks, moves through the pipeline undetected. The test documents this and names the defense: the human checkpoint. The breach report states it in every output.

This is not a weakness hidden in fine print. It is the central architectural principle. GOPEL doesn’t solve the problem of AI deception by being smarter than AI. It solves it by refusing to play the intelligence game at all, preserving all raw evidence, and routing everything to a human who can evaluate what the machines cannot. Whether this is the right architectural trade-off for national infrastructure is a legitimate debate. That the trade-off is buildable and testable is no longer in question.

How This Connects to the Policy Argument

The AI Provider Plurality Congressional Package proposes GOPEL as one path to federal AI governance infrastructure. The government builds the road. The AI platforms are the vehicles. Citizens choose their vehicles. The government guarantees the road is safe. That is the analogy. Whether Congress builds this specific road, a different road, or a combination is a policy decision. What this implementation addresses is the prior question: can such a road be built?

The feasibility question has three parts. First, whether a non-cognitive governance layer is technically possible: whether the seven operations can be implemented without cognitive contamination. The code shows this. Fourteen modules, 183 tests, seven independent reviews, zero non-cognitive violations.

Second, whether provider plurality produces measurable governance value: whether using multiple AI platforms generates better outcomes than single-provider workflows. The adversarial review data shows this. Seven platforms reviewed the same codebase. Each found things the others missed. Two critical vulnerabilities were caught by multiple platforms independently, producing convergent validation. No single platform found everything. The platform that found the most critical issues (DeepSeek) missed things that others caught (Gemini’s wrapper HMAC finding, Kimi’s logger health check). The platform that caught the deadlock (Claude) was reviewing its own prior fixes and still almost missed the implication. Provider plurality is not theoretical. It produced specific, measurable security improvements in this codebase. Extension to high-stakes decision domains requires the operational validation that Phase 0 pilots are designed to provide.

Third, whether governance infrastructure can support multiple operating models calibrated to risk. The three models described in the Congressional Package correspond to three checkpoint configurations in the code. Model 1 (Agent Responsible AI) runs the full pipeline and pauses at final output. Model 2 (Agent AI Governance) pauses at every RECCLIN role gate. Model 3 (Manual Human AI Governance) uses no automation; the agent only logs. The governance runtime provides the authorization framework for the selected model, with the operating_model parameter wired into the execution path. Full checkpoint gate enforcement per operating model is a Phase 4 implementation target. The infrastructure accommodates all three. Organizations choose their model based on the risk classification of the work.

None of this means GOPEL is the only architecture that could work. It means at least one architecture does work, at reference implementation scale, under adversarial conditions. The field can stop debating whether governance infrastructure is feasible and start debating which governance infrastructure to build.

Phase 0 of the Congressional Package requires no new appropriation. Agencies adopt manual governance using existing resources. GOPEL v0.6.1 is the reference implementation that informs Phase 0 pilot design and provides the technical schema for Phase 1 development. It isn’t deployment-ready software. It runs on mock adapters, not live API connections. There is no CLI, no Docker image, no production key management. These are operational concerns. The governance layer is complete and tested. The operational scaffolding is not.

NIST could begin audit file schema design using the published specification. GSA could develop API compatibility certification criteria for AI providers. FTC could evaluate the API accessibility mandate against the working implementation. The code exists. The policy conversation can proceed with evidence rather than promises.

What Remains Open

Honest engineering requires naming what isn’t finished.

Some limitations are architectural and cannot be resolved at any scale. Semantic manipulation by a platform that produces structurally clean lies is undetectable by any deterministic system. The monitoring-of-monitoring problem, where the heartbeat monitor itself is compromised, has no application-level termination. The human arbitration trust boundary assumes the human’s workstation is not compromised.

Some limitations require deployment infrastructure that a reference implementation cannot provide. API key management requires organizational KMS integration. Key rotation requires external cadence enforcement. The caller-supplied governance context trust boundary requires signed context assembly within a trusted execution environment. Windows compatibility requires alternative file locking primitives.

Some limitations are development targets that can be resolved in future versions. Navigator plurality is the most significant: dispatching the Navigator task to multiple platforms simultaneously and cross-validating their syntheses. Governance state persistence would survive process crashes. The O(N) write amplification pattern needs migration to append-mode logging for production scale. The governance module at 1,500 lines would benefit from decomposition into separate authorization, policy, and escalation submodules.

All of these are documented in the README with their severity classifications, the platforms that identified them, and the mitigation paths. Nothing is hidden. The architecture is stronger for naming its gaps openly rather than pretending they don’t exist.

The Evidence Standard

This work operates under a three-tier evidence discipline applied consistently across all publications in this body of work.

Tier 1 evidence is proven by others: peer-reviewed research, government reports, published standards. The automation bias research (Goddard et al., 2011; Banovic et al., 2023; EDPS TechDispatch #2/2025) that supports the case for human checkpoints is Tier 1. The NIST AI Risk Management Framework and EU AI Act compliance requirements are Tier 1.

Tier 2 evidence is built and operated as working concepts. GOPEL v0.6.1 is Tier 2. The adversarial review findings are Tier 2. The 183 test results are Tier 2. The claim that non-cognitive constraint holds across 14 modules verified by static analysis is Tier 2. These are not proven at institutional scale. They are working concepts with documented operational evidence showing promise.

Tier 3 evidence is proposed for development. Navigator plurality is Tier 3. Formal verification of the non-cognitive constraint is Tier 3. Production deployment with live API connections is Tier 3.

No Tier 2 evidence is presented as Tier 1. No Tier 3 aspiration is presented as Tier 2 accomplishment. The current proof record is author-controlled and adversarially reviewed with AI platform assistance. Independent institutional validation, whether through NIST evaluation, academic peer review, or professional security audit, is a next step that this publication is designed to enable. The code exists. The tests pass. The limitations are named. The evidence tier is stated.

Why the Code Is Public

GOPEL is published under Creative Commons Attribution-NonCommercial 4.0 International license as a defensive publication. The repository establishes prior art with a public timestamp. Every core technical infrastructure claim referenced by the Congressional Package is documented in code with test coverage and adversarial review records.

The decision to publish publicly rather than seek patent protection is deliberate. If the argument is that governance infrastructure should exist as public infrastructure, then the evidence for that argument cannot be enclosed. The CC BY-NC 4.0 license ensures non-commercial use with attribution remains free while requiring permission for commercial deployment. The license allows government use for public infrastructure without restriction. For commercial AI providers implementing compatible interfaces, the Congressional Package’s proposed API accessibility mandate would establish the compatibility requirement through legislation, independent of this reference implementation’s license terms. The code is public. The specification is public. The adversarial review record is public. Anyone can verify the claims. Anyone can challenge the architecture. Anyone can build something better.

That last point matters. If another team builds a governance architecture that outperforms GOPEL on security, scalability, or operational simplicity, the field advances. If a research institution formally verifies the non-cognitive constraint or refutes it, the field advances. If an agency pilot reveals failure modes this reference implementation did not anticipate, the field advances. The only outcome that does not advance the field is continued insistence that the work cannot begin.

Conclusion

The AI governance conversation has produced an abundance of specifications, frameworks, principles, and patent filings. What it has not produced, until now, is working code that implements non-cognitive constraint, provider plurality, checkpoint-based human authority, cryptographic audit trails, and multi-platform adversarial verification in a single testable architecture.

GOPEL v0.6.1 is that code. It is a reference implementation, not a finished product. It shows feasibility, not deployment readiness. It may not be the architecture that ultimately serves as national infrastructure. But it eliminates the claim that no such architecture can exist. Something can be built. Something was built. It was tested under adversarial conditions by seven independent platforms, and it held.

The question facing policymakers is no longer whether governance infrastructure for multi-AI systems is technically possible. The question is how long the country continues operating without it.

Seven AI platforms reviewed the code. Each found things the others missed. The human operator found things none of them caught. Every critical implementation vulnerability was fixed. Every limitation is documented. The non-cognitive constraint holds.

The repository is at github.com/basilpuglisi/HAIA. The code is the argument. The invitation is open: challenge it, improve it, or build something better. Any of those moves the field forward. Only inaction does not.

Related Documents

This proof-of-concept article supports the AI Provider Plurality Congressional Package:

Document 1: Summary Flyer (elevator pitch for infrastructure proposal)

Document 2: Ethics for Oversight (constitutional and philosophical case)

Document 3: AI Provider Plurality (legislative framework and policy mechanism)

Document 4: Methods Addendum (technical specification and operational experience)

Supporting publications:

Puglisi, B. C. (2025). Governing AI: When Capability Exceeds Control. ISBN 9798349677687.

HAIA-RECCLIN Agent Architecture Specification v2.2, EU Compliance Version (GitHub)

HAIA-RECCLIN Academic Working Paper, EU Regulatory Compliance Edition

Human-AI Collaboration Audit, End of Year 2025

github.com/basilpuglisi/HAIA

February 2026 | AI Provider Plurality Proof of Concept

This article was developed through structured human-AI collaboration using the HAIA-RECCLIN methodology. The code described in this article was developed collaboratively with Claude (Anthropic) and adversarially reviewed by seven independent AI platforms: Claude, ChatGPT, Gemini, Grok, Kimi, DeepSeek, and MiniMax. Human judgment governed all architectural decisions, fix prioritization, and publication timing.