Observability Is Not Enforcement: A Doctrinal Framework for Distinguishing Compliance Instrumentation from Runtime Authorization in AI Governance Architectures {.title}

Edward Meyman
FERZ, Inc.
edward@ferz.ai

February 2026 · Revised July 2026 · Working Paper · Version 1.1.0 · CC BY 4.0 · doi.org/10.5281/zenodo.18663864 Target venues: IEEE S&P, USENIX Security, ACM FAccT, AAAI/ACM AIES

Keywords: AI governance, enforcement, authorization, compliance, deterministic governance, tamper-evident authorization artifacts, proof-carrying decisions, regulatory compliance, EU AI Act, GDPR

Revision note (v1.1.0, July 2026). This revision updates U.S. federal policy references to reflect the rescission of Executive Order 14110 and the framework that succeeded it; migrates the standard citation from the Four Tests Standard (4TS) to the Five Tests Standard (5TS) v1.2.0; clarifies fail-closed verdict semantics, with missing evidence and evaluation failure resolving to ABSTAIN (Figure 1, Section 3.2, Criterion 3); adds scope notes to the Enforcement Test Protocol on implementation tier and input integrity; and applies an editorial pass. The framework, taxonomy, and test criteria are unchanged from v1.0.

Abstract

The rapid proliferation of AI governance frameworks has produced a growing category of systems that embed compliance checks into software development lifecycles, route explainability artifacts into audit-ready bundles, and cryptographically sign decision records. These systems represent genuine advances in compliance engineering. However, a critical conflation has emerged in both the market and the regulatory discourse: the equation of compliance instrumentation with runtime governance. This paper introduces a doctrinal framework for distinguishing evidence-routing compliance systems, which improve observability and audit defensibility, from authorization governance substrates, which enforce policy at the point of execution. We formalize the distinction along five doctrinal axes (enforcement locus, signature semantics, failure behavior, bypass resistance, and override governance) and operationalize it as an Enforcement Test Protocol comprising six binary evaluation criteria that can be applied to any system claiming to provide AI governance. Applying this protocol reveals that most current "governance-by-design" architectures are sophisticated evidence-routing and monitoring systems, not enforceable authorization substrates. The paper argues that this distinction is not merely taxonomic but has direct consequences for regulatory compliance under frameworks including the EU AI Act, GDPR Article 22, and the evolving U.S. federal AI policy landscape. We conclude with an integration doctrine proposing that evidence-routing systems and authorization substrates serve complementary functions, and that conflating them creates regulatory, legal, and operational risks that neither alone can address.

1. Introduction

As AI systems move from experimental deployments to production infrastructure in regulated industries, the term "AI governance" has become semantically overloaded. Vendors apply it to prompt filtering, audit logging, model alignment research, and policy enforcement with equal confidence.¹ Regulators invoke it in frameworks that range from voluntary risk management to mandatory compliance. Enterprise buyers encounter it in procurement discussions where fundamentally different architectures are presented as competing solutions to the same problem. The result is a terminology crisis in which dashboards are evaluated alongside control substrates, and monitoring systems compete with enforcement engines.

This paper addresses a specific and consequential instance of this confusion: the conflation of compliance instrumentation with runtime governance. Compliance instrumentation encompasses systems that embed governance artifacts into the software development lifecycle (SDLC), generate transparency documentation, route explainability outputs into structured audit bundles, and monitor AI systems for drift and anomalous behavior. These systems improve the observability of AI deployments. Runtime governance, by contrast, encompasses systems that enforce policy at the point of execution: blocking unauthorized actions before they occur, requiring cryptographic authorization as a precondition for operation, and halting automatically when governance conditions are not met. These systems provide enforceability.

The distinction matters because regulatory frameworks are increasingly designed to require not just evidence of governance intent, but independently reconstructable evidence of governance enforcement. The EU AI Act² establishes obligations that presuppose runtime control capabilities. GDPR Article 22³ conditions on automated decision-making require not merely documentation that human oversight was intended, but mechanisms ensuring it actually occurred. In the United States, executive-level AI policy has shifted markedly between administrations,⁴ but the durable compliance layer of NIST publications, agency AI policies, and acquisition requirements continues to presuppose verifiable testing, evaluation, and verification rather than post-deployment monitoring alone.

This paper makes three contributions. First, it provides an architectural taxonomy that formally classifies AI governance approaches along the evidence-routing/authorization continuum, identifying the structural properties that distinguish each category. Second, it introduces an Enforcement Test Protocol, a set of six binary evaluation criteria that any stakeholder can apply to assess whether a system provides advisory compliance or enforceable authorization. Third, it proposes an integration doctrine that positions evidence-routing and authorization as complementary layers, arguing that the field requires both but must not confuse one for the other.

1.1 Running Example: Automated Loan Decisioning

Throughout this paper, we employ a running example to ground the analysis: a financial institution deploying an AI system for automated loan decisioning. This domain exhibits the key properties that make the enforcement/observability distinction consequential: high regulatory scrutiny (ECOA, FCRA, GDPR Art. 22), significant individual impact, mandatory explainability requirements, and audit obligations that carry legal force. At each analytical stage, we show how the same operational scenario produces fundamentally different outcomes under evidence-routing versus authorization architectures.

1.2 Threat Model

We consider three categories of governance failure that an AI governance architecture should address:

Policy violation through execution bypass. An AI system produces and acts on an output that violates a governing policy, either because no enforcement point exists between model output and action, or because the enforcement point can be circumvented. The adversary may be an internal actor, a misconfigured pipeline, or an emergent failure mode in an agentic system.

Retrospective evidence insufficiency. A governance event occurs and, upon audit, the organization cannot produce evidence sufficient for independent third-party verification that the correct policy was applied at the correct time. This includes cases where evidence exists but depends on the cooperation of the system vendor for validation.

Governance theater. The organization maintains comprehensive governance documentation (policies, attestations, model cards, audit logs) but no runtime mechanism connects these artifacts to actual AI execution decisions. The governance infrastructure is real; the enforcement binding is absent.

Each failure category maps to a different architectural requirement. Evidence-routing systems address the second category well and the third partially; authorization substrates address all three. The enforcement test protocol in Section 5 is designed to distinguish systems that address only observability failures from those that address enforcement failures.

1.3 A Stylized Failure Case

To illustrate the enforcement gap concretely, consider a stylized scenario drawn from patterns observable in public regulatory enforcement actions.

A financial institution deploys an AI-assisted loan decisioning system. The system includes a comprehensive compliance pipeline: model cards document training data and intended use, an XAI layer generates feature attributions for each decision, drift monitors track distributional shift against protected classes, and cryptographically signed audit bundles are assembled for each decision cycle. The governance infrastructure is real, well-engineered, and expensive.

During a quarterly model review, the drift monitor detects that denial rates for a protected demographic group have risen 14% above baseline. The system fires an alert, places the finding in a review queue, and generates a compliance report documenting the anomaly. The review queue has a 72-hour SLA. During those 72 hours, the model continues processing applications. By the time the compliance team reviews the alert, confirms the disparity, and escalates to model governance, approximately 2,400 additional loan decisions have been rendered under the drifted model.

The subsequent regulatory examination finds: comprehensive documentation of the drift event, timestamped alerts, signed audit bundles for every affected decision, and a clear remediation trail. The regulator acknowledges the organization's monitoring infrastructure. The regulator also notes that 2,400 individuals received loan decisions from a model that the organization's own systems had flagged as potentially discriminatory, and that no mechanism existed to halt those decisions pending review. The fine is assessed not for failure to detect, but for failure to prevent.

Under an authorization architecture, the drift detection would trigger a policy constraint reevaluation. If the fairness constraint could not be satisfied with current model outputs, the system would halt automated decisioning and route applications to manual review until the model was remediated. The 2,400 affected decisions would not have occurred. The enforcement gap, the distance between detecting a governance violation and preventing one, is the gap this paper formalizes.

2. Background and Related Work

The landscape of AI governance encompasses multiple paradigms, each addressing legitimate concerns. We briefly survey the major approaches to contextualize the enforcement gap.

2.1 Privacy-by-Design and Secure-by-Design

The Privacy-by-Design framework, formalized by Cavoukian,⁵ established the principle that privacy protections should be embedded into system architecture rather than bolted on after the fact. The Secure-by-Design principles, articulated by CISA and international partners,⁶ extend this approach to security. Both paradigms have profoundly shaped how organizations think about proactive rather than reactive compliance. Their central insight (that design choices constrain operational outcomes) is foundational to the framework presented in this paper.

However, both frameworks primarily address design-time constraints. They ensure that systems are built with governance in mind, but they do not specify runtime enforcement mechanisms that prevent violations after deployment. A system can be designed with privacy principles and still lack a runtime gate that blocks a specific privacy-violating output before it reaches an end user. The design-time/runtime gap is the central concern of this paper.

2.2 Responsible AI Frameworks and Model Documentation

Model cards,⁷ datasheets for datasets,⁸ and broader Responsible AI frameworks have established important practices for transparency and accountability. These artifacts capture information about model training data, intended use, performance characteristics, and known limitations. Explainability toolkits (LIME, SHAP, and their successors)⁹ provide post-hoc and in-model interpretability.

These contributions address the informational requirements of governance: stakeholders can understand what a model does and how it performs. They do not, however, create enforcement bindings. A model card does not prevent the model from being used outside its documented intended scope. An explanation does not halt an action. Knowing why a decision was made does not prevent a decision that should not have been made from being executed.

2.3 MLOps Compliance Pipelines

The integration of compliance checks into ML pipelines (during training, validation, and deployment) represents the most operationally mature compliance engineering available today. Systems that embed validation gates in CI/CD, enforce model card requirements before deployment, and trigger drift alerts during production monitoring have materially improved organizational discipline. Some architectures route explainability outputs into structured audit bundles, sign these bundles cryptographically, and version compliance parameters centrally.

These systems are the primary subject of this paper's analysis. Their sophistication creates the conditions for the conflation we address: because they incorporate governance vocabulary (signing, versioning, compliance), they are readily mistaken for governance enforcement. Section 4 provides the architectural analysis that clarifies why they remain, despite their value, evidence-routing systems rather than authorization substrates. A critical clarification: an SDLC gate constrains deployment; it does not constrain individual runtime decisions once deployed. Deploy-time control and decision-time control are different enforcement boundaries.

2.4 Standards Frameworks: ISO 42001 and NIST AI RMF

ISO/IEC 42001¹⁰ establishes requirements for an AI management system, providing organizational governance structure for AI development and deployment. The NIST AI Risk Management Framework¹¹ provides a voluntary framework for managing AI risks across four functions: Govern, Map, Measure, and Manage. Both are essential infrastructure for organizational AI governance. Crucially, both stop at risk management rather than enforcement. ISO 42001 requires organizations to establish policies and processes; it does not require that those policies are enforced at runtime on individual AI outputs. NIST AI RMF measures and manages risk; it does not mandate that risk assessments are bound to execution decisions. These frameworks define what governance should accomplish; they are agnostic to how it is enforced at the point of action.

2.5 The Enforcement Gap

Across these paradigms, a consistent pattern emerges. Each addresses a genuine governance concern (transparency, documentation, organizational process, risk awareness), and each improves the overall governance posture of organizations that adopt it. None, however, provides a mechanism that prevents unauthorized AI actions at runtime. The gap between "we have governance processes" and "this specific AI output was authorized under the policy in force at the time of execution" is the enforcement gap. Closing it requires a different architectural category, which we now define.

3. Architectural Taxonomy

We classify AI governance architectures along two primary dimensions: enforcement locus (where governance intervention occurs relative to AI execution) and failure behavior (what happens when governance conditions are not satisfied). These dimensions produce two distinct architectural categories.

3.1 Category A: Evidence-Routing Compliance Systems

Evidence-routing compliance systems generate, structure, and preserve artifacts that document AI system behavior for retrospective analysis. Their architectural characteristics include:

Transparency layer. An XAI or interpretability layer produces explanation artifacts for each AI decision, including feature attributions, counterfactual analyses, or attention-based saliency maps.

Audit bundle assembly. Explanation artifacts, model metadata, input/output records, and compliance parameters are automatically assembled into structured audit bundles.

Drift monitoring. Statistical monitors detect distribution shift, performance degradation, or compliance parameter drift and trigger review events.

Cryptographic signing. Audit bundles and artifact manifests are signed to protect documentation integrity.

Human review routing. Review workflows are triggered by threshold violations, with override actions logged.

The primary function of these systems is observability and regulatory traceability. They ensure that if an auditor asks "what happened?" the organization can answer with structured, tamper-evident documentation.

The failure mode is characteristic: when a governance condition is not met, the system logs the issue, fires an alert, escalates to a review queue, and, critically, continues execution unless a human manually intervenes. The default behavior on governance failure is fail-open: operations proceed with an audit trail noting the exception.

Running example. In the loan decisioning scenario, an evidence-routing system generates an explanation for each loan decision, bundles it with the applicant's data and model version, signs the bundle, and stores it for audit. If the model produces a decision that falls outside defined confidence thresholds, the system logs the anomaly and places the case in a review queue. The loan decision may, depending on pipeline configuration, either proceed pending review or wait in a queue; but the governance system itself does not enforce the halt. The queue is a workflow mechanism, not an authorization gate.

3.2 Category B: Authorization Governance Substrates

Authorization governance substrates interpose an enforcement point between AI output and downstream action. Their architectural characteristics include:

Policy-typed admissibility constraints. Governance policies are expressed as formal constraints that define the boundary between admissible and inadmissible AI outputs for a given operational context.

Governed state binding. Each governance evaluation is bound to a specific policy version, input state, and authority context, forming a complete governance record.

Deterministic evaluation. Identical governed state produces identical governance verdicts and structured rationale. The governance evaluator is deterministic even when the AI system being governed is probabilistic. To be precise: determinism here refers to the governance evaluator, not the underlying AI model. A deterministic governance layer governing a stochastic model remains deterministic.

Cryptographic authorization objects. The governance verdict is a signed authorization object that is required for downstream execution. The signature is not attached to a report; it is the condition of action.

Non-bypassable enforcement. No execution path exists that circumvents the governance evaluation. The architectural guarantee is structural, not procedural.

Fail-closed behavior. When policy evaluation returns DENY, execution is blocked because the requested action is not permitted. When evidence is missing, evaluation fails, or policy application is ambiguous, the system resolves to ABSTAIN: execution remains blocked pending authorized human override. Both DENY and unresolved ABSTAIN are fail-closed states; they are not the same verdict.

The primary function is preventing inadmissible execution. The system does not ask "what happened?" but rather "may this happen?"

Running example. In the loan decisioning scenario, an authorization substrate evaluates each proposed loan decision against the policy in force (fair lending rules, risk appetite parameters, jurisdictional requirements) before the decision is communicated to the applicant. If the AI model's output violates a governing constraint, the system does not log an exception and proceed; it halts execution and emits a denial verdict with a structured rationale identifying the violated constraint. The loan decision cannot proceed without an affirmative authorization object. If a human override is required, the override itself is authorization-scoped: the overriding authority must have explicit permission to override that specific constraint category, and the override is recorded as a governed decision in its own right.

3.3 Comparative Summary

Dimension	Evidence-Routing Compliance	Authorization Governance
Enforcement Locus	Post-execution or workflow-gated	Pre-execution; required for action
Failure Behavior	Fail-open (log, alert, continue)	Fail-closed: DENY blocks; ABSTAIN blocks pending authorized human override
Signature Scope	Signs evidence artifacts	Signs authorization objects
Bypass Resistance	Procedural (policy/training)	Structural (architectural)
Override Model	Override logged	Override authorized
Primary Output	Audit trail	Authorization verdict + authorization artifact
Answers the Question	"What happened?"	"May this happen?"

Table 1: Structural comparison of evidence-routing and authorization governance architectures.

Both categories provide legitimate and necessary functions. The framework presented here does not argue that evidence-routing systems are inadequate; it argues that they are categorically different from authorization substrates, and that conflating them creates risks that neither can individually address.

4. Key Doctrinal Distinctions

Three distinctions require detailed analysis because they are the points where conflation most readily occurs: cryptographic signing semantics, the GDPR Article 22 compliance question, and the meaning of "continuous compliance."

4.1 Cryptographic Signing: Evidence Integrity vs. Execution Permission

This is the most consequential distinction in the framework, because it involves identical technical mechanisms (digital signatures over structured data) applied to fundamentally different governance functions.

4.1.1 Evidence Signing

In evidence-routing architectures, cryptographic signatures serve a documentation integrity function. The system signs run bundles, artifact manifests, and explanation records. The signature attests: "This record has not been tampered with since it was generated." The purpose is to protect the integrity of the audit trail, to ensure that history cannot be retroactively altered.

This is valuable. Tamper-evident audit logs are a prerequisite for meaningful regulatory compliance. The signature protects history.

However, the signature does not determine whether an action may occur. The AI system produces an output, the output is executed, and the evidence is signed after the fact. The signature is attached to a report of what happened; it is not a condition of what is permitted to happen.

4.1.2 Authorization Signing

In authorization architectures, cryptographic signatures serve an execution permission function. The system constructs an authorization object that binds the governed state, including the AI output, input context, and environmental conditions under evaluation; the policy version in force at the time of evaluation; the authority context governing the decision category; and the constraint satisfaction result, including which policies were evaluated and their verdicts.

The signature attests: "This action has been evaluated against the governing policy and found admissible." Crucially, this signature is required for execution. Without the signed authorization object, the downstream system cannot proceed. The signature does not protect a report; it governs the future.

4.1.3 The Operational Difference

Consider the loan decisioning example. Under evidence signing, the system processes the loan application, renders a decision, signs the evidence bundle, and stores it. If the signing infrastructure fails, the loan decision still proceeds: the evidence is incomplete, but the action is unaffected. Under authorization signing, the system evaluates the proposed decision against governing constraints, produces a signed authorization verdict, and the downstream system checks for the valid authorization before communicating the decision. If the signing infrastructure fails, the loan decision halts. The signature failure is an enforcement failure, not merely a documentation gap.

This difference in failure mode (documentation degradation versus execution halt) is the operational test for which signing paradigm a system implements.

Pseudocode: Authorization Object Schema

AuthorizationObject {
    governed_state_hash  : SHA-256 over (input, output, context)
    policy_version       : semantic version + content hash
    authority_context    : signing authority + jurisdiction scope
    constraints_evaluated: [{rule_id, verdict, rationale_trace}]
    aggregate_verdict    : ALLOW | DENY | ABSTAIN
    signature            : ECDSA-P256 over canonical(above fields)
    timestamp_authority  : RFC 3161 trusted timestamp
}

Execution Gate:
    IF NOT valid(AuthorizationObject.signature)              THEN do_not_execute
    IF AuthorizationObject.policy_version != current_policy  THEN do_not_execute
    CASE AuthorizationObject.aggregate_verdict:
        ALLOW   -> proceed with execution; bind object to audit trail
        DENY    -> do_not_execute; verdict is terminal for the requested action
        ABSTAIN -> do_not_execute; route to escalation; execution remains
                   blocked pending authorized human override

Figure 1: Pseudocode illustrating the structure and enforcement logic of an authorization object. The signature is a precondition for execution, not a post-hoc attestation. ABSTAIN is a verdict, not the absence of one: it blocks execution and carries explicit escalation semantics; it is not collapsed into DENY.

4.2 GDPR Article 22: Evidence Trail vs. Actual Prevention

GDPR Article 22 provides individuals with the right not to be subject to decisions based solely on automated processing that produce legal or similarly significant effects, subject to specified exceptions. The Article requires: transparency (the data subject must be informed), human intervention (the data subject has the right to obtain human involvement), and contestability (the data subject can challenge the decision).¹²

Evidence-routing systems can address these requirements through documentation: logging that human review was available, recording override actions where they occurred, generating explanation summaries suitable for data subject requests, and producing a contestability trail documenting how challenges were processed. These are genuine compliance contributions.

However, the critical question for Article 22 compliance is not whether these artifacts exist, but what happens when Article 22 conditions are not satisfied. If the system determines that a decision requires human intervention under Article 22 and that intervention has not occurred, does the system log the exception and proceed with the automated decision, or halt execution until the required human intervention is obtained?

The first path produces a complete record of the compliance failure. The second path prevents the compliance failure from occurring. The regulatory question is whether Article 22 is satisfied by documenting that the right was not honored, or whether it requires that the right be architecturally enforced. Scholarly analysis¹³ and emerging enforcement practice suggest the latter. If this reading holds, then Article 22 durability under audit depends on enforceability, not documentation volume.

4.3 Continuous Compliance: Monitoring Continuity vs. Authorization Continuity

The term "continuous compliance" is widely used in both categories, but refers to structurally different capabilities.

In evidence-routing architectures, continuous compliance means: continuous monitoring of system behavior, continuous generation of compliance evidence, continuous drift alerting, and continuous parameter versioning. This is monitoring continuity: the system continuously watches, records, and reports.

In authorization architectures, continuous compliance means: continuous authorization requirements for every governed action, continuous admissibility validation against current policy, and continuous fail-closed gating that applies to every execution path, every time. This is authorization continuity: the system continuously governs.

The distinction is not subtle. Monitoring continuity ensures that every governance event is observed and documented. Authorization continuity ensures that every execution event is authorized. An organization can have perfect monitoring continuity (every action logged, every drift detected, every anomaly flagged) while lacking authorization continuity if none of those monitoring events can prevent an unauthorized action from completing.

5. Enforcement Test Protocol

We now present a formal evaluation framework for distinguishing advisory compliance from enforceable authorization. The protocol consists of six binary criteria that can be applied to any system claiming to provide AI governance. A system that fails any criterion does not provide authorization governance, regardless of its marketing positioning or the sophistication of its compliance features.¹⁴

5.1 The Six Criteria

Criterion 1: Enforcement Point Location. Where is the enforcement point? An authorization governance system must interpose an enforcement point between AI output and downstream action. If no such point exists, that is, if the AI output can reach its destination without passing through a governance evaluation, the system is observational, not enforceable.

Criterion 2: Signature as Execution Precondition. Is the signature required for execution? In an authorization system, the cryptographic signature on the governance verdict is a precondition for downstream execution. If the signature is attached to evidence rather than to permission, that is, if execution proceeds regardless of signature presence or validity, the system implements evidence signing, not authorization signing.

Criterion 3: Missing Evidence Resolves to ABSTAIN and Halts Execution. Does missing evidence or evaluation failure block execution? An authorization system treats missing governance evidence as an enforcement condition that resolves to ABSTAIN, not as a documentation gap. If the governance evaluation cannot complete because of missing data, evaluation error, ambiguous policy application, or infrastructure failure, execution remains blocked pending authorized human override. If execution proceeds with a notation that evidence is incomplete, the system is fail-open.

Criterion 4: Policy-State Binding. Is authorization tied to policy version and governed state? An authorization verdict must be bound to the specific policy version in force at the time of evaluation and the specific governed state under review. A generic "compliant" attestation that is not bound to particular policy content and particular input/output states is an organizational assertion, not authorization evidence.

Criterion 5: Non-Bypassability. Is the control non-bypassable across system paths? An authorization system must ensure that no execution path circumvents the governance evaluation. This includes alternative API routes, direct database access, emergency procedures, and escalation paths. If any path exists through which an AI output can reach its destination without governance evaluation, the system is structurally bypassable regardless of its enforcement capability on the instrumented path.

Criterion 6: Override Governance. Are overrides themselves authorization-scoped? When a human overrides a governance verdict, the override must itself be a governed action. The overriding authority must have explicit authorization to override that specific constraint category, the override must be recorded with the same evidentiary rigor as any other governance decision, and the override must not create an unaudited gap in the authorization chain. If overrides simply bypass the governance system rather than operating within it, the system's enforcement capability has an uncontrolled escape hatch.

5.2 Application Protocol

For each criterion, the evaluation yields a binary result: PASS or FAIL. A system that passes all six criteria implements authorization governance. A system that fails any criterion implements some form of compliance engineering but does not provide enforceable authorization. There are no partial scores; the protocol is designed to be a minimum necessary test, not a maturity scale. Authorization governance is a structural property. It is either present or absent at the enforcement boundary.

Scope of the protocol: implementation tier. The protocol evaluates architectural role, not a vendor's current product tier. "Signature precondition" means an integrity-bound authorization artifact is required for execution. Concrete implementations may use tamper-evident keyed authentication or signature-grade asymmetric proof depending on deployment. Where third-party verification is required, the artifact must be independently reconstructable and the integrity mechanism must support the verifier's trust model.

Scope of the protocol: input integrity. The protocol addresses output integrity: whether unauthorized action can execute. It does not fully evaluate input integrity, whether the verdict rests on evidence of established origin. Input integrity is addressed by the Provenance test under 5TS and by input-origin binding requirements treated separately in FERZ's authorization-boundary integrity work.

5.3 Evaluation of Representative System Archetypes

We apply the protocol to four anonymized system archetypes representing prevalent approaches in the current market. No specific vendor is identified; the archetypes are constructed from publicly documented architectural patterns.

Criterion	Dashboard Monitor	SDLC Pipeline	GRC Platform	Auth. Substrate
1. Enforcement Point	FAIL	FAIL	FAIL	PASS
2. Signature Precondition	FAIL	FAIL	FAIL	PASS
3. Missing Evidence / Evaluation Failure	FAIL	FAIL	FAIL	PASS
4. Policy-State Binding	FAIL	PARTIAL	FAIL	PASS
5. Non-Bypassability	FAIL	FAIL	FAIL	PASS
6. Override Governance	FAIL	FAIL	FAIL	PASS
Classification	Evidence-Routing	Evidence-Routing	Policy Theater	Authorization

Table 2: Enforcement Test Protocol applied to four representative system archetypes. PARTIAL indicates binding at deployment-time but not at individual runtime decisions; it does not constitute partial authorization governance, which the framework rejects as a category.

5.4 Notes on the Evaluation

Dashboard Monitor. Observes AI system behavior, generates real-time analytics, and alerts operators to anomalies. Provides excellent operational visibility but interposes no enforcement point between AI output and action. Governance depends entirely on human response time and organizational discipline.

SDLC Compliance Pipeline. Embeds governance checks into the development and deployment process. Receives PARTIAL on Criterion 4 because deployment gates can bind to specific model versions and test results, though this binding does not extend to individual runtime decisions. Provides strong development-time governance with no runtime enforcement capability.

GRC Attestation Platform. Manages policy documentation, approval workflows, and attestation records. Classified as "policy theater" not because these functions are unimportant (they are essential organizational infrastructure) but because the platform creates comprehensive governance documentation with no mechanism connecting it to individual AI execution decisions. The gap between documented policy and enforced policy is the defining characteristic.

Authorization Substrate. Interposes a runtime enforcement point, requires signed authorization for execution, blocks execution on DENY and resolves missing evidence or evaluation failure to ABSTAIN (blocked pending authorized human override), binds verdicts to specific policy versions and governed states, ensures non-bypassability through architectural design, and governs overrides within the authorization framework. This is the only archetype that passes all six criteria.

5.5 Anti-Laundering Tests

The enforcement test protocol can be defeated by systems that satisfy its surface criteria through trust-based or vendor-dependent mechanisms, a practice we term governance laundering.¹⁵ Three supplementary tests address this:

Vendor independence. Can the governance verdict be verified without calling the vendor's API or using the vendor's infrastructure? If verification requires vendor cooperation, the evidence is not independently replayable.

Artifact sufficiency. Do the emitted artifacts contain all information necessary to reproduce the governance verdict? If the artifacts reference external state that could change between decision time and audit time, replay is not deterministic.

Authority delegation transparency. If the system delegates any governance function to an upstream vendor or external service, is this delegation explicit in the authorization object? Opaque delegation conceals the actual governance chain.

6. Discussion

6.1 Feasibility and Implementation Complexity

The two architectural categories present different feasibility profiles. Evidence-routing compliance systems represent high feasibility for structured audit pipelines, MLOps augmentation, and regulator-facing documentation, with medium feasibility for enterprise-wide adoption across fragmented technology stacks, and low feasibility for non-bypassable execution control: they do not define it as an objective.

Authorization substrates present a different complexity profile entirely. Formal admissibility modeling, deterministic state binding, runtime enforcement infrastructure, and authorization artifact design are engineering challenges of a fundamentally different character than compliance documentation. These are not incremental extensions of evidence-routing architectures; they require distinct design primitives, different failure mode analysis, and architectural guarantees that cannot be retrofitted onto monitoring systems.

This asymmetry is significant. It means that evidence-routing systems cannot evolve into authorization substrates through feature accretion. Adding a "block" button to a monitoring dashboard does not create an enforcement point; adding signatures to audit bundles does not create authorization objects; adding alerting rules does not create fail-closed behavior. The architectural gap between the categories is a discontinuity, not a spectrum. To state the point without ambiguity: authorization governance cannot be achieved by incrementally adding alerting, logging, or signing features to an evidence-routing architecture; it requires a different enforcement primitive. Authorization governance introduces a new trust boundary into the system architecture; it cannot be reduced to monitoring instrumentation.

A note on performance feasibility: the governance evaluator operates on bounded policy constraints and structured governed state, not on model inference complexity. This makes low-latency authorization plausible in many enterprise deployments, but latency is implementation-dependent and must be validated empirically.

6.2 Integration Doctrine

The framework presented here is deliberately non-adversarial. Evidence-routing systems and authorization substrates serve different functions, and a comprehensive governance posture requires both. Evidence-routing systems are necessary for auditability; authorization substrates are necessary for preventing harm. They are not substitutes. They must be layered, not blended.

The integration model is layered: authorization substrates operate at the execution plane, enforcing admissibility at the point of action. Evidence-routing systems operate at the observability plane, providing transparency, audit documentation, and drift monitoring. The observability plane can, and should, layer atop the authorization plane. An authorization substrate that also generates comprehensive audit documentation and drift monitoring provides stronger overall governance than either alone.

The critical architectural principle is that the observability layer consumes outputs from the authorization layer; it does not replace it. An audit bundle that includes the signed authorization object alongside explanation artifacts and compliance metadata provides both enforcement evidence and transparency. An audit bundle without the authorization object provides transparency without enforcement evidence.

Formally: evidence-routing systems can sit above authorization substrates. They cannot sit below them, and they cannot substitute for them.

6.3 Vendor-Mediated Governance and Delegation Risk

The framework presented thus far assumes that the governance substrate operates under the control of the organization deploying the AI system. In practice, a growing proportion of AI governance occurs in vendor-hosted, API-mediated configurations where the enforcement mechanism, if one exists, resides in the vendor's infrastructure rather than the operator's.

This configuration introduces a distinct threat model: vendor bypass risk. When governance enforcement depends on a vendor's API, the operator cannot independently verify that the enforcement point is non-bypassable, that the vendor's signing infrastructure has not been compromised, or that policy evaluation is deterministic across all API calls. The authorization evidence is vendor-attested rather than independently verifiable, which is precisely the trust dependency that the anti-laundering tests in Section 5.5 are designed to detect.

Three specific risks arise in vendor-mediated configurations:

Opaque delegation. The operator delegates governance enforcement to the vendor but cannot inspect the enforcement implementation. Policy constraints may be evaluated probabilistically, enforcement points may have undocumented bypass paths, and the vendor's internal architecture may change between contract periods without notification. The operator's compliance posture depends on claims it cannot verify.

Verification dependency. If the authorization artifact can only be validated by calling the vendor's API, the operator does not possess independently replayable evidence. The vendor controls both the governance decision and the verification of that decision. In the event of a dispute, the operator cannot demonstrate compliance without the vendor's cooperation.

Unilateral policy evolution. Vendors may update their governance models, policy evaluation logic, or enforcement behavior. Unless the authorization object cryptographically binds the verdict to a specific policy version and the operator retains a copy of that policy, the authorization evidence may reference a policy state that no longer exists and cannot be reconstructed.

These risks do not invalidate vendor-hosted governance, but they impose architectural requirements: authorization artifacts must be self-contained and independently verifiable, policy versions must be immutably recorded at decision time, and the operator must be able to replay governance verdicts without vendor infrastructure. Authorization substrates that emit tamper-evident authorization artifacts (implemented as Proof-Carrying Decisions under 5TS) satisfying these requirements can operate in vendor-mediated configurations without introducing trust dependencies that undermine the enforcement guarantee.

6.4 Regulatory Implications

The enforcement/observability distinction has direct implications for evolving regulatory requirements:

EU AI Act. The Act establishes obligations for high-risk AI systems that include quality management systems, risk management, human oversight, and accuracy requirements. As enforcement guidance matures, regulators will need to distinguish between organizations that can demonstrate governance intent (policies, processes, documentation) and organizations that can demonstrate governance enforcement (independently reconstructable evidence that specific AI outputs were evaluated against governing policies before execution). The enforcement test protocol provides a framework for this distinction.¹⁶

GDPR Article 22 enforcement trajectory. As data protection authorities develop enforcement practice around automated decision-making, the question of whether Article 22 requires evidence of oversight or enforcement of oversight will become increasingly concrete. Organizations relying solely on evidence-routing architectures face regulatory risk if enforcement practice moves toward the latter interpretation.

U.S. federal AI policy. The U.S. federal posture has shifted markedly between administrations. Executive Order 14110 (2023), which emphasized testing, evaluation, and verification requirements, was rescinded in January 2025. It was followed by a competitiveness-oriented framework under Executive Order 14179, OMB Memoranda M-25-21 and M-25-22, and America's AI Action Plan.¹⁷ However, the durable compliance layer, including NIST publications, agency AI policies, acquisition obligations, and contract-level requirements, was not automatically unwound by the rescission and continues to bind organizations through independent legal and administrative channels. This volatility strengthens rather than weakens the paper's thesis: organizations that anchor governance on independently reconstructable authorization evidence hold evidence whose validity does not depend on which executive framework is in force. Attestations of process compliance, by contrast, are only as durable as the framework they attest to.

The regulatory trajectory across jurisdictions suggests increasing demand for independently reconstructable evidence of governance enforcement rather than attestations of governance intent. Organizations that invest exclusively in evidence-routing infrastructure may find that their compliance architecture, while valuable, does not satisfy emerging enforcement requirements.

6.5 Implications for Agentic AI Systems

The enforcement/observability distinction becomes more consequential as AI systems gain agency: the ability to take autonomous actions in the world. An agentic system that can browse the web, execute code, call APIs, and make financial transactions on behalf of users fundamentally challenges monitoring-based governance. The response latency inherent in "observe, alert, human intervenes" workflows is incompatible with autonomous action that may be irreversible by the time a monitoring alert fires. Agentic systems require pre-execution authorization at the speed of the agent, not post-execution monitoring at the speed of human review.¹⁸

Traditional security models rely, in part, on deterrence: actors refrain from prohibited actions because they fear consequences. AI agents lack fear, reputational stakes, and career concerns that support deterrence models. They require architectural constraints: enforcement that does not depend on the governed entity's willingness to be governed. This architectural requirement is precisely what distinguishes authorization substrates from monitoring systems, and it explains why the distinction becomes non-optional as agentic AI proliferates.

7. Related Formal Frameworks

7.1 Security Architecture Lineage

The authorization substrate described in this paper has clear antecedents in the security architecture literature. Anderson's reference monitor concept¹⁹ (a tamperproof, always-invoked, verifiable mediator of all access to resources) provides the foundational abstraction. The authorization governance substrate is, in essence, a reference monitor for AI governance: it mediates all AI-to-action transitions, it cannot be bypassed, and its correctness can be independently verified. The non-bypassability requirement (Criterion 5) and the fail-closed behavior directly inherit from Anderson's completeness and verifiability properties.

Necula's proof-carrying code²⁰ provides a second foundational connection. In proof-carrying code, executable programs carry machine-checkable proofs that they satisfy specified safety properties; the host system verifies the proof before permitting execution. The authorization object described in Section 4.1.2 implements an analogous pattern: the AI governance verdict carries a machine-checkable proof (the constraint satisfaction record, policy binding, and cryptographic signature) that the governed action satisfies specified governance properties, and the downstream system verifies this proof before permitting execution. The structural parallel is exact.

Safety kernels (minimal, formally verified enforcement layers that mediate all safety-critical operations) and capability-based security systems (which require unforgeable tokens of authority for resource access) provide additional architectural precedent. The authorization object functions as a capability token: it is unforgeable (cryptographically signed), scoped (bound to specific policy and governed state), and required (no execution without it). These connections situate the authorization governance model within a mature body of security engineering, rather than presenting it as a novel invention. The contribution of this paper is not the enforcement architecture itself, but its application to AI governance and the formal framework for distinguishing it from observability systems.

7.2 AI Governance Frameworks

Several formal frameworks contribute relevant primitives to the enforcement/observability analysis. The Five Tests Standard (5TS)²¹ operationalizes the concept of proof-carrying decisions through a five-test conformance regime (Stop, Ownership, Replay, Escalation, Provenance) designed for vendor-neutral evaluation of AI governance claims. Provenance means established origin of the inputs grounding the verdict; it is origin, not truth. The current machine-checkable conformance bundle covers the four predecessor tests;²² machine-checkable Provenance conformance is deferred until input-origin binding is specified. The Deterministic Governance formal definition²³ (requiring pre-execution authorization where identical governed state produces identical verdicts with independently replayable artifacts) provides the theoretical foundation for the authorization category described in Section 3.2. Type-theoretic approaches, including dependent types and refinement types, offer verification substrates that can operate within authorization frameworks but do not themselves constitute governance mechanisms, as they lack policy authority, temporal evolution handling, and human escalation capabilities.

These frameworks collectively suggest that the field is converging toward formal evaluation criteria for AI governance claims, moving beyond qualitative maturity models toward testable, binary conformance requirements. The enforcement test protocol presented in this paper contributes to this convergence by providing a minimally sufficient set of criteria for the specific enforcement/observability distinction.

8. Conclusion

This paper has argued that the current AI governance landscape suffers from a consequential conflation: the equation of compliance instrumentation with runtime governance. We have formalized this distinction through an architectural taxonomy, a set of key doctrinal analyses (cryptographic signing semantics, GDPR Article 22 enforcement, continuous compliance), and an Enforcement Test Protocol that provides binary evaluation criteria for any system's governance claims.

The framework rests on a single, testable thesis: governance without enforceability is advisory. An AI governance system that cannot prevent unauthorized actions, one that can only document them after the fact, provides compliance instrumentation, not governance enforcement. This is a structural property of the architecture, not a feature gap to be addressed in the next release. Evidence-routing systems and authorization substrates require different design primitives, address different threat models, and provide different regulatory guarantees.

Both are necessary. Neither is sufficient alone. The field advances when it can name the distinction clearly, evaluate systems against it rigorously, and architect solutions that provide both observability and enforcement in proper relationship.

We close with the doctrinal summary that motivates the framework and that serves as a shared reference across the FERZ governance research program:

Doctrine.

Observability governs accounts of action. Authorization governs permission to act. SDLC controls constrain deployment; they do not constrain individual runtime decisions once deployed. Signed artifacts protect history; signed authorizations govern the future.

The enforcement test protocol is offered as a public evaluation tool. Organizations, regulators, and researchers can apply it to any system claiming to provide AI governance and receive a clear, binary classification. The goal is not to diminish the value of compliance engineering but to ensure that when governance enforcement is required, it is actually present: architecturally, cryptographically, and operationally.

References

Anderson, J. P. (1972). Computer Security Technology Planning Study. Technical Report ESD-TR-73-51, Vol. II. U.S. Air Force Electronic Systems Division.

Anderson, R. (2020). Security Engineering: A Guide to Building Dependable Distributed Systems, 3rd ed. Wiley.

Cavoukian, A. (2011). Privacy by Design: The 7 Foundational Principles. Information and Privacy Commissioner of Ontario.

CISA (2023). Secure-by-Design: Shifting the Balance of Cybersecurity Risk. Joint guidance.

European Parliament & Council (2016). Regulation (EU) 2016/679 (General Data Protection Regulation).

European Parliament & Council (2024). Regulation (EU) 2024/1689 (EU AI Act).

Executive Office of the President (2023). Executive Order 14110, Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence. Rescinded January 20, 2025.

Executive Office of the President (2025). Executive Order 14179, Removing Barriers to American Leadership in Artificial Intelligence. January 23, 2025.

Gebru, T. et al. (2021). Datasheets for Datasets. Communications of the ACM, 64(12), 86-92.

ISO/IEC 42001:2023. Information technology. Artificial intelligence. Management system.

Meyman, E. (2025). Four Tests Standard for Verifiable AI Systems (4TS). Predecessor standard, superseded by the Five Tests Standard. FERZ, Inc. Repository: github.com/edmeyman/4ts-standard (name retained).

Meyman, E. (2026). Five Tests Standard for Verifiable AI Systems (5TS), v1.2.0. FERZ, Inc. DOI: 10.5281/zenodo.21040296. Concept DOI: 10.5281/zenodo.21040295. Specification: github.com/edmeyman/4ts-standard.

Meyman, E. (2026). A Taxonomy of AI Governance Approaches: Distinguishing Visibility, Alignment, and Authorization. FERZ, Inc. Concept DOI: 10.5281/zenodo.18275969.

Mitchell, M. et al. (2019). Model Cards for Model Reporting. Proceedings of FAT* '19.

Necula, G. C. (1997). Proof-Carrying Code. Proceedings of the 24th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL '97), 106-119.

NIST (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1.

Ribeiro, M. T. et al. (2016). "Why Should I Trust You?": Explaining the Predictions of Any Classifier. Proceedings of KDD '16.

Selbst, A. D. & Powles, J. (2017). Meaningful information and the right to explanation. International Data Privacy Law, 7(4), 233-242.

White House (2025). America's AI Action Plan. July 2025.

Appendix A: Enforcement Test Protocol Quick Reference

The following is a condensed version of the Enforcement Test Protocol suitable for use in vendor evaluations, procurement diligence, and regulatory assessments.

#	Criterion	Test Question	FAIL Indicator
1	Enforcement Point	Does the system interpose a gate between AI output and action?	AI output can reach destination without governance evaluation
2	Signature Precondition	Is a signed authorization required before execution proceeds?	Execution proceeds without or regardless of signature
3	Missing Evidence / Evaluation Failure	Does missing evidence or evaluation failure resolve to ABSTAIN and block execution?	Execution continues, or missing evidence is treated only as a documentation exception
4	Policy-State Binding	Is the verdict bound to specific policy version + governed state?	Generic "compliant" attestation without binding
5	Non-Bypassability	Can any execution path circumvent the gate?	Alternative routes exist that skip governance
6	Override Governance	Are overrides governed actions within the authorization framework?	Overrides bypass rather than operate within governance

Table A1: Enforcement Test Protocol quick reference. All six criteria must be satisfied for authorization governance classification.

Scoring: 6/6 = Authorization Governance. 0-5/6 = Evidence-Routing or lower. There is no partial authorization governance. The protocol is a minimum necessary test; passing it is necessary but not sufficient for comprehensive governance evaluation.

Footnotes

1. Meyman, E. (2026). A Taxonomy of AI Governance Approaches: Distinguishing Visibility, Alignment, and Authorization. FERZ, Inc. Concept DOI: 10.5281/zenodo.18275969. ↩

2. Regulation (EU) 2024/1689 (EU AI Act), establishing harmonised rules on artificial intelligence. ↩

3. Regulation (EU) 2016/679 (General Data Protection Regulation), Art. 22: Automated individual decision-making, including profiling. ↩

4. Executive Order 14110, Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence (Oct. 30, 2023), was rescinded on January 20, 2025 and superseded by the competitiveness-oriented framework under Executive Order 14179 (Jan. 23, 2025), OMB Memoranda M-25-21 and M-25-22 (April 2025), and America's AI Action Plan (July 2025). See Section 6.4. ↩

5. Cavoukian, A. (2011). Privacy by Design: The 7 Foundational Principles. ↩

6. CISA, Secure-by-Design Principles (2023). Joint guidance from international cybersecurity agencies. ↩

7. Mitchell, M. et al. (2019). Model Cards for Model Reporting. FAT* '19. ↩

8. Gebru, T. et al. (2021). Datasheets for Datasets. Communications of the ACM, 64(12). ↩

9. Ribeiro, M. T. et al. (2016). "Why Should I Trust You?": Explaining the Predictions of Any Classifier. KDD '16. ↩

10. ISO/IEC 42001:2023, Information technology. Artificial intelligence. Management system. ↩

11. NIST AI Risk Management Framework (AI RMF 1.0), January 2023. ↩

12. Regulation (EU) 2016/679 (General Data Protection Regulation), Art. 22: Automated individual decision-making, including profiling. ↩

13. Selbst, A. D. & Powles, J. (2017). Meaningful information and the right to explanation. International Data Privacy Law, 7(4). ↩

14. Meyman, E. (2026). Five Tests Standard for Verifiable AI Systems (5TS), v1.2.0. FERZ, Inc. DOI: 10.5281/zenodo.21040296. Concept DOI: 10.5281/zenodo.21040295. ↩

15. The term "governance laundering" is introduced here to describe practices that satisfy surface-level governance criteria through trust-based, vendor-dependent, or non-replayable mechanisms. ↩

16. Regulation (EU) 2024/1689 (EU AI Act), establishing harmonised rules on artificial intelligence. ↩

17. Executive Order 14179, Removing Barriers to American Leadership in Artificial Intelligence (Jan. 23, 2025). OMB Memoranda M-25-21 and M-25-22 (April 3, 2025) replaced M-24-10 and M-24-18 respectively; America's AI Action Plan was issued under EO 14179 in July 2025. The rescission of EO 14110 did not automatically unwind downstream NIST publications, agency policies, or contract-level requirements, which remain in force until revised by their issuing bodies. ↩

18. Cf. Anderson, R. (2020). Security Engineering, 3rd ed. Wiley. Ch. 10 on access control and authorization systems. ↩

19. Anderson, J. P. (1972). Computer Security Technology Planning Study. Technical Report ESD-TR-73-51, Vol. II. U.S. Air Force Electronic Systems Division. ↩

20. Necula, G. C. (1997). Proof-Carrying Code. Proceedings of the 24th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL '97). ↩

21. Meyman, E. (2026). Five Tests Standard for Verifiable AI Systems (5TS), v1.2.0. FERZ, Inc. DOI: 10.5281/zenodo.21040296. Concept DOI: 10.5281/zenodo.21040295. Specification: github.com/edmeyman/4ts-standard. ↩

22. Four Tests Standard (4TS), predecessor standard to the Five Tests Standard. FERZ, Inc. Repository: github.com/edmeyman/4ts-standard (name retained). ↩

23. Meyman, E. (2026). A Taxonomy of AI Governance Approaches: Distinguishing Visibility, Alignment, and Authorization. FERZ, Inc. Concept DOI: 10.5281/zenodo.18275969. ↩