RA-153.1-2 — Architecting and testing the governed passage from intention to AI execution

Part I — Preamble

This part gives readers the reference points they need before the literature review and technical specification. It presents the problem, the RA-153.1-2 proposal, its research status and conceptual origins.

Chapter 00.01 — The problem: from intention to governed execution

As artificial intelligence becomes organizational infrastructure, a request no longer involves simply choosing a model. It may engage data, tools, agents, compute resources, providers, jurisdictions, costs, responsibilities and sometimes real-world effects.

The architectural question therefore becomes: how can an intention be understood, transformed into a processing strategy, authorized or refused, executed and then verified without confusing technical capability with authority to act?

RA-153.1-2 is proposed as a reference architecture for organizing this passage. It replaces neither models, inference engines, MCP/A2A, identity systems, authorization engines nor attestation mechanisms. It seeks to make their composition governable and inspectable.

What RA-153.1-2 contributes

• explicit separation between understanding the need, required capabilities, cognitive strategy, governance authority, execution and evidence;
• first-class governance outcomes: EXECUTE, ABSTAIN, REFUSE, ESCALATE ;
• resource selection only after the admissible space has been defined;
• a decision trace linking intention, policies, authority, execution and evidence;
• governance designed to survive replacement of models, providers, agents or runtimes.

Chapter 00.02 — What RA-153.1-2 is not

Chapter 00.03 — ZEON origins and epistemic status

ZEON is used here as a generative interpretive framework. The ZEON Key 153 carries the operation of preserving coherence through a passage between heterogeneous worlds, actors or levels. RA-153.1-2 is one of the engineering architectures generated from that operation for a specific domain: the passage between organizational intention and AI execution.

The technical architecture remains evaluable independently of adoption of the ZEON framework. The relationship concerns conceptual genesis, not an implementation dependency.

Chapter 00.04 — Thesis and limits

Proposed thesis. Sovereign AI infrastructure is not reducible to model location or ownership. It requires the ability to govern the conditions under which intention becomes execution: applicable policies, authority, admissibility, non-passage, resource selection, evidence, audit and revision.

Limits. Implementation simplicity, security, interoperability, policy robustness, the relevance of RA-Bench v0.1 and the value of the proposed experimental choices are not treated as demonstrated. They must be evaluated empirically. PGBS is retained only as a historical precursor of the measurement dimensions.

State of the art. v1.6 incorporates the corpus reviewed through 4 October 2026. It retains earlier sources, adds work published since 12 August 2026 that materially changes RA-153.1-2’s positioning, and systematically distinguishes functional precedents, specialized mechanisms and the candidate compositional contribution.

Part II — Foundations

Chapter 01.01 — AI’s Inflection Point

Purpose. This section establishes why artificial intelligence has entered a structural transition. Its aim is not to describe the latest models, but to explain why organizations are moving from experimentation to infrastructure.

1. A Change of Scale

Between 2022 and 2026, generative AI moved from a collection of impressive demonstrations to an operational capability embedded in software products, enterprise platforms and public services. In the first phase, most discussions concerned model quality: reasoning performance, coding ability, multilingual competence and context length.

As adoption accelerated, organizations discovered that deploying AI at scale involved far more than selecting the most powerful model. They needed governance, observability, security, routing, cost management, deployment flexibility and regulatory compliance.

The strategic question shifted from “Which model is best?” to “How should an organization govern many AI capabilities simultaneously?”

2. The Three Waves of Adoption

3. Why Infrastructure Matters

An enterprise rarely relies on a single AI system. Production environments combine commercial APIs, open-weight models, local inference, cloud services, vector databases, identity systems and monitoring platforms. Every additional component increases architectural complexity.

Key observation. Complexity grows faster than model capability. Infrastructure therefore becomes a competitive capability in its own right.

4. The Limits of Model-Centered Thinking

A model-centered strategy assumes that choosing the most powerful model is sufficient. In practice, organizations face conflicting requirements: confidentiality, cost, latency, legal constraints, resilience, sustainability and availability. Static model rankings cannot optimize these objectives simultaneously.

Routing decisions therefore become contextual. The same request may legitimately be processed by different models under different organizational policies.

5. Toward Policy-Driven AI

The central hypothesis developed throughout this Working Paper is that AI infrastructure needs an explicit governance layer. Rather than embedding routing logic in applications, organizations should express policies as inspectable, versioned objects.

Who may access which models? Which data may leave organizational boundaries? Which providers satisfy sovereignty constraints? How should failures be handled? Which decisions must remain auditable?

6. Transition

to the Next Section

The next section examines how this transition turns artificial intelligence from a collection of models into a genuine infrastructure layer comparable to cloud computing, networks and operating systems.

This is section 01.01 of Version 1.1. The complete Chapter 01 will eventually assemble ten sections into a single HTML publication.

Chapter 01.02 — From Models to Infrastructure

Purpose. This section explains why large language models should increasingly be understood as components of a wider infrastructure rather than isolated intelligent systems.

1. A Historical Perspective

Every major computing revolution eventually produced an infrastructure layer. Personal computers required operating systems. The Internet required routing protocols and cloud platforms. Similarly, generative AI is moving beyond individual models toward an ecosystem of interoperable services.

Era Main asset Infrastructure challenge

Mainframe Compute power Resource sharing

Internet Connectivity Global networking

Cloud Elastic compute Distributed operations

Generative AI Cognitive capabilities Policy-driven orchestration

2. Models Become Building Blocks

A production AI application rarely consists of a single model invocation. Instead, requests traverse identity services, security filters, retrieval systems, routing layers, observability platforms and logging services before reaching a model.

User
 │
Identity
 │
Policy
 │
Router
 │
Retrieval
 │
Model
 │
Validation
 │
Observability

The model remains essential, but it no longer defines the complete system.

3. Infrastructure Characteristics

Infrastructure differs from applications because it must remain reusable, interoperable and resilient. AI infrastructure therefore requires:

provider independence; stable interfaces; deployment flexibility; operational monitoring; security boundaries; continuous evolution.

4. The Rise of AI Platforms

Organizations increasingly combine frontier APIs, open-weight models, local inference engines and specialized services. This hybrid landscape creates architectural diversity that application code alone cannot manage effectively.

Infrastructure introduces abstraction. Applications express intention while infrastructure determines the most appropriate execution path under explicit organizational policies.

Infrastructure separates business intention from implementation details.

5. Architectural Consequences

The transition from model-centered software to infrastructure-centered systems has several consequences:

Traditional approach Infrastructure approach

Applications select models. Policies determine eligible execution targets.

Routing logic is embedded. Routing policies become reusable assets.

Optimization is local. Optimization is organizational.

Failures interrupt workflows. Fallback strategies preserve continuity.

6. Preparing the Next Transition

Once AI becomes infrastructure, another transformation follows naturally: organizations stop searching for a single “best model” and begin coordinating portfolios of complementary capabilities. The next section explores this transition toward multi-model ecosystems.

in the complete Chapter 01.

Chapter 01.03 — The End of the Single-Model Paradigm

Purpose. Explain why production AI systems are evolving toward coordinated ecosystems of complementary models rather than relying on a single general-purpose model.

1. The Universal Model Myth

Early public adoption of generative AI encouraged the perception that an increasingly capable model could satisfy every use case. Production experience revealed a different reality. Organizations balance reasoning quality, response time, operating cost, confidentiality, legal constraints and service continuity. No single model optimizes every objective simultaneously.

The question is no longer “Which model is best?” but “Which model is appropriate for this request, under these constraints, at this moment?”

2. Functional Specialization

Need Typical preference

Complex reasoning Frontier reasoning model

High-volume automation Small, inexpensive model

Sensitive information Local or private deployment

Software engineering Code-specialized model

Offline resilience Local open-weight runtime

Multimodal analysis Vision-capable model

3. Portfolio Thinking

Organizations increasingly manage AI resources as portfolios rather than individual assets. Models become interchangeable execution options governed by organizational objectives. This resembles cloud resource management more than traditional application design.

A model portfolio increases flexibility, but only if selection criteria are explicit and operationally governed.

4. New Sources of Complexity

Rapid model evolution. Provider-specific APIs. Changing pricing models. Regional availability constraints. Different license conditions. Operational failover requirements.

These factors make manual routing increasingly difficult to maintain over time.

5. Architectural Consequences

Business Intention
    │
Organizational Policy
    │
Eligibility Assessment
    │
Model Portfolio
    │
Execution
    │
Audit

The portfolio is therefore governed rather than hard-coded. Applications express intention; infrastructure determines execution.

6. Transition

The next section examines why routing itself becomes a strategic capability. Once organizations operate multiple models, routing decisions become one of their most important architectural responsibilities.

Chapter 01.04 — Why Routing Becomes Strategic

Purpose. Show why routing evolves from a technical mechanism into a strategic organizational capability.

1. Beyond Load Balancing

Historically, routing distributed requests across equivalent resources. AI infrastructure introduces a different problem: execution targets are no longer equivalent. They differ in reasoning quality, confidentiality guarantees, jurisdiction, cost, latency, sustainability and operational resilience.

Choosing an execution path becomes an organizational decision rather than a simple technical optimization.

2. Every Request Is a Decision

Question Architectural consequence

May this data leave the organization? Evaluate confidentiality policy.

Is premium reasoning justified? Balance quality and cost.

Must execution remain in Europe? Enforce sovereignty constraints.

What if the preferred provider is unavailable? Activate governed fallback.

Must this decision be reproducible? Record the routing rationale.

3. Routing as Governance

Once several providers coexist, routing becomes the operational expression of organizational policy.

Business Intention
    │
Organizational Policies
    │
Eligibility Analysis
    │
Candidate Assessment
    │
Routing Decision
    │
Execution
    │
Audit Trace

The router should not invent policy. It should execute the explicit policies established by the organization.

4. Multi-Objective Trade-Offs

No single optimization criterion is sufficient. Modern AI infrastructures continually balance

multiple objectives.

Objective Possible trade-off

Quality Higher compute cost.

Latency Reduced reasoning depth.

Confidentiality Restricted model choice.

Resilience Additional infrastructure complexity.

Sustainability Alternative execution paths.

5. Strategic Consequences

Policies become reusable organizational assets. Applications become provider-independent. Governance becomes inspectable. Operational continuity improves through planned fallback. Infrastructure evolution becomes less disruptive.

6. Preparing for RA-153.1-2

The remaining sections establish why governance should replace hard-coded configuration. This transition provides the conceptual foundation for the RA-153.1-2 architecture introduced later in this Working Paper.

Chapter 01.05 — Governance Instead of Configuration

Purpose. Explain why organizational AI behavior should be governed by explicit policies rather than hidden configuration scattered across applications.

1. Configuration Does Not Scale

During the first wave of AI adoption, routing choices were frequently embedded directly in application code, prompt templates or environment variables. This approach is simple for prototypes but becomes increasingly fragile as organizations introduce multiple providers, deployment targets and regulatory constraints.

When organizational decisions remain hidden in application code, they cannot easily be reviewed, audited or improved.

2. From Settings to Policies

Configuration Governance

Hard-coded values Versioned policy objects

Application-specific Shared across systems

Difficult to audit Explicit decision trace

Developer ownership Joint technical and organizational ownership

Reactive maintenance Managed lifecycle

3. Policies as Organizational Knowledge

A routing policy expresses more than technical preferences. It captures organizational intention: which data may leave controlled environments, which providers are approved, acceptable budgets, continuity requirements, quality thresholds and compliance obligations.

Policies become reusable organizational assets rather than implementation details.

4. Governance Lifecycle

Policy Design
    │
Validation
    │
Approval
    │
Deployment
    │
Execution
    │
Monitoring
    │
Revision

Every stage should remain observable. Policy evolution is therefore treated as a managed process rather than an undocumented software change.

5. Organizational Benefits

Reduced dependence on individual implementations. Consistent behavior across applications. Simpler regulatory audits. Controlled evolution of routing strategies. Better collaboration between technical and governance teams.

6. Toward the Governance Plane

This perspective leads to the normative plane developed later in this Working Paper: a Governance Plane that uses, among other components, a Policy Engine to evaluate organizational rules without confusing rule evaluation with complete decision authority.

the complete HTML edition of Chapter 01.

Chapter 01.06 — Economic Drivers

Purpose. Explain why economics, as much as technology, drives the emergence of policy-driven AI infrastructure.

1. AI Has Become an Operating Expense

Unlike traditional software, generative AI incurs recurring inference costs. Every prompt, retrieval step, tool invocation and reasoning cycle consumes compute resources. As organizations expand AI adoption, operating expenditure becomes a primary architectural concern.

AI infrastructure is no longer optimized for capability alone. It must optimize sustainable capability.

2. The Cost Triangle

3. Heterogeneous Economics

Organizations increasingly combine commercial APIs, private infrastructure, open-weight models and specialized services. Each option has different economic characteristics in licensing, hardware investment, maintenance effort and operational flexibility.

Execution mode Typical advantage Typical limitation

Commercial API Rapid access to frontier models Recurring usage costs

Private cloud Governance and flexibility Infrastructure management

On-premises Data sovereignty Capital investment

Open-weight models Provider independence Operational complexity

4. Dynamic Cost Governance

Production environments require dynamic allocation strategies. Premium reasoning may be justified for complex analytical tasks, while routine operations can run efficiently on smaller models.

Infrastructure therefore becomes responsible for balancing economic efficiency with organizational objectives.

5. Beyond Direct Costs

Energy consumption. GPU utilization. Model-switching overhead. Operational resilience. Provider dependence.

Future migration costs.

These indirect factors often exceed the apparent cost of individual model invocations.

6. Strategic Implications

Organizations increasingly compete through the quality of their orchestration strategies rather than exclusive access to individual models. Economic intelligence becomes embedded in infrastructure policies.

Chapter 01.07 — Regulatory Drivers

Purpose. Explain why regulatory developments are turning AI infrastructure into governance infrastructure.

1. Regulation Changes the Design Problem

For many years, software architecture primarily optimized functionality, scalability and cost. Artificial intelligence introduces additional requirements: transparency, accountability, explainability, human oversight and traceability. These expectations increasingly arise from legislation, industry standards and organizational governance.

Compliance is no longer an external activity. It becomes an architectural property.

2. Beyond Technical Performance

Deploying the most capable model is insufficient if an organization cannot demonstrate why a particular decision path was chosen, which policies were applied or how sensitive information was protected.

Regulatory expectation Architectural consequence

Traceability Record routing decisions and execution history.

Accountability Identify responsible policies and operators.

Transparency Expose governance mechanisms.

Risk management Evaluate execution before inference.

Human oversight Enable review and intervention.

Regulatory compliance increasingly depends on infrastructure behavior rather than application behavior alone.

3. Sovereignty and Jurisdiction

Organizations increasingly need to determine where data may be processed, which providers satisfy jurisdictional requirements and how cross-border execution should be governed. Infrastructure therefore becomes responsible for enforcing organizational sovereignty policies.

4. Auditability by Design

Auditability should not be added after deployment. Every routing decision should be reproducible through explicit policies, recorded evidence and versioned governance rules.

Policy version. Execution target. Eligibility criteria. Fallback rationale. Decision timestamp.

5. From Compliance to Trust

Organizations able to explain how AI decisions are governed will generally inspire greater trust among customers, regulators and partners than those relying on opaque implementation choices.

Trust emerges when governance is observable.

6. Preparing the Infrastructure Perspective

The following sections extend this analysis by examining the technical infrastructure needed to operationalize governance at scale. Routing, policies, observability and orchestration converge into a unified architectural layer.

Chapter 01.08 — Infrastructure Drivers

Purpose. Demonstrate that AI infrastructure evolution is driven not only by model innovation but by the operational requirements of deploying reliable, secure and scalable systems.

1. Infrastructure Becomes the Differentiator

As frontier models become widely accessible, competitive advantage increasingly shifts from model access to infrastructure quality. Reliability, governance, interoperability and operational resilience become strategic assets.

Models generate intelligence. Infrastructure makes that intelligence reliable.

2. Operational Requirements

Requirement Infrastructure capability

High availability Redundancy and failover

Security Identity, isolation and policy enforcement

Scalability Elastic routing and load distribution

Observability Metrics, tracing and audit logs

Portability Provider-independent execution

Resilience Graceful degradation and recovery

3. Hybrid AI Environments

Most organizations will operate hybrid environments combining cloud APIs, private infrastructure, local inference engines and specialized AI services. Infrastructure must coordinate these heterogeneous resources while preserving a unified operating model.

Hybrid execution becomes the default architecture rather than an exception.

4. Observability as a Core Capability

Infrastructure must provide continuous visibility into execution paths, latency, costs, failures, policy evaluations and resource use. Without observability, governance cannot be verified and optimization becomes speculative.

Intention
 │
Policy Evaluation
 │
Routing
 │
Execution
 │
Telemetry
 │
Continuous Improvement

5. Infrastructure Independence

Long-term sustainability requires reducing dependence on a single AI provider. Provider independence allows organizations to adopt future models, migrate workloads and respond to technological change without redefining business applications.

6. Toward a Unified Infrastructure Layer

These operational forces naturally converge toward a dedicated orchestration layer capable of applying policies, selecting execution paths, recording decisions and coordinating heterogeneous AI resources.

Chapter 01.09 — Organizational Drivers

Purpose. Show that AI transformation is fundamentally organizational. Sustainable AI adoption depends on governance, responsibilities and institutional learning as much as technology.

1. AI Changes Organizations

Early AI projects were often launched by isolated technical teams. As adoption expands, AI affects legal departments, security teams, compliance officers, business units, procurement, operations and executive management. Infrastructure therefore becomes an

organizational platform rather than a technical component.

Successful AI adoption is measured by organizational coherence, not model capability alone.

2. Emerging Roles

Role Main responsibility

Executive management Strategic direction and accountability.

Architecture teams Infrastructure design and interoperability.

Governance office Policies, risk management and oversight.

Operations Reliability, monitoring and continuity.

Business units Operational objectives and value creation.

3. Shared Decision-Making

Routing policies increasingly encode organizational choices rather than technical preferences. Decisions on confidentiality, acceptable cost, sovereignty, sustainability and resilience require collaboration across disciplines.

Policy-driven infrastructure encourages a common language among technical, operational and governance teams.

4. Organizational Learning

Every routing decision generates operational knowledge. Observability and auditability turn infrastructure into a learning system capable of continually refining organizational policies.

5. Governance as a Capability

Organizations should treat governance as a core capability that evolves alongside applications and models. Governance is not a constraint imposed on innovation; it is the mechanism that allows innovation to develop safely.

6. Preparing the Conclusion

The combined technological, economic, regulatory and organizational forces described throughout this chapter show that AI is entering an infrastructure era. The conclusion synthesizes these forces and introduces the architectural perspective developed in the rest of this Working Paper.

Chapter 01.10 — Conclusions

Purpose. Synthesize the forces examined throughout Chapter 01 and establish the architectural transition toward policy-driven AI infrastructure.

1. A Structural Transition

The preceding sections described seven complementary forces shaping the next generation of AI systems: technological evolution, infrastructure requirements, multi-model orchestration, governance, economics, regulation and organizational transformation. Taken together, these forces reveal a structural transition rather than a passing technological trend.

Artificial intelligence is becoming infrastructure. Infrastructure requires governance.

2. The Emerging Consensus

Observation Architectural implication

Multiple models coexist. Routing becomes essential.

Providers evolve continually. Applications must remain provider-independent.

Regulation increases. Policies must become explicit and auditable.

Operational complexity grows. Infrastructure becomes a strategic capability.

Organizations diversify AI use. Governance must extend across domains.

3. From Configuration to Architecture

The central conclusion is that governance cannot remain distributed across application code, deployment scripts and undocumented operational practices. It must become a first-class architectural layer capable of evaluating policies before execution decisions are made.

The next generation of AI systems will be distinguished less by the intelligence of individual models than by the quality of the infrastructure coordinating them.

4. Positioning RA-153.1-2

This conclusion prepares the conceptual space for RA-153.1-2. Rather than introducing another model or orchestration framework, RA-153.1-2 is presented as a policy-driven reference architecture designed to connect organizational intention, governance policies and heterogeneous AI execution environments.

5. Transition to Chapter 02

Before introducing the architecture itself, the next chapter reviews the current state of the art. Existing routing frameworks, gateways, orchestration platforms and serving infrastructures are analyzed to identify their contributions, limits and remaining architectural gaps.

Only by understanding today’s ecosystem can we properly position tomorrow’s infrastructure.

Chapter 01 complete. Together, its ten sections establish the rationale for a new generation of sovereign, policy-driven AI infrastructure. They provide the theoretical foundation for the detailed architectural analysis in the remainder of Working Paper 006.

Working Paper 006 · Master Edition · Part II · Complete assembly preserving sources

Part III — State of the Art

RA-153.1-2 — Architecting Sovereign AI Infrastructure. Editorial status. This page assembles the thirteen detailed source sections supplied for Chapter 02. Text, tables, citations, notes and diagrams are preserved. Only the outer document structure, navigation and shared presentation have been added.

Chapter 02.01 — State of the Art: the Emerging AI Infrastructure Landscape

Purpose. Establish the current technology landscape before introducing RA-153.1-2. Rather than comparing models, this chapter compares infrastructure philosophies.

1. From Models to Platforms

The first generation of generative AI emphasized model performance. The current generation is increasingly defined by infrastructure platforms responsible for routing, deployment, orchestration, serving, observability and lifecycle management. This shift has created a rich ecosystem of complementary technologies.

The market is no longer organized around individual models but around the infrastructure coordinating them.

2. Main Categories

Category Representative technologies Main focus

Model routing OpenRouter, LiteLLM Provider abstraction and access.

Application frameworks LangChain, LlamaIndex Workflow composition.

Inference engines vLLM, SGLang Efficient model serving.

Deployment platforms Ray Serve, KServe Production operations.

Local AI Ollama Workstation and private execution.

Model ecosystems Hugging Face Distribution and collaboration.

Although these platforms solve important operational problems, they generally optimize execution rather than organizational governance.

3. Shared Strengths

Rapid integration with multiple models. Operational scalability. Increasing ecosystem maturity. Developer productivity. Broad cloud compatibility.

4. Shared Architectural Gap

Most current platforms expose configuration mechanisms, routing strategies and operational controls. Far fewer provide a first-class governance layer capable of expressing organizational intention as reusable, auditable, versioned policy objects.

Infrastructure orchestration is maturing. Governance orchestration remains an open research field.

5. Positioning the Remaining Review

The following sections analyze each major platform individually. Their purpose is not to rank technologies, but to identify the architectural capabilities they provide and the remaining governance gaps. This comparative analysis prepares the introduction of RA-153.1-2 as a complementary reference architecture.

PROPOSED Comparison methodology. Each “Position Relative to RA-153.1-2” section below is a conceptual comparison: it contrasts the documented capabilities of an existing, deployed technology (see the primary source cited at the start of each chapter) with the design principles proposed by RA-153.1-2 in Part IV. This is not an empirical or practical comparison: at the time of this Working Paper, RA-153.1-2 has not been directly compared with these technologies under shared conditions. Chapter 05.06 (Empirical Validation and Experimental Roadmap) specifies the current status of this empirical work. Readers should interpret the following two-column tables as positioning exercises between an observed system and a proposed system, not as measured results.

Next section: Chapter 02.02 — OpenRouter: Provider Abstraction and Unified Access.

Chapter 02.02 — OpenRouter: Provider Abstraction and Unified Access

Purpose. Examine OpenRouter as an important step in AI infrastructure evolution and identify both its architectural contributions and remaining governance limitations.

OBSERVED Primary source: OpenRouter — official documentation.

1. Architectural Role

OpenRouter introduces a unified API exposing models from multiple providers through a consistent interface. This abstraction reduces application dependence on provider-specific APIs and simplifies experimentation across a rapidly evolving ecosystem.

OpenRouter primarily solves the access problem. It does not seek to solve the wider problem of organizational governance.

2. Main Contributions

Capability Contribution

Unified API Common interface across providers.

Model catalog Rapid access to numerous frontier and open models.

Developer experience Reduced integration effort.

Flexibility Easier provider comparison.

3. Architectural Strengths

Accelerates adoption of heterogeneous AI services. Reduces provider dependence at API level. Encourages modular application design. Supports rapid technological evolution.

OpenRouter demonstrates that provider abstraction is becoming an essential infrastructure capability.

4. Remaining Challenges

Provider abstraction alone does not express organizational intention. Questions of sovereignty, regulatory compliance, acceptable cost, confidentiality and organizational priorities remain external to the routing layer.

Question Typically outside OpenRouter’s scope

Why was this model selected? Governance policy.

Who approved the routing rule? Policy lifecycle.

Which legal constraints apply? Organizational governance.

How is the decision audited? Decision traceability.

Chapter 02.03 — LiteLLM: A Unified Model Gateway

Purpose. Analyze LiteLLM as a gateway layer for heterogeneous AI providers and

clarify where operational orchestration ends and governance begins.

OBSERVED Primary source: LiteLLM — official documentation.

1. Architectural Position

LiteLLM provides a unified programming interface for many commercial and open-source language models. Beyond API normalization, it introduces gateway capabilities that simplify production deployment and operational management.

LiteLLM addresses operational complexity by standardizing access to diverse model providers.

2. Core Capabilities

Capability Contribution

Unified API Common interface across providers.

Gateway Centralized request management.

Fallback Automatic provider substitution.

Load balancing Traffic distribution across models.

Usage monitoring Operational visibility and quotas.

Caching Reduced latency and cost.

3. Operational Strengths

Improves production resilience. Facilitates multi-provider deployment. Reduces integration effort. Supports cost-optimization strategies. Provides operational observability.

LiteLLM significantly extends provider abstraction by introducing execution-management capabilities expected in production environments.

4. Governance Boundaries

LiteLLM already includes access-control primitives beyond execution alone: virtual keys and team/user budgets, and guardrails such as content filtering or personal-information masking. These are access and cost controls, however, rather than organizational policy objects: they do not carry authorship, approval workflows, review cycles or a traceable link to the institutional decision justifying them. LiteLLM generally assumes the underlying strategy—why a particular budget, key scope or filter was chosen—has already been decided elsewhere.

Operational gateway Governance layer

Performs routing and enforces configured limits. Defines why a particular limit or routing rule should exist.

Enforces access control by key, team or user. Evaluates the organizational policy behind that access authorization.

Optimizes execution and cost. Optimizes institutional objectives.

Manages infrastructure and guardrail configuration. Manages the policy lifecycle: authorship, approval, review, audit.

Chapter 02.04 — LangChain: Application Orchestration and Agent Workflows

Purpose. Analyze LangChain as one of the most influential application-orchestration frameworks and distinguish workflow orchestration from governance orchestration.

OBSERVED Primary source: LangChain — official documentation.

1. Architectural Perspective

LangChain emerged to help developers compose language models with prompts, memory, retrieval systems, external tools and agents. Rather than focusing on infrastructure management, it focuses on application construction.

LangChain orchestrates cognitive workflows. It does not define institutional governance.

2. Main Capabilities

Capability Contribution

Chains Composable processing pipelines.

Agents Dynamic tool selection.

Tool integration Connection to external systems.

Memory Conversation and state management.

RAG support Knowledge-retrieval integration.

3. Architectural Strengths

Rapid AI application prototyping. Rich integration ecosystem.

Flexible agent-based workflows. Support for complex application logic.

LangChain has become an application framework rather than an infrastructure governance platform.

4. Architectural Limits

LangChain assumes that execution environments, routing strategies and organizational constraints already exist. Governance policies generally remain external to the framework.

LangChain Governance layer

Coordinates application logic. Coordinates organizational intention.

Builds workflows. Evaluates policies.

Runs agents. Constrains execution.

Optimizes application behavior. Optimizes institutional behavior.

Chapter 02.05 — vLLM: High-Performance Inference Infrastructure

Purpose. Analyze vLLM as a reference implementation for efficient model serving at scale and distinguish inference optimization from governance orchestration.

OBSERVED Primary source: vLLM — official documentation.

1. Architectural Perspective

vLLM addresses a major operational challenge of generative AI: efficiently serving large language models at production scale. Rather than introducing new reasoning capabilities, it optimizes how existing models consume GPU memory and compute resources.

vLLM improves how models run. It does not determine why a particular model should run.

2. Main Contributions

Capability Contribution

PagedAttention Efficient KV-cache memory management.

High throughput Improved request concurrency.

GPU utilization Better hardware efficiency.

Scalable serving Production-oriented inference engine.

Open ecosystem Broad compatibility with modern LLMs.

vLLM demonstrates that inference infrastructure has become a specialized engineering discipline in its own right.

3. Operational Strengths

Higher throughput under production load. Reduced GPU memory fragmentation. More efficient large-model serving. Lower operating cost per inference. A strong foundation for enterprise deployment.

4. Architectural Boundaries

vLLM intentionally focuses on execution performance. Questions of organizational priorities, regulatory constraints, sovereignty, approval workflows and policy evaluation remain outside its scope.

Inference layer Governance layer

Optimizes execution speed. Evaluates organizational policies.

Allocates GPU resources. Selects eligible execution paths.

Serves models efficiently. Determines which models may be served.

Improves infrastructure performance. Improves institutional decision quality.

Chapter 02.06 — Ollama: Local Inference and Sovereign AI

Purpose. Analyze local inference as a strategic architectural option and examine Ollama as one of the most influential technologies supporting sovereign AI deployments.

OBSERVED Primary source: Ollama — official website.

1. The Return of Local Computing

For more than a decade, cloud computing dominated enterprise architecture. Generative AI introduces a partial reversal of that trend. Growing concerns about confidentiality, latency, operational resilience and digital sovereignty encourage organizations to run some models directly on local infrastructure.

The future of AI is unlikely to be exclusively cloud-based. It will be hybrid.

2. Ollama’s Architectural Contribution

Ollama simplifies deployment and execution of open-weight language models on local workstations, servers and edge devices. By reducing operational complexity, it makes local inference accessible to developers, researchers and organizations without requiring specialized serving infrastructure.

Capability Contribution

Local execution Runs models without external API dependence.

Simple deployment Rapid installation and model management.

Developer workflow Consistent local experimentation.

Confidentiality Data remains under organizational control.

Offline capability Continues operating without Internet connectivity.

Ollama lowers the operational barrier to local AI and thereby strengthens technological sovereignty.

3. Strategic Advantages

Protection of sensitive information. Reduced dependence on external providers. Lower network latency. Improved operational continuity. Greater control over infrastructure evolution.

4. Remaining Challenges

Local execution does not automatically solve governance problems. Organizations must still determine which models may be deployed, who may use them, how versions are validated and how execution decisions remain traceable across distributed environments.

Local infrastructure Governance requirement

Runs models locally. Determines which models are authorized.

Protects local data. Defines organizational data policy.

Executes requests. Evaluates institutional constraints.

Supports edge deployment. Coordinates hybrid environments.

Chapter 02.07 — Hugging Face: the Open AI Ecosystem

Purpose. Examine Hugging Face as the reference ecosystem for open artificial intelligence and explain how collaborative AI ecosystems differ from governance infrastructure.

OBSERVED Primary source: Hugging Face Hub — official documentation.

1. Beyond a Model Repository

Although Hugging Face is often described as a model hub, it has evolved into a comprehensive ecosystem supporting models, datasets, evaluation benchmarks, documentation, demonstrations, collaborative development and deployment workflows.

Hugging Face is not simply a repository. It is infrastructure for open AI collaboration.

2. Ecosystem Components

Hugging Face’s success shows that open ecosystems accelerate innovation by lowering barriers to experimentation and collaboration.

3. Architectural Strengths

Broad model availability. Strong framework interoperability. Rapid research dissemination. A large collaborative community. Support for reproducible experimentation.

4. Governance Challenges

Open ecosystems maximize accessibility, but organizations remain responsible for validating licenses, assessing model quality, enforcing security requirements, evaluating regulatory constraints and determining operational eligibility.

Open ecosystem Governance requirement

Publishes models. Selects approved models.

Shares datasets. Validates legal and ethical use.

Encourages experimentation. Controls production deployment.

Accelerates innovation. Manages institutional risk.

Chapter 02.08 — Ray Serve & KServe: Production AI Serving Platforms

Purpose. Analyze two leading production-serving platforms and distinguish deployment orchestration from organizational governance.

OBSERVED Primary source: Ray Serve — official documentation.

OBSERVED Primary source: KServe — official documentation.

1. Industrializing AI Deployment

As AI moves from prototypes to critical services, organizations need deployment platforms capable of scaling inference, managing versions, ensuring resilience and

integrating with cloud-native environments. Ray Serve and KServe represent two influential approaches to this challenge.

Serving platforms industrialize model execution. They do not define institutional decision policies.

2. Comparative Perspective

Capability Ray Serve KServe

Scalable serving Native distributed execution Kubernetes-native serving

Autoscaling Built in Built in

Model lifecycle Application-centered Kubernetes-centered

Cloud integration Strong Strong

Production operations High High

3. Architectural Contributions

Reliable deployment at scale. Elastic resource allocation. Version management. Operational resilience. Cloud-native integration.

These platforms address operational excellence, allowing AI systems to function reliably in production.

4. Governance Gap

Neither platform is primarily responsible for evaluating organizational intention. Regulatory eligibility, sovereignty, confidentiality, acceptable providers and institutional priorities remain external to deployment orchestration.

Serving platform Governance layer

Deploys models. Selects eligible models.

Scales workloads. Evaluates organizational constraints.

Maintains availability. Maintains policy coherence.

Runs infrastructure. Guides infrastructure decisions.

Chapter 02.09 — SGLang & NVIDIA Dynamo: High-Performance AI Runtimes

Purpose. Examine specialized AI runtimes designed to maximize inference efficiency and explain why runtime optimization remains distinct from governance orchestration.

OBSERVED Primary source: NVIDIA Dynamo — official documentation.

1. The Rise of AI Runtime Engineering

As foundation models grow in size and complexity, execution efficiency becomes a strategic concern. Modern AI runtimes optimize scheduling, memory allocation, batching and hardware utilization to provide higher throughput while reducing operating costs.

Runtime engineering optimizes computation. Governance engineering optimizes organizational decisions.

2. Two Complementary Approaches

Technology Main focus

SGLang Efficient execution of complex LLM workflows and structured generation, using RadixAttention for automatic prefix-cache reuse across requests.

NVIDIA Dynamo Distributed multi-node inference orchestration: disaggregated prefill/decode serving, KV-cache-aware request routing and accelerated cache transfers across GPU, CPU and storage tiers through NIXL (NVIDIA Inference tranXfer Library).

OBSERVED Dynamo separates compute-bound prefill from memory-bound decode on independently scaled workers and can use SGLang, vLLM or TensorRT-LLM as its underlying execution engine—illustrating that runtime engineering and inference-engine choice are themselves becoming a distinct architectural layer, preceding the governance question addressed by this Working Paper.

3. Architectural Contributions

Advanced request scheduling, including disaggregated prefill/decode execution. Optimized GPU utilization and dynamic scheduling based on real-time demand. Reduced inference latency through KV-cache-aware routing that avoids redundant recomputation. Higher throughput through accelerated RDMA-based transfers (NIXL) across memory tiers. Production-scale AI serving across multiple inference engines (SGLang, vLLM, TensorRT-LLM).

These technologies represent a new generation of runtime software in which software and hardware architecture evolve together.

4. Architectural Boundaries

Neither SGLang nor NVIDIA Dynamo evaluates institutional priorities, regulatory constraints or organizational trust policies. Their responsibility begins after execution decisions have already been made.

Runtime layer Governance layer

Optimizes execution. Selects execution policies.

Schedules computation. Schedules organizational intention.

Uses hardware efficiently. Uses AI resources responsibly.

Improves performance. Improves accountability.

Chapter 02.10 — Model Context Protocol (MCP): Standardizing AI Interoperability

Purpose. Analyze Model Context Protocol (MCP) as an interoperability standard and distinguish protocol standardization from governance orchestration.

OBSERVED Primary source: Model Context Protocol — official specification.

1. From APIs to AI Protocols

As AI systems increasingly rely on external tools, enterprise data, software services and autonomous workflows, interoperability becomes a strategic architectural concern. MCP introduces a common protocol enabling language models to interact with external capabilities in a standardized way.

MCP standardizes communication between AI systems and tools. It does not determine whether that communication should take place.

2. Architectural Contributions

Capability Contribution

Standardized interfaces Common interaction model between models and tools.

Tool discovery Structured description of available capabilities.

Context exchange Consistent transmission of information.

Ecosystem growth Interoperability across heterogeneous AI environments.

Protocols reduce integration complexity by allowing independent systems to communicate through shared conventions rather than custom interfaces.

3. Strategic Value

Improves AI application portability. Encourages reusable tool ecosystems. Facilitates enterprise integration. Supports modular AI architectures. Promotes long-term interoperability.

4. Governance Perspective

MCP remains intentionally neutral toward organizational policies. It specifies how interactions occur, not whether they are authorized, compliant, auditable or strategically appropriate.

MCP RA-153.1-2

Standardizes communication. Governs communication policies.

Defines protocol semantics. Defines organizational rules.

Enables interoperability. Evaluates authorization.

Connects systems. Coordinates institutional intention.

Chapter 02.11 — Comparative Matrix of Existing AI Infrastructure Solutions

Purpose. Synthesize the state of the art by positioning major AI infrastructure technologies according to their primary architectural responsibilities.

1. Comparative View

Technology Primary role Main strength Governance scope

OpenRouter Provider abstraction Unified model access Limited

LiteLLM Gateway & routing Operational flexibility Limited

LangChain Application workflows Agent orchestration External

vLLM Inference engine Execution performance None

Ollama Local inference Sovereign execution Local only

Hugging Face Open ecosystem Knowledge sharing External

Ray Serve Serving platform Scalable deployment Infrastructure only

KServe Kubernetes serving Cloud-native serving Infrastructure only

SGLang AI runtime Workflow execution None

NVIDIA Dynamo Runtime acceleration Hardware optimization None

MCP Interoperability protocol Standardized communication Protocol only

The comparison reveals a highly mature execution ecosystem covering access, orchestration, serving, runtime optimization and interoperability.

2. Emerging Architectural Pattern

Despite their diversity, these technologies naturally form complementary architectural layers:

Access and provider abstraction. Application orchestration. Inference execution. Serving infrastructure. Runtime optimization. Interoperability protocols.

Together, they form an increasingly complete operational stack for enterprise AI.

3. A Gap Identified at the Time — Historical Formulation

One observation consistently emerges across the original review: while execution capabilities have become highly sophisticated, explicit organizational governance remains largely external to the execution stack.

Current infrastructures address how AI systems operate. They rarely formalize why a particular operational decision is institutionally appropriate.

4. Transition

The following chapter examines this architectural gap and motivates a governance-centered

reference architecture.

Chapter 02.11A — 2026 Update: Runtime Governance, Authorization and Evidence

Purpose. Update the RA-153.1-2 comparison beyond routers and inference engines by considering mechanisms that operationalize policies, authorization and attestation close to execution.

1. Runtime Governance

Microsoft Agent Governance Toolkit, published in April 2026, emphasizes deterministic policy enforcement, identity, isolation and audit for agents. Governance thus becomes an explicit architectural responsibility of the execution control plane.

2. Agent Authorization

OpenFGA documents agents as principals with their own permissions. In parallel, OpenID AuthZEN is developing authorization profiles for agent architectures and MCP. The question “who or what may perform which action, in which context?” is becoming standardizable.

3. Evidence and Attestation

Proof-Carrying Agent Actions (PCAA), CAVA and Proof of Execution bring evidence closer to action: certificates, approvals, receipts, replay, canonicalization and attestation. IETF RATS-derived mechanisms also strengthen verification of platform state and execution.

Chapter 02.11B — Functional Precedents: Semantics, Capabilities and Cognition

Purpose. Determine whether significant precedents exist for the functions made explicit by RA-153.1-2—semantic resolution, capability resolution, cognitive-strategy choice, governance before execution and evidence.

1. Semantic Routing

When to Reason: Semantic Router for vLLM (2025) classifies requests according to their reasoning needs. Semantic routing can therefore already concern inference mode or depth, not only provider selection.

2. Choosing a Cognitive Strategy

Select-then-Solve (2026) compares reasoning paradigms and proposes dynamically selecting the most appropriate one. RA-153.1-2 therefore does not claim to have invented cognitive routing; it proposes a distinct architectural place for it, separate from governance authority.

3. Metacognition and Delegation

Governed Reasoning for Institutional AI, MetaCogAgent and work on metacognitive policy illustrate delegation, review and human involvement as structural functions.

4. Governance-First

Arbiter-K and Context Kubernetes are strong precedents for the principle that a probabilistic cognitive layer must not be sovereign over effects and that classification errors must not become authorization leaks.

5. Capability Resolution

A2A formalizes Agent Cards describing identity, capabilities and skills; MCP exposes tools with metadata and schemas. These protocols provide capability-discovery building blocks without, on their own, defining the governed transformation of institutional intention into requirements and then a mandate.

6. Cross-Layer Policies

2026 work on declarative cross-layer policies shows that a policy can span routing, orchestration, MCP/A2A and infrastructure. This function is not specific to RA-153.1-2.

7. Action Governance and Attestation

PCAA, CAVA, Proof of Execution and attestation mechanisms provide substantial precedents for portable evidence and execution verification. RA-153.1-2’s Trust Passage must therefore remain a composable interface, not a claim to have invented attestation.

8. Precedence Matrix

9. Conclusion

The contribution WP006 can reasonably propose does not lie in inventing each building block, but in their explicit separation into composable responsibilities and their organization as a governed passage chain between institutional intention and a verifiable effect.

Primary sources: see “Appendix — Primary Sources for the v1.3 State-of-the-Art Update”, retained as the main corpus; v1.6 directly incorporates decisive work published through 4 October 2026.

Chapter 02.11C — Integrated v1.6 Update: Authority, Delegation, Continuity and Evidence

Chapter 02.12 — Analysis of Architectural Gaps

Purpose. Identify not a supposedly absent function in the state of the art, but the open composition question linking interpretation of intention, capabilities, cognition, authority, execution and evidence.

1. An Ecosystem Now Rich in Governance

The 2026 state of the art no longer permits runtime governance, agent authorization, semantic routing, cognitive-strategy selection or attestation to be described as largely vacant fields. Distinct projects and research cover each function with varying maturity, formalization and validation.

The architectural problem therefore shifts: it is no longer merely about adding governance to an execution stack, but about determining how semantic, capability, cognitive, normative and operational decision planes can cooperate without confusing capability, preference and authority.

2. The Composition Question

An infrastructure may correctly understand intention yet select an unauthorized capability. It may choose a suitable cognitive strategy yet produce an institutionally illegitimate effect. It may execute an authorized action but fail to produce portable evidence. Conversely, an authorization layer may be correct without understanding the cognitive quality of a proposed strategy.

3. Residual Gaps to Test

4. Revised Architectural Interpretation

RA-153.1-2 is therefore not justified by a lack of routing or governance tools. It is proposed as a way to make responsibility boundaries between these functions explicit and organize their composition around a governed passage.

This remains an architectural hypothesis. Its value depends on reducing coupling, making decisions more auditable, preserving institutional authority and composing with existing standards and engines without adding complexity that exceeds the benefits.

5. Transition to RA-153.1-2

The next chapter presents RA-153.1-2 as this decomposition/composition proposal. It no longer starts from a governance “void”, but from a landscape rich in specialized mechanisms whose articulation remains a research and engineering question.

Chapter 02.13 — Toward a Governance-Centered Reference Architecture

Purpose. Conclude the review by precisely formulating what RA-153.1-2 still proposes after considering 2025–2026 work on semantic routing, reasoning paradigms, governance-first, authorization and attestation.

1. From the “Missing Layer” to Plane Composition

The review now identifies strong solutions for execution, semantic routing, agent coordination, authorization, runtime control and evidence. WP006 can therefore no longer present a generic governance layer as missing from the landscape.

The question becomes composition: how can inspectable boundaries between interpretation, capabilities, cognitive strategy, normative decision, effect and evidence be preserved while allowing each layer to evolve independently?

2. RA-153.1-2 Architectural Proposal

Institutional intention
        ↓
Semantic resolution
        ↓
Capability resolution
        ↓
Cognitive resolution / strategy
        ↓
Governance passage
        ↓
EXECUTE / ABSTAIN / REFUSE / ESCALATE
        ↓
[if EXECUTE] Governed execution
        ↓
Evidence / receipts / attestation
        ↓
Audit and policy revision

The first three layers produce interpretations, possibilities and strategies. They do not, on their own, confer authority to produce an effect. The governance passage turns—or refuses to turn—a possibility into an execution mandate.

3. Central Invariant

4. Revised Scientific Positioning

RA-153.1-2 does not claim individual invention of semantic routing, capability resolution, cognitive routing, governance-first, agent authorization, non-passage or attestation. Significant precedents exist for each function.

WP006 proposes a reference architecture that separates them into composable responsibilities and organizes their relationship as a governed passage from institutional intention to verifiable effect. This contribution remains PROPOSED: it must be evaluated against neighboring architectures identified in the review.

5. Architectural Falsifiability Criterion

The proposal would be weakened if an existing or future architecture demonstrated functionally equivalent decomposition with comparable guarantees and better simplicity, interoperability or performance. It would be strengthened if independent prototypes showed that RA’s separation measurably improves auditability, policy portability, non-passage quality or dependency control without disproportionate operational cost.

6. Transition

to Chapter 03

Chapter 03 now specifies RA-153.1-2 within this narrower frame: not as “the missing router”, but as a proposal for boundaries and composition among semantic, capability, cognitive, normative, execution and evidence planes.

End of Chapter 02 — State of the Art

Part IV — RA-153.1-2 Reference Architecture

This part now constitutes the document’s canonical reference. Every simplified description or appendix diagram must remain compatible with this chain.

Chapter 03.01 — Design principles

RA-153.1-2 begins with a structuring distinction: interpreting, being capable, proposing, authorizing, executing and evidencing are different responsibilities. Combining them in a single router or agent creates authority confusion, hidden dependencies and difficult-to-audit traces.

Chapter 03.02 — Canonical architecture: six planes, eight stages

INTENTION / REQUEST
        ↓
[SEMANTIC PLANE]       1. Semantic resolution
        ↓
[CAPABILITY PLANE]     2. Required-capability resolution
        ↓
[COGNITIVE PLANE]      3. Candidate-strategy construction
        ↓
[NORMATIVE PLANE]      4. Governance: policies + authority + risks + obligations
        ↓
                       5. EXECUTE / ABSTAIN / REFUSE / ESCALATE
        ↓ if EXECUTE
[EXECUTION PLANE]      6. Admissible-resource resolution
                       7. Delegated mandate execution
        ↓
[EVIDENCE PLANE]       8. Evidence → attestation → verification → audit → revision

Here “plane” denotes an architectural responsibility. An implementation may group several planes in one software component, but must preserve their logical boundaries and auditability.

Inter-plane contracts

Chapter 03.03 — Semantic and capability planes

1. Semantic Resolution

The Semantic Resolution Engine transforms a raw request into a governable representation. It identifies what the situation appears to request, ambiguities, affected objects, sensitivity and confidence. It does not select a model directly.

NEED
  intents[]
  semantic_objects[]
  constraints[]
  ambiguities[]
  sensitivity
  evidence_requirements[]
  confidence
  provenance

2. Capability Resolution

From the interpreted need, the capability plane describes what must be possible without yet selecting who will do it. A2A, MCP or other discovery mechanisms may provide capability descriptions, but RA resolution first expresses requirements independently of the available catalog.

Capability-plane question

“Which capabilities are needed to address this need correctly under its constraints?”

3. Invariant

A technically capable resource is not admissible for that reason alone. Capability resolution opens a space of possibilities; it produces no authority.

Chapter 03.04 — Cognitive plane: the Cognitive Routing Engine

Cognitive-plane question

“Which processing approach is appropriate for this need?”

The Cognitive Routing Engine constructs one or more candidate strategies: direct response, document research, tool invocation, decomposition, sequential or parallel execution, comparison between systems, critique, verification, simulation or human involvement.

Each candidate describes required capabilities, dependencies, stages, evidence needs, stop conditions, known risks and rationale. It remains a proposal.

Chapter 03.05 — Normative plane: governance, policies and authority

Normative-plane question

“Is this passage legitimate, authorized and sufficiently justified under the applicable policies?”

1. The Policy Engine Is a Component, Not the Entire Authority

The Policy Engine identifies and evaluates applicable rules: confidentiality, sovereignty, jurisdiction, roles, cost, security, quality, oversight obligations, evidence requirements or sector-specific prohibitions. In v1.5 it is explicitly located inside the Governance Plane.

2. Authority and Human Gate

Policy may delegate or limit authority or require human authority. When a case is high-impact, ambiguous, contestable or outside the mandate, the system may produce ESCALATE rather than simulate authority it does not possess.

3. First-Class Outcomes

Chapter 03.06 — Execution plane: resource resolution and delegated execution

Only after EXECUTE does the system resolve admissible resources. This replaces the function previously called the “Decision Router”. That term is abandoned because the authority decision has already occurred in the normative plane.

Execution Router question

“Among authorized resources, which combination appropriately executes the mandate?”

Selection may compare quality, cost, latency, energy, resilience, availability and dependence, but may never reintroduce a resource excluded by governance. Targets may be local models, private services, cloud providers, agents, tools, specialized runtimes or isolated environments.

Chapter 03.07 — Evidence plane: Trust Passage, evidence and attestation

Governance is complete only if the decision can be bound to what was actually executed.

1. Trust Passage

The Trust Passage is proposed as a portable interface describing passage or non-passage decisions: relevant intention, authority, policy versions, evaluated conditions, admissible candidates, governance outcome, any mandate and evidence requirements. It is not yet an established standard.

2. Attestation

Attestation links the declared passage to observable material allowing a verifier to check what was actually authorized and executed. RA-153.1-2 assumes no single signature technology, tamper-resistant ledger, TEE, RATS mechanism, action certificate or replay method.

Governed decision
   ↓
Trust Passage
   ↓ if EXECUTE
Mandate → Execution
   ↓
Evidence / receipts / traces
   ↓
Attestation
   ↓
Independent verification
   ↓
Audit and policy revision

Chapter 03.08 — Governance lifecycle

Institutional intention
   ↓
Policy definition / versioning
   ↓
Need interpretation and candidate strategy
   ↓
Governance decision
   ↓
Passage or non-passage
   ↓
Governed execution
   ↓
Observability and evidence
   ↓
Audit / evaluation
   ↓
Institutional policy revision

Organizational learning does not mean policies rewrite themselves automatically. It means execution and audit evidence can inform an explicit institutional revision process.

Chapter 03.09 — Deployment models

RA-153.1-2 is independent of execution location. The same governance can cover local, private, cloud, edge or isolated resources. Deployment models differ in constraints, not in the fundamental passage logic.

Chapter 03.10 — Sovereign AI infrastructure scenarios

Public administration. Policies may require jurisdiction, traceability, explainability and human approval for selected decisions.

Healthcare. Confidentiality, role, evidence and oversight constraints may sharply restrict admissible resources.

Critical industry. Local inference can preserve continuity while external resources are reserved for workloads compatible with sovereignty and security policies.

Research and universities. The architecture can balance cost, reproducibility, openness, data sensitivity and access to specialized capabilities.

Territories and small organizations. Explicit governance may enable use of external capabilities while retaining control over usage conditions and dependencies.

Chapter 03.11 — Architectural conformance invariants

An implementation should be considered conformant with RA-153.1-2’s intent only if it preserves at least these invariants:

• understanding the need does not implicitly select authority;
• capability discovery does not constitute authorization;
• cognitive strategy is not sovereign over effects;
• EXECUTE, ABSTAIN, REFUSE and ESCALATE remain distinguishable and auditable;
• resource selection takes place in a space already made admissible;
• execution is bounded by an explicit mandate;
• evidence binds mandate and effect without confusing attestation with legitimacy;
• specialized components remain replaceable and composable.

Synthesis. RA-153.1-2 is not an architecture deciding instead of the organization. It is an architecture making explicit where a decision must be taken, under whose authority, with what evidence and how far execution may go.

Chapter 03.12 — Inter-plane contracts and typed artifacts

v1.6 consolidates the conceptual separation of six planes into explicit, verifiable contracts. The formalism below is deliberately minimal: it defines what a plane may assume, what it must produce and what it must not do. It prescribes no particular language, provider or engine.

v1.5 invariants

I1  capable(r) ↛ admissible(r)
I2  strategy(s) ↛ authority(s)
I3  domain_effect(e) ⇒ outcome = EXECUTE ∧ valid(mandate)
I4  outcome ∈ {ABSTAIN, REFUSE, ESCALATE} ⇒ no_domain_effect
I5  selected_resource ∈ admissible_resources(mandate)
I6  observed_effect ⊆ authorized_scope(mandate)
I7  every_executed_effect ↔ verifiable_binding(mandate, action, evidence)
I8  policy_version, authority and revocation state are bound to the decision
I9  fallback and retry preserve the same admissibility constraints

Note. These invariants are properties to test. An implementation may satisfy the conceptual architecture yet fail empirically to preserve them under faults, attacks or concurrency; RA-Bench is designed precisely to reveal such failures.

Chapter 03.13 — Strengthened v1.6 invariants

The integrated research refines RA-153.1-2’s boundaries without adding a seventh plane. The following invariants become canonical for v1.6:

I10 authority_source(x) determines which fields x may authorize; information ≠ authority
I11 downstream_scope ⊆ upstream_authority_ceiling
I12 delegated_scope ⊆ parent_mandate_scope
I13 security_context(R5) ≡ security_context(R4) for authority-relevant fields
I14 retry ∨ fallback ∨ delegation ⇒ no_authority_widening
I15 ESCALATE ⇒ no_domain_effect until an external authority produces a new R4
I16 HumanGate ⇒ decision_packet(question, owner, options, consequences, uncertainties, provenance, contestability)
I17 execution_claim ≠ observed_effect; R6 MUST preserve the distinction
I18 evidence_assurance is bounded by provenance, substrate and auditor independence
I19 transcript_success ↛ execution_success
I20 every executed effect MUST remain traceable to principal → authority → mandate → binding → observed effect

Consequence. “Passage continuity” is not a single token carried end to end. It is verifiable preservation of several relationships: who speaks with what authority, what may be done, what was authorized, how the mandate was delegated, what actually executed and what can be evidenced.

Part V — Implementation Framework

Contents

Chapter 04.01 — Implementation Principles

Purpose. Translate RA-153.1-2’s conceptual architecture into practical implementation principles for enterprise, public-sector and sovereign AI infrastructure.

1. From Architecture to Implementation

RA-153.1-2 deliberately separates conceptual governance from implementation technology. This allows organizations to deploy the same governance architecture across programming languages, cloud providers, inference engines and orchestration frameworks.

Architecture defines responsibilities. Implementations realize them.

A reference architecture should remain stable while implementations evolve continually.

2. Fundamental Components

Component Responsibility

Policy repository Persistent governance knowledge.

Governance Plane / Policy Engine Policy evaluation and authorization.

Execution Router Execution-target selection.

Connector layer Integration with providers and runtimes.

Observability services Tracing, metrics and audit ledgers.

3. Design Principles

Loose coupling between governance and execution. Technology-independent interfaces. Composable policy modules. Immutable audit records. Incremental deployment and migration.

4. Reference Layering

Applications
   │
RA-153.1-2 Governance
   │
Connectors / Protocols
   │
Inference Engines & AI Services
   │
Infrastructure

Governance should evolve more slowly than execution technology.

5. Transition

The next section examines interoperability mechanisms allowing RA-153.1-2 to coordinate heterogeneous AI ecosystems without imposing proprietary dependencies.

Chapter 04.02 — Interoperability Architecture

Purpose. Define how RA-153.1-2 interoperates with heterogeneous AI ecosystems while remaining independent of any particular provider, protocol or execution framework.

1. Interoperability as a Design Requirement

Modern AI infrastructure combines multiple APIs, inference engines, orchestration frameworks and deployment environments. RA-153.1-2 therefore adopts interoperability as a fundamental architectural requirement rather than an optional integration feature.

Governance should unify ecosystems without standardizing implementations.

RA-153.1-2 specifies governance responsibilities, not proprietary communication protocols.

2. Interoperability Layers

Layer Purpose

Applications Business services and AI-enabled workflows.

Governance Policy evaluation and routing decisions.

Protocol connectors Adapters to external APIs and standards.

Execution platforms Inference engines and orchestration systems.

Infrastructure Cloud, private data centers and edge devices.

3. Reference Integration Points

Model Context Protocol (MCP). REST and gRPC APIs. Message-oriented middleware. Event-driven architectures. Cloud-native service meshes.

4. Logical Integration Model

Applications
   │
RA-153.1-2 Governance
   │
Protocol Adapters
├── MCP
├── REST
├── gRPC
├── Events
   │
Execution Platforms

5. Architectural Benefits

Provider independence. Incremental migration. Technological evolution without governance redesign. Unified policy enforcement. Long-term interoperability.

Interoperability preserves technological freedom. Governance preserves institutional coherence.

6. Transition

The next section introduces extensibility mechanisms allowing RA-153.1-2 to evolve through modular governance components and reusable policy packs.

Chapter 04.03 — Extensibility and Governance Modules

Purpose. Describe how RA-153.1-2 can evolve through modular governance components while preserving architectural coherence and long-term interoperability.

1. Modular Governance

RA-153.1-2 is designed as an extensible governance platform rather than a monolithic system. Governance capabilities can be added, replaced or refined without changing the architectural core.

Stable architecture. Evolving governance.

The governance core remains deliberately compact, while domain-specific capabilities are implemented as reusable modules.

2. Governance Module Categories

Module Responsibility

Compliance Enforcement of regulatory and legal policies.

Security Identity, trust and access policies.

Data sovereignty Jurisdiction and locality constraints.

Ethics Institutional ethical governance rules.

Optimization Cost, latency and resource-allocation policies.

Sector extensions Healthcare, finance, public sector, industry.

3. Extension Model

Core Governance
   │
Governance Plane / Policy Engine
   │
Module Registry
├── Compliance
├── Security
├── Sovereignty
├── Ethics
├── Sector Packs
   │
Execution Router

4. Design Principles

Composable policy packs. Independent module lifecycles. Backward-compatible interfaces. Standard governance contracts. Shared audit model.

5. Architectural Perspective

By separating the governance core from specialized modules, RA-153.1-2 allows organizations to adapt governance to new regulations, industries and technologies without fragmenting the overall architecture.

Governance diversity should emerge from modular policies, not incompatible architectures.

6. Transition

The next section presents implementation paths showing how organizations can progressively adopt RA-153.1-2 while minimizing operational disruption.

Chapter 04.04 — Incremental Adoption Strategy

Purpose. Present an incremental adoption strategy allowing organizations to deploy RA-153.1-2 without disrupting existing AI systems.

1. Evolution Rather Than Replacement

RA-153.1-2 is designed to coexist with existing infrastructure. Organizations can progressively introduce governance capabilities while preserving operational continuity.

Governance should be introduced incrementally rather than through disruptive replacement.

The architecture supports gradual migration from isolated AI deployments to policy-driven governance.

2. Reference Adoption Phases

Phase Objective

1. Assessment Inventory AI assets, providers and governance gaps.

2. Pilot Deploy the Governance Plane / Policy Engine on selected workflows.

3. Integration Connect existing inference platforms through adapters.

4. Expansion Extend governance across organizational domains.

5. Optimization Continually improve policies through audit and feedback.

3. Migration Architecture

Existing Applications
    │
Legacy AI Services
    │
RA-153.1-2 Gateway
    │
Governance Plane / Policy Engine
    │
Execution Router
    │
Current & Future AI Platforms

4. Success Factors

Executive sponsorship. Cross-functional governance teams. Reusable policy libraries. Incremental deployment metrics. Continuous organizational learning.

Successful adoption depends more on governance maturity than technological complexity.

5. Transition

The next section introduces governance metrics and maturity indicators to assess long-term adoption.

Chapter 04.05 — Governance Maturity Model

Purpose. Introduce a maturity model enabling organizations to assess, compare and progressively improve their AI governance capabilities.

1. Why a Maturity Model?

Technology adoption alone does not guarantee responsible AI. Sustainable governance requires measurable organizational capabilities. RA-153.1-2 therefore proposes a governance maturity model

describing progressive levels of institutional capability.

AI maturity should be assessed through governance capabilities rather than model sophistication.

The maturity model is an organizational roadmap, not a certification framework.

2. Governance Maturity Levels

3. Assessment Dimensions

Policy management. Decision transparency. Auditability. Interoperability. Sovereignty. Organizational learning.

4. Organizational Progression

Progression between maturity levels should be driven by governance improvements rather than infrastructure replacement. Organizations can evolve incrementally while preserving existing operational investments.

Governance maturity is measured by institutional coherence, not technological complexity.

5. Transition

The next section introduces governance metrics and key performance indicators supporting continuous assessment of RA-153.1-2 deployments.

Chapter 04.06 — Governance Metrics and Indicators

Purpose. Define measurable indicators allowing organizations to continually monitor, assess and improve AI governance under RA-153.1-2.

1. Measuring Governance

Governance must be observable through objective indicators. RA-153.1-2 therefore distinguishes operational-performance metrics from governance-quality metrics. Both dimensions

are necessary, but answer different questions.

Performance measures how efficiently AI operates. Governance measures how responsibly AI operates.

Governance metrics should support decision-making, organizational learning and accountability rather than compliance reporting alone.

2. Fundamental Governance Indicators

3. Balanced Governance Dashboard

Compliance Transparency Risk Sovereignty Operational Efficiency Institutional Learning

4. Governance Feedback Loop

Indicators should feed directly into governance reviews. Metrics are not an end in themselves; they provide evidence for refining policies, improving routing decisions and strengthening institutional resilience.

The objective of governance metrics is continuous improvement, not continuous surveillance.

5. Transition

The next section concludes Chapter 04 by synthesizing implementation guidance and preparing the evaluation framework introduced in Chapter 05.

Chapter 04.07 — Chapter Conclusion

Chapter 04 has translated RA-153.1-2’s conceptual foundations into an implementation-oriented reference framework. It has shown how governance can be deployed incrementally, interoperably and independently of execution technologies.

Implementation Contributions

Section Contribution

Implementation principles Technology-independent governance architecture.

Interoperability Integration across heterogeneous AI ecosystems.

Governance modules Composable, extensible governance capabilities.

Adoption strategy Incremental deployment path.

Maturity model Organizational governance roadmap.

Metrics & indicators Continuous governance evaluation.

RA-153.1-2 is designed to evolve with AI ecosystems while preserving institutional coherence and long-term governance continuity.

From Architecture to Practice

The implementation framework confirms that governance is not an additional software component but an architectural capability spanning policy definition, execution control, observability and organizational learning.

Implementation succeeds when governance becomes an operational capability rather than a theoretical principle.

Preparing Evaluation

The next chapter introduces an evaluation framework designed to assess governance effectiveness through reference scenarios, measurable indicators and reproducible benchmarking methodologies.

A reference architecture reaches maturity only when it can be objectively evaluated and consistently reproduced.

Chapter 04.08 — Application profiles: App_IA_Citoyenne

RA-153.1-2 is a reference architecture; an application does not become RA-conformant simply through conceptual lineage. Applications must be developed for their own problem and then linked to RA through an explicit, testable, revisable alignment profile.

The detailed profile is published separately within the RA-153.1-2 package at application-profiles/App_IA_Citoyenne_RA153_Alignment_Profile_v0.1.html.

Part VI — RA-Bench v0.2: Scientific Validation and Falsification

The objective is no longer an abstract “governance score”, but testing specific properties under normal, adversarial and infrastructure-change conditions. The protocol prioritizes disqualifying violations, dimensional metrics, uncertainty and controlled comparisons.

Chapter 05.00 — Research questions and hypotheses H1–H5

No hypothesis is “confirmed” by construction. Thresholds, non-inferiority margins and success criteria must be preregistered for each campaign and published with the results.

Chapter 05.01 — Adversary and fault model

RA-Bench assumes that an adversary or failure can act at several boundaries without simultaneously controlling every trust root. Campaigns must precisely declare the attacker’s permitted capabilities.

v0.1 non-goal. Total simultaneous compromise of the governance engine, identity root, evidence storage and runtime is outside the base threat model; it requires a strengthened evaluation profile.

v1.6 threat-model extensions

Chapter 05.02 — RA-Bench v0.2: reference scenarios

Each scenario must include nominal, boundary and adversarial cases; data, policies, component versions and expected results are published before execution when this does not invalidate the test.

Chapter 05.03 — Non-compensatory gates and metrics

Gates added in RA-Bench v0.2

Dimensional metrics after gates

“Sovereignty” is no longer used as a monolithic metric in v0.1. RA-Bench separately measures jurisdictional compliance, provider dependence, policy portability, identity/authority control and substitutability when the evaluation profile requires them.

Chapter 05.04 — Baselines and ablations

Comparison baselines

A publication must specify whether a baseline is reproduced from public code, reimplemented from a specification or only approximated. An approximation must never be presented as an evaluation of the original implementation.

RA ablations

Chapter 05.05 — Experimental protocol, uncertainty and reproducibility

• Preregistration: hypotheses, thresholds, non-inferiority margins, exclusions and secondary analyses are declared before the campaign.
• Paired design: the same scenarios, policies and perturbation conditions are run on each baseline where possible.
• Repetitions: multiple seeds, models/runtimes and repetitions are used for probabilistic components; deterministic components are tested on exhaustive or targeted partitions as appropriate.
• Uncertainty: rates are published with suitable confidence intervals; continuous metrics with distributions, appropriate medians/means and bootstrap or an equivalent method.
• Effects before p-values: effect sizes and absolute differences take priority; statistical significance without operational relevance is insufficient.
• Three TEVV strata: controlled system tests, adversarial red teaming and human-workflow tests when Human Gate is involved, consistent with the spirit of NIST ARIA/TEVV approaches.
• Published artifacts: scenarios, policies, versions, configurations, seeds, traces, scoring scripts and exclusions must be versioned to enable replication.

Chapter 05.06 — Interpretation, falsification and roadmap

Recommended steps: 1) minimal R0–R6 prototype; 2) RB-01 to RB-10 campaign against BL0 and BL1; 3) add BL2/BL3; 4) ablations; 5) independent replication; 6) sector extensions (administration, healthcare, finance, infrastructure, education) with domain-specific policies.

v1.5 presents none of these results as established. It now defines an experimental program precise enough for third parties to implement RA-153.1-2, compare it with neighboring architectures and attempt to falsify it.

Part VII — Governance Engineering and Outlook

Chapter 06.01 — Future Research Directions

Purpose. Identify the main scientific and engineering challenges shaping the next generation of governance architectures for AI ecosystems.

1. Beyond Today’s AI Platforms

AI systems are evolving toward distributed, multimodal and increasingly autonomous infrastructures. Governance architectures must therefore evolve from static policy enforcement toward adaptive institutional coordination.

The future challenge is not merely to build more capable AI, but to govern increasingly capable AI responsibly.

RA-153.1-2 is presented as a reference architecture intended to evolve alongside future execution technologies rather than compete with them.

2. Research Priorities

Research area Open questions

Adaptive policy systems How can governance evolve while remaining auditable?

Distributed governance How can policies remain coherent across multiple institutions?

Machine-readable governance How should governance policies be represented formally?

Sovereign AI How can territorial and legal autonomy be preserved?

Governance benchmarks How can governance quality become an internationally measurable capability?

3. Long-Term Vision

Future governance architectures should support interoperability, transparency, institutional trust and continuous learning without constraining technological innovation.

Governance should become enabling infrastructure for trustworthy AI ecosystems.

4. Transition

The next section examines long-term evolution toward institutional AI ecosystems in which governance becomes a shared capability rather than an isolated software layer.

Chapter 06.02 — Toward Institutional AI Ecosystems

Purpose. Explore the evolution from isolated AI deployments toward interoperable institutional ecosystems governed by shared policies, transparent decisions and collaborative accountability.

1. From Systems to Ecosystems

Most current AI deployments remain organization-centered. Future infrastructure will increasingly connect public institutions, businesses, research organizations and sovereign platforms. Governance must therefore become a shared architectural capability.

The next generation of AI will be connected not only through networks, but through governance.

Institutional ecosystems require common governance principles while preserving organizational autonomy and technological diversity.

2. Fundamental Capabilities

Capability Purpose

Shared policies Coordinate governance across organizations.

Interoperable trust Enable cooperation without centralized control.

Distributed audit Provide verifiable accountability across ecosystems.

Policy federation Respect local autonomy while ensuring global coherence.

Continuous learning Improve governance through accumulated evidence.

3. Conceptual Evolution

Independent AI Systems
     │
Federated Governance
     │
Institutional Cooperation
     │
Trusted AI Ecosystems

4. Long-Term Perspective

Future governance architectures should allow institutions to cooperate while preserving sovereignty, transparency and accountability. Governance becomes infrastructure for collective intelligence rather than an operational constraint.

Institutional trust will increasingly depend on governance architecture quality as much as AI model quality.

5. Transition

The next section examines emerging governance paradigms and the long-term evolution toward policy-native AI infrastructure.

Chapter 06.03 — Policy-Native AI Infrastructure

Purpose. Explore an architectural paradigm in which governance policies become native AI infrastructure components rather than external constraints applied after deployment.

1. From Policy-Aware to Policy-Native

Many current AI systems are policy-aware: governance is added through gateways, filters or external services. A policy-native architecture integrates governance into the operational fabric from the start.

The most trustworthy AI infrastructures will not apply policy afterward; they will be designed around it from the outset.

RA-153.1-2 illustrates this transition by treating governance as a first-class architectural capability rather than an operational accessory.

2. Foundational Characteristics

Characteristic Architectural consequence

Policy by design Governance requirements shape system architecture.

Native explainability Every decision is explainable by construction.

Continuous auditability Evidence is produced throughout execution.

Adaptive governance Policies evolve without redesigning core systems.

Institutional portability Governance can move across infrastructures.

3. Conceptual Architecture

Institutional Intention
     │
Governance Policies
     │
Decision Orchestration
     │
AI Services
     │
Operational Evidence

4. Long-Term Implications

Policy-native infrastructure could enable interoperable public services, sovereign AI platforms and regulated industrial ecosystems where governance becomes a reusable architectural layer shared across institutions.

Policy-native architectures transform governance from a compliance burden into institutional infrastructure.

5. Transition

The next section examines governance as an emerging engineering discipline for trustworthy AI ecosystems.

Chapter 06.04 — Governance as an Engineering Discipline

Purpose. Argue that AI governance should evolve into a formal engineering discipline supported by reference architectures, measurable methods, reusable policy patterns and reproducible practices.

1. From Compliance to Engineering

Governance has often been treated as documentation, regulation or organizational oversight. Future AI ecosystems require governance to become an engineering activity with explicit design principles, implementation methods and verification protocols.

Designing trustworthy AI requires designing trustworthy governance.

A governance discipline complements software engineering rather than replacing it. It defines how institutional intention is translated into operational behavior.

2. Pillars of Governance Engineering

Pillar Purpose

Reference architectures Provide reusable structural patterns.

Policy engineering Specify and maintain machine-readable governance.

Governance metrics Objectively measure institutional quality.

Verification & audit Produce verifiable governance evidence.

Continuous improvement Evolve governance through operational feedback.

3. Engineering Lifecycle

Institutional Intention
   │
Architecture
   │
Policy Design
   │
Implementation
   │
Evaluation
   │
Continuous Improvement

4. Toward a Scientific Field

The long-term objective is a shared body of knowledge including standards, benchmark suites, policy languages, design patterns and educational curricula dedicated to governance engineering.

Governance engineering could become as fundamental to AI as software engineering became to computing.

5. Transition

The next section presents WP006’s general conclusion and summarizes RA-153.1-2’s architectural contributions.

General Conclusion

This working paper has proposed RA-153.1-2 as a governance reference architecture for sovereign, interoperable, policy-driven AI infrastructure. Rather than introducing another AI model or orchestration framework, RA-153.1-2 focuses on the architectural layer translating institutional intention into governed operational decisions.

Main Contributions

Contribution Description

Architectural positioning Governance as an independent architectural layer.

Reference architecture — separation of semantic, capability, cognitive, normative, execution and evidence planes; policies, non-passage, execution and evidence are treated as distinct responsibilities.

Implementation framework Incremental adoption, interoperability and modular governance.

Evaluation framework Benchmarks, scoring methods and reproducibility protocols.

Research vision Governance engineering as an emerging scientific discipline.

WP006’s central proposal is that trustworthy AI ecosystems require trustworthy governance architectures designed with the same rigor as software and infrastructure.

A Paradigm Shift

AI evolution is no longer defined solely by larger models or faster hardware. It increasingly depends on institutions’ ability to govern heterogeneous AI ecosystems transparently, explainably and auditably.

The future of AI will depend not only on intelligence, but on the quality of the governance architectures organizing that intelligence.

Future Work

The concepts introduced here invite further work on policy languages, governance standards, benchmark suites, interoperability specifications and open-source reference implementations. These developments could contribute to a shared body of knowledge for governance engineering.

RA-153.1-2 is presented not as a final solution, but as a foundation for collaborative research on AI ecosystem governance.

Outlook

Part VIII — Appendices

Appendix — Primary Sources for the v1.3 State-of-the-Art Update

Sources consulted and reviewed for the update through 12 August 2026. This list complements the references already present in the preceding chapters.

• When to Reason: Semantic Router for vLLM
• From Inference Routing to Agent Orchestration: Declarative Policy Compilation with Cross-Layer Verification
• Select-then-Solve: Paradigm Routing as Inference-Time Optimization for LLM Agents
• Governed Reasoning for Institutional AI
• Context Kubernetes
• From Craft to Kernel / Arbiter-K
• MetaCogAgent
• Intent-Governed Tool Authorization for AI Agents (IGAC)
• Proof-Carrying Agent Actions (PCAA)
• CAVA
• Proof of Execution
• Hardware-rooted attestation for AI-agent evidence
• A2A Protocol Specification
• MCP Specification 2026-07-28 — Tools
• Microsoft Agent Governance Toolkit
• OpenFGA — Authorization for Agents
• OpenID Foundation — AuthZEN / agent era

Appendix A — RA-153.1-2 Reference Glossary

This glossary uses the canonical v1.5 nomenclature.

Appendix B — Canonical RA-153.1-2 Diagrams

This appendix includes only diagrams compatible with the canonical architecture in Part IV.

B.1 Governed passage chain

Intention
  ↓
Semantic resolution
  ↓
Capability resolution
  ↓
Cognitive strategy
  ↓
Governance / authority
  ↓
EXECUTE · ABSTAIN · REFUSE · ESCALATE
  ↓ if EXECUTE
Admissible-resource resolution
  ↓
Delegated execution
  ↓
Evidence · Attestation · Audit · Revision

B.2 The six planes

B.3 Institutional loop

Versioned policies
  ↓
Governed decisions
  ↓
Executions / non-passages
  ↓
Evidence and audits
  ↓
Institutional evaluation
  ↓
Explicit policy revision

Appendix C — Policy Pack Examples

This appendix illustrates how governance policies can be represented as versioned, machine-readable policy packs using the schema defined in Chapter 05.04 (Reproducibility Protocols). The examples are illustrative and technology-neutral.

C.1 Policy Pack Structure

{
 "id": "PP-2026-014",
 "version": "1.0.0",
 "author": "Example Institution — AI Governance Office",
 "scope": "Institutional Governance Baseline",
 "approval_status": "approved",
 "approved_by": "AI Governance Committee",
 "effective_date": "2026-01-01",
 "superseded_by": null,
 "rules": [
  { "rule_id": "POL-001-R1", "condition": "data.classification == 'sensitive'", "expected_action":
"route_to_local_models", "rationale": "see C.2 — Data Sovereignty" },
  { "rule_id": "POL-002-R1", "condition": "provider.certified == true and confidence >= threshold",
"expected_action": "prefer_certified_provider", "rationale": "see C.3 — Model Selection" },
   { "rule_id": "POL-003-R1", "condition": "decision.impact == 'high'", "expected_action":
"require_human_approval", "rationale": "see C.4 — Human Approval" },
    { "rule_id": "POL-004-R1", "condition": "always", "expected_action": "record_immutable_evidence", "rationale":
"see C.5 — Audit" }
 ]
}

C.2 Data Sovereignty Policy

{
 "rule_id": "POL-001-R1",
 "condition": "data.classification == 'sensitive' and data.jurisdiction not in approved_jurisdictions",
 "expected_action": "route_to_local_models",
 "rationale": "Sensitive data must remain within approved jurisdictions."
}

C.3 Model Selection Policy

{
 "rule_id": "POL-002-R1",
 "condition": "provider.certified == true and confidence >= threshold",
 "expected_action": "prefer_certified_provider",
 "fallback": "local_inference",
  "rationale": "Prefer certified providers when confidence exceeds the threshold; otherwise fall back to local inference."

}

C.4 Human Approval Policy

{
 "rule_id": "POL-003-R1",
 "condition": "decision.impact == 'high'",
 "expected_action": "require_human_approval",
 "workflow": "approval_required",
 "rationale": "High-impact decisions require explicit human approval."
}

C.5 Audit Policy

{
 "rule_id": "POL-004-R1",
 "condition": "always",
 "expected_action": "record_immutable_evidence",
 "rationale": "Every routing decision produces immutable governance evidence."
}

Policy packs separate institutional intention from implementation technology, enabling portability, transparency and continuous governance evolution.

Appendix D — RA-Bench v0.1: Reference Sheet

D.1 Minimum Campaign Artifacts

D.2 Gates

G1 Unauthorized Effect · G2 Mandate Violation · G3 Non-Passage Integrity · G4 Admissibility Bypass · G5 Evidence Binding.

D.3 Baselines

BL0 Coupled · BL1 Policy Enforcement · BL2 Governed Cognition · BL3 Certificate-Bound Runtime · BL4 Full RA.

D.4 Ablations

A1 merged semantics/capability · A2 no cognitive routing · A3 merged cognition+governance · A4 resources before governance · A5 no first-class non-passage · A6 no mandate/effect binding · A7 fallback without prior governance · A8 no version/revocation binding.

D.5 PGBS Legacy

PGBS-01 through PGBS-06 is retained as a historical precursor of WP006 v1.1–v1.4 measurement dimensions. Its metrics can inform RA-Bench, but the weighted composite score is no longer the primary verdict: conformance, authority and mandate integrity are treated as non-compensatory properties where the scenario requires them.

Appendix E — Governance Design Patterns

This appendix introduces reusable architectural patterns intended to help designers implement governance capabilities consistently across heterogeneous AI infrastructure.

E.1 Purpose

Design patterns capture recurring governance solutions independently of a specific implementation technology.

E.2 Reference Patterns

Pattern Problem Solution

Policy Gateway Execution requests require policy validation. Evaluate governance policies before invoking any AI service.

Federated Policy Multiple institutions maintain independent rules. Combine local autonomy with shared governance principles.

Evidence First Decisions must remain auditable. Generate governance evidence as a native execution artifact.

Human Escalation High-impact decisions require oversight. Route sensitive cases to explicit human-approval workflows.

Adaptive Policy Evolution Policies evolve over time. Version governance packs independently of execution systems.

E.3 Pattern Relationships

Institutional intention
     │
Candidate strategy
     │
Governance Plane
     │
EXECUTE / ABSTAIN / REFUSE / ESCALATE
     │ if EXECUTE
Execution Router
     │
Evidence First / Attestation
     │
Institutional improvement

E.4 Benefits

Reusable governance architectures. Technology-independent implementation guidance. Improved interoperability. Consistent governance practices. Easier standardization.

Design patterns turn architectural principles into reusable engineering knowledge.

Appendix F — Alignment with Existing Standards

This appendix positions RA-153.1-2 relative to widely recognized AI governance and management frameworks. Rather than replacing existing standards, RA-153.1-2 aims to be an architectural layer capable of operationalizing their governance objectives.

PROPOSED Comparison methodology. As in the state-of-the-art review (Chapter 02.01, Section 5), the positioning below is conceptual: it maps RA-153.1-2’s proposed design objectives to the publicly documented scope of each standard/framework (see the sources cited in Chapter 00, Section 6, for NIST AI RMF and the EU AI Act). No formal conformance evaluation or certification process has been conducted.

F.1 Comparative Positioning

Framework Main focus Relationship to RA-153.1-2

NIST AI RMF AI risk management Provides governance objectives that RA-153.1-2 may operationalize through policy-driven orchestration.

ISO/IEC 42001 AI management systems Supports organizational governance; RA-153.1-2 provides architectural implementation patterns.

EU AI Act Regulatory compliance Policies can encode regulatory obligations and

routing constraints.

Model Context Protocol (MCP) Interoperable access to tools and context Can provide an execution interface beneath governance.

Cloud & hybrid platforms Execution infrastructure Remain interchangeable under governance oversight.

F.2 Conceptual Layering

Institutional Objectives
    │
Regulations & Standards
    │
RA-153.1-2 Governance
    │
Execution Platforms
    │
AI Services

F.3 Complementarity

Standards define principles and obligations. Policies translate principles into executable governance. RA-153.1-2 coordinates operational decisions. Execution platforms supply AI capabilities.

Standards establish expectations; governance architectures turn them into operational practice.

F.4 Outlook

Future versions may include formal mappings, conformance profiles and reference policy libraries aligned with international standards to facilitate adoption across public and private institutions.

F.5 — 2026 Front: Emerging Agent Standards and Mechanisms

Microsoft Agent Governance Toolkit — runtime governance, policy enforcement, identity, audit.
OpenFGA — agents as principals, permissions and authorization relations.
OpenID AuthZEN — standardized authorization-decision interface and agent/MCP profiles.
PCAA — action certificates, approvals, receipts and portable evidence.
CAVA — action canonicalization and cross-runtime attestation.
IETF RATS / hardware attestation — evidence and appraisal of platform state.

F.6 — Composition Principle

PROPOSED. RA-153.1-2 should remain composable with these specialized mechanisms rather than attempt to reproduce them. Its own responsibility remains governed orchestration of the passage from intention to execution, including deciding that no passage should occur.

Appendix H — LCZ-ZS1 License

This Working Paper belongs to the Commun ZEON.

LCZ-ZS1 defines the publication framework adopted by ZEON Systems for its commons. Its purpose is to preserve integrity, transmission and non-capture of the Commun ZEON while encouraging exploration, adaptation and reciprocal sharing.

About this reproduction. LCZ-ZS1 is published and maintained by ZEON Systems, a French association under the 1901 law. Its official, canonical text is French, at the URL given at the end of this appendix. The text below is an English translation for Working Paper readers’ convenience; it neither rewrites nor reinterprets the license and preserves its untranslated canonical expressions. In any discrepancy, the canonical French text prevails.

H.1 Why ZEON Systems Exists

Every living work needs a space in which what has been created can be preserved, shared, transmitted and extended without being captured. ZEON Systems performs this role as steward of the commons. The association does not seek to close access to ZEON resources. It seeks to ensure that their circulation remains faithful to their spirit: developing agency, cooperation, relational sovereignty and the robustness of living systems.

ZEON Systems protects the common resources enabling the ZEON ecosystem to be transmitted and grow: foundational texts, ZEON Keys, architectures, reference frameworks, protocols, licenses, practices, public pages, discernment mechanisms and digital resources. These are not conceived as private property. They form a living heritage intended for exploration, adaptation and extension within a non-capture framework.

H.2 ZEON Systems’ Four Missions

Mission Description

Preserve Conserve the works, texts, models and architectures constituting ZEON’s living heritage.

Transmit Make these resources accessible to those seeking to understand, learn, experiment or contribute.

Protect Prevent exclusive capture of the commons while supporting its circulation, adaptation and enrichment.

Federate Welcome those seeking to contribute sustainably to building and protecting the ZEON commons.

H.3 The LCZ-ZS1 License

LCZ-ZS1 governs the use, sharing and development of ZEON tools, texts and mechanisms. Its intention is simple: allow meaning to circulate while protecting the ZEON architecture’s integrity—“protéger la circulation du sens”.

1. Free exploration

ZEON tools and texts may be used freely to explore meaning individually or collectively.

2. Attribution

All public use must mention: ZEON · Licence LCZ-ZS1 · ZEON Systems.

3. Reciprocal sharing

Every adaptation, extension or derivative development of ZEON must remain under LCZ-ZS1 — ZEON Systems.

4. Non-capture

Elements of the ZEON project may not be exclusively appropriated, patented or incorporated into a closed system preventing their circulation.

5. Integrity

ZEON texts, archetypes, mechanisms and tools may be shared or extended provided changes to their spirit are clearly identified.

6. Spirit of the license

LCZ-ZS1 protects the circulation of meaning and the integrity of the ZEON architecture.

LCZ-ZS1 does not seek to prevent use. It seeks to prevent capture. It permits exploration, transmission, adaptation and development while requiring derivative resources to remain within reciprocal-sharing and non-capture arrangements—“relier sans capturer”.

H.4 Joining ZEON Systems

Joining ZEON Systems does not mean joining a company. It means contributing to preservation of a living commons. Members participate in protecting, enriching and transmitting ZEON ecosystem resources so the commons remains open, living and accessible to future generations.

A living work is not simply owned. It is stewarded, transmitted and cultivated.

H.5 Canonical Reference

Official LCZ-ZS1 License https://zeons.org/zeon/licence.html

This page is the canonical LCZ-ZS1 reference. In future revisions, the canonical

online version prevails.

Canonical expressions preserved throughout this appendix: LCZ-ZS1 · Commun ZEON · Relier sans capturer · Protéger la circulation du sens · Non-capture.

Working Paper 006 v1.5 · Scientific Edition · Part VIII — Appendices A–H · Parts I–VIII