The CTO Advisor 4+1 Layer AI Infrastructure Model

Last revised: October 2026

A Reference Architecture for Composable Enterprise AI Systems

Executive Summary

Every vendor today claims to deliver an “AI Platform” or an “AI Operating System.” In reality, they’re describing different layers of an increasingly disaggregated ecosystem. The CTO Advisor 4+1 Layer AI Infrastructure Model was born not from theory, but from practice.

The DGX Realization: When I moved an AI application from the seamless abstraction of Google Cloud Platform (GCP) to a bare-metal NVIDIA DGX Spark, I hit a wall. The cloud had been operating an invisible Reasoning Plane—making autonomous decisions about where and how to run intelligence, decisions that transcended simple Kubernetes resource scheduling.

The move exposed what was missing: Layer 2C. While GCP provided implicit autonomy—Cloud Run handling auto-scaling based on load (cost/SLA optimization) and Vertex AI managing data access (avoiding egress)—the bare-metal deployment forced me to confront that these functions were nonexistent outside the cloud’s control plane.

Six months later, running vLLM and Ollama side by side on the same Spark hardware confirmed the gap wasn’t a one-time discovery—it’s a persistent architectural absence. I’m making constant decisions about what gets loaded, what gets swapped, and which runtime serves which model. The same gap showed up at hyperscaler scale in a Google Cloud Next briefing with an AI video startup managing dozens of models across accelerator types. Their CTO said something that hit home: he doesn’t want his AI engineers understanding Kubernetes. He wants managed infrastructure that works. The complexity isn’t proportional to scale. The missing layer is. (See: I Just Wanted Endpoints)

The lesson: If you want the intelligence of a hyperscaler AI stack, you must explicitly define and build the Layer 2C Reasoning Plane.

Link: Is your AI Infrastructure 2C Reasoning ready? Try our AI Stack Builder and get a report and heat map about your AI Roadmap.

This framework makes hyperscaler AI system architecture explicit and reproducible for enterprise environments. The goal: reclaim architectural clarity, close the AI delivery gap, and enable enterprises to build composable, performant, and governable AI environments.

1. The Four Foundational Layers of the Enterprise AI Stack

The +1 designation emphasizes that Layer 3 (Agent Applications) is the Value Plane; it consumes the lower layers to deliver business outcomes.

Layer	Purpose	Representative Technologies	Primary Value
Layer 3: AI Application Layer (+1)	Deliver AI-powered business capabilities	LangGraph, CrewAI, Semantic Kernel, Custom Copilots	Business Logic, workflow automation
Layer 2C: Agentic Infrastructure	Policy-driven placement and resource coordination (The Autonomy Layer)	Kamiwaza Orchestration, Custom (OPA + Constraint Solver)	Autonomy, Policy Enforcement
Layer 2B: Application Runtime	Execute and coordinate AI workloads and service graphs	Ray, Vertex AI Pipelines, NVIDIA NIMs, KServe	Model Serving, workflow orchestration
Layer 2A: Infrastructure Orchestration	Govern & provision compute environments	Rafay, Run:ai, GKE Autopilot	GPU Scheduling, quotas, policy
Layer 1C: Data Movement & Pipelines	Move/transform data into governed stores & indexes	Dataflow, Fivetran, Airflow	ETL/ELT, lineage, cost-aware movement
Layer 1B: Context Management & Retrieval	Low-latency retrieval for RAG/features	Weaviate, pgvector, FAISS/ScaNN	Vector/hybrid search, context windows
Layer 1A: Data Foundation & Governance	Governed data foundation: what the data is, who can use it, where it came from	VAST Data, Databricks, Snowflake Arctic	Lakehouse, governance, feature store
Layer 0C: Storage Substrate	Hold the bytes and feed the accelerators	Lustre and other parallel file systems, all-flash file and object arrays	Throughput to accelerators, placement, tiering
Layer 0B: Network Fabric	Move traffic between compute, storage, and the outside	InfiniBand, Ultra Ethernet, NVLink, VMware NSX	Latency, congestion control, isolation
Layer 0A: Compute	Run the workload on silicon	NVIDIA DGX, AMD Instinct, Google TPU, hypervisors	Throughput, runtime portability, partitioning

A note on Layer 1A: In 2026, the data plane’s basics are table stakes. Fast, reliable, S3-compatible storage is one of them, and it now sits at Layer 0C. An open table format like Iceberg is another, and it sits at Layer 1A. These are qualifying criteria, not differentiators. If your vendor can’t deliver them, it isn’t a serious option. But the strategic question has moved above 1A: who owns the reasoning logic your AI system depends on, and what borrowed judgment are you inheriting from your platform vendor? That analysis is in Layer 1A Is Table Stakes. The Real AI Infrastructure Question Is Above It.

2. The Operational Tri-Plane: Orchestration, Runtime, and Reasoning

The operational core is split into three highly specialized planes. Layer 2C is the architectural differentiator that turns infrastructure capacity (2A) and model execution (2B) into an intelligent platform.

Layer 2A – Infrastructure Orchestration (Control Plane)

Role: Govern resource allocation and enforce static policy (quotas, RBAC, lifecycle).

Responsibilities:

Provision and scale Kubernetes/GPU clusters
Enforce quotas, namespaces, RBAC
Optimize utilization and fair-share scheduling
Surface telemetry to Layer 2C for autonomous decision-making

Example policy (enforced by Layer 2A, consumed by Layer 2C):

apiVersion: v1
kind: ResourceQuota
metadata:
  name: ml-team-financial-models
  namespace: financial-ml
spec:
  hard:
    requests.nvidia.com/gpu: "16"

This quota ensures the financial ML team cannot exceed 16 GPUs. Layer 2C respects this constraint when making placement decisions.

Layer 2B – Application Runtime & Execution (Execution Plane)

Role: Manage runtime execution, distributed inference, and model serving.

Responsibilities:

Execute model inference and training workloads
Orchestrate distributed RAG graphs and agent workflows
Handle backpressure, retries, circuit breakers
Expose inference APIs and service endpoints
Report SLA metrics to Layer 2C

Layer 2C – Agentic Infrastructure (The Reasoning Plane)

Role: Act as an intelligent policy engine that makes autonomous placement decisions using business context (governance, cost, SLAs), not just cluster metrics. It enforces the Compute Moves to Data principle.

The Two Layer 2Cs

Production experience—validated across the Articul8 Enterprise Reasoning Plane whitepaper, the Town of Vail deployment, and my own DGX Spark operations—revealed that enterprises actually need two distinct Layer 2C functions:

Infrastructure Layer 2C — the autonomous policy engine that sits between infrastructure orchestration and application runtime, making placement decisions using business context, not just cluster metrics. European customer query → Route to EU cluster. This is the original Layer 2C definition and it remains the foundation.

Intelligence Layer 2C — the reasoning engine that routes requests to the right domain-specific agents, breaks complex missions into sub-missions, and makes autonomous decisions about which intelligence executes against which problem. Semiconductor defect analysis → Route to domain expert agents.

Together: Right intelligence in right place with right cost. Most enterprise AI stacks have neither.

The distinction matters because the failure modes are different. Infrastructure Layer 2C failures produce compliance violations and cost explosions. Intelligence Layer 2C failures produce wrong answers, missed context, and agents that can’t decompose complex problems. Conflating them guarantees you’ll solve the wrong problem first.

This split is documented in depth in The Enterprise Reasoning Plane: Extending the 4+1 Layer AI Infrastructure Model and explored operationally in When Developer Workflow Discipline Isn’t Enough.

Routing Is Not Reasoning

A clarification that has become necessary: endpoint aggregation is not Layer 2C.

Stacks like LiteLLM paired with llama-swap are emerging to provide a single OpenAI-compatible endpoint that dynamically loads and unloads models across runtimes. It’s real progress—endpoint abstraction over heterogeneous serving backends. But it’s routing and model swapping, not reasoning. It doesn’t factor in business context, SLAs, workload priority, or governance policy. It’s plumbing toward Layer 2C, not the layer itself.

If a tool can tell you which model is available but can’t tell you which model should run based on cost, compliance, data residency, and SLA constraints—it’s Layer 2B functionality being marketed as Layer 2C.

Technical Differentiation: Layer 2C vs. Traditional Orchestration

Capability	K8s Operators (Layer 2A)	Layer 2C (Reasoning Plane)
Decision Input	Cluster state (CPU/GPU metrics)	Multi-dimensional: Cluster state + Data governance metadata + Cost policy + Latency SLO
Optimization	Single objective (utilization, queue depth)	Multi-objective (cost + latency + compliance)
Scope	Single cluster	Cross-cluster, hybrid, and edge environments

Example Decision Algorithm (Layer 2C Placement):

# Layer 2C logic: Makes a multi-objective decision
data_meta = self.governance_catalog.get_metadata(workload_request.dataset_id)  # Query Layer 1A

# Apply compliance filter
compliant_clusters = [c for c in clusters if self._satisfies_compliance(c, data_meta.compliance_tags)]

# Multi-objective optimization: minimizes cost/latency while satisfying constraints
best_cluster = self._optimize(
    objectives=[minimize(cost), minimize(latency)],
    constraints=[
        lambda c: c.region == data_meta.data_residency,  # Data Residency Rule
        lambda c: c.available_gpu >= workload.required_gpu
    ])

3. Decision Authority Placement (DAPM)

The 4+1 model surfaces a governance question it can’t answer alone. Every layer makes runtime tradeoffs. A fabric reroutes traffic. A storage system re-tiers data. Layer 2C places a workload or picks a model. Who authorized each of those decisions, and who answers for them?

The Decision Authority Placement Model (DAPM) answers that question. Authority is always placed at a boundary: between two teams, between a human and a model, or between the enterprise and a vendor. At any boundary it lands in one of three placements.

Retained. The near side decides. That’s the human, the team, or code the enterprise writes and controls, wherever that code runs. If you wrote the policy and the vendor’s engine only evaluates it, you decided.
Delegated. Authority crosses under a bounded, revocable grant. The vendor’s or the model’s judgment makes the call inside bounds you set, and you can override any single decision at runtime. Delegation without an override path is cession with a friendlier name.
Ceded. Authority crosses with no way to pull it back. The platform or the model decides, often invisibly, and you inherit the outcome. Ceded isn’t an insult. It describes the governance relationship, not fitness for purpose.

One test decides the placement at every boundary. Can the near side see the decision, override it, and hold the decider accountable? Any no is Ceded.

The other half is accountability. The accountability anchor is the person or team that answers for the outcome. The distance between where the authority went and where the accountability stayed is the DAPM Gap, and that’s where the failures come from.

DAPM prescribes four conditions any design has to meet. Place authority explicitly, at a named boundary. Anchor accountability to the same place. Give every delegation an override path, or call it a cession. Produce evidence that the placement held at runtime.

On my DGX Spark, I retain Layer 2C. I decide what runs, where, and when, and there’s no platform to delegate to. That gives me complete control and zero leverage. A Google Cloud customer running inference on Cloud Run, with GKE handling orchestration, has ceded much of that authority to the platform and gained operational scale in return. Neither placement is wrong. Leaving authority unplaced is.

DAPM also names a second property: portability, whether you can leave with the opinions you built against a vendor. It’s separate from who decides. You can retain authority over a proprietary engine you can’t leave, or run on a portable standard while a vendor’s model makes the calls. The layer2c.com vendor assessments score both, at every layer.

The practical vendor question DAPM adds: when a vendor pitches an AI platform, ask which layer is its Layer 2C. Then ask, at each layer: can I see your platform’s runtime decision, can I override it, and who’s accountable when it’s wrong?

DAPM is published separately and extended by the Auditable Authority companion paper, which introduces the Evidence Chain pattern: DAPM places authority; the Evidence Chain proves that authority was respected at runtime.

4. Data Plane: The Foundation for Context and Retrieval

The Data Plane (1A, 1B, 1C) serves as the context engine. Layer 1A (Data Foundation & Governance) is the Governance Catalog that Layer 2C uses to make its decisions.

Example Governance Metadata (Layer 1A)

This is what Layer 2C queries from the governance catalog:

{
  "dataset_id": "customer_orders_eu",
  "classification": "PII",
  "data_residency": "EU",
  "retention_policy": "7_years",
  "storage_endpoints": [
    "s3://eu-central-1/customer-data"
  ],
  "compliance_tags": {
    "gdpr_compliant": true,
    "data_classification": "Level_3"
  },
  "lineage": {
    "source_system": "SAP_ERP",
    "last_updated": "2024-10-29T08:00:00Z"
  }
}

This metadata drives Layer 2C placement decisions.

Example: How Layer 2C Enforces “Compute Moves to Data”

Scenario: European customer queries copilot about their order history.

Layer 3 Request: Agent asks for customer data
Layer 2C Reasoning: Intercepts the request and queries the Layer 1A Governance Catalog for the dataset metadata: data_residency: "EU"
Placement Decision: Layer 2C instructs Layer 2A to provision the runtime only on available clusters in the EU region (eu-central-1)
Execution: Inference runs entirely within the EU. The data never crossed borders.

Key enabler: Governance metadata (1A) became orchestration input (2C).

5. Layer 0: Compute, Fabric & Storage Substrate

Layer 0 is the physical substrate everything above it runs on: the silicon, the network that connects it, and the storage that feeds it. The original version of this section treated that substrate as one thing. It isn’t. A GPU server, a switch fabric, and a storage array each make different runtime decisions, carry different lock-in, and answer to different teams. One layer hid the differences that drive the buying decision.

Layer 0 has three sub-layers. The split follows the runtime decision each part of the substrate makes, not the vendor’s product catalog. It also follows how most enterprises are already organized, with a server and virtualization team, a network team, and a storage team. Each sub-layer has a team that answers for it.

Layer 0A – Compute

Role: Run the workload on silicon, and present that silicon to everything above it.

Covers:

Host CPUs, GPUs, tensor processing units (TPUs) and other accelerators, and the servers they ship in
Integrated systems: rack-scale GPU systems, TPU pods, turnkey AI factories
The operating system and hypervisor, including GPU partitioning (Multi-Instance GPU layouts, virtual GPU profiles)
Power and cooling

Runtime decisions: which hardware the workload’s compiled form binds to, how an accelerator gets carved up, which host a virtual machine lands on, and when power or thermal limits throttle it. Which host is a 0A decision. Which workload gets the capacity is Layer 2A.

Layer 0B – Network Fabric

Role: Move traffic between compute and storage, and out of the data center.

Covers:

Scale-up and scale-out interconnects: NVLink, InfiniBand, Ultra Ethernet
Data center, campus, and wide area network (WAN) switching and routing
Network virtualization that programs the fabric: VMware NSX, cloud software-defined networking
Network interface cards (NICs) and data processing units (DPUs) where they make transport decisions

Runtime decisions: routing, congestion control, isolation between tenants, and when switch state changes or changes back.

Layer 0C – Storage Substrate

Role: Hold the bytes and get them to the accelerators fast enough.

Covers:

Storage arrays and storage servers
Storage software on commodity servers, including parallel and object file systems
Front-end protocols: Network File System (NFS), Server Message Block (SMB), S3, NVMe over Fabrics

Runtime decisions: where data lands, when it moves between tiers, how it replicates, and what rebuilds first after a failure.

Layer 0C is where the data sits. Layer 1A is the data itself: what it is, who can use it, where it came from. Storage counts at 0C only. A storage platform that also sells a catalog or data governance shows up at 1A for those, never for the storage itself.

Where do the lines fall?

A component sits where its decision gets made, not where the vendor files it. VMware sells NSX as part of a virtualization platform. However, NSX decides network state, so it’s Layer 0B. The hypervisor beside it is 0A. One product can sit in more than one sub-layer, the same way a storage platform sits at both 0C and 1A.

Hardware management splits by scope. The controller built into a server or a rack is part of that hardware, and it counts there. A fleet manager you run across hundreds of servers is a different thing. It provisions infrastructure and enforces policy over it, which is Layer 2A’s job, so that’s where it sits. The split matters when you leave. You can swap one OEM’s servers for another’s without rebuilding anything. You can’t carry the fleet templates and firmware baselines you built in the first vendor’s manager. That lock-in lives in the fleet manager, not the box. Who holds authority during an incident a year after deployment is a separate question, day-two operational authority, and neither this model nor DAPM answers it yet.

Why does the split matter? Because the failures happen at the seams. Take a VMware Cloud Foundation (VCF) rollout where developers request virtual networks and get them in minutes. The network team still answers for the network. So who decided that a switch configuration should change, or change back? The platform did. Authority was ceded to it implicitly, and accountability stayed with the network team. That distance between where the decision went and who answers for it is the DAPM Gap. With one Layer 0, that seam is invisible. With three, it has a name: the boundary between 0A and 0B. If you can’t name the boundary, you can’t place the authority.

Can you leave Layer 0?

Generic x86 servers and NVIDIA GPUs look like the most portable things in the stack, and on a purely technical level they are. That’s the wrong level to ask the question. Can the services that support Layers 1 and 2 be decoupled from the vendor’s Layer 0? The answer depends on what the vendor is offering.

Can I take my decisions from Google TPUs to NVIDIA CUDA? Maybe. If the workload runs on an open runtime like vLLM, yes. Can I get Gemini on AWS’s NVIDIA GPUs? No. Gemini runs on NVIDIA Blackwell inside Google Distributed Cloud, so the silicon isn’t what holds it there. The service is. Hardware is only as portable as the services you run on it.

6. Layer 3: The AI Application Layer (+1)

Layer 3 is the Value Plane where agents realize autonomous reasoning. It is the application logic that consumes the autonomy and policy enforcement provided by Layer 2C.

Division of Responsibility:

Layer 3 (Agent Apps): Focuses on Application Logic (e.g., multi-step planning, memory management for a user)
Layer 2C (Agentic Infra): Focuses on Infrastructure Logic (e.g., policy enforcement, global capacity management)

Intra-Loop Governance

A design constraint that emerged in production: when the same model both performs work and decides when to stop, escalate, retry, or redefine success, reliability degrades. This is the Intra-Loop Governance problem.

Layer 3 agents operating without explicit loop boundaries will expand their own scope. The AI evolution has caused an immense amount of confusion among enterprise AI stakeholders—business process owners see a natural language interface and assume AI has both intelligence and consistency. Neither is true. The design requirement is to separate the execution role from the judgment role within agentic loops, or accept that governance is structurally absent from the system.

Treat reasoning models as components that require explicit authority boundaries, not as general-purpose substitutes for existing system logic. If a decision can be made deterministically, it should be. If reasoning is required, it should be invoked deliberately and in isolation. Systems fail when authority is assumed rather than assigned.

7. End-to-End Flow and Case Studies: The Tri-Plane in Action

The modern AI request flows Upward (Data & Context) from Layer 0 to 3, while Control (Policy & Orchestration) flows Downward from Layer 2C/2A to 0.

Case 1: The DGX Realization (Architectural Exposure of Layer 2C)

The vCTOA was successfully deployed on a managed environment (GCP Cloud Run, Vertex AI) where the Layer 2C function was implicit.

Layer 2A/2B (Runtime/Orchestration) was handled by Cloud Run, providing seamless auto-scaling (load-based scaling is a form of cost/SLA optimization)
Data Locality was implicitly managed by Vertex AI and Google Search Grounding, reducing the need for explicit egress controls

The attempt to define the stack for a bare-metal DGX Spark environment immediately exposed the missing Layer 2C. The realization: on-premise, I would have to manually build the logic to manage auto-scaling, enforce cost limits, and ensure the LLM workload runs near its data (GCS/Discovery Engine), validating that Layer 2C is the essential, missing component in traditional bare-metal AI infrastructure.

Case 2: CTO Signal Scanner (Layer 2C Function as Cost Governor)

The vCTOA architecture implements a critical cost-saving function via Conditional Grounding and Advisory Mode (disabling live search).

L3 Agent Request: “Analyze this stream of articles”
Decision Logic (Embedded in Layer 3): The Chat API (L3) executes the logic to switch between using the curated knowledge base (cheap) and invoking Google Search Grounding (expensive, L2B/External). This logic is structurally performing the cost governance function of Layer 2C.
Impact: By pre-filtering content before invoking the expensive LLM/Search process (an optimization currently embedded in L3), the system achieved a 70% reduction in L2B (GPT) API calls—proving that this decision-making is the core autonomous cost governance that needs to be abstracted into Layer 2C.

This shows that in early-stage enterprise AI platforms, the core Layer 2C function often starts embedded within the Layer 3 application logic, waiting to be abstracted into its own dedicated reasoning plane for enterprise-wide use.

Case 3: The Town of Vail Smart City (Agentic Layer 2C in Action)

The HPE Agentic Smart City solution deployed in the Town of Vail uses the Kamiwaza orchestration platform as a direct, explicit implementation of Layer 2C (The Reasoning Plane). This deployment proves the architectural viability and speed of Layer 2C, moving from concept to four functional use cases in less than three months.

Layer 2C Functions Demonstrated:

1. Autonomous Governance and Security (ReBAC)

Kamiwaza’s ReBAC (Relationship, Attribute, Role-Based Access Control) security model is implemented at Layer 2C to ensure agents can only access data and tools within their authorized security context, even when sub-agents are involved. This is critical for cross-departmental use cases where a single agent (L3) may need to query data from multiple, siloed systems (L1A/B).

2. Compliance-Driven Policy Enforcement (508 Compliance)

The Agentic solution includes a use case for 508 compliance (accessibility for people with disabilities), which Vail has already implemented. The Layer 2C agent not only identifies areas for remediation but is able to perform those remediations (e.g., creating alt text for images, reading PDFs), with a human-in-the-loop review before posting. This demonstrates an agent autonomously enforcing a key governance policy, a core function of Layer 2C.

3. Cross-Silo Coordination and Multi-Objective Decision-Making (Fire Detection and Prevention)

Layer 2C orchestrates multiple Layer 2B models (Vision AI, Geospatial) and Layer 1C data feeds (NOAA, satellite imagery, moisture sensors) to analyze a potential fire incident. It uses a complex, multi-objective assessment (e.g., high timber rating + high home impact + Red Flag Day) to create a full report and urgency rating, which then dictates a multi-departmental workflow (notifying fire department, city planners, and reverse 911). This policy-driven, time-sensitive workflow is the essence of Layer 2C autonomy.

4. Compute-to-Data Locality

The Kamiwaza stack, running in Vail’s private data center, is designed to move the compute to the data. Its Inference Mesh and Distributed Data Engine scan all enterprise data, build a global data catalog (L1A), and redirect inference requests to the stack closest to the required data, ensuring security and low latency.

The Vail use case provides a clear, high-ROI example of Layer 2C’s ability to break down departmental silos with a unified agentic platform.

Case 4: Google Cloud — Layer 2C at Hyperscaler Scale

At Google Cloud Next, I sat in a briefing with an AI video startup that validated Layer 2C at the opposite end of the scale spectrum from my DGX Spark. They’re running stacks of models for a single workflow: video fusion, object detection, lighting, shadows, occlusion. Each model is potentially 10 to 100 gigabytes. Different models require different accelerator types and different amounts of memory.

Google’s response is productized Layer 2C:

Inference Gateway routes AI requests based on KV cache disposition and workload characteristics — yielding significant improvements in latency and cost.
Dynamic Workload Scheduler matches workloads to available resources and productizes accelerator availability through mechanisms such as Flex Start.
Managed KV cache tiering traverses HBM, local storage, and managed storage.

These are all Reasoning Plane capabilities — orchestration intelligence that sits between hardware and application. What was notable: not a single reference to tokens or cost of tokens. This CTO was taking full advantage of GPUs in Cloud Run, with GKE handling orchestration. The experience confirmed that the Layer 2C gap is identical at every scale. The only difference is whether you’re managing it manually or the platform is managing it for you. The DAPM question is whether you placed that authority on purpose, and whether you can override what the platform decides.

8. Common Failure Modes

Failure Mode 1: Skipping Layer 2C (The Critical Failure)

Symptom: Application team builds agent that directly calls 2A orchestration APIs.

What Breaks: GDPR Violation. Agent provisions GPU in US region, retrieves EU customer data, leading to PII compliance failure.

Fix: Implement a Layer 2C service mesh where all provisioning requests flow to enforce the if data_residency == "EU" then cluster.region must == "EU" rule.

Failure Mode 2: Telemetry Lag in 2C Decision Loop

Symptom: Layer 2C makes placement decisions based on 5-minute-old utilization data.

What Breaks: SLA Violation. 2C routes workload to an “idle” cluster that is actually at 95% utilization.

Fix: Migrate telemetry data consumption from pull-based (stale metrics) to push-based streaming with a maximum age limit (e.g., 1 second).

Failure Mode 3: Boundary Friction Between 2A and 2C

Symptom: 2C (Reasoning) and 2A (Orchestration) policies conflict. 2C says “Scale up,” but 2A says “Quota exceeded, scaling down.”

What Breaks: Cost Spikes/Churn. Constant pod thrashing prevents workloads from completing.

Fix: Introduce hysteresis bands (e.g., stable zone: 65-85%) into the Layer 2C scaling logic to prevent rapid, conflicting decisions.

DAPM calls this boundary friction: two placements that each make sense on their own, failing at the seam where one layer’s decision triggers consequences the other layer governs.

Failure Mode 4: Unplaced Authority (DAPM Failure)

Symptom: AI system operates correctly in pilot but produces compliance incidents, unexplainable decisions, or audit failures in production. No one can identify who authorized the system’s runtime behavior.

What Breaks: Governance. The system accumulated decision rights through inheritance rather than design. Authority was never explicitly placed — it was assumed by the model, the platform, or the team that deployed it.

Fix: Apply DAPM to every runtime decision, at whatever layer it’s made. Name the boundary. Place the authority: Retained, Delegated, or Ceded. Name the accountability anchor. Give every delegation an override path. Keep evidence that the placement held. Do it before deployment. If a decision can be made deterministically, it should be. If reasoning is required, invoke it deliberately and in isolation. Leaving authority unplaced is still a decision, and someone answers for it in the post-incident review.

9. Decision Frameworks: Build vs. Buy

Feature	Option 1: Build Your Own 2C	Option 2: Packaged 2C Platform (e.g., Kamiwaza)
Effort	6-12 months, 2-3 engineers	2-4 months implementation (Vail achieved use cases in <3 months)
Components	OPA/Kyverno (Policy), Custom Python/Constraint Solver (Placement), etcd (State)	Kamiwaza Orchestration, NVIDIA NeMo Guardrails, Ray on KubeRay + Custom Controller
Control	High (Custom algorithms)	Medium (Vendor-defined APIs)

10. Implementation Guide: Sequencing

Critical path: You CANNOT skip to Layer 3 without 1A, 2A, 2B, and 2C.

Phase	Layers	Key Deliverable
Phase 1: Foundation	Layer 1A, Layer 2A	Can provision GPU workloads with governed quotas
Phase 2: Runtime	Layer 1B, Layer 2B	Can serve models and execute RAG pipelines at scale
Phase 3: Reasoning	Layer 2C	Policy-driven placement working (Integrate 2C with 1A and 2A)
Phase 4: Applications	Layer 3	Business value realized via autonomous agent workflows

11. Cost Lens by Layer (ROI of Layer 2C)

Layer 2C is the Cost Governor because it is the only component that sees cost across all layers simultaneously.

Example: Multi-Objective Cost Optimization

Metric	Without Layer 2C (Naive Routing)	With Layer 2C (Cost-Aware Routing)
Placement Logic	Routes to fastest available GPU (A100 in US)	Routes to sufficient GPU (A10 in EU)
Data Egress	$0.08/GB (from EU storage to US compute)	$0.00 (Local access in EU)
Cost per 1000 Requests	~$2.50	~$1.20

ROI of Layer 2C: Layer 2C facilitates a 52% cost reduction by trading latency headroom for cost savings, all while meeting the SLA. This infrastructure autonomy provides a clear, defensible business justification for the Layer 2C investment.

12. Strategic Takeaways

For CTOs

Action 1: Challenge Vendor Claims

When a vendor pitches an “AI Platform,” ask: “Which layer is your Layer 2C?” If they cannot define the reasoning plane, they are selling you automation, not autonomy.

Then ask the DAPM question at each layer: can I see your platform’s runtime decision, can I override it, and who’s accountable when it’s wrong?

Action 2: Sequence Your Build

Do not fund Layer 3 agent applications until Layer 2C is deployed and integrated with Layer 1A governance.

Anti-pattern: Building Layer 3 agents before 2C exists leads to ungoverned autonomy, cost explosions, and compliance failures.

Action 3: Identify Borrowed Judgment

Map where your AI system inherits runtime decisions from a vendor platform that you can’t see or override. Then ask the portability question: when you move the workload, which of the opinions you built don’t move with it? Where both answers are bad, that’s borrowed judgment. Decisions you can’t see, built into opinions you can’t take with you. No data-portability checklist will catch it, because the data was never the part that was stuck.

For Architects

Principle 1: Governance Enables Autonomy

Layer 2C only works if Layer 1A metadata is rich and accurate. Investment in the Data Plane (1A) must precede investment in the Reasoning Plane (2C).

Principle 2: Disaggregate for Agility

Replace monolithic “AI platforms” with best-of-breed components at each layer, defined by clear API contracts (See Appendix A).

Principle 3: Place Authority Before You Deploy

Every runtime decision has a placement, at every layer, not only Layer 2C. Make it explicit during architecture, not during the audit. Systems fail when authority is assumed rather than assigned.

13. Related Frameworks

The 4+1 model is the structural backbone. These companion frameworks address the governance, economics, and operational dimensions that the infrastructure model alone cannot cover. They were not built independently — they are observations of the same problem from different angles. That synthesis is documented in One Problem, Five Frameworks: Why Enterprise AI Stalls — and How to Fix It.

Decision Authority Placement Model (DAPM): Who decides at runtime, at a named boundary. Places authority as Retained, Delegated, or Ceded, anchors accountability to it, and requires an override path for every delegation. When authority placement is left implicit, disputes don’t end cleanly.

AI Factory Economics — What hidden responsibility costs. Oversight, rework, governance, orchestration, monitoring, and quality control often determine real economics. Cheap inference with expensive operating drag is not efficient AI.

Intra-Loop Governance — What happens inside agentic systems. When the same model both performs work and decides when to stop, escalate, retry, or redefine success, reliability degrades.

Auditable Authority & Evidence Chain — DAPM places authority. The Evidence Chain proves that authority was respected at runtime. Design tool for preventing capability-driven drift.

Fourth Cloud — The venue reality: AI control has to span SaaS, hyperscaler, private cloud, edge, neocloud, and embedded vendor platforms. Decision placement must be explicit across all of them.

4+1 RFP Framework — A practitioner-aligned, vendor-neutral standard for evaluating AI platforms against the 4+1 model. Published as an open edition.

TRiSM Field Guide — Operationalizing AI trust, risk, and security management through 4+1 and DAPM architecture, controls, evidence, and operating decisions.

The comprehensive treatment of this framework system is available as a free download: 4+1: The Enterprise AI Field Manual — Revised Edition.

Changelog

November 2025: Original publication. Introduced the 4+1 Layer AI Infrastructure Model, Layer 2C as the Reasoning Plane, the DGX Spark realization, vCTOA cost governance case study, and the Town of Vail deployment.
May 2026: Added Infrastructure/Intelligence Layer 2C distinction. Added DAPM (Decision Authority Placement Model) section and Retained/Delegated/Ceded classification. Added routing vs. reasoning clarification. Added Google Cloud Next case study (Case 4). Added Failure Mode 4 (Unplaced Authority). Added Intra-Loop Governance under Layer 3. Added Layer 1A table-stakes note. Added Action 3 (Borrowed Judgment) and Principle 3 (Place Authority Before You Deploy). Added Related Frameworks section. Added changelog.
October 2026: Split Layer 0 into three sub-layers by the runtime decision each makes: 0A Compute, 0B Network Fabric, 0C Storage Substrate. The original section treated the substrate as one thing; compute, networking, and storage each decide differently, lock in differently, and answer to different teams. Storage moved out of Layer 1A to 0C, and 1A is renamed Data Foundation & Governance: it’s the data itself, not where it sits. Reconciled the DAPM content with DAPM v2: placement at a named boundary, one see-override-accountable test, Retained including code the enterprise controls, the accountability anchor and the DAPM Gap, the four prescriptions, and portability as a separate property. Renamed Failure Mode 3 to boundary friction, since DAPM v2 uses “oscillation” for authority moving after incidents.