The CTO Advisor 4+1 Layer AI Infrastructure Model

By Published On: November 5, 2025

The CTO Advisor 4+1 Layer AI Infrastructure Model

Last revised: May 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 Storage & Governance Durable, governed data foundation VAST Data, Databricks, Snowflake Arctic Lakehouse, governance, feature store
Layer 0: Compute & Network Fabric Raw compute, networking, and acceleration fabric NVIDIA DGX, AMD MI300, InfiniBand, Ethernet Throughput, latency, capacity

A note on Layer 1A: In 2026, Layer 1A capabilities—fast, reliable, S3-compatible, Iceberg-capable storage—are table stakes. These are qualifying criteria, not differentiators. If your storage vendor cannot deliver them, they are not 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 that it cannot answer alone: if Layer 2C makes autonomous decisions, who authorized that autonomy, and under what constraints?

The Decision Authority Placement Model (DAPM) answers that question. DAPM uses a three-state classification:

  • Retained — Human decides. The system presents options; a person makes the call.
  • Delegated — Human sets policy, AI executes within guardrails. Authority is bounded and auditable.
  • Ceded — AI decides autonomously. The organization accepts the system’s judgment within a defined domain.

Every Layer 2C decision—where to place a workload, which model to route to, whether to invoke expensive grounding or use the local knowledge base—falls into one of these categories. The design task is to make that classification explicit before deployment, not discover it during the post-incident review.

On my DGX Spark, I retain full governance over Layer 2C because no platform exists to delegate to. I decide what runs, where, and when. That gives me complete control and zero leverage. A Google Cloud customer running inference through Cloud Run with GKE handling orchestration has ceded significant portions of that authority—and gained operational scale in return. Neither placement is wrong. Unplaced authority is wrong.

The practical vendor question DAPM adds: When a vendor pitches an AI Platform, ask not only “Which layer is your Layer 2C?” but also “What authority classification does your platform assume—Retained, Delegated, or Ceded—and where does the boundary sit?”

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 (Storage & 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.

  1. Layer 3 Request: Agent asks for customer data
  2. Layer 2C Reasoning: Intercepts the request and queries the Layer 1A Governance Catalog for the dataset metadata: data_residency: "EU"
  3. Placement Decision: Layer 2C instructs Layer 2A to provision the runtime only on available clusters in the EU region (eu-central-1)
  4. 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 & Network Fabric

The physical substrate: GPUs/TPUs/CPUs, interconnects, and offload. Networking is a first-class element that defines throughput and data locality.

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 — and the DAPM question is whether you’ve made that delegation explicit.

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: Policy Oscillation 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.

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. Classify every Layer 2C decision as Retained, Delegated, or Ceded. Document the classification before deployment. If a decision can be made deterministically, it should be. If reasoning is required, invoke it deliberately and in isolation. The absence of an explicit placement decision is itself a decision — one that will be evaluated during 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: “What authority classification does your platform assume — Retained, Delegated, or Ceded — and where does the boundary sit?”

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 reasoning logic from a vendor platform without explicit governance. When you move a workload off that platform, what judgment doesn’t move with it? That’s your borrowed judgment dependency — and it’s the lock-in vector that no portability checklist will catch.

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 Layer 2C decision has an authority classification. 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 owns runtime judgment. Classifies authority as Retained, Delegated, or Ceded. 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.

Share This Story, Choose Your Platform!

RelatedArticles