Abstract
The rapid multiplication of foundation models, inference providers, local runtimes, specialized agents and regulatory constraints is transforming artificial intelligence from a model-selection problem into an infrastructure-governance problem. Organizations increasingly need to determine not merely which model can answer a request, but which execution environment is authorized, appropriate, affordable, available, explainable and compatible with organizational policy.
This Working Paper examines the emergence of a policy-driven orchestration layer for artificial intelligence. It reviews the contemporary routing and serving ecosystem, identifies the capabilities still missing from most available stacks, and develops PRISM153 as a reference architecture for governing heterogeneous AI resources across public cloud, private cloud, local, edge and isolated environments. The paper argues that sovereignty should not be reduced to model ownership or hosting location. It should also include the ability to define, execute, inspect and revise the policies by which AI workloads are assigned to models, providers, agents and infrastructures.
The document is written for engineers, architects, researchers, public institutions and organizational decision-makers. It distinguishes current technical facts, architectural proposals and open research hypotheses. Its objective is not to promote a universal router, but to establish a rigorous framework for discussing sovereign, auditable and resilient AI orchestration.
Executive Summary
Artificial intelligence is becoming an organizational infrastructure. Yet most organizations still interact with it as a collection of disconnected models, APIs and tools.
During the first phase of large-language-model adoption, the dominant question was model capability: which model produced the best answer, generated the most reliable code, understood the longest context or supported the required modality? That question remains important, but it is no longer sufficient. A production environment may simultaneously include commercial APIs, open-weight models, internally fine-tuned systems, retrieval services, agents, gateways, safety filters, vector databases, identity services and observability components. Each component introduces dependencies and constraints. The result is not a single AI system but a heterogeneous execution field.
In this field, each request becomes a decision. Should it leave the organization? May it be processed outside a defined jurisdiction? Does it contain personal, medical, industrial or security-sensitive information? Is an expensive frontier model justified? Can a smaller local model satisfy the task? Is the preferred provider currently available? Must the answer be reproducible? Which evidence must be retained for audit? Can cached knowledge be reused? What should happen when the optimal route is unavailable?
ProposedThe central challenge is no longer only to access intelligence. It is to govern the conditions under which intelligence is mobilized.
Existing tools already solve important parts of this problem. Model gateways normalize APIs. Inference engines improve throughput. serving frameworks deploy models at scale. Agent frameworks coordinate tools and workflows. Cloud-native systems provide scheduling, resilience and observability. These capabilities are necessary. They do not, however, automatically create an explicit and auditable organizational decision layer.
PRISM153 is introduced in this paper as a reference architecture for that missing layer. The name expands to Protocol for Routed Intelligent Specialized Models. Its foundational proposition is simple: routing should be the consequence of policy evaluation. A request should first be interpreted in context, evaluated against explicit constraints, matched with eligible execution targets, and only then assigned to a model or service. The resulting decision should be observable, explainable and available for later review.
Policy-driven
Rules concerning confidentiality, sovereignty, quality, cost, latency, energy and availability are represented explicitly.
Model-agnostic
Applications are decoupled from particular providers, models and runtime environments.
Hybrid
Cloud, private, local, edge and isolated resources are treated as governed execution targets.
Auditable
Decisions can record the policy, eligible candidates, selected route, rationale and outcome.
Resilient
Fallback and graceful-degradation strategies preserve organizational intent during failures.
Evolutionary
Policies, models and deployment targets can change without rewriting every application.
Sovereignty as an operational capacity
This paper uses the term sovereignty in a concrete architectural sense. It does not imply technological isolation, nor does it require every component to be developed locally. Sovereignty is treated as the capacity of an organization or ecosystem to understand its dependencies, define the rules governing AI execution, retain meaningful alternatives, preserve continuity, and verify that its decisions are being applied.
This interpretation is particularly relevant in Europe. The European AI Act entered into force on 1 August 2024 and reaches broad applicability on 2 August 2026, subject to its phased exceptions. At the same time, European investment in AI Factories and high-performance computing is increasing access to shared computing resources. These developments make infrastructure governance a practical concern rather than a purely conceptual one. They create a need for architectures that can connect regulatory duties, organizational policy and technical execution without reducing governance to a final compliance checklist.
Trustworthiness cannot be delegated to the model
The NIST AI Risk Management Framework frames AI risk management as an organizational activity spanning governance, mapping, measurement and management. This perspective is compatible with the thesis of the present paper: trustworthiness is not a property that can be inferred from the identity of a model alone. It emerges from the system in which the model is selected, configured, supplied with context, monitored and used.
A strong model can be used in an inappropriate context. A local model can preserve confidentiality while producing inadequate results. A low-cost route can silently degrade service quality. A redundant architecture can still fail if all alternatives depend on the same provider or region. For this reason, routing decisions must be situated inside a broader governance process.
Chapter 00.01 — Beyond AI Routing: Governance as Infrastructure
Purpose and Central Proposition
PRISM153 is not primarily original because it can route a request toward one model rather than another. Its originality lies in making the governance of that decision an explicit, independent and inspectable layer of the AI infrastructure.
Modern AI stacks already contain gateways, model routers, inference engines, agent frameworks, serving platforms, observability systems and deployment schedulers. These technologies make heterogeneous AI resources accessible and operational. Yet the rules connecting institutional intent to execution are still frequently dispersed across application code, provider configuration, security controls, procurement choices, undocumented practices and human judgment.
PRISM153 proposes to externalize this fragmented decision logic and organize it as a reusable governance architecture. Routing then becomes the operational consequence of policy evaluation rather than the primary function of the system.
PRISM153 does not begin with the question “Which model should receive this request?” It begins with the question “Under which conditions may this organizational intention be translated into AI execution?”
1. The Most Likely Misreading: “Another AI Router”
The term routing creates an immediate risk of reduction. A reader may interpret PRISM153 as a gateway that chooses between providers according to cost, latency, capability or availability. Such functions are useful, and PRISM153 may rely on them, but they do not define its architectural contribution.
A conventional router generally receives a request, evaluates technical or economic parameters, and selects an execution target. Even when advanced constraints are supported, the decision logic often remains tied to the gateway, deployment platform or application that implements it.
PRISM153 changes the level at which the problem is formulated. It treats every AI execution as the materialization of an institutional decision. The execution target matters, but so do the authority under which the decision is made, the policy version applied, the constraints that disqualified alternatives, the rationale for the final route, the evidence retained, and the conditions under which the decision may later be revised.
2. The Architectural Inversion
The dominant model-centric architecture treats the model or provider as the central object. Applications are designed around its interface, capabilities, limits and commercial conditions. Governance is then added through configuration, filters, contractual controls or compliance procedures.
PRISM153 proposes the opposite order:
Traditional model-centric order
Application → Provider Configuration → Model → Controls → Logs
PRISM153 governance-centric order
Institutional Intent
↓
Explicit Governance Policies
↓
Eligibility and Authorization
↓
Decision and Rationale
↓
Execution Target
↓
Evidence, Audit and Policy Learning
In this second order, models, providers, runtimes and infrastructures become governed resources. They remain technically essential, but they no longer define the organizational logic of the system.
The model becomes replaceable. The governance capacity remains.
This inversion has a strategic consequence. Technological components may evolve rapidly without requiring the organization to abandon the principles by which those components are selected, authorized and supervised.
3. The Governance Operating Layer
The architectural space occupied by PRISM153 can be described as a Governance Operating Layer: a layer positioned between organizational intention and heterogeneous AI execution resources.
The expression does not imply a conventional operating system and does not claim that PRISM153 replaces security, identity, legal review, risk management, model evaluation or human accountability. It identifies a missing coordinating responsibility: translating these inputs into executable and auditable decisions.
Intent interpretation
Identify the purpose, context, requester, sensitivity and expected outcome of a workload.
Policy evaluation
Determine which legal, institutional, technical, economic and ethical constraints apply.
Eligibility filtering
Exclude models, providers, agents or environments that do not satisfy mandatory conditions.
Decision arbitration
Compare eligible routes across quality, cost, latency, energy, resilience and dependency criteria.
Execution delegation
Translate the authorized decision into a call to gateways, runtimes, agents or serving platforms.
Decision memory
Preserve sufficient evidence to explain, audit, evaluate and improve future governance.
PRISM153 therefore sits neither inside the model nor solely inside the application. It coordinates the relationship between institutional authority and technical execution.
4. Policies as Durable Architectural Assets
The most important object in PRISM153 is not the model catalogue. It is the policy system through which an organization expresses the conditions governing AI execution.
A policy may represent confidentiality requirements, jurisdictional limits, user permissions, budget ceilings, quality thresholds, sustainability objectives, continuity obligations, logging restrictions, human-oversight requirements or domain-specific prohibitions. These policies are not merely documentation. They are intended to become inspectable, versioned and operational objects.
| Element | Conventional treatment | PRISM153 treatment |
|---|---|---|
| Organizational rule | Document, procedure or implicit convention | Explicit policy object |
| Model selection | Embedded in application logic | Consequence of policy evaluation |
| Provider change | Application migration | Governed substitution of an execution resource |
| Exception | Manual override or hidden conditional | Declared, authorized and traceable decision |
| Audit evidence | Operational logs assembled after execution | Decision trace designed as part of execution |
| Learning | Local technical optimization | Institutional revision of policies and decision criteria |
5. How PRISM153 Differs from Existing Infrastructure
PRISM153 is designed to complement, not replace, the existing AI infrastructure ecosystem. Its difference is therefore best understood by architectural responsibility rather than by a feature checklist.
| Infrastructure family | Primary responsibility | Question typically answered | PRISM153 relationship |
|---|---|---|---|
| API gateway | Normalize access, authentication, quotas and traffic | How can this service be reached? | Uses gateways as execution connectors. |
| Model router | Select among models or providers | Which available target best satisfies routing criteria? | Constrains and authorizes routing through policy outcomes. |
| Inference engine | Execute models efficiently | How can this model run with high performance? | Treats inference engines as governed execution resources. |
| Serving platform | Deploy, scale and operate model endpoints | How can this workload remain available and scalable? | Delegates execution after governance decisions. |
| Agent framework | Coordinate tools, models and multi-step workflows | How should a task be decomposed and performed? | Governs which agents, tools and actions are authorized. |
| Observability platform | Collect traces, metrics and operational events | What happened during execution? | Adds the policy context and rationale explaining why it happened. |
| Compliance tooling | Assess controls and produce evidence | Does the system satisfy defined requirements? | Connects compliance requirements to runtime decisions. |
| PRISM153 | Govern the translation of institutional intent into AI execution | Should this run here, now, under these conditions, and how can that decision be demonstrated? | Coordinates the other layers without subsuming them. |
The distinction is not absolute. Existing platforms may implement policy features, and future products may converge toward governance-centric capabilities. PRISM153 does not claim that no comparable feature exists. Its proposed originality lies in making this responsibility the organizing principle of the entire reference architecture.
6. Sovereignty as Decision Capacity
Debates about sovereign AI often focus on model ownership, national origin, data location, open weights or access to computing infrastructure. Each of these dimensions matters, but none is sufficient on its own.
An organization may host a model locally while depending on opaque policies, unavailable expertise or an uncontrolled software supply chain. Conversely, an organization may use external resources while retaining strong contractual, technical and operational control over the conditions of use.
PRISM153 therefore defines sovereignty as a set of operational capacities:
- the capacity to know which resources and dependencies are being used;
- the capacity to define which conditions govern their use;
- the capacity to exclude unacceptable execution pathways;
- the capacity to preserve alternatives and continuity;
- the capacity to inspect and explain execution decisions;
- the capacity to revise policies without rebuilding every application;
- the capacity to retain institutional knowledge when technologies change.
Sovereignty is not the possession of a model. It is the retained capacity to govern the relationship between organizational intention and technological execution.
7. The Contribution of Key 153
From Routing Requests to Bridging Worlds
Within the ZEON architecture, Key 153 is described as the operator of transition between understanding and action. It preserves intent while enabling passage across heterogeneous domains, actors and levels of interpretation.
Applied to PRISM153, this conceptual origin introduces a broader reading of routing. The system does not merely transport a request toward a computational target. It mediates between organizational purpose, human responsibility, policy constraints, artificial capabilities and technical infrastructures.
PRISM153 routes intentions, capabilities and responsibilities—not only requests.
This conceptual contribution helps explain why coherence is central to the architecture. A technically successful route may still be institutionally incoherent if it violates confidentiality, weakens accountability, creates hidden dependency, prevents future alternatives or displaces risk elsewhere in the system.
The engineering architecture and its evaluation criteria remain independently assessable. Acceptance of the ZEON conceptual framework is not required to implement or evaluate PRISM153. The full architectural application of Key 153 is developed in Chapter 03.01 (Part IV); this section previews the concept for readers encountering it here first.
8. The Original Contribution of PRISM153
The original contribution proposed by PRISM153 can be stated through five connected claims.
Routing is treated as the operational result of policy evaluation, not as an isolated optimization function.
Organizational rules become reusable, versioned and executable architectural assets rather than hidden configuration or external documentation.
The system preserves not only what was executed, but the authority, policy context, eligible alternatives and rationale associated with the decision.
Institutional control is designed to persist while models, providers, runtimes and deployment environments change.
Execution evidence feeds audit, evaluation and policy evolution, transforming operational experience into institutional intelligence.
If Internet routing standardized how packets move across heterogeneous networks, PRISM153 explores how governance decisions might be expressed, executed and inspected across heterogeneous AI infrastructures.
This analogy is intentionally limited. PRISM153 is not presented as an established protocol or universal standard. It identifies a comparable architectural ambition: separating a durable coordination layer from rapidly evolving underlying technologies.
9. Research Boundaries and Transition
The claims in this chapter define an architectural proposition, not an empirical conclusion. Their value must be assessed through implementation, comparison and testing.
Future validation should examine whether a governance operating layer can:
- represent sufficiently expressive policies without becoming unmanageable;
- produce explainable decisions without exposing sensitive data;
- remain interoperable across heterogeneous infrastructures;
- avoid excessive latency, cost and operational complexity;
- preserve human authority and clear accountability boundaries;
- support deterministic controls where required and adaptive behavior where justified;
- demonstrate measurable gains in sovereignty, resilience and auditability.
Execution makes AI available. Orchestration makes it usable. Governance makes its mobilization accountable, revisable and sovereign.
1. The Problem Addressed
1.1 Fragmentation
The AI infrastructure landscape is fragmenting rapidly. Organizations may use general-purpose frontier models for complex reasoning, smaller models for high-volume tasks, multimodal systems for documents and images, specialized models for code or science, local models for sensitive workloads, and agents for multi-step operations. These resources are exposed through incompatible interfaces, pricing models, context limits, service guarantees and governance regimes.
1.2 Hidden decision logic
Routing logic is often embedded inside application code, prompt templates, ad hoc conditionals or vendor-specific configuration. This makes it difficult to answer basic governance questions: Who defined the rule? Which version was active? Why was a given model selected? Which alternatives were rejected? Did the decision respect the applicable confidentiality or budget policy? Can the organization reproduce the decision?
1.3 Conflicting objectives
AI execution is a multi-objective decision problem. Quality, cost, latency, confidentiality, sovereignty, sustainability and availability may point toward different routes. A single static hierarchy of models is therefore insufficient. The appropriate choice depends on the request, user, organizational context, current infrastructure state and applicable policy.
| Objective | Typical question | Potential conflict |
|---|---|---|
| Quality | Which eligible system is most capable for this task? | Higher capability may increase cost, latency or dependency. |
| Confidentiality | May the data leave the controlled environment? | Local execution may offer lower performance. |
| Sovereignty | Which jurisdictions, providers and dependencies are acceptable? | Restrictions may reduce available capacity. |
| Cost | What budget is proportionate to the task? | Cost minimization may degrade outcome quality. |
| Latency | How quickly must the result be produced? | Fast routes may provide less reasoning depth. |
| Resilience | What happens if the preferred route fails? | Fallbacks may violate original assumptions unless pre-governed. |
| Energy | Can a lower-compute route satisfy the requirement? | Energy reduction may affect performance or response time. |
1.4 The governance gap
Many infrastructure stacks are optimized for throughput, compatibility or developer convenience. The gap examined by this Working Paper is the absence of a shared, inspectable layer that translates organizational intent into execution decisions. Such a layer must remain technically realistic: it cannot replace identity management, security engineering, legal analysis, model evaluation or human accountability. It must connect them.
2. Contribution of the Working Paper
This document makes five primary contributions.
The paper maps the major functions of contemporary AI infrastructure: API normalization, routing, inference serving, model deployment, agent orchestration, tool connectivity, observability and cloud-native scheduling. The purpose is not to rank products, but to clarify which architectural problems each family addresses.
The paper identifies the difference between technical routing and governed routing. It analyses the need for explicit policy objects, multi-objective arbitration, hybrid execution, decision memory, auditability, policy lifecycle management and organizational accountability.
PRISM153 is developed as a modular architecture comprising request analysis, policy evaluation, eligibility filtering, decision scoring, token and credential management, execution adapters, caching, observability, fallback and audit mechanisms.
The paper examines how the same architectural principles change across public administration, healthcare, industry, research, defence-sensitive contexts, local authorities and small or medium-sized organizations.
The final chapters identify unresolved questions concerning adaptive policies, distributed governance, multi-agent coordination, energy-aware orchestration, human oversight and the memory of infrastructure decisions.
3. Method and Epistemic Discipline
3.1 Three statuses of statement
To preserve clarity, the document distinguishes three categories of statement:
| Status | Meaning | Expected support |
|---|---|---|
| Observed | A documented feature, standard, regulatory fact or established engineering practice. | Primary documentation, official standards or peer-reviewed research where available. |
| Proposed | An element of the PRISM153 reference architecture or an architectural recommendation. | Explicit rationale, comparison with alternatives and declared assumptions. |
| Hypothesized | An open research direction whose value remains to be demonstrated. | Research question, possible evaluation method and clear statement of uncertainty. |
3.2 Source policy
Technical descriptions should prioritize primary sources: official documentation, standards bodies, project repositories and original research papers. Regulatory descriptions should rely on official institutional sources. Marketing language is not treated as independent evidence. Where fast-moving tools are compared, the date and version context should be stated because capabilities may change rapidly.
3.3 Evaluation criteria
Architectures and tools are examined through a common set of criteria:
Interoperability Policy expressiveness Deployment flexibility Auditability Resilience Security boundaries Operational complexity Cost control Energy awareness Vendor dependency
3.4 Audience
The paper is written for several audiences that do not share the same vocabulary. Engineers need implementable components and interface boundaries. Researchers need explicit hypotheses and evaluation criteria. Decision-makers need to understand dependency, risk and governance. Public institutions need traceability, legal compatibility and continuity. The document therefore combines technical depth with explanatory passages, while avoiding the claim that one level can substitute for another.
3.5 Research Process
This Working Paper was developed through an iterative research process combining engineering practice, systemic architectural analysis and AI-assisted exploration, rather than by linear writing. Each iteration refined concepts, architecture, terminology and structure before being incorporated into the document. The technical foundation originates from the development of PRISM153 by Mossaab Souaissa; ZEON Systems Research — with Adel's contribution to the coherence layer — provided the systemic architectural framework used to organize, formalize and position the emerging concepts (see Appendix G for how these contributions relate).
Research Question
↓
Technical Development
↓
Architectural Exploration
↓
AI-assisted Dialogue
↓
Critical Review
↓
Formalization
↓
Working Paper
Artificial intelligence was used as a research instrument rather than as an autonomous author: it supported architectural exploration, literature synthesis, conceptual comparison, drafting, restructuring and critical review. Research direction, architectural choices, validation of hypotheses and editorial decisions remained under human responsibility throughout.
This Working Paper documents not only a governance architecture for AI infrastructures, but also a research methodology for developing coherent socio-technical architectures through human–AI collaboration.
4. Structure of Version 1.0
| Chapter | Title | Purpose |
|---|---|---|
| 00 | Cover, Executive Summary and Editorial Framework | Define the thesis, scope, method and reading contract. |
| 01 | Why AI Infrastructure Is Becoming Strategic | Explain the transition from isolated model use to governed AI ecosystems. |
| 02A | State of the Art — Gateways, Routers and Inference Engines | Analyse API normalization, routing and high-performance serving. |
| 02B | State of the Art — Orchestration, Deployment and Protocols | Analyse agents, cloud-native deployment, local runtimes and tool protocols. |
| 03 | What Is Still Missing | Formalize the governance, sovereignty and auditability gaps. |
| 04A | PRISM153 — Architectural Vision and System Boundaries | Define principles, actors, trust zones and core components. |
| 04B | Policy Engine and Decision Architecture | Specify policy representation, eligibility, scoring and decision traces. |
| 04C | Deployment, Cache, Resilience and Governance | Specify operational patterns and lifecycle governance. |
| 05 | Representative Use Cases | Apply the architecture to concrete organizational contexts. |
| 06 | Toward a European Sovereign AI Infrastructure | Situate policy-driven orchestration within the European infrastructure landscape. |
| 07 | Research Directions | Define open questions and possible evaluation programs. |
| Annexes | Technology Atlas, Policy Schemas, Glossary and Bibliography | Provide reusable technical and documentary resources. |
4.1 A chapter-based HTML publication model
Version 1.0 is designed as a set of autonomous HTML pages rather than a single monolithic file. Each chapter can therefore be reviewed, corrected, translated, cited and updated independently. A final index page will assemble the complete publication through stable navigation, shared metadata and a unified visual identity.
4.2 Versioning
The version number applies both to the complete Working Paper and to each chapter. A chapter may receive a minor revision without requiring the immediate republication of every other chapter. Material technical changes, new regulatory facts or substantial architectural changes should be recorded in a revision history.
4.3 Scope and Continuation
This Working Paper defines the architectural framework and positions PRISM153 as a governance-centric reference architecture. It is deliberately a foundation, not a closing account: the empirical validation, benchmark execution and further technical specification of PRISM153 are the ongoing responsibility of its developer, Mossaab Souaissa, and are expected to extend beyond Version 1.0. Readers should interpret the "roadmap" language used in Chapters 05.06 and elsewhere accordingly — as a deliberate division of labor between this positioning document and the technical work it is designed to support, not as an oversight.
5. Central Thesis
ProposedA sovereign AI infrastructure is not defined only by where models are hosted. It is defined by the capacity to govern, execute, inspect and revise the decisions that connect organizational intent to AI resources.
This thesis has several consequences. First, the organization must know which resources exist and under which conditions they may be used. Second, policy must be externalized from individual applications wherever practical. Third, routing decisions must be traceable without exposing more sensitive information than necessary. Fourth, resilience must preserve policy intent rather than merely restore connectivity. Fifth, sovereignty must be measurable through operational capabilities, not asserted as a label.
PRISM153 is one proposed response to these requirements. Its relevance will depend on whether it can be implemented with sufficient simplicity, security and interoperability. The chapters that follow therefore examine not only its conceptual appeal but also its engineering constraints and possible failure modes.
6. Foundational References for Chapter 00
- National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, 2023. Official NIST resource.
- European Commission, AI Act enters into force, 1 August 2024. Official European Commission notice.
- European Commission, Regulatory framework for artificial intelligence — application timeline. Official policy page.
- European Commission, AI Factories, updated 23 April 2026. Official European digital strategy page.
- EuroHPC Joint Undertaking, European High Performance Computing Joint Undertaking. Official EuroHPC portal.
- Cloud Native Computing Foundation, Cloud Native Artificial Intelligence Whitepaper, 2024. CNCF report page.
References in this chapter establish the regulatory and infrastructural context. Detailed product, protocol and research references will be provided in the relevant state-of-the-art chapters.
7. Citation and Reuse
Recommended citation:
Publication and reuse conditions should follow the licence selected by the authors for the complete Working Paper. Any implementation using the PRISM153 name should distinguish faithful implementation, experimental adaptation and independent derivative work.