# Fourth Cloud — Full Dataset > https://fourthcloud-23ae5.web.app/llms-full.txt Complete vendor assessments. Use this file for detailed questions: scoring per function, narratives, gap ownership, DAPM, identity plane continuity, and notes. --- # VMware Cloud Foundation (VCF) — Fourth Cloud Assessment *Fourth Cloud Control Plane Assessment — Substrate-Agnostic* **Version:** v2.4 **Date:** May 29, 2026 **Status:** complete **Evolution model:** continuous **Source:** VCF 9.1 GA (May 2026), VMware Explore 2025, Broadcom press releases, VCF Private AI blog series, 4+1 VMware assessment v1.2, Fourth Cloud methodology v2.3, comparative review against ChatGPT v0.1 and Gemini v1.0, vSphere Supervisor VM Service documentation (Broadcom TechDocs May 2026), VCF 9.0 app modernization blog (VMware July 2025), editorial review and consistency corrections, VCF 9.1 GA documentation verification (May 2026), Broadcom VCF 9.1 security/MCP/vSAN blogs, Tanzu Platform Agent Foundations announcement, Broadcom self-assessment workbook review ## Summary Finding VMware Cloud Foundation is the most operationally mature Fourth Cloud control plane for on-prem environments. The v2.2 assessment incorporates three model comparisons and a product documentation pressure test that materially changed several scores. The core finding is unchanged: VCF is strongest at FC-2A and FC-2B, weakest at FC-1 and FC-4, and absent at FC-2C. FC-0 F1 moves to 3. vSphere Lifecycle Manager combined with OEM Hardware Support Managers (HSMs) integrates firmware lifecycle into the VCF management plane for primary OEM hardware. Dell, HPE, and Lenovo publish HSMs — firmware updates flow through SDDC Manager alongside software lifecycle. This was missed in v2.0 and v2.1. FC-2A F4 and F5 both move to 3. vSphere HA and maintenance mode provide genuine cross-workload substrate lifecycle integration, and vLCM + HSM integration closes the firmware scheduling gap. GPU management through vGPU profiles, MIG isolation, DRS GPU policies, and platform-integrated NVIDIA GPU Operator constitutes strong accelerator management with partially-held scheduling intelligence — the F3=3 anchor. FC-2B F1 stays at 3 with a corrected and strengthened narrative. The VM Service CRD model introduced in VCF 9.0 is the decisive evidence: VMs are deployed and managed through standard kubectl and Kubernetes YAML manifests via VirtualMachine CRDs, in the same namespace, with the same RBAC, and through the same toolchain as container workloads. The two-model consensus for F1=2 in comparative review was based on the pre-9.0 vSphere mental model. VCF 9.x is genuinely Kubernetes-native for both VMs and containers. FC-4 F5 moves to 1. MCP Server Governance governs access to MCP tools but does not manage tool connections end-to-end as a platform service. The distinction between access control over connections and managed connection infrastructure is the correct boundary between F1=1 and F2=2. FC-4 remains VCF's most significant gap portfolio. All four universal FC-4 functions score 0 — event fabric, API management, workflow orchestration, and SaaS/system integration. FC-4 F5 (AI-native integration) scores 1 as an AI-workload-specific function. An enterprise deploying VCF as a Fourth Cloud control plane must acquire and maintain a full integration platform. FC-2C remains absent with Structural gap ownership — no product announcement with confirmed timeline exists. Identity plane continuity scores 1 (siloed); the VM Service CRD model extends the native plane to cover VMs and containers within FC-2B, but AI inference workloads, FC-1 data governance, FC-0 substrate identity, and FC-4 integration boundaries remain outside it. v2.4 corrections applied following VCF 9.1 GA documentation verification and review of the Broadcom self-assessment workbook (which returned a parallel VCF self-assessment rather than itemized feedback; all claims were verified against primary Broadcom documentation before any cell moved). One score change: FC-4 F5 (AI-native integration) corrected from 1 to 2 — VCF 9.1 ships MCP Server Governance (RBAC access control, GA) plus a centralized Audit Trail in VCF Operations (call-level audit across all components, GA). Access control plus audit clears the same bar as the comparable on-prem MCP governance peer, resolving a latent cross-vendor calibration inconsistency. The remaining gap from 3 is the managed AI integration fabric (tool discovery, connection lifecycle, dynamic routing, agent-to-agent identity propagation), which no on-prem vendor provides. Three narrative updates, no score change: FC-0 F2 adds confirmed VCF 9.1 multi-accelerator breadth (AMD MI350 Enhanced DirectPath, multi-host GPUDirect RDMA, ConnectX-7/BlueField-3); FC-1 F1 adds Native vSAN S3 Object Storage as a Vendor roadmap note (tech preview in 9.1.x, not GA, not scored); FC-3 F4 strengthens the existing score with confirmed Tanzu Platform Agent Foundations and MCP marketplace publishing. FC-2B F4 gap ownership remains Opinion — v2.3 correctly characterized the remaining gap as the structural on-prem inference ceiling (narrower backends, less cloud-like auto-scaling) configured around with existing primitives, not a Vendor roadmap item. Against the AWS=4 benchmark, the FC-4 F5=2 remains two full gradient steps below the hyperscaler managed-integration model; the change reflects genuine VCF 9.1 MCP governance progress, not a narrowing of the structural managed-service gap. ## Identity Plane Continuity **Score:** 1 **Classification:** siloed **Gap ownership:** mixed **Layers in plane:** fc2a, fc2b-vm-container **Layers siloed:** fc0, fc1, fc2b-inference, fc2c, fc3, fc4 VCF 9.x introduces the VCF Identity Broker, which improves administrator SSO across VCF components with support for Entra ID, Okta, Active Directory, OpenLDAP, Ping Identity, and generic SAML. This is a meaningful improvement to the administrative persona experience. It does not create a workload identity plane. The VM Service CRD model introduced in VCF 9.0 meaningfully extends the native identity plane: VMs deployed through VM Service CRDs operate within the same Kubernetes RBAC, namespace model, and service account infrastructure as container workloads. A VM and a container in the same vSphere Namespace share the same identity surface — the same Kubernetes RBAC policies govern both. This extends the native identity plane from FC-2A into FC-2B for VM and container workloads specifically. AI inference workloads through Model Runtime use a different API surface and are not in the same Kubernetes identity plane. FC-0 substrate identity — OEM hardware node compliance tagging — is not visible at FC-2A or FC-2B without operator-configured policy bridges. FC-1 data governance metadata is not in the same identity plane as FC-2A orchestration policy. FC-2C does not exist. FC-3 application identity through MCP Server Governance uses vSphere user groups — a meaningful connection to FC-2A — but not extended to FC-4. FC-4 has no integration fabric so identity propagation across integration boundaries does not exist. **Buyer implication:** No. You cannot use FC-0 substrate identity to control FC-2B application runtime execution natively in VCF. A SOX-tagged hardware node does not automatically restrict which application runtimes execute on it. Enforcing that constraint requires the operator to write vSphere DRS rules, NSX micro-segmentation policy, and Kubernetes admission controller rules independently — three separate policy instruments, each requiring maintenance when the SOX tagging changes. The cost is not theoretical: every cross-layer identity enforcement requirement in VCF is a Closeable gap with Townsend's full Section 2.6 lifecycle burden. For an enterprise with significant compliance requirements spanning multiple layers, this is the most expensive gap in the VCF Fourth Cloud profile. ## Layer-by-layer scoring | Layer | Avg score | Status | |---|---|---| | FC-0 — Physical & Virtual Substrate | 3.00 | Strong | | FC-1 — Distributed Data & Context Fabric | 1.75 | Gap | | FC-2A — Infrastructure Orchestration | 2.80 | Moderate | | FC-2B — Execution & Runtime | 2.75 | Moderate | | FC-2C — The Reasoning Plane | 0.00 | Absent | | FC-3 — Application Distribution and Governance | 2.75 | Moderate | | FC-4 — Integration Fabric | 0.40 | Absent | **DAPM profile:** Retained 8 · Delegated 1 · Ceded 17 ### FC-0 — Physical & Virtual Substrate *The physical foundation the control plane lifecycles — scored on the control plane's relationship to substrate, not on the substrate itself.* #### Hardware lifecycle management *(universal)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Delegated vSphere Lifecycle Manager (vLCM) combined with OEM Hardware Support Managers (HSMs) provides firmware and driver lifecycle management in lockstep with VCF software updates through SDDC Manager. Dell, HPE, Lenovo, and other major OEMs publish HSMs for VCF — when an HSM is deployed, SDDC Manager can manage firmware updates through the same lifecycle workflow as VCF software component upgrades. The enterprise retains hardware vendor choice but sheds the manual hardware lifecycle burden for primary OEM hardware. The gap from 4: HSM availability varies by OEM — less common hardware vendors may not have published HSMs, requiring separate management surfaces for those nodes. For primary enterprise OEM hardware (Dell, HPE, Lenovo), the vLCM + HSM integration closes the hardware lifecycle gap to the level of the F3=3 anchor. This is an Opinion gap — the enterprise deploys the appropriate OEM HSM through existing VCF mechanisms, not a new capability acquisition. #### Substrate heterogeneity *(universal)* **Score:** 3 · **Gap ownership:** structural · **DAPM:** Retained VCF runs on Dell PowerEdge, HPE ProLiant, Lenovo ThinkSystem, Cisco UCS, Supermicro, NEC, Fujitsu, and others through the same vSphere control plane. The enterprise retains hardware vendor choice without changing the management plane above it. VCF 9.1 manages AMD Instinct MI350, NVIDIA Blackwell HGX B200/NVLink Switch, and Intel accelerators through unified vGPU profiles, vmclasses, and DRS policies — the broadest multi-accelerator management of any on-prem control plane assessed. The gap from 4: substrate selection is not fully invisible — the developer or operator specifying a GPU workload must select accelerator type through vmclass configuration. Hardware-agnostic intent declaration remains partial. VCF 9.1 GPU breadth (confirmed): HGX B200/B300 and NVLink Switch support, DirectPath I/O for NVIDIA ConnectX-7 and BlueField-3 SuperNICs with Enhanced DirectPath, Enhanced DirectPath for AMD Instinct MI350, and GPUDirect RDMA across multi-host configurations. Multi-accelerator Model Runtime deploys AI models on both AMD and NVIDIA GPUs without application refactoring. This is the broadest multi-accelerator management set of any on-prem control plane assessed — and it is genuine substrate heterogeneity (AMD + NVIDIA + Intel) rather than NVIDIA-only, distinguishing VCF from the predominantly NVIDIA-locked AI stacks of the other assessed vendors. #### Substrate portability *(universal)* **Score:** 3 · **Gap ownership:** structural · **DAPM:** Ceded VCF runs on on-prem hardware AND public cloud substrate via VMware Cloud on AWS, AND distributed/edge environments via VCF Edge — without architectural changes to the control plane. The same vSphere management plane, the same VCF Automation catalog, and the same operational model apply across all substrate types. This is VCF's most distinctive Fourth Cloud claim: the control plane is genuinely substrate-agnostic. The gap from 4: VMware Cloud on AWS and VCF Edge are separate SKUs with some operational differences from on-prem VCF. True architectural unity across all substrate types is present in principle but requires per-deployment configuration in practice. *Notes: FC-0 F1 improved materially once vLCM + OEM HSM integration was accounted for. The remaining gap is not that VCF lacks hardware lifecycle integration for primary OEMs; it is that coverage depends on HSM availability and configuration by OEM. VCF scores higher than DCAP on F2 and F3 because VCF is hardware-agnostic by design. DCAP manages Dell hardware; VCF manages any hardware.* ### FC-1 — Distributed Data & Context Fabric *The data fabric the reasoning plane queries for placement decisions — covers the full enterprise data estate, not AI workloads only.* #### Data location and gravity awareness *(universal)* **Score:** 2 · **Gap ownership:** closeable · **DAPM:** Retained VCF Operations provides rich infrastructure telemetry — GPU utilization, model metrics, capacity trending — that reflects where workloads are running. vSAN provides storage topology visibility. What VCF does not provide is a unified, programmatically queryable data catalog that tells FC-2C where enterprise data physically lives — which cluster, which storage system, which geographic location — across all data types. A compliance query ('where is all HIPAA-tagged data and can it be accessed from cluster A?') cannot be answered by the VCF control plane without the enterprise assembling that picture from separate storage management tools. The FC-2C query interface for data location is unconfirmed and structurally absent because FC-2C itself does not exist. Roadmap note (not scored): Native vSAN S3 Object Storage is in tech preview in VCF 9.1.x, with GA expected in an upcoming 9.1 patch release. It brings S3-compatible object storage as a third storage type alongside block and file, with multi-tenancy and S3 buckets-as-a-service through VCF Automation. When GA, this closes part of the FC-1 substrate gap — S3 storage for AI workloads would no longer require a separate Dell/HPE/VAST system. Per methodology, tech preview capability is not scored; this is flagged as Vendor roadmap for the FC-1 substrate story. #### Governance and compliance metadata *(universal)* **Score:** 2 · **Gap ownership:** closeable · **DAPM:** Ceded VCF's governance capabilities are real but narrow. MCP Server Governance (9.1) provides agent-tool access governance enforced through vDefend — which user groups can call which MCP tools. Advanced Cyber Compliance (ACC) provides infrastructure compliance posture management. vSAN provides storage-level encryption and access control. What VCF does not provide is enterprise data governance — compliance tagging of relational databases, file classification by data sensitivity, HIPAA tagging of EHR data in VMs, GDPR residency enforcement at the data layer. Traditional data types require separate governance tooling (Collibra, Informatica, or equivalent). The enterprise must acquire, deploy, and integrate a data governance platform to fill this gap. Closeable but material — a new vendor relationship and a significant integration surface. #### Retrieval and context services *(ai-workload)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Ceded Private AI Services Vector Database and Data Indexing/Retrieval are included in the VCF subscription — no separate deployment required. VCF 9.1 adds Google Workspace document support alongside existing Microsoft Office, PDF, and CSV support. The retrieval service is platform-native and managed. The gap from 4: backend options are narrower than purpose-built alternatives (Weaviate, Pinecone, VAST InsightEngine), and retrieval depth for enterprise-specific document formats requires configuration of existing platform primitives. No new capability acquisition required — the enterprise configures what VCF already provides. Opinion gap. #### Data pipeline and lineage *(universal)* **Score:** 0 · **Gap ownership:** closeable · **DAPM:** Retained VCF provides no data pipeline or lineage capability for any data type. No ETL, no CDC from operational databases, no streaming pipeline management, no ML pipeline orchestration, no lineage tracking. The enterprise deploys Airflow, Kubeflow, dbt, Apache NiFi, or a commercial integration platform separately. This is the most consistent gap in VCF's FC-1 profile — it has appeared in every VCF assessment without change and reflects a deliberate scope boundary: VCF is an infrastructure control plane, not a data platform. Closeable but high-cost: a full data pipeline and lineage capability requires a platform acquisition (Databricks, Informatica, or equivalent) with significant lifecycle burden. *Notes: FC-1 is VCF's weakest layer for enterprises with AI workloads. F2 and F4 are both Closeable gaps requiring material capability acquisition. F1 is Closeable because the data location awareness that FC-2C would need does not exist in VCF and cannot be configured from existing primitives. The F3 score of 3 is the bright spot — Private AI Services retrieval is genuinely platform-native and adequately capable for most enterprise RAG use cases.* ### FC-2A — Infrastructure Orchestration *Unified orchestration of the full enterprise workload portfolio through one control plane — VMs, databases, batch, containers, and AI workloads with shared resource pools, shared quota enforcement, and unified visibility.* #### Workload universality *(universal)* **Score:** 3 · **Gap ownership:** structural · **DAPM:** Ceded vSphere Supervisor manages VMs, VKS manages Kubernetes containers, and Private AI Services manages AI inference — all from the same control plane with shared resource pools, shared RBAC, and unified vCenter/VCF Operations visibility. A database VM, a microservices container cluster, and a GPU inference workload on the same cluster are all visible and manageable from one console. This is VCF's foundational Fourth Cloud strength and is unmatched among on-prem control plane vendors. The gap from 4: GPU scheduling intelligence sits primarily with NVIDIA GPU Operator and vGPU Manager rather than vSphere-native policy for AI workloads specifically. For traditional workloads (VMs, containers, batch) the unified surface is complete and mature. Structural gap — the GPU scheduling dependency on NVIDIA is universal across all on-prem vendors. #### Resource lifecycle automation *(universal)* **Score:** 2 · **Gap ownership:** structural · **DAPM:** Ceded VCF automates workload lifecycle within the hardware the enterprise already owns. DRS provides automated load balancing across clusters. vSphere HA provides automatic VM recovery from hardware failures. VKS provides Kubernetes cluster scaling within provisioned node capacity. SDDC Manager provides automated patching and upgrades across VCF software components. What VCF cannot do is provision new physical nodes automatically in response to workload demand — scaling out requires procurement, delivery, and rack integration outside the control plane. This is structural: VCF is a software control plane that does not control the physical supply chain. An enterprise running VCF under HPE GreenLake or Dell APEX as-a-service consumption models would score F2=3 because those models pre-stage capacity that the control plane can activate. VCF on customer-owned hardware is F2=2. #### Policy and quota enforcement *(universal)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Ceded vSphere Namespaces provide resource quotas and RBAC across VM and container workloads from a single surface. NSX micro-segmentation enforces network policy across all workload types. MCP Server Governance enforces agent-tool access policy for AI workloads. Advanced Cyber Compliance provides continuous compliance enforcement with drift detection and remediation. The coverage across workload types is genuine and consistent. The gap from 4: policy does not propagate automatically across all enforcement layers — network policy in NSX, quota policy in vSphere Namespaces, and agent policy in MCP Server Governance are configured separately even though they share the same underlying governance surface. The enterprise configures enforcement per layer using existing VCF primitives. Opinion gap — no new capability required, but per-layer configuration is the operator's responsibility. #### Substrate lifecycle integration *(universal)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Ceded VCF provides strong workload-lifecycle integration with hardware events across all workload types. vSphere maintenance mode automatically drains all workload types — VMs, VKS containers, and AI workloads — from a node before planned maintenance windows with no operator coordination required per workload. vSphere HA detects hardware failures and automatically restarts workloads on healthy nodes across all workload types. DRS continuously rebalances workloads in response to hardware resource changes. vLCM with OEM HSMs integrates firmware update scheduling with workload lifecycle — firmware updates flow through the same SDDC Manager lifecycle plane as software updates, and maintenance mode drains workloads automatically before firmware is applied. The gap from 4: accelerator-specific hardware events (GPU failures, NVLink topology changes) are not fully integrated into VCF's workload scheduling decisions — GPU failure recovery depends on NVIDIA GPU Operator rather than vSphere HA natively. This is an Opinion gap for GPU-specific lifecycle integration — the enterprise configures NVIDIA GPU Operator integration with existing VCF primitives. #### Accelerator and GPU management *(ai-workload)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Ceded VCF 9.1 provides strong platform-integrated accelerator management. vGPU profiles and vmclasses deliver multi-tenant GPU isolation with memory strictly partitioned per tenant and zero side-channel risk across GPU framebuffer. Multi-Instance GPU (MIG) isolation is supported for fine-grained GPU partitioning. DRS policies incorporate GPU resource dimensions for automated workload balancing across accelerator capacity. DirectPath I/O for NVIDIA Blackwell HGX B200, NVLink Switch, and AMD MI350 provides high-performance dedicated GPU access. vSphere Namespaces expose GPU resource quotas through the same Kubernetes RBAC surface as CPU and memory quotas — the operator configures GPU capacity through familiar vSphere primitives. The gap from 4: deep GPU scheduling intelligence — which workload gets which GPU tier under dynamic cost, compliance, and performance policy conditions — sits with NVIDIA GPU Operator rather than vSphere-native scheduling logic. This matches the F3=3 anchor: 'strong accelerator management through platform-integrated GPU operator, scheduling intelligence partially held by accelerator vendor.' This is an Opinion gap — the enterprise configures NVIDIA GPU Operator integration through existing VCF Supervisor primitives. *Notes: FC-2A is VCF's strongest layer and the on-prem benchmark against which other control planes are calibrated. F1, F3, F4, and F5 all score 3. F2 remains 2 because VCF automates lifecycle inside fixed enterprise-owned capacity but does not control the physical supply chain.* ### FC-2B — Execution & Runtime *Execution environments for the full enterprise workload portfolio with consistent developer experience, persona abstraction, and observability.* #### Runtime universality *(universal)* **Score:** 3 · **Gap ownership:** structural · **DAPM:** Ceded VCF 9.0 introduced VM Service — a Kubernetes-native execution surface for VMs exposed as Custom Resource Definitions (CRDs) through the vSphere Supervisor. VMs and containers are exposed through the same Supervisor/Kubernetes control surface, with VMs represented as Kubernetes custom resources rather than as a separate vCenter-only workflow. A developer deploys a VirtualMachine resource using standard kubectl and Kubernetes YAML manifests, in the same namespace, with the same RBAC, and through the same toolchain as a container workload. VKS adds Kubernetes clusters as a third workload type through the same Supervisor API. Private AI Services Model Runtime adds AI inference as a fourth workload type through a platform-managed service. All four types are managed through the same vSphere Supervisor control plane with shared resource pools, shared quota enforcement through vSphere Namespaces, and unified visibility through VCF Operations. The gap from 4: AI inference workloads through Model Runtime use a different API surface than kubectl — developers call Model Runtime APIs rather than deploying Kubernetes resources. This is the 'some workload types expose substrate-specific interfaces' exception at F3=3, not a reason to score 2. The bimodal concern raised by two other models — that VMs and containers require different toolchains — is resolved by VM Service CRDs in VCF 9.x. That assessment was based on the pre-9.0 vSphere operational model. #### Persona abstraction at execution *(universal)* **Score:** 2 · **Gap ownership:** opinion · **DAPM:** Ceded The primitives for persona separation exist across all major workload types but their depth is uneven. Kubernetes and AI workloads expose strong developer abstraction — Tanzu's intent-based deployment and Model Runtime's API gateway shield developers from substrate details effectively. VM workloads still expose substrate-specific details at the developer layer: vCenter tooling, VMDK selection, network adapter type, datastore placement. Operator visibility is consistently strong across all workload types — vSphere provides full substrate detail with override controls. Security audit surfaces exist through vDefend, ACC, and MCP Server Governance. The gradient definition at F2=2 — 'developer abstraction strong for some types, substrate-exposed for others' — more accurately describes VCF's actual state than the F2=3 anchor. The gap is Opinion: extending consistent developer abstraction to VM workloads uses existing VCF Automation blueprint primitives and does not require new capability acquisition. Note: VCF 9.x improves administrator identity continuity through the VCF Identity Broker, supporting Entra ID, Okta, Active Directory, OpenLDAP, Ping Identity, and generic SAML — this strengthens the administrative persona experience but does not change the workload developer abstraction finding. #### Execution lifecycle and observability *(universal)* **Score:** 3 · **Gap ownership:** mixed · **DAPM:** Ceded VCF Operations provides native cross-workload correlation for VCF-managed workload types — VMs, containers, GPU workloads, and AI service metrics appear in the same VCF Operations dashboard with correlated visibility. VCF Operations for Networks extends this to network telemetry. Fleet management and integrated telemetry provide strong lifecycle primitives across the VMware estate. Live patching in 9.1 reduces maintenance disruption across all workload types. This is partial native correlation — the F3=3 anchor — not an absent correlation layer. The gap from 4: correlation breaks at the boundaries of VCF-managed workloads. Non-VMware services, application-layer telemetry, data governance events, and AI runtime events that originate outside VCF-managed components require cross-platform correlation the enterprise must assemble. For enterprises with existing observability platforms (Datadog, Dynatrace, Splunk): extending correlation to non-VCF telemetry is an Opinion gap — configure existing tools against VCF's OpenTelemetry-compatible telemetry streams. For enterprises without existing observability tooling: the non-VCF correlation gap is Closeable — a material new capability acquisition. #### AI inference and agent execution *(ai-workload)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Ceded Private AI Services Model Runtime is a platform-native managed inference service included in the VCF subscription. Multi-tenant isolation through vGPU profiles. API gateway for inference endpoint management. Agent Builder provides platform-native agent construction using Model Runtime models and Vector Database knowledge bases. MCP Server Governance provides agent-tool access control. The remaining gap is breadth and automation depth rather than absent capability: backend options are narrower than hyperscaler AI platforms, inference auto-scaling is less cloud-like, and NVIDIA AI Enterprise remains a load-bearing dependency. Enterprises configure and operate within the Private AI Services model rather than receiving hyperscaler-equivalent managed inference. No new capability acquisition is required to close the gap — the enterprise operates within existing platform primitives and accepts the narrower backend and automation ceiling. *Notes: FC-2B F3 is the most nuanced score in this assessment because the same gap has two different ownership classifications depending on what the enterprise already has. The assessment cannot resolve this for a generic buyer — the narrative explicitly flags it and the buyer applies their own situation.* ### FC-2C — The Reasoning Plane *Autonomous, policy-driven placement for ALL workload types — deriving compute location from live data gravity, compliance constraints, capacity, and cost simultaneously, without operator intervention.* #### Autonomous placement reasoning *(universal)* **Score:** 0 · **Gap ownership:** structural · **DAPM:** Retained Applying the integration vs. coexistence test: VCF 9.1 has no component that makes autonomous placement decisions by consuming live FC-1 metadata simultaneously with FC-2A state. VCF Operations has GPU and model telemetry. MCP Server Governance has agent access policy. vSAN has storage governance metadata. vDefend has security posture. vSphere Supervisor has workload scheduling authority. All of these exist inside the same control plane. None are wired to a placement engine that derives placement from first principles when a new constraint arrives. Applying the workload universality test: there is no unified reasoning plane for VMs, containers, AI inference, and databases. Applying the first-principles derivation test: when a new GDPR residency requirement arrives, an operator must manually update NSX network policy, vSphere DRS affinity rules, and vSAN storage policy independently. The system derives nothing. VCF Intelligent Assist (tech preview) is agentic IT operations automation — it diagnoses and resolves infrastructure issues. This is a sophisticated FC-2A capability, not FC-2C reasoning. Gap ownership is Structural: Broadcom has made no specific product announcement for FC-2C capability with a confirmed timeline. The methodology is explicit — a structural gap becomes a vendor roadmap gap only when a specific product with a confirmed timeline exists. Intention is not a roadmap. The architectural prerequisites are present inside VCF, which means when Broadcom does ship FC-2C the migration cost will be lower than any other on-prem vendor — but the absence of a product announcement requires the Structural classification today. *Notes: VCF's FC-2C structural advantage: the cross-OEM visibility that VCF has from the hypervisor up means a VCF FC-2C would be the first multi-vendor infrastructure reasoning plane. Dell's FC-2C must integrate with Dell storage APIs, NVIDIA Run:ai APIs, and OpenManage APIs from the outside. VCF's FC-2C would query VCF Operations, vSAN, and vSphere Supervisor internally. The engineering cost of closing this gap is lower for VCF than for any other on-prem vendor.* ### FC-3 — Application Distribution and Governance *The governed surface through which enterprise applications of all types are published, versioned, discovered, and consumed across the enterprise estate.* #### Application catalog and distribution *(universal)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Ceded VCF Automation provides a governed self-service catalog with pre-built AI workload templates, infrastructure blueprints, and Live Application Stack Blueprints for versioned, redeployable application topologies. Tanzu Marketplace provides a curated path to certified middleware, data services, and AI tooling. AI agents and containers are well-covered with platform-native governance. Traditional enterprise applications and middleware are partially covered — VCF Automation can deploy and govern them, but the catalog depth for enterprise middleware (databases, messaging systems, integration platforms) is narrower than OperatorHub on OpenShift. The gap from 4 is Opinion: the enterprise configures VCF Automation catalog entries for additional application types using existing blueprint primitives. No new capability acquisition required. #### Application lifecycle governance *(universal)* **Score:** 2 · **Gap ownership:** mixed · **DAPM:** Ceded VCF provides meaningful lifecycle governance for its primary application types. Kubernetes admission controllers enforce container policy. MCP Server Governance provides agent lifecycle controls including version access and tool authorization. Advanced Cyber Compliance provides infrastructure compliance posture tracking with drift detection. The gap: there is no unified audit trail across all application types. Container audit trails live in Kubernetes audit logs, VM lifecycle events in vCenter, agent governance in MCP Server Governance, and infrastructure compliance in ACC. For enterprises with existing SIEM deployments (Splunk, Microsoft Sentinel): correlating these streams is an Opinion gap — the enterprise configures existing tools against VCF's audit surfaces. For enterprises without SIEM: this is a Closeable gap requiring a material new capability acquisition. #### Developer experience and self-service *(universal)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Ceded Tanzu provides strong developer self-service for containerized and AI workloads — developers publish code and receive production-ready deployments with governance applied by the platform. VCF Automation provides self-service infrastructure deployments for VM and AI workload blueprints. Model Runtime provides an API-based inference interface that shields developers from GPU infrastructure details. The gap from 4: traditional enterprise application developers — those deploying ERP extensions, legacy Java applications, or database-backed services — still interact with more substrate-specific tooling than Kubernetes or AI developers do. Extending self-service uniformly to traditional application types uses existing VCF Automation primitives. Opinion gap — configuration activity, not capability acquisition. #### AI application and agent distribution *(ai-workload)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Ceded Private AI Services Agent Builder provides platform-native agent construction. MCP Server Governance provides governed distribution of MCP servers with agent tool authorization enforced through vDefend. Tanzu enables developer self-publication of agents and MCP servers to the enterprise via governed marketplace. Model Store provides curated LLM access with RBAC. The gap from 4: prompt injection controls and output audit trails at the platform level require enterprise configuration of existing vDefend and audit primitives rather than being platform-default behaviors. This is an Opinion gap — the primitives exist in vDefend's security enforcement and VCF's audit surfaces; the enterprise configures AI-specific policies using what already exists. Tanzu Platform Agent Foundations (confirmed GA, April 2026) strengthens this position: developers get governed access to models, MCP servers, and marketplace services pre-curated by IT, through a centralized AI gateway controlling tool/model availability, usage, cost, and safety filters. The Tanzu service publisher (Tanzu Platform 10.3) publishes any MCP server to the Cloud Foundry Marketplace as a discoverable, governed service — turning the marketplace into an AI capability distribution channel with Spring Cloud Gateway enforcement and network-policy isolation per published service. This supports the existing score: VCF provides platform-native AI application and agent distribution with governance. The gap from 4 remains the managed-service ceiling — the enterprise operates the Tanzu distribution surface rather than consuming it as a fully managed hyperscaler service. *Notes: FC-3 is a genuine VCF strength relative to hardware-focused vendors like Dell. The Tanzu + VCF Automation + MCP Server Governance combination provides a coherent governed application distribution surface. The comparison to IBM/Red Hat OpenShift is instructive: OpenShift scores higher on F1 (OperatorHub catalog breadth) and F3 (developer self-service maturity), but VCF scores higher on F4 (AI agent governance maturity). Different strengths for different buyer postures.* ### FC-4 — Integration Fabric *Event bus, API management, workflow orchestration, and system connectors connecting enterprise applications to each other and to systems of record — without point-to-point integrations.* #### Event fabric and messaging *(universal)* **Score:** 0 · **Gap ownership:** closeable · **DAPM:** Retained VCF provides no managed event fabric or messaging infrastructure. NSX provides network-level event visibility for security and connectivity purposes — this is not an application-level event bus. There is no schema enforcement, fan-out delivery, event filtering, replay capability, or protocol support (JMS, AMQP, MQTT, STOMP) at the platform level. An enterprise deploying VCF as a Fourth Cloud control plane must acquire and operate a separate messaging platform — Apache Kafka, Red Hat AMQ, AWS EventBridge, or equivalent. This is a Closeable gap but a material one: a full enterprise event fabric is a significant platform acquisition with its own lifecycle burden. Every application integration that requires event-driven connectivity is a point-to-point integration the enterprise builds and maintains independently. #### API management and gateway *(universal)* **Score:** 0 · **Gap ownership:** closeable · **DAPM:** Retained VCF does not ship a full API lifecycle management platform. Avi Load Balancer is a network-layer load balancer — it provides SSL termination, load balancing, and basic rate limiting. These are network-layer gateway functions, not API lifecycle management. Full API management — publication workflow, versioning governance, developer portal, transformation layer, API-level audit trails, and identity propagation from caller to backend — requires a separate platform acquisition. The distinction matters: Avi is a network appliance that can proxy API traffic; an API management platform governs the lifecycle of APIs as first-class assets. VCF provides the former; Fourth Cloud FC-4 F2 requires the latter. Closeable through acquiring an API management platform (Red Hat 3scale, Kong, Apigee, MuleSoft). Enterprises that already own an API management platform can integrate it behind Avi, reducing incremental acquisition cost, but VCF itself does not provide the capability. #### Workflow and process orchestration *(universal)* **Score:** 0 · **Gap ownership:** closeable · **DAPM:** Retained VCF provides no managed workflow orchestration for enterprise business processes. Tanzu provides GitOps-based deployment pipelines — this is infrastructure pipeline automation, not business process orchestration. There is no managed equivalent to Step Functions, Airflow DAGs for business workflows, or BPMN process engines at the platform level. An enterprise deploying VCF for Fourth Cloud must acquire and operate separate workflow orchestration tooling for both traditional business processes (SAP workflow, ServiceNow orchestration integration) and AI agent chains (separate from Tanzu's deployment pipelines). The two workflow concerns — traditional and AI — require separate tooling with no platform-native unification. Closeable but high-cost: each workflow type requires a separate acquisition. #### SaaS and enterprise system integration *(universal)* **Score:** 0 · **Gap ownership:** closeable · **DAPM:** Retained VCF provides no pre-built, maintained connectors to enterprise systems of record. There are no maintained SAP, Salesforce, ServiceNow, Oracle, Workday, or mainframe connectors in VCF. The MCP Server Governance capability in 9.1 provides MCP tool connections to Oracle, Microsoft SQL Server, ServiceNow, GitHub, Slack, and PostgreSQL — but these are AI agent tool connections governed through MCP protocol, not enterprise system integration connectors with lifecycle management, transformation, and lineage. Every system-of-record integration the enterprise needs is a point-to-point connection the enterprise builds and maintains independently using VCF's infrastructure as the deployment substrate. The Townsend Section 2.6 gap lifecycle cost applies to every system connection: initial build, ongoing maintenance as both sides evolve, and lifecycle coordination. For an enterprise with 10 system-of-record connections, this represents $10–20M in 5-year gap lifecycle cost if no integration platform is acquired. Closeable through acquiring an integration platform (Red Hat Camel K, MuleSoft, Boomi) — itself a material investment. #### AI-native integration *(ai-workload)* **Score:** 2 · **Gap ownership:** closeable · **DAPM:** Ceded VCF 9.1 MCP Server Governance (GA) provides RBAC access control over MCP tool connections — which user groups can access which MCP tools across Oracle, Microsoft SQL Server, ServiceNow, GitHub, Slack, and PostgreSQL without building custom connectors — with enforcement through vDefend and Avi Load Balancer. VCF 9.1 additionally ships a centralized Audit Trail in VCF Operations providing a time-sliced, standardized-format view of user activity across all components including VKS, allowing operators to trace the full event chain across the stack. Together these provide two of the three capabilities that define managed MCP access governance: RBAC access control and centralized call-level audit. This clears the same bar as the strongest on-prem peer at this function — access governance with audit is stronger than basic access control (F5=1) and below full managed connection infrastructure (F5=3). Score 2. The remaining gap from 3 is the managed AI integration fabric: no managed MCP tool discovery, no connection lifecycle management, no dynamic semantic routing, and no platform-native agent-to-agent identity propagation. A within-band distinction from the peer at this score: VCF governs access at the group-to-tool level rather than providing per-tool read/write capability filtering — a narrower capability difference, not a full gradient step. Gap ownership Closeable — acquiring a managed AI integration platform (Red Hat Application Foundations with Connectivity Link, or a dedicated MCP gateway) provides the missing managed connection infrastructure. Score corrected from v2.3 F5=1 following VCF 9.1 GA verification: the v2.3 score predated confirmation of the VCF Operations centralized Audit Trail, which is the capability that moves this from access-control-only (1) to access-control-plus-audit (2). This correction also resolves a cross-vendor calibration inconsistency — the comparable on-prem MCP governance peer scored 2 for the same capability class. *Notes: FC-4 is VCF's most significant structural gap portfolio. Three universal functions score 0 — event fabric, workflow orchestration, and system integration. This is not a deficiency in VCF's design as a virtualization platform; it is a consequence of VCF's scope boundary. VCF is an infrastructure control plane, not an integration platform. The buyer choosing VCF as a Fourth Cloud control plane is choosing to acquire and maintain a separate integration platform. That choice should be explicit and budgeted. The comparison to IBM/Red Hat OpenShift at FC-4 is the starkest in the instrument: OpenShift scores 4 on F1, F2, and F4 — AMQ, 3scale, and Camel K provide what VCF entirely lacks.* --- # Red Hat OpenShift — Fourth Cloud Assessment *Fourth Cloud Control Plane Assessment — Red Hat Vendor Boundary* **Version:** v2.4 **Date:** May 29, 2026 **Status:** complete **Evolution model:** continuous **Source:** Red Hat OpenShift self-managed subscription guide, Red Hat Application Services subscription guide, OpenShift 4.18/4.21 release notes, OpenShift AI 3.4 GA, Red Hat Summit 2026, IBM Think 2026, Fourth Cloud methodology v2.4, three-model comparative review (Gemini, ChatGPT), Red Hat vendor feedback (May 2026), Red Hat Application Services subscription guide (Sep 2025), Red Hat OpenShift GitOps packaging confirmation, Red Hat Connectivity Link MCP Gateway technical preview documentation ## Summary Finding Red Hat OpenShift's strongest Fourth Cloud characteristics are at FC-3 and FC-4, anchored by an included federated identity plane that spans orchestration through integration. OperatorHub's operator model — encoding Day 2 operational intelligence in the operator rather than requiring the enterprise to build operational knowledge — is a genuine platform capability included in the base subscription. The Keycloak identity federation plane spanning FC-2A through FC-4 is an included architectural advantage that eliminates the enterprise's need to build cross-layer identity bridges for primary orchestration, execution, application distribution, and integration functions. The Red Hat vendor boundary is the critical scoping decision in this assessment. Red Hat products requiring additional subscription purchases — OpenShift AI, Ansible Automation Platform, Red Hat Integration — are scored at their product family capability with explicit additional licensing flags. The rationale: all in-scope capabilities share a single Red Hat vendor relationship with no SI gate. IBM watsonx products are out of scope because they represent a separate IBM vendor relationship with a potential SI gate at the Red Hat/IBM boundary. These IBM products are equally deployable on other Kubernetes control planes and do not represent OpenShift-specific advantages. The additional licensing structure within the Red Hat product family is the primary gap characteristic of this assessment. OpenShift AI (additional Red Hat licensing) closes FC-1 F3, FC-2A F5, FC-2B F4, and FC-3 F4. Ansible Automation Platform (additional Red Hat licensing) closes FC-0 F1 and FC-2A F4. Red Hat Integration (additional Red Hat licensing) provides FC-4 event fabric, API management, workflow orchestration, and system connectors. Each of these is a Red Hat product with a Red Hat support relationship, but each represents an additional procurement decision. The buyer assembling the full Red Hat Fourth Cloud stack makes multiple licensing decisions against a single vendor relationship. FC-2C is absent. No Red Hat product addresses autonomous placement reasoning from live data governance metadata. Kubernetes scheduling through taints, tolerations, node affinity, and ACM placement policies is sophisticated rule dispatch — operators write placement rules, the platform executes them. The gap between rule dispatch and autonomous reasoning from first principles is the defining FC-2C characteristic, and no on-premises control plane assessed has closed it. FC-1 is the layer where OpenShift's profile as an application and workload platform is most apparent. Without the IBM watsonx portfolio, OpenShift has infrastructure telemetry and Kubernetes workload governance through ACS, but no enterprise data catalog, no cross-platform data governance, and limited data pipeline capability beyond what Red Hat Integration provides for streaming and ETL patterns. The enterprise buyer requiring a complete Fourth Cloud data fabric must plan for IBM watsonx products as a separate procurement layer. v2.4 corrections applied following Red Hat vendor review and primary source documentation checks. Eight changes: (1) Red Hat OpenShift GitOps (Argo CD) confirmed included in base OpenShift Container Platform subscription — FC-3 F2 corrected from 2 to 3; gap ownership updated to Opinion. (2) Red Hat Process Automation Manager confirmed transitioned to IBM for new purchases — FC-4 F3 corrected from 3 to 2; gap ownership updated to Closeable (IBM). (3) FC-4 F5 gap ownership corrected from Closeable to Vendor roadmap — MCP Gateway is technical preview in OpenShift AI 3.4 with confirmed active development. (4) FC-4 product names updated throughout — Red Hat Integration (renewals only) replaced with Red Hat Application Foundations (new subscriptions) where applicable. (5) Red Hat SSO renamed to Red Hat build of Keycloak throughout. (6) OpenShell characterization corrected — NVIDIA-founded open source project; Red Hat is a contributor. (7) Scoping note updated to reflect on-premises watsonx dependency on OpenShift substrate — not a score change; surfaces competitive gap closure advantage without crediting IBM capability to Red Hat scores. (8) FC-1 F1, FC-1 F2, FC-2C narratives updated to note on-premises watsonx closure paths are OpenShift-specific — not a score change; consistent with the instrument principle that third-party products requiring a specific control plane as substrate are noted for competitive context without being credited to the control plane score. ## Scoping note This assessment scores Red Hat OpenShift using the vendor support boundary as the scope line. Red Hat products — including those requiring additional Red Hat subscription purchases — are in scope. The rationale: when something breaks, the enterprise calls Red Hat for all in-scope capabilities. One vendor relationship, no SI gate, regardless of whether the capability requires a separate Red Hat subscription. IBM watsonx products (watsonx.data, watsonx.governance, Confluent, DataStage, Concert, watsonx Orchestrate, IBM Sovereign Core) are out of scope — separate IBM vendor relationship, separate IBM support relationship, and a separate procurement decision from the Red Hat/OpenShift subscription. The instrument scores the vendor boundary, not the ecosystem. Instrument consumers should be aware of one material fact confirmed during vendor review: on-premises watsonx deployment requires OpenShift specifically. Cloud Pak for Data requires an OpenShift substrate. An enterprise on Nutanix NKP, OpenStack, or any other Kubernetes control plane cannot deploy on-premises watsonx without first adopting OpenShift. This means OpenShift's FC-1 gap closure path — through on-premises watsonx.data for data location awareness and watsonx.governance for compliance metadata — is more capable and more accessible than the gap closure paths available to enterprises on other on-premises Kubernetes control planes. The gaps score the same; the closure options are not equivalent. Enterprises procuring the complete IBM stack — OpenShift as substrate plus IBM watsonx products — should evaluate this as an IBM assessment, not a Red Hat assessment. In that procurement model the FC-1 and FC-2C scores change materially because the full IBM product family from substrate to reasoning plane is in scope. The IBM/OpenShift full-stack assessment is a separate instrument entry. This note does not change any score in this assessment. It is consistent with the instrument's principle that the score reflects what the enterprise receives within the vendor's own subscription boundary. Third-party products that require a specific control plane as substrate are noted where they create a competitive closure advantage — without crediting the third-party capability to the control plane's score. Additional Red Hat licensing flags reflect the current Red Hat product portfolio as of May 2026. Red Hat Integration is available for subscription renewals only; new subscriptions use Red Hat Application Foundations, which includes streams for Apache Kafka, Red Hat build of Apache Camel, Red Hat 3scale API Management, Red Hat build of Debezium, and Red Hat build of Apicurio Registry. Red Hat Process Automation Manager has transitioned to IBM for new purchases (IBM Process Automation Manager Open Edition). Where additional Red Hat licensing is required, the function narrative flags it explicitly using current product names. ## Identity Plane Continuity **Score:** 3 **Classification:** federated **Gap ownership:** mixed **Layers in plane:** fc2a, fc2b, fc3, fc4 **Layers siloed:** fc0, fc1, fc2c Red Hat build of Keycloak is included in the base OpenShift subscription and provides a federated identity plane spanning the orchestration, execution, application distribution, and integration layers. Keycloak federates enterprise identity providers — LDAP, Active Directory, SAML 2.0, OIDC — into the OpenShift Kubernetes RBAC surface. FC-2A: enterprise identity determines namespace access, resource quota application, and operator permissions — natively in the Keycloak plane, included. FC-2B: namespace execution is Keycloak-governed; OpenShift Service Mesh propagates service identity through mTLS within the cluster; service account to Keycloak token exchange for application-layer identity requires configuration of included primitives — Opinion gap. FC-3: application distribution through OperatorHub and Developer Console self-service approval gates (OLM, OPA/Gatekeeper) are Keycloak-governed — included. The FC-3 identity plane membership rests on OLM and the Developer Console, not on GitOps — Red Hat OpenShift GitOps is a separately licensed product and is not credited for identity plane membership. FC-4: 3scale API Management (additional Red Hat licensing, Red Hat Integration) integrates with Keycloak through OAuth 2.0 and OIDC — API caller enterprise identity propagates through the gateway to backend services. 3scale has no community equivalent — this requires additional Red Hat licensing, but the identity propagation capability is genuine and Red Hat-supported. FC-0 is siloed: substrate node compliance tagging connects to workload placement through operator-configured node affinity rules, not through the Keycloak plane — Opinion gap using included primitives. FC-1 is siloed: data governance identity requires additional IBM licensing. FC-2C is siloed: agent identity governance requires additional IBM licensing. **Buyer implication:** Yes for orchestration, execution, application distribution, and integration layers within the Red Hat product family. An enterprise developer Keycloak-federated identity controls what they deploy in OpenShift (FC-2A), what executes in their namespace (FC-2B), what they can access from OperatorHub and the Developer Console (FC-3), and — with Red Hat Integration — what API calls carry their identity to backend services (FC-4). The identity plane spans these layers without the enterprise building point-to-point identity bridges. Substrate identity control — ensuring a compliance-tagged physical node automatically restricts application runtime execution — requires operator-configured node affinity rules using included OpenShift primitives, an Opinion gap requiring no new capability acquisition. Data governance identity and agent identity require additional IBM licensing. ## Layer-by-layer scoring | Layer | Avg score | Status | |---|---|---| | FC-0 — Physical & Virtual Substrate | 2.33 | Moderate | | FC-1 — Distributed Data & Context Fabric | 2.25 | Moderate | | FC-2A — Infrastructure Orchestration | 2.80 | Moderate | | FC-2B — Execution & Runtime | 3.00 | Strong | | FC-2C — The Reasoning Plane | 0.00 | Absent | | FC-3 — Application Distribution and Governance | 3.00 | Strong | | FC-4 — Integration Fabric | 2.60 | Moderate | **DAPM profile:** Retained 14 · Delegated 6 · Ceded 6 ### FC-0 — Physical & Virtual Substrate *The physical foundation the control plane lifecycles.* #### Hardware lifecycle management *(universal)* **Score:** 2 · **Gap ownership:** closeable · **DAPM:** Delegated Included: Machine Config Operator (MCO) manages node OS configuration and OS-level updates across the cluster as part of the control plane lifecycle — nodes are drained, OS updated, and rejoined automatically. Metal3 (included for bare metal deployments) extends node lifecycle management to bare metal infrastructure — provisioning, inspection, and decommissioning of bare metal nodes through the Kubernetes-native BareMetalHost CRD. This is meaningful for enterprises running OpenShift on bare metal without a virtualization layer. Kubernetes node health monitoring detects failures and triggers workload recovery. Additional Red Hat licensing required (Ansible): Red Hat Ansible Automation Platform provides OEM firmware lifecycle automation using vendor-specific Ansible collections for Dell, HPE, Lenovo — bringing firmware update scheduling into coordination with OpenShift maintenance mode. With Ansible: MCO + Metal3 + Ansible together constitute the F1=2 anchor — full hardware lifecycle for supported substrate, enterprise retains hardware vendor choice but not management burden. The physical supply chain constraint applies at FC-2A F2, not here — F1 measures lifecycle management of existing substrate, not provisioning of new substrate. Note: OEM-layer compositions such as IBM Fusion HCI and Dell DCAP provide tighter substrate lifecycle integration for their respective hardware platforms when deployed alongside OpenShift — these are additional vendor licensing decisions that do not affect the OpenShift control plane score. #### Substrate heterogeneity *(universal)* **Score:** 2 · **Gap ownership:** structural · **DAPM:** Retained Included: OpenShift runs on Dell, HPE, Lenovo, Cisco, Supermicro, AWS, Azure, GCP, OCI, and IBM Cloud through the same Kubernetes control plane — workload scheduling is unified across heterogeneous substrate at the Kubernetes layer. Node Feature Discovery discovers hardware capabilities and exposes them to the scheduler. NVIDIA GPU Operator (OperatorHub, available without additional licensing) provides basic GPU node management. Additional Red Hat licensing required (OpenShift AI): full multi-accelerator management across NVIDIA, AMD ROCm, Intel Gaudi, and IBM Spyre through unified Kubernetes primitives. Score 2 reflects: workload scheduling is unified across OEM hardware, but hardware management remains OEM-specific. OpenShift has no hypervisor providing a hardware-abstraction layer — Node Feature Discovery and device plugins expose OEM hardware capabilities to the Kubernetes scheduler without abstracting OEM management differences. Operators managing mixed OEM hardware nodes experience unified Kubernetes scheduling but OEM-specific hardware management tooling. The F2=2 anchor applies: single control plane manages multiple OEM hardware types through unified scheduling primitives, but OEM-specific tools surface to operators at the hardware management layer. Structural — architectural constraint of hypervisor-less control planes. #### Substrate portability *(universal)* **Score:** 3 · **Gap ownership:** structural · **DAPM:** Ceded Included: OpenShift runs on-prem (bare metal, virtualized), AWS (ROSA), Azure (ARO), GCP, OCI, IBM Cloud, and edge through the same control plane with the same operational model — Developer Console, Administrator Console, OperatorHub, OLM — consistent across all substrate types. OCI support is confirmed and relevant for enterprises with Oracle estates. Red Hat OpenShift Virtualization Service on IBM Cloud (GA June 2026) extends VM workload support to managed cloud substrate. ROSA on AWS provides genuine elastic node provisioning through cluster auto-scaler — the platform provisions new nodes in response to workload demand on cloud substrate. Gap from 4: each deployment is a separate cluster — a single OpenShift control plane does not span on-prem and cloud under one management boundary. Structural — multi-substrate single-plane management is not productized on any on-premises control plane. *Notes: FC-0 F1 and F2 both reflect the absence of a hypervisor abstraction layer. OpenShift manages node OS lifecycle through Machine Config Operator and bare metal node lifecycle through Metal3, but hardware-level OEM management remains vendor-specific. Ansible Automation Platform (additional Red Hat licensing) closes the firmware lifecycle gap. Substrate portability is OpenShift's defining architectural strength — the same control plane, operational model, and developer interface runs across on-prem, AWS (ROSA), Azure (ARO), GCP, OCI, and IBM Cloud. ROSA on AWS provides genuine cluster auto-scaler capability where Red Hat and AWS jointly provide elastic node provisioning — a managed offering advantage on cloud substrate.* ### FC-1 — Distributed Data & Context Fabric *The data fabric the reasoning plane queries — full enterprise data estate.* #### Data location and gravity awareness *(universal)* **Score:** 1 · **Gap ownership:** closeable · **DAPM:** Retained Included: OpenShift monitoring (Prometheus) provides programmatically queryable infrastructure telemetry — node utilization, pod resource consumption. OpenShift Data Foundation (Platform Plus) provides storage topology visibility — which nodes hold which persistent volumes, storage pool utilization. This is storage awareness, not data awareness. The distinction is material for FC-2C placement purposes: the control plane knows where a persistent volume is placed but not what data that volume contains or what regulatory classification applies to it. A placement query asking whether GDPR-regulated data is on a GDPR-compliant node cannot be answered by OpenShift's infrastructure telemetry. Score 1 reflects: programmatic storage topology awareness available, enterprise data catalog absent. Gap closure note: on-premises watsonx.data (IBM licensed, separate IBM vendor relationship) provides a unified data lakehouse with federated catalog spanning structured, unstructured, streaming, and transactional data sources — and on-premises deployment requires OpenShift specifically through Cloud Pak for Data. This gap closure path is an OpenShift competitive advantage versus other on-premises Kubernetes control planes, which cannot deploy on-premises watsonx.data without first adopting OpenShift. The closure path is IBM-licensed and IBM-supported; it does not change this score. #### Governance and compliance metadata *(universal)* **Score:** 2 · **Gap ownership:** closeable · **DAPM:** Retained Included (Platform Plus): Red Hat Advanced Cluster Security (ACS) provides continuous security compliance enforcement against CIS, NIST, PCI DSS, and HIPAA frameworks at the infrastructure and Kubernetes workload level — vulnerability scanning, runtime security policy, network segmentation compliance, image provenance tracking. OPA/Gatekeeper provides policy-as-code admission control across all workload types. These governance capabilities propagate to workload admission enforcement — ACS blocks non-compliant workloads at deploy time and detects violations at runtime. The gap from 3: ACS governs Kubernetes workloads and infrastructure comprehensively but does not govern enterprise data — relational database records, mainframe files, SaaS system data — at the compliance metadata layer. Score 2 reflects ACS's genuine included infrastructure governance — automated compliance enforcement for Kubernetes workloads across industry frameworks. Gap closure note: on-premises watsonx.governance (IBM licensed, separate IBM vendor relationship) provides AI governance and enterprise data compliance metadata spanning the full data estate — and on-premises deployment requires OpenShift specifically through Cloud Pak for Data. This gap closure path is an OpenShift competitive advantage versus other on-premises Kubernetes control planes. The closure path is IBM-licensed and IBM-supported; it does not change this score. #### Retrieval and context services *(ai-workload)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Delegated Additional Red Hat licensing required (OpenShift AI): pgvector on OpenShift Data Services Manager provides platform-assisted vector search with Red Hat support. NVIDIA NeMo Retriever integration provides GPU-accelerated retrieval pipelines. Red Hat product — one vendor relationship, no SI gate. Score at product family capability: F3=3 with OpenShift AI flag. Gap from 4: backend options are narrower than hyperscaler managed retrieval services; retrieval configuration requires enterprise setup of existing OpenShift AI primitives rather than fully managed intent declaration. Opinion gap — no new capability acquisition required beyond OpenShift AI subscription. #### Data pipeline and lineage *(universal)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Ceded Additional Red Hat licensing required — three Red Hat products compose this score: (1) Red Hat Application Foundations (streams for Apache Kafka): managed Kafka streaming pipeline with schema registry, consumer group management, and Red Hat support SLA — streaming data ingestion and event-driven data movement. (2) Red Hat build of Apache Camel (Red Hat Application Foundations): 300+ Red Hat-maintained connectors for ETL and data movement across SAP, Salesforce, Oracle, and major enterprise systems. (3) OpenShift AI Data Science Pipelines (Red Hat AI Enterprise): Kubeflow-based ML pipeline orchestration with experiment tracking and pipeline lineage for ML artifacts — knowing which pipeline step produced which model artifact. All three are Red Hat products — one vendor relationship, no SI gate. Gap from 4: enterprise data lineage across all data types — knowing which operational database record was used as training input — requires additional IBM licensing. Score 3 reflects the Red Hat pipeline stack: streaming (Kafka), ETL (Camel), and ML pipeline orchestration (OpenShift AI Data Science Pipelines) under one Red Hat support relationship. *Notes: FC-1 reflects OpenShift's profile as an application and workload platform rather than an enterprise data platform. ACS (Platform Plus) provides genuine infrastructure and workload governance that earns F2=2 — automated compliance enforcement against industry frameworks at the Kubernetes workload layer. The data governance gap at F2 is the enterprise data estate: databases, mainframe records, SaaS data. Red Hat Integration provides a genuine data pipeline capability through Kafka streaming and Camel K ETL that is a Red Hat product family strength. Enterprise data lineage beyond ML pipeline artifacts requires additional IBM licensing.* ### FC-2A — Infrastructure Orchestration *Unified orchestration of the full enterprise workload portfolio.* #### Workload universality *(universal)* **Score:** 3 · **Gap ownership:** structural · **DAPM:** Retained Included: OpenShift manages containers, VMs (OpenShift Virtualization — KubeVirt CRDs, VMs deployed through kubectl and Kubernetes YAML in the same namespace and RBAC as containers), databases (OpenShift Data Services Manager), and batch jobs (Kubernetes Jobs) through the same Kubernetes API surface. OpenShift Virtualization is included — VMs are Kubernetes-native, not a separate operational domain. All workload types share RBAC, namespace quotas, and network policy. Additional Red Hat licensing required (OpenShift AI): AI workload scheduling through Kueue, multi-accelerator model serving. Score at product family capability: F1=3 with OpenShift AI flag. Gap from 4: GPU scheduling intelligence for the most demanding AI workloads remains partially dependent on accelerator-specific operators. Structural — unified scheduling authority for all workload types at hyperscaler equivalent level is not productized on any on-premises platform. #### Resource lifecycle automation *(universal)* **Score:** 2 · **Gap ownership:** structural · **DAPM:** Retained Included: Kubernetes HPA and KEDA for workload auto-scaling based on resource metrics and custom metrics. Machine Config Operator manages node OS state. OpenShift cluster auto-scaler provisions new worker nodes on cloud substrate (ROSA, ARO, GCP, OCI) in response to workload demand — on cloud substrate this approaches the managed consumption model. On-premises: bounded by available physical nodes, cannot provision new hardware. The physical supply chain constraint applies universally to on-premises deployments regardless of control plane choice. Additional Red Hat licensing (Ansible): partially closes the on-prem gap through infrastructure provisioning workflow automation. Additional IBM licensing for demand-driven automated workload placement is out of scope and does not represent an OpenShift-specific advantage. Single score of 2 reflects the on-premises structural constraint — the platform is scored as a platform, not split by deployment model. Structural on-premises. #### Policy and quota enforcement *(universal)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Retained Included: ResourceQuotas, LimitRanges, NetworkPolicies, PodSecurityAdmission, OPA/Gatekeeper admission controllers — consistent policy enforcement across all workload types through the Kubernetes API. Red Hat Advanced Cluster Management (ACM, Platform Plus): multi-cluster policy enforcement — governance policies applied consistently across all OpenShift clusters in the fleet with centralized visibility and drift detection. ACM is a genuine included differentiator at scale: enterprises running OpenShift across multiple sites benefit from centralized fleet-level policy enforcement from a single control plane. Gap from 4: policy propagation across all enforcement layers requires per-layer configuration — admission controllers, ACM governance policies, and network policies are independently configured. Opinion gap — enterprise configures consistent enforcement using included primitives. #### Substrate lifecycle integration *(universal)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Delegated Included: Node drain and cordon for planned maintenance — workloads automatically evacuated across all workload types before maintenance. Machine Config Operator manages node OS state changes in coordination with workload drain — a node OS update triggers drain, update, and rejoin automatically. Kubernetes node health monitoring detects failures and triggers workload recovery via pod rescheduling and VM live migration (OpenShift Virtualization). Rolling cluster upgrades with workload continuity. Additional Red Hat licensing required (Ansible): OEM firmware lifecycle automation using vendor-specific Ansible collections — firmware update scheduling coordinated with OpenShift maintenance mode. With Ansible: MCO + Ansible + maintenance mode together approach the F4=3 anchor — planned maintenance triggers automatic workload migration, firmware management partially integrated. Score at product family capability: F4=3 with Ansible flag. Gap from 4: accelerator-specific hardware events (GPU failures) are not fully integrated into scheduling decisions across all accelerator types. Opinion gap — configure NVIDIA GPU Operator integration using existing OpenShift AI primitives. #### Accelerator and GPU management *(ai-workload)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Retained Additional Red Hat licensing required (OpenShift AI): Kueue provides native GPU queue management, fair-share scheduling, and multi-tenant quota enforcement across NVIDIA, AMD ROCm, Intel Gaudi, and IBM Spyre. Kueue makes NVIDIA Run:ai optional through Kubernetes-native GPU scheduling — the enterprise governs GPU allocation through Kubernetes primitives without requiring a commercial GPU scheduling layer. Score at product family capability: F5=3 with OpenShift AI flag. Gap from 4: deep GPU scheduling for large-scale distributed AI workloads across multiple nodes still benefits from NVIDIA GPU Operator integration. Opinion gap — Kueue provides the baseline; enterprises configure NVIDIA GPU Operator for advanced patterns using existing OpenShift AI primitives. Capability distinction: OpenShift uses Kubernetes-native queue management with software-enforced scheduling; hypervisor-based platforms use hardware-enforced GPU partitioning. Different isolation models address different enterprise requirements. *Notes: FC-2A is OpenShift's strongest orchestration layer. The unified Kubernetes control plane across containers, VMs (OpenShift Virtualization), databases, and AI workloads reflects OpenShift's design as a workload-universal platform. ACM multi-cluster fleet governance (Platform Plus) is a genuine included capability for enterprises running OpenShift at scale across multiple sites — fleet-level policy enforcement from a central control plane. The on-premises resource lifecycle automation constraint at F2=2 is structural: on-premises deployments are bounded by available physical nodes. On cloud substrate (ROSA, ARO), cluster auto-scaler provides elastic node provisioning that approaches the managed consumption model.* ### FC-2B — Execution & Runtime *The execution plane where workloads actually run.* #### Runtime universality *(universal)* **Score:** 3 · **Gap ownership:** structural · **DAPM:** Retained Included: OpenShift executes containers and VMs through the same Kubernetes API surface — KubeVirt CRDs for VMs (kubectl, same namespace and RBAC as containers), standard pod specs for containers, Kubernetes Jobs for batch, OpenShift Data Services Manager for databases. All workload types share the same scheduler, resource pools, and Developer Console. OpenShift Virtualization brings VMs into the Kubernetes-native execution surface — VMs and containers share the same developer toolchain, namespace model, and RBAC governance. Additional Red Hat licensing required (OpenShift AI): managed AI inference through Models-as-a-Service. Score at product family capability: F1=3 with OpenShift AI flag. Gap from 4: AI inference uses a different API surface (Models-as-a-Service API) than kubectl-based workloads — the developer interface for AI inference remains workload-type-specific. Structural — collapsing inference APIs and Kubernetes deployment APIs into a single surface is not productized on any on-premises platform. #### Persona abstraction at execution *(universal)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Retained Included: OpenShift Developer Console provides workload-type-agnostic self-service — containers, VMs, database operators, integration components through the same intent-based interface. For VMs: VM instance types (CPU/memory profiles) and image catalog abstract substrate details when pre-configured by operators. ACS (Platform Plus) provides security audit surfaces across all workload types at runtime. OpenShift Dev Spaces (included): governed developer workspaces where AI coding assistants — Claude CLI, GitHub Copilot, Continue, Cline, Roo — inherit the enterprise security posture. Developer AI tool usage is governed by the enterprise security posture without requiring developers to change their toolchain; the security persona gains visibility into AI tool usage across developer teams. Gap from 4: VM workloads expose more network and storage substrate to developers than container workloads when VM instance types are not pre-configured. Opinion gap — extending complete abstraction uses existing OpenShift Virtualization primitives. No new capability acquisition required. #### Execution lifecycle and observability *(universal)* **Score:** 3 · **Gap ownership:** mixed · **DAPM:** Delegated Included: OpenShift monitoring (Prometheus, Alertmanager, Thanos) provides cluster-level metrics across all workload types in standard formats. OpenShift Logging provides log aggregation. OpenShift distributed tracing (Jaeger/Tempo operator through OperatorHub) provides trace data. Three observability pillars — metrics, logs, traces — in standard formats (Prometheus, OpenTelemetry, OTLP). OpenShift Service Mesh (included) provides native correlation at the application request layer — distributed traces across container service-to-service calls are natively correlated. Partial native correlation: container-to-container request paths correlated natively through Service Mesh; VM-to-container and AI-to-container correlation requires enterprise assembly against OpenShift's standard telemetry streams. Gap from 4: cross-workload correlation spanning all workload types in a single surface requires either existing enterprise observability platform integration (Opinion gap) or additional observability platform acquisition (Closeable). Mixed gap ownership. #### AI inference and agent execution *(ai-workload)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Retained Additional Red Hat licensing required (OpenShift AI): Models-as-a-Service with token quotas, rate limiting, self-service API keys, showback dashboards, and multi-accelerator model serving across NVIDIA, AMD, Intel Gaudi, IBM Spyre. AI gateway via Connectivity Link (Envoy/Kuadrant/Istio) provides governed access to inference endpoints. OpenShell integration (Red Hat co-engineering with NVIDIA) provides sandboxed agent execution with infrastructure-level policy enforcement. Token quota enforcement and showback dashboards provide AI operational management depth — which teams consumed which model capacity — that is relevant for enterprise chargeback and capacity planning. Score at product family capability: F4=3 with OpenShift AI flag. Gap from 4: inference auto-scaling is Kubernetes-native (HPA/KEDA) rather than serverless — less elastic than hyperscaler managed inference. Model backend breadth is narrower than hyperscaler multi-provider model catalogs. Opinion gap — enterprises configure scaling using existing Kubernetes primitives. Additional IBM licensing required for cross-framework agent orchestration — not an OpenShift-specific capability. *Notes: FC-2B reflects OpenShift's design as an execution platform for all primary enterprise workload types. The unified Kubernetes API surface across containers and VMs (OpenShift Virtualization) is included and genuine. OpenShift Dev Spaces is a distinctive included capability: governed developer workspaces where AI coding assistants inherit the enterprise security posture. AI inference management at production depth — token quotas, showback dashboards, multi-accelerator serving — requires OpenShift AI (additional Red Hat licensing). Cross-workload observability correlation for non-OpenShift-managed systems requires either existing enterprise observability tooling or additional acquisition.* ### FC-2C — The Reasoning Plane *Autonomous, policy-driven placement deriving from live data governance metadata.* #### Autonomous placement reasoning *(universal)* **Score:** 0 · **Gap ownership:** structural · **DAPM:** Retained Included: Kubernetes scheduler with node affinity, pod affinity, taints and tolerations — pre-configured rule dispatch. HPA and KEDA — reactive scaling based on metrics thresholds. ACM placement policies (Platform Plus) — multi-cluster workload placement based on cluster labels and policy expressions authored by operators. OPA/Gatekeeper — admission-time policy enforcement against operator-defined rules. Applying the first-principles derivation test: when a new GDPR residency constraint arrives, an operator writes a new ACM placement rule expressing the GDPR requirement. ACM executes the rule; it does not derive the rule from the constraint. The constraint-to-rule translation is the operator's responsibility. This is sophisticated rule dispatch, not autonomous reasoning. No Red Hat product derives placement from live FC-1 governance metadata without operator rule authoring. Gap closure note: on-premises IBM Concert (the closest available approach to FC-2C) requires OpenShift specifically — making OpenShift the only on-premises Kubernetes control plane with an accessible path toward FC-2C through a cohesive IBM platform. IBM Concert provides demand-driven workload placement optimization (Infrastructure-2C) rather than compliance-metadata-derived placement from FC-1 signals (the full FC-2C definition). This closure path is IBM-licensed and IBM-supported; it does not change this score. Gap ownership Structural: no Red Hat product with a confirmed timeline addresses autonomous placement reasoning from data governance metadata. *Notes: FC-2C is absent in the Red Hat OpenShift subscription. The technical primitives that an eventual reasoning plane would require — ACM placement policies, OPA/Gatekeeper admission controls, Kubernetes node affinity, ACS compliance enforcement — are present in OpenShift. What is absent is the product that connects these primitives to live FC-1 data governance metadata and derives placement decisions from first principles without operator rule authoring. ACM placement policies are the closest signal: a cluster labeled HIPAA-compliant can receive designated workloads. But when a new GDPR residency constraint arrives, an operator writes a new placement rule — ACM executes it. The constraint-to-rule translation is the operator's job. No Red Hat product with a confirmed timeline addresses autonomous placement reasoning from data governance metadata.* ### FC-3 — Application Distribution and Governance *The governed surface through which enterprise applications are published, versioned, discovered, and consumed.* #### Application catalog and distribution *(universal)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Retained Included: OperatorHub provides a broad platform-native application catalog governed through OLM. Coverage spans databases (PostgreSQL, MySQL, MongoDB, Redis, CockroachDB), messaging middleware (Kafka, ActiveMQ, RabbitMQ operators), security tools (Vault, cert-manager, Falco), AI/ML frameworks (Kubeflow, Ray, MLflow, KServe, NVIDIA GPU Operator), monitoring (Prometheus Operator, Grafana, Jaeger), integration components (Camel K community operator, Debezium CDC), and traditional enterprise application support tooling. Red Hat Marketplace extends to certified third-party applications with formal Red Hat support SLAs. The operator model is a qualitative differentiator: an operator encodes application-specific Day 2 operational knowledge — the PostgreSQL operator knows how to provision replicas, handle failover, manage backups, and upgrade schema. Template-based catalog approaches provide deployment templates without this operational intelligence. Gap from 4: traditional enterprise applications running inside VMs (SAP ABAP, Oracle E-Business Suite, COBOL batch) are governed at the VM level through OLM — the VM is the catalog item, not the application inside it. The application payload inside the VM is governed by its own lifecycle management, not by OLM. Governance applies to the workload container, not the application payload. #### Application lifecycle governance *(universal)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Retained Included: Operator Lifecycle Manager (OLM) governs operator versioning, upgrade approval channels (stable, fast, candidate), dependency resolution, and channel-based deprecation across the OperatorHub catalog. ACS (Platform Plus) provides continuous compliance enforcement with drift detection. OpenShift audit logging provides per-resource audit trails across all workload types. Red Hat OpenShift GitOps (Argo CD) is included in the base OpenShift Container Platform subscription — declarative application lifecycle management with every application change tracked in Git, drift detected, and reconciliation logged as audit-trail-as-architecture. The Argo CD Agent component (multi-cluster fleet management) requires OpenShift Platform Plus. Score 3 reflects: OLM provides operator lifecycle governance; included Argo CD provides declarative GitOps lifecycle management with audit trails; ACS provides continuous compliance drift detection. Gap from 4: unified audit trail across all application types — containers, VMs, databases, AI models — in a single correlated surface requires SIEM integration. Opinion gap — enterprises with existing SIEM configure against OpenShift's standard audit telemetry using included primitives. #### Developer experience and self-service *(universal)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Retained Included: OpenShift Developer Console provides platform-native self-service across containers, VMs, database operators, integration components through the same intent-based interface. OLM and OPA/Gatekeeper enforce approval gates as platform policy — developers deploy from the approved catalog without manual operator approval for standard containerized and VM deployments. OpenShift Dev Spaces (included): governed developer workspaces where AI coding assistants — Claude CLI, GitHub Copilot, Continue, Cline, Roo — inherit the enterprise security posture. Developer AI tool usage is governed by the enterprise without requiring developers to change their toolchain. Gap from 4: unevenness across traditional enterprise applications and non-operatorized middleware — developers deploying traditional enterprise applications through OpenShift Virtualization experience more substrate-aware workflows than developers deploying containerized applications. Score 3 reflects strong developer self-service for cloud-native and Kubernetes-native workload types with genuine included differentiators. Opinion gap — extending consistent abstraction to all workload types uses existing OpenShift Virtualization primitives. #### AI application and agent distribution *(ai-workload)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Delegated Included: AI applications distributed through OperatorHub as standard operators — Kubeflow, Ray, KServe, NVIDIA GPU Operator with catalog governance. No AI-specific governance (model version tracking, agent tool authorization, prompt injection controls) in the base subscription. Additional Red Hat licensing required (Red Hat AI Enterprise — single subscription includes OpenShift + OpenShift AI): Models-as-a-Service governance for inference workloads — model version management, token quota enforcement, self-service API keys with rate limiting. OpenShell (NVIDIA-founded open source project for sandboxed agent execution; Red Hat is a contributor and integrating it with the Red Hat AI platform) provides infrastructure-level policy enforcement for agent workloads. Score at product family capability: F4=3 with Red Hat AI Enterprise flag. Gap from 4: cross-framework agent distribution governing agents from LangFlow, LangGraph, and A2A protocol requires additional IBM licensing — not an OpenShift-specific advantage. Prompt injection controls and output audit trails require configuration of existing ACS and OpenShift audit primitives. Opinion gap — existing Red Hat platform primitives address these without new capability acquisition. *Notes: FC-3 scores reflect three-model comparative review corrections from v2.1. F1 corrected from 4 to 3: governance applies to the operator or VM wrapper, not to the application payload inside it — traditional enterprise applications inside VMs are governed at the VM level by OLM, not at the application level. F2 corrected from 3 to 2: Red Hat OpenShift GitOps is a separately licensed product; community Argo CD through OperatorHub is the unsupported community path. F3 corrected from 4 to 3: unevenness across traditional enterprise applications and non-operatorized middleware prevents F3=4. OperatorHub's operator model — encoding Day 2 operational intelligence in the operator — remains a genuine qualitative differentiator from template-based catalog approaches within the F1=3 score band. Dev Spaces is an included differentiator at F3.* ### FC-4 — Integration Fabric *Event bus, API management, workflow orchestration, and system connectors.* #### Event fabric and messaging *(universal)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Ceded Additional Red Hat licensing required (Red Hat Application Foundations): streams for Apache Kafka provides managed event streaming with schema registry, consumer group management, and exactly-once delivery semantics — Red Hat support SLA. AMQ broker (included in Red Hat Runtimes, part of Application Foundations) provides JMS, AMQP, MQTT, STOMP, and OpenWire protocol support for enterprise messaging patterns. Both are Red Hat products — one vendor relationship, Red Hat support, no SI gate. Included: OpenShift Serverless (Knative Eventing) provides cluster-internal event routing — intra-cluster only, not enterprise event bus. Community Kafka operator through OperatorHub available without additional licensing — community support, no Red Hat SLA. Score at product family capability: F1=3 with Red Hat Application Foundations flag. Gap from 4: mainframe messaging depth at full protocol integration requires additional IBM tooling — not an OpenShift-specific capability. Note: Red Hat Application Foundations is designed and validated for OpenShift — operator installation, OLM lifecycle, and certificate management are OpenShift-native, providing lower integration friction than deploying the same products on other Kubernetes control planes. #### API management and gateway *(universal)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Ceded Included (Platform Plus): OpenShift API Management up to 100,000 API calls per day — developer tier only, insufficient for enterprise production scale. OpenShift Service Mesh provides service-level API governance within the cluster. Additional Red Hat licensing required (Red Hat Application Foundations): Red Hat 3scale API Management provides full API lifecycle — publication workflow, versioning governance, developer portal, access control, rate limiting at enterprise scale, transformation, and analytics for internal and external APIs. 3scale integrates with Red Hat build of Keycloak through OAuth 2.0 and OIDC — API caller enterprise identity propagates through the gateway to backend services, originating identity surviving API gateway traversal. Red Hat product — one vendor relationship, Red Hat support, no SI gate. Score at product family capability: F2=3 with Red Hat Application Foundations flag. Gap from 4: serverless scaling and transformation pipeline depth are narrower than hyperscaler API gateway services. Opinion gap — enterprises configure 3scale capabilities using existing Red Hat Application Foundations primitives. #### Workflow and process orchestration *(universal)* **Score:** 2 · **Gap ownership:** closeable · **DAPM:** Ceded Included: Community Camel K operator through OperatorHub — basic integration workflow patterns, community-maintained connectors, no Red Hat support SLA. OpenShift Pipelines (Tekton) — CI/CD pipeline automation, not business process orchestration. Additional Red Hat licensing required (Red Hat Application Foundations): Red Hat build of Apache Camel provides cloud-native integration workflow orchestration with 300+ Red Hat-maintained connectors, long-running process patterns, and Red Hat support SLA — covering event-driven integration workflows and ETL orchestration patterns. Score 2 reflects: Red Hat build of Apache Camel provides genuine cloud-native workflow orchestration within the Red Hat Application Foundations subscription. Gap from 3: BPMN-compliant business process orchestration — approval workflows with saga patterns, compensation logic, long-running human task management — is not available as a Red Hat product for new subscriptions. Red Hat Process Automation Manager has transitioned to IBM for new purchases (IBM Process Automation Manager Open Edition). This requires a separate IBM vendor relationship. Gap ownership Closeable through IBM Process Automation Manager Open Edition (separate IBM procurement) or third-party BPMN tooling deployed on OpenShift. Score corrected from v2.3 F3=3 following confirmation that Red Hat Process Automation Manager is no longer available for new Red Hat subscriptions. #### SaaS and enterprise system integration *(universal)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Ceded Additional Red Hat licensing required (Red Hat Application Foundations): Red Hat build of Apache Camel provides 300+ Red Hat-maintained connectors spanning SAP, Salesforce, ServiceNow, Oracle, Workday, IBM MQ (protocol-level), Slack, GitHub, Microsoft 365, and major SaaS platforms. Red Hat build of Debezium (included in Application Foundations) provides CDC capability — row-level database change capture for streaming enterprise data changes to downstream consumers. Red Hat maintains these connectors under support SLA — when an upstream API changes, Red Hat updates the connector. Included: community Apache Camel connectors available through OperatorHub without additional licensing — community-maintained, no Red Hat SLA for connector updates. Enterprise production system integration requires the Red Hat Application Foundations subscription for support guarantees. Red Hat product — one vendor relationship, no SI gate. Score at product family capability: F4=3 with Red Hat Application Foundations flag. Gap from 4: deep mainframe integration (CICS transactions, z/OS data sets, IMS databases beyond IBM MQ protocol support) requires additional IBM tooling — not an OpenShift-specific advantage. Opinion gap for primary enterprise connectors — Red Hat maintains them under the support SLA. #### AI-native integration *(ai-workload)* **Score:** 2 · **Gap ownership:** vendor-roadmap · **DAPM:** Delegated Included: OpenShift Service Mesh (Istio) provides service-to-service mTLS governing AI service calls within the cluster — basic intra-cluster AI service governance. Additional Red Hat licensing required (Red Hat AI Enterprise): Connectivity Link (Envoy/Kuadrant/Istio) provides managed AI gateway with rate limiting, token quota enforcement, and access control for inference endpoints — AI-specific API management built on the same Istio/Envoy foundation as OpenShift Service Mesh. Connectivity Link manages AI inference API access at the gateway level and is included in OpenShift AI 3.4 at no additional cost beyond Red Hat AI Enterprise. MCP Gateway (built on Kuadrant/Envoy, developed with OpenShift networking team): provides identity-based tool filtering so agents only see authorized tools, OAuth2 token exchange for scoped per-backend access, credential management for sensitive tool calls, and MLflow integration for end-to-end agent traceability. MCP catalog in OpenShift AI provides a governed, centralized space for validated MCP server discovery, deployment, and lifecycle management. Current GA status: Connectivity Link inference gateway is GA in OpenShift AI 3.4. MCP Gateway is technical preview in OpenShift AI 3.4; MCP catalog and MCP lifecycle operator are developer preview. Score 2 reflects GA Connectivity Link inference endpoint governance. Gap from 3: MCP Gateway — which would provide full tool-level filtering, agent identity propagation, and audit trails — is technical preview. Vendor roadmap: MCP Gateway capability is confirmed in active development with technical preview status; GA expected in a near-term OpenShift AI release. *Notes: FC-4 product names updated following Red Hat vendor feedback. Red Hat Integration is available for renewals only; new subscriptions use Red Hat Application Foundations (streams for Apache Kafka, Red Hat build of Apache Camel, Red Hat 3scale API Management, Red Hat build of Debezium, Red Hat build of Apicurio Registry). Red Hat Process Automation Manager has transitioned to IBM for new purchases — FC-4 F3 score corrected from 3 to 2 as a result. FC-4 F5 gap ownership corrected from Closeable to Vendor roadmap: Red Hat's MCP Gateway (Connectivity Link-based) provides identity-based tool filtering, OAuth2 token exchange, and credential management — currently in technical preview in OpenShift AI 3.4. This capability would move FC-4 F5 to 3 when GA.* --- # Nutanix Cloud Platform — Fourth Cloud Assessment *Fourth Cloud Control Plane Assessment — Nutanix Vendor Boundary* **Version:** v1.2 **Date:** May 29, 2026 **Status:** complete **Evolution model:** continuous **Source:** Nutanix .NEXT 2026 press releases, Nutanix Cloud Platform licensing documentation, Nutanix support policies, NCM Self-Service documentation, Nutanix Enterprise AI 2.6 release notes, Nutanix Data Lens 2.0 documentation, Foundation Central GA announcement, NCI HCL and hardware platform documentation, community forum hardware compatibility discussions, DCIG external storage analysis, Fourth Cloud methodology v2.4, three-model comparative review (Gemini v2.5, ChatGPT v1.0) — eight corrections applied, DAPM reconciliation review (May 2026) — corrected Delegated/Retained misclassifications at FC-0 F1, FC-1 F3, FC-2A F5, FC-2B F4, FC-3 F1-F4 ## Summary Finding Nutanix Cloud Platform is the most architecturally complete on-premises control plane in the instrument that is neither a pure IaaS substrate (Oxide) nor a developer-platform-first stack (OpenShift). Its defining strength is the unified management plane across VMs, Kubernetes, databases, AI inference, and cloud burst through a single Prism Central surface — the broadest workload management coverage of any HCI platform assessed. NC2 on AWS, Azure, and GCP with the same Prism Central management plane is Nutanix's strongest FC-0 differentiator: the only on-premises vendor providing genuine same-control-plane cloud portability through its base product. Three documentation-driven corrections and five three-model comparison corrections materially refined the assessment from v1.0. The HCL constraint remains the most consequential finding: Nutanix's hardware compatibility list is component-combination-specific — the enterprise cannot bring existing OEM servers. FC-0 F2 corrected to 2 (from 1 — too aggressive, and from two-model consensus of 3 — ignores HCL constraint). FC-0 F1 corrected to 3 (LCM manages firmware on certified nodes). FC-2A F2 corrected to 2 (NC2 cloud burst is a deployment option advantage, not the platform's on-premises position). FC-2A F5 corrected to 2 (GPU topology-aware placement is Vendor roadmap H2 2026). FC-1 F2 corrected to 2 (Data Lens file/object governance comparable to ACS precedent). FC-1 F3 corrected to 2 (NDB pgvector is managed database, not managed retrieval service). FC-3 F3 corrected to 3 (portal fragmentation is within-band gap, not F3=2). FC-4 F3 corrected to 1 (NCM runbooks = community Camel K IT automation precedent). FC-4 is entirely absent — identical to VCF. Nutanix has no event fabric, API management, workflow orchestration, or maintained connector library. NAI 2.6's MCP server governance scores FC-4 F5=2 — stronger than VCF's F5=1 because NAI provides API key injection, tool-level filtering, and full audit trails as managed gateway services. Every other FC-4 function scores 0. The enterprise choosing Nutanix must acquire and operate an integration platform separately, identical to VCF. FC-2C is absent — identical to VCF and OpenShift. NCM Intelligent Operations and AHV's upcoming GPU topology-aware placement (H2 2026 roadmap) provide infrastructure placement intelligence, but neither derives placement from FC-1 compliance metadata. The gap is Structural — no Nutanix product with confirmed timeline addresses compliance-metadata-driven placement across all workload types. The buyer profile for Nutanix is enterprises migrating from VMware who need a proven HCI platform with cloud burst capability, a broader workload coverage story than VCF (VMs plus Kubernetes plus managed databases plus AI inference through one Prism Central), and tolerance for the HCL constraint and the FC-4 assembly burden. Nutanix's NC2 cloud burst, NCM Intelligent Operations, and NAI 2.6 MCP governance are genuine differentiators within the on-premises HCI category. The HCL strictness and FC-4 absence are the honest trade. v1.2 DAPM corrections applied following reconciliation review. Seven DAPM misclassifications corrected: FC-0 F1 Delegated→Ceded (LCM is Nutanix-proprietary, not substitutable); FC-1 F3 Delegated→Ceded (NDB pgvector is the primary managed service path — Ceded; Milvus via NKP is the secondary open-source path — Delegated, noted in narrative); FC-2A F5 Retained→Delegated (NVIDIA GRID/vGPU is NVIDIA-proprietary firmware, not commodity or open-source — same classification as all assessed vendors); FC-2B F4 Retained→Ceded (NAI AI Gateway governance layer is Nutanix-proprietary; NVIDIA NIM inference engines beneath it are Delegated); FC-3 F1, F2, F3, F4 all Delegated→Ceded (NCM blueprints, NKP lifecycle governance, NAI model catalog and MCP governance are Nutanix-proprietary management opinions the enterprise cannot lift to a competing platform without rebuilding). No scores changed. The DAPM profile now correctly reflects the authority structure: Nutanix's management plane opinions are Ceded throughout FC-2A, FC-2B, and FC-3. The NC2 cloud substrate component at FC-0 F3 remains Retained (AWS/Azure/GCP bare metal is commodity cloud compute). Open-source components (Milvus via NKP at FC-1 F3, community Kubernetes operators at FC-3 F1) remain Delegated where noted in narratives. ## Scoping note This assessment scores the Nutanix Cloud Platform using the vendor support boundary as the scope line. All Nutanix-branded products are in scope — NCI, NCM, NKP, NAI, NUS, NDB, Data Lens, NC2, Flow — with additional Nutanix licensing flags where separate subscription purchases are required. One Nutanix vendor relationship, one support call, no SI gate across all in-scope products. Where additional Nutanix subscriptions are required beyond the base NCP, the function narrative flags this explicitly. Products not yet GA (NKP Metal, Agentic AI full solution, NetApp ONTAP integration, Dell PowerStore) are not scored and receive Vendor roadmap flags. Critical HCL note: Nutanix's hardware compatibility list is component-combination-specific. The enterprise cannot bring arbitrary OEM hardware from its existing estate. Hardware must be NX appliances or OEM-certified node configurations with specific component combinations purchased through Nutanix's channel. This is materially stricter than VCF or OpenShift hardware requirements and directly affects FC-0 F2 scoring. Support policy note: Nutanix's official support policy explicitly excludes configuration and usage support for non-Nutanix-branded hardware platforms — hardware-software boundary issues on OEM nodes require navigating two separate vendor support relationships. ## Identity Plane Continuity **Score:** 2 **Classification:** partial **Gap ownership:** mixed **Layers in plane:** fc2a, fc2b-vm, fc3, fc1-nus **Layers siloed:** fc0-substrate, fc2b-kubernetes, fc2c, fc4 Prism Central RBAC with LDAP/AD federation provides identity governance across FC-2A orchestration, FC-2B VM execution (through Flow categories and AHV security policies), FC-3 application distribution (NCM Self-Service approval gates), and FC-1 NUS data access (file/object permissions through AD integration) — all through Nutanix's native category and project model without separate identity bridge tools. A project identity in Nutanix simultaneously governs resource provisioning (FC-2A), VM execution and network security policy (FC-2B), self-service approval gates (FC-3), and file/object access on NUS (FC-1 NUS). This cross-layer identity consistency for VM workloads is genuine and included in NCP. FC-2B Kubernetes workloads are siloed: NKP uses Kubernetes RBAC and service accounts as a separate identity model from Prism project identity. Connecting Prism identity to Kubernetes workload identity requires operator-configured bridges — an Opinion gap within the Nutanix product family using existing NKP RBAC primitives. FC-0 substrate identity does not propagate to workload scheduling decisions through the identity plane; node categories can connect substrate classification to project policy but this is operator-configured. FC-2C is absent. FC-4 has no Nutanix integration fabric identity; NAI AI Gateway RBAC governs AI model access for AI workloads only. NAI's MCP server RBAC is in scope for AI-specific identity but does not constitute a general FC-4 integration identity plane. **Buyer implication:** Yes for VM infrastructure layers. An operator's Prism-federated enterprise identity controls what they can deploy (FC-2A), what VMs execute in their project with what network security policies (FC-2B), what marketplace items they can request (FC-3), and what NUS file/object data they can access (FC-1 NUS) — without building separate identity bridges. No for Kubernetes workload identity: NKP workloads require separately configured Kubernetes RBAC. No for integration fabric identity: no Nutanix integration fabric exists. No for data governance identity beyond NUS: external databases, mainframe data, and SaaS systems require additional tooling. ## Layer-by-layer scoring | Layer | Avg score | Status | |---|---|---| | FC-0 — Physical & Virtual Substrate | 2.67 | Moderate | | FC-1 — Distributed Data & Context Fabric | 1.75 | Gap | | FC-2A — Infrastructure Orchestration | 2.60 | Moderate | | FC-2B — Execution & Runtime | 3.00 | Strong | | FC-2C — The Reasoning Plane | 0.00 | Absent | | FC-3 — Application Distribution and Governance | 2.75 | Moderate | | FC-4 — Integration Fabric | 0.60 | Absent | **DAPM profile:** Retained 9 · Delegated 1 · Ceded 16 ### FC-0 — Physical & Virtual Substrate *The physical foundation the control plane lifecycles.* #### Hardware lifecycle management *(universal)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Ceded Included: Lifecycle Manager (LCM) provides coordinated lifecycle management across AOS, AHV, firmware, BIOS, BMC, and Nutanix services as one cluster-level operation on certified HCL nodes. Within certified configurations, LCM manages firmware updates through the Nutanix toolchain — operators do not need to use iDRAC or iLO separately for firmware lifecycle on HCL-certified nodes. AHV maintenance mode drains VMs automatically before node maintenance. AHV HA restarts VMs automatically on surviving nodes. LCM reads IPMI and OEM health metrics to inform update scheduling. Dell PowerFlex synchronous DR coordination extends lifecycle integration across external storage. Note: Foundation Central (GA .NEXT 2026) is a Day 0 deployment tool simplifying initial cluster imaging on certified OEM nodes — it does not change the ongoing lifecycle management story. Gap from 4: lifecycle management is bounded to certified HCL node configurations. Physical supply chain — provisioning new hardware — remains outside Nutanix control. Full maintenance transparency at the hyperscaler benchmark level requires the enterprise to operate within Nutanix-certified hardware configurations. Opinion gap — the enterprise configures maintenance windows using existing LCM primitives. Two-model consensus (Gemini, ChatGPT) confirms F1=3. Score corrected from v1.0 F1=2. DAMP correction (v1.2): Corrected from Delegated. LCM lifecycle opinions are Nutanix-proprietary — the enterprise cannot take LCM's coordinated firmware and software lifecycle management and operate it on a competing HCI platform without rebuilding. Not substitutable; Ceded. #### Substrate heterogeneity *(universal)* **Score:** 2 · **Gap ownership:** structural · **DAPM:** Ceded Nutanix manages multiple certified OEM hardware configurations through unified Prism Central primitives — Dell XC Plus, HPE, Cisco UCS, Lenovo, Fujitsu, and NX appliances are all managed through one management surface with consistent operational model. External storage integrations (Dell PowerFlex GA, Pure Storage FlashArray GA) add validated compute-storage combinations under Prism Central management. This is genuine heterogeneity management across certified configurations. Critical HCL constraint: Nutanix's Hardware Compatibility List is component-combination-specific. The enterprise cannot bring existing OEM servers from its estate — even if the server model matches an HCL entry, the specific NIC model, NVMe drive configuration, and firmware version must match the certified combination exactly. Hardware options are NX appliances or OEM-certified node configurations purchased through Nutanix's channel. The community forum is explicit: "a Nutanix node is HCL specific and you cannot just buy something and add the correct hardware." Nutanix's official support policy excludes configuration and usage support for non-Nutanix-branded hardware platforms. Score 2 reflects: genuine heterogeneity management across certified configurations through unified Prism primitives, with the HCL constraint preventing arbitrary OEM hardware from the enterprise estate. Structural — the HCL constraint is a deliberate design choice. Score corrected from v1.0 F2=1 (too aggressive) and from two-model consensus of F2=3 (ignores HCL constraint). F2=2 is the correct calibration. #### Substrate portability *(universal)* **Score:** 3 · **Gap ownership:** structural · **DAPM:** Ceded Included: NC2 (Nutanix Cloud Clusters) runs the full AOS/AHV stack on bare metal instances in AWS, Azure, and Google Cloud — the same Prism Central management plane, same AHV hypervisor, same NCM for lifecycle management, same NKP for Kubernetes. An enterprise runs Nutanix on-premises (NX appliances or certified OEM nodes) and extends to NC2 on cloud bare metal without changing management toolchain. GC2 (Government Cloud Clusters) extends this to AWS GovCloud and AWS European Sovereign Cloud for regulated industries. The operational model is genuinely consistent across on-premises and cloud deployments. Gap from 4: NC2 requires cloud provider bare metal instances — it runs Nutanix software on cloud bare metal, not on cloud virtual instances. This means NC2 does not provide fully elastic auto-scaling equivalent to cloud-native managed services. NC2 on Google Cloud added C3 bare metal and Hyperdisk storage support (.NEXT 2026), expanding the cloud substrate flexibility. Score 3 reflects genuine same-control-plane substrate portability across on-premises and three major hyperscalers — the strongest on-premises vendor substrate portability in this instrument. *Notes: FC-0 F1 corrected from 2 to 3 following three-model comparison: LCM manages firmware, BIOS, and BMC on certified HCL nodes through the Nutanix toolchain. FC-0 F2 corrected from 1 to 2: genuine heterogeneity management across certified configurations, but HCL component-combination specificity prevents arbitrary OEM hardware. F2=3 (two-model consensus) ignored the HCL constraint; F2=1 (our v1.0) was too aggressive. F2=2 is the correct calibration. FC-0 F3=3 through NC2 remains unchanged — the strongest substrate portability of any on-premises vendor in the instrument.* ### FC-1 — Distributed Data & Context Fabric *The data fabric the reasoning plane queries for placement decisions.* #### Data location and gravity awareness *(universal)* **Score:** 2 · **Gap ownership:** closeable · **DAPM:** Retained Additional Nutanix licensing required (NUS): Nutanix Unified Storage 5.3 provides S3-compatible object storage, file services (NFS, SMB), and block storage with programmatic location awareness through Prism Central APIs. Smart tiering knows data temperature — hot data on local NVMe, cold data tiered automatically to Google Cloud or OVHcloud S3. NUS 5.3 adds multitenant object scaling and quotas for AI data lakes. NDB (additional Nutanix licensing) provides location awareness for managed databases (Oracle, SQL Server, PostgreSQL, MySQL, MongoDB) provisioned within Nutanix. Prism Central knows where VMs, NUS volumes, and NDB databases are placed across the cluster. Gap from 3: data location awareness is bounded to the Nutanix storage estate. Enterprise data outside Nutanix — Oracle databases on legacy SAN, mainframe records, SaaS data — is invisible to Prism's data location awareness. No unified enterprise data catalog spanning all data types. Closeable through third-party data catalog tooling deployed on Nutanix VMs or NKP. Score 2 reflects programmatic data location awareness for the Nutanix storage estate — the strongest on-premises vendor at this function within their storage scope. #### Governance and compliance metadata *(universal)* **Score:** 2 · **Gap ownership:** closeable · **DAPM:** Retained Additional Nutanix licensing required (Data Lens 2.0, GA .NEXT 2026): Nutanix Data Lens provides ransomware detection, anomalous access monitoring, data audit trails, access governance, and permissions visualization for Nutanix Unified Storage files and objects — on-premises including air-gapped environments. Security Central (NCI Ultimate) provides infrastructure compliance posture management against CIS and NIST frameworks at the VM and infrastructure level. Data Lens is security-primary: who accessed which NUS files, anomalous behavior patterns, data age analytics, file distribution insights. It is not a compliance metadata engine that classifies enterprise data and propagates regulatory tags to placement enforcement decisions. Score 2 reflects: genuine file and object governance analytics through Data Lens within NUS scope, genuine infrastructure compliance through Security Central — both real Nutanix capabilities providing more than zero governance metadata. Comparable to OpenShift's ACS scoring F1=2 for infrastructure and Kubernetes workload compliance bounded to OpenShift scope. Gap from 3: governance metadata is bounded to NUS files/objects and Nutanix infrastructure; not spanning external databases, mainframe data, or SaaS systems; not propagating compliance metadata to placement enforcement. Closeable through third-party data governance tooling. Score corrected from v1.0 F2=1 following two-model consensus (Gemini, ChatGPT both score 2 with same reasoning as our corrected position). #### Retrieval and context services *(ai-workload)* **Score:** 2 · **Gap ownership:** closeable · **DAPM:** Ceded Additional Nutanix licensing required (NAI + NDB): Nutanix provides validated infrastructure patterns for retrieval workloads through GPT-in-a-Box blueprints — deployment automation for Milvus and pgvector on NKP with NUS storage. NDB provides managed PostgreSQL with pgvector extension — a managed database service that can store and query vectors with Nutanix support. NAI AI Gateway connects retrieval results to inference endpoints with RBAC and rate limiting. The distinction from F1=3: NDB pgvector is a managed database that stores vectors, not a purpose-built managed vector search service. GPT-in-a-Box is an infrastructure automation blueprint for deploying retrieval components, not a fully managed platform-native RAG API service — the enterprise deploys and operates the retrieval software on Nutanix infrastructure. Score 2 reflects: validated retrieval infrastructure patterns and managed database-backed vector storage, without a fully managed hyperscaler-equivalent RAG pipeline service. Gap from 3: the enterprise operates the retrieval software stack; Nutanix provides the infrastructure and database management layer beneath it. Closeable through additional tooling or NAI evolution. Score corrected from v1.0 F3=3 following two-model consensus (Gemini, ChatGPT both score 2). DAMP correction (v1.2): Corrected from Delegated. Primary scored capability is NDB pgvector — a Nutanix-managed database service whose operational opinions are Nutanix-proprietary and captive. Secondary path (Milvus via NKP) is genuinely Delegated (open-source with real alternatives) and noted in the narrative. The DAPM reflects the primary managed service path. #### Data pipeline and lineage *(universal)* **Score:** 1 · **Gap ownership:** closeable · **DAPM:** Retained Included: NUS smart tiering provides automated data movement between on-premises NVMe storage and cloud object storage (Google Cloud, OVHcloud S3) based on data temperature — storage lifecycle automation within the NUS estate. NKP catalog provides open-source MLOps engines (Kubeflow, MLflow) for deployment — community tooling without Nutanix management. Additional Nutanix licensing (NAI): MLOps workflow engines available through NKP AI catalog provide ML pipeline orchestration for AI workloads — open-source tools delivered through NKP, not Nutanix-proprietary managed services. No Nutanix product provides managed ETL, CDC, streaming pipeline management, or enterprise data lineage tracking. The NUS storage tiering is storage lifecycle automation, not enterprise data pipeline management. MLOps engines through NKP are open-source tooling the enterprise deploys and operates. Score 1 reflects: NUS automated storage tiering included, open-source ML pipeline tooling accessible through NKP catalog without Nutanix management, no managed enterprise data pipeline services. Closeable through third-party tooling — same path available on any platform. *Notes: FC-1 F2 corrected from 1 to 2: two-model consensus confirms Data Lens file/object governance is comparable to OpenShift ACS infrastructure governance precedent — genuine within NUS scope, not zero. FC-1 F3 corrected from 3 to 2: two-model consensus confirms NDB pgvector is a managed database with vector capability, not a purpose-built managed retrieval service; GPT-in-a-Box is infrastructure automation, not a managed RAG platform. FC-1 F1=2 and F4=1 unchanged.* ### FC-2A — Infrastructure Orchestration *Unified orchestration of the full enterprise workload portfolio.* #### Workload universality *(universal)* **Score:** 3 · **Gap ownership:** structural · **DAPM:** Ceded Additional Nutanix licensing required (NKP, NDB, NAI): Prism Central provides a unified management surface across VMs (AHV — included), Kubernetes workloads (NKP), managed databases (NDB), and AI inference workloads (NAI). Operators and developers interact with Prism Central for all workload types — one management surface covering the full enterprise workload portfolio. Multi-hypervisor support (AHV, ESXi, Hyper-V) through Prism Central is a genuine included differentiator: enterprises with mixed hypervisor estates manage both AHV and ESXi workloads through one management pane. The underlying control plane architecture is federated — AHV for VMs, NKP for Kubernetes, NDB for databases, NAI for AI inference — but the management experience is unified through Prism Central. Per the instrument's scoring rule: score at product family capability, note additional licensing. Gap from 4: GPU scheduling intelligence for demanding AI workloads benefits from NVIDIA GPU Operator integration. Structural — same constraint as all on-premises platforms. Score 3 reflects product family workload universality through Prism Central with additional Nutanix licensing flag. #### Resource lifecycle automation *(universal)* **Score:** 2 · **Gap ownership:** structural · **DAPM:** Ceded Included: AHV Acropolis Dynamic Scheduler (ADS) automatically rebalances VMs across nodes based on resource utilization within available cluster capacity. AHV HA automatically restarts VMs on surviving nodes when a host fails. NCM Intelligent Operations provides capacity forecasting, anomaly detection, and automated remediation recommendations. Strong lifecycle automation within fixed cluster capacity. NC2 provides a cloud burst path — when on-premises capacity is exhausted, the enterprise can extend to AWS, Azure, or GCP bare metal through the same Prism Central management plane without changing operational tooling. On cloud substrate, NC2 approaches F2=3 behavior through cloud infrastructure provisioning. Single score of 2 reflects the on-premises structural constraint — the platform is scored as a platform, not split by deployment model. Physical supply chain for new on-premises hardware remains outside Nutanix control. NC2 cloud burst capability is noted as a genuine operational differentiator: no other on-premises HCI vendor provides a managed cloud capacity expansion path through the same control plane. Structural — physical supply chain constraint applies universally to on-premises deployments. Score corrected from v1.0 F2=3 following two-model consensus (Gemini, ChatGPT both score 2). Same methodology rule applied to OpenShift: ROSA approaches F2=3 on cloud substrate but platform scores at on-premises position. #### Policy and quota enforcement *(universal)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Ceded Included in NCP (NCI Pro/Ultimate): Prism Central project-based resource quotas governing vCPUs, memory, and storage across all clusters simultaneously. Flow Network Security provides microsegmentation — VM category-based network security policies enforced at the hypervisor layer. Flow Virtual Networking provides VPC-equivalent network isolation with consistent policy enforcement. Security Central (NCI Ultimate) provides continuous security posture management and compliance benchmarking. Multi-hypervisor policy enforcement: Prism Central enforces the same project quotas, security policies, and compliance posture across AHV and ESXi clusters simultaneously — the only vendor in the instrument managing mixed hypervisor estates under unified policy. NCM Self-Service enforces approval gate workflows — developer provisioning requests governed by policy before resource consumption. Gap from 4: policy does not automatically propagate to application-layer enforcement within Kubernetes pods (NKP has its own policy primitives). Opinion gap — enterprise configures NKP NetworkPolicy and RBAC alongside Prism policies using existing Nutanix primitives. #### Substrate lifecycle integration *(universal)* **Score:** 3 · **Gap ownership:** structural · **DAPM:** Ceded Included: LCM coordinates software updates across AOS, AHV, NCC, and Nutanix services as one cluster-level coordinated operation. LCM reads IPMI and OEM health metrics to inform update scheduling — hardware health awareness integrated into software update decisions. AHV maintenance mode automatically drains VMs before node maintenance across all workload types — VM and Kubernetes workloads are evacuated before scheduled maintenance. Dell PowerFlex synchronous DR coordination (.NEXT 2026 GA) extends lifecycle integration across external storage — AHV maintenance mode and PowerFlex replication state are coordinated through LCM and Prism Central. AHV HA automatically recovers workloads from node failures. Gap from 4: hardware firmware lifecycle requires OEM tooling — LCM reads hardware health but does not push firmware updates. Full firmware-plus-software lifecycle coordination in one operation requires OEM management platform integration alongside LCM. Structural — same physical constraint as all software control planes without OEM HSM-equivalent native integration. #### Accelerator and GPU management *(ai-workload)* **Score:** 2 · **Gap ownership:** vendor-roadmap · **DAPM:** Delegated Included: AHV provides GPU passthrough (VMs access physical GPUs directly) and NVIDIA GRID vGPU (multi-tenant GPU sharing through hardware partitioning) — GA and mature. Hardware-enforced GPU partitioning through vGPU is a genuine Nutanix capability providing multi-tenant isolation. NKP provides NVIDIA GPU Operator integration for Kubernetes GPU workload management. Gap from 3: GPU scheduling intelligence above vGPU partitioning — topology-aware placement, automatic GPU right-sizing, demand-driven GPU allocation — relies on NVIDIA operators deployed in guest clusters rather than native Prism scheduling intelligence. AHV GPU topology-aware automatic placement optimization is part of the Nutanix Agentic AI solution (early access, GA H2 2026) — this specific capability will move the score toward 3 when GA. NAI 2.6 AI Gateway manages inference endpoints with RBAC and rate limiting across GPU-backed model servers. Score 2 reflects GA capabilities: hardware-enforced vGPU partitioning, NKP GPU Operator for Kubernetes workloads, NAI inference endpoint management — without native Prism-level topology-aware GPU scheduling. Vendor roadmap — H2 2026 AHV GPU topology-aware placement GA will close the gap to F5=3. Score corrected from v1.0 F5=3 following two-model consensus (Gemini, ChatGPT both score 2). DAMP correction (v1.2): Corrected from Retained. AHV vGPU relies on NVIDIA GRID/AI Enterprise — NVIDIA-proprietary firmware for hardware-enforced GPU partitioning. Not commodity substrate; not open-source with real alternatives at scale. Delegated — NVIDIA is the primary dependency, substitutable in principle with AMD GPU support (if certified) but NVIDIA is the de facto standard. Same classification as NVIDIA GPU dependencies across all assessed vendors. *Notes: FC-2A F2 corrected from 3 to 2 following two-model consensus: NC2 cloud burst approaches F2=3 on cloud substrate but the platform is scored at its on-premises position — same methodology rule as OpenShift ROSA. FC-2A F5 corrected from 3 to 2 following two-model consensus: GPU scheduling intelligence above vGPU is NVIDIA-provided; Nutanix GPU topology-aware placement is Vendor roadmap (H2 2026). FC-2A F1=3, F3=3, F4=3 unchanged — all five functions previously at 3 now split: F1=3, F2=2, F3=3, F4=3, F5=2.* ### FC-2B — Execution & Runtime *The execution plane where workloads actually run.* #### Runtime universality *(universal)* **Score:** 3 · **Gap ownership:** structural · **DAPM:** Ceded Additional Nutanix licensing required (NKP, NDB, NAI): AHV executes VM workloads natively — included. NKP executes Kubernetes container workloads. NDB executes managed databases (Oracle, SQL Server, PostgreSQL, MySQL, MongoDB). NAI executes AI inference workloads through Models-as-a-Service. All workload types execute within the Nutanix platform under Prism Central management. Multi-hypervisor execution: enterprises with existing ESXi workloads can execute both ESXi VMs and AHV VMs through Prism Central during migration, providing runtime continuity through the transition. Gap from 4: AI inference through NAI uses a different API surface (NAI Models-as-a-Service endpoint API) than VM and Kubernetes workloads through Prism Central — same structural exception as all on-premises platforms. Structural. #### Persona abstraction at execution *(universal)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Ceded Included: NCM Self-Service provides developer self-service for VM workloads through blueprint-based provisioning — developers request resources through the NCM portal without operator intervention, with approval gates enforced by NCM policy. Operators retain full Prism Central visibility into cluster health, hardware state, and resource utilization. Security Central provides security audit surfaces. Multi-hypervisor self-service: the same NCM Self-Service portal serves developers provisioning AHV VMs and ESXi VMs — developers do not experience a toolchain change during hypervisor migration. Additional Nutanix licensing (NKP): Kubernetes developer self-service through NKP interface. Additional Nutanix licensing (NAI): AI developer self-service through NAI portal. Gap from 4: developer self-service for Kubernetes (NKP), AI (NAI), and databases (NDB) uses separate portals from the NCM VM self-service — not a single unified interface across all workload types. Opinion gap — enterprise configures NKP, NAI, and NDB self-service alongside NCM using existing Nutanix primitives. Score 3 reflects product family persona abstraction with per-workload-type portal acknowledgment. #### Execution lifecycle and observability *(universal)* **Score:** 3 · **Gap ownership:** mixed · **DAPM:** Ceded Included: NCM Intelligent Operations provides cross-VM-infrastructure observability with native correlation — VM performance, storage I/O, network metrics, and cluster health correlated in one Prism Central view with anomaly detection and automated remediation recommendations. This is partial native correlation across the VM infrastructure layer, stronger than telemetry exposure alone. NCM Intelligent Operations includes capacity forecasting and automated remediation — the platform surfaces correlated insights rather than raw metrics. Nutanix has a certified partnership with Dynatrace (Global Innovation Partner of the Year at .NEXT 2026) — extends cross-workload correlation to application-layer observability for enterprises with Dynatrace. Gap from 4: native NCM correlation covers VM infrastructure comprehensively; application-layer correlation across containers (NKP), databases (NDB), and AI inference (NAI) requires Dynatrace integration (third party, Opinion for enterprises with Dynatrace) or configuration of additional Nutanix telemetry streams. Mixed gap ownership — Opinion for enterprises with existing observability platforms, Closeable for enterprises without. #### AI inference and agent execution *(ai-workload)* **Score:** 3 · **Gap ownership:** vendor-roadmap · **DAPM:** Ceded Additional Nutanix licensing required (NAI 2.6, GA March 2026): Models-as-a-Service providing endpoint APIs for NVIDIA NIM and Hugging Face models. AI Gateway with unified policy control over cloud-hosted and private LLMs — RBAC, token-based rate limiting, showback dashboards, full observability. MCP server support with tool-level filtering and API key injection at the gateway — agents connect to enterprise tools through managed MCP access governance with audit trails. Fine tuning (LoRA/PEFT) within the NAI platform. NVIDIA Nemotron model support. Air-gapped deployment supported. NAI AI Gateway's MCP governance is a genuine differentiator: API key injection at the gateway level (not per-server), tool-level filtering (read-only vs. write capabilities), and full audit trails distinguish NAI from basic MCP access control. Gap from 4: cross-framework agent orchestration — governing agents from LangFlow, LangGraph, and A2A protocol alongside NAI-native agents — is part of the Nutanix Agentic AI full solution (early access, GA H2 2026). Vendor roadmap — H2 2026 GA confirmed for cross-framework orchestration. Inference scaling is Kubernetes-native through NKP (HPA/KEDA) — Opinion gap. DAMP correction (v1.2): Corrected from Retained. NAI AI Gateway — the inference governance layer providing RBAC, token-based rate limiting, MCP server access management, and audit trails — is Nutanix-proprietary. The enterprise that has configured NAI AI Gateway policies governing which teams access which models and which agents call which MCP tools has accumulated Nutanix-captive governance opinions that cannot be lifted to a competing inference gateway without rebuilding. Ceded for the NAI governance layer. The underlying NVIDIA NIM inference engines are Delegated (NVIDIA-provided, separately licensed). *Notes: FC-2B scores 3, 3, 3, 3 — matching VCF and OpenShift. Within the score band: NCM Intelligent Operations with native anomaly detection and remediation recommendations is included and stronger than telemetry exposure alone (comparable to VCF Operations). NAI 2.6 MCP server governance with tool-level filtering is ahead of VCF's MCP Server Governance at FC-4 F5. Multi-hypervisor self-service continuity through ESXi-to-AHV migration is a genuine included differentiator for the VMware migration market.* ### FC-2C — The Reasoning Plane *Autonomous, policy-driven placement deriving from live data governance metadata.* #### Autonomous placement reasoning *(universal)* **Score:** 0 · **Gap ownership:** structural · **DAPM:** Retained Nutanix has the most developed FC-2C signal of any on-premises HCI vendor — and still does not pass the FC-2C litmus. NCM Intelligent Operations makes automated remediation recommendations based on infrastructure signals — resource utilization, anomaly patterns, capacity forecasting. AHV GPU topology-aware placement optimization (H2 2026 roadmap) will automatically optimize VM placement across GPU-dense servers based on topology — Infrastructure-2C for AI workload resource optimization. Neither consumes live FC-1 governance metadata to derive placement. Data Lens generates governance metadata for NUS files and objects; that metadata does not flow into AHV's scheduler or NCM's placement recommendations. When a new GDPR residency constraint arrives, an operator configures Prism project policies, Flow network policies, and VM placement affinities. NCM executes the configured policies — the constraint-to-rule translation is the operator's responsibility. Applying the first-principles derivation test: no Nutanix product derives placement from live FC-1 compliance metadata without operator rule authoring. Gap ownership Structural: no Nutanix product with confirmed timeline addresses the full FC-2C definition of compliance-metadata-derived placement across all workload types. The H2 2026 Agentic AI solution addresses Infrastructure-2C for AI workloads (GPU topology placement) but Structural for compliance-metadata placement derivation. *Notes: FC-2C is absent — identical finding to VCF and OpenShift. Nutanix's infrastructure intelligence layer (NCM Intelligent Operations, upcoming AHV GPU topology-aware placement) is the most developed of any on-premises HCI vendor. The gap from FC-2C is the same structural gap: compliance metadata from FC-1 does not drive placement decisions. When the Agentic AI solution GA's in H2 2026 and if Nutanix connects NCM's placement intelligence to Data Lens governance signals, this is the most plausible on-premises path to FC-2C in the instrument.* ### FC-3 — Application Distribution and Governance *The governed surface through which enterprise applications are published, versioned, discovered, and consumed.* #### Application catalog and distribution *(universal)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Ceded Included: NCM Self-Service (formerly Calm) provides a governed application catalog through blueprints — pre-configured application stacks that developers deploy through the Nutanix Marketplace without building infrastructure. Blueprints are operator-authored deployment templates encoding provisioning, configuration, scaling, and Day 2 scripts. Nutanix Marketplace contains ready-to-use blueprints for common workloads. The blueprint model is comparable to VCF Automation templates in deployment intelligence depth — strong Day 1 provisioning and configuration, Day 2 operations through scripted runbooks rather than continuously running operators. Additional Nutanix licensing (NKP): NKP provides Kubernetes application distribution through Helm charts and Kubernetes operators — operators from the Kubernetes ecosystem encode Day 2 operational intelligence equivalent to OperatorHub. Additional Nutanix licensing (NAI): NAI model catalog with RBAC-governed access. Additional Nutanix licensing (NDB): managed database provisioning. With the full product family: VMs (NCM blueprints), Kubernetes applications (NKP operators/Helm), databases (NDB), and AI models (NAI catalog) covered across workload types. Gap from 4: Day 2 operational intelligence depth varies by workload type — NKP operators provide continuous Day 2 intelligence for Kubernetes applications; NCM blueprints provide deployment-time automation with scripted Day 2 for VM applications. Opinion gap — enterprise authors Day 2 scripts in blueprints for VM workloads using existing NCM primitives. Score 3 reflects product family catalog coverage with consistent governance across workload types. DAMP correction (v1.2): Corrected from Delegated. NCM blueprints encoding deployment automation, and NAI model catalog governance policies, are Nutanix-proprietary management opinions. An enterprise that has built NCM blueprints for its infrastructure automation cannot lift those blueprints to a competing HCI platform without rebuilding. The NKP operator catalog (community Kubernetes operators) is genuinely Delegated — noted in narrative — but the primary catalog governance mechanism (NCM blueprints, NAI catalog) is Ceded. #### Application lifecycle governance *(universal)* **Score:** 2 · **Gap ownership:** mixed · **DAPM:** Ceded Included: NCM provides RBAC governance over blueprint access and approval gates for VM application provisioning. NCM audit logging records all self-service actions — who requested, who approved, what was deployed. LCM manages Nutanix platform component lifecycle. Security Central (NCI Ultimate) provides continuous compliance drift detection at infrastructure level. Additional Nutanix licensing (NKP): NKP provides Kubernetes-native lifecycle governance — Helm release management, Flux GitOps for declarative application state, namespace-level RBAC. NKP Flux GitOps is included in the NKP subscription without a separate subscription purchase. Additional Nutanix licensing (NDB): database lifecycle governance — automated patching, version management, backup governance. Additional Nutanix licensing (NAI): AI model lifecycle governance — model version management, token quota enforcement. Per-product lifecycle governance is genuine but operates in separate domains — NCM governs VMs, NKP governs Kubernetes apps, NDB governs databases, NAI governs AI models. No unified lifecycle governance surface correlating audit trails across all application types in one view. Gap from 3: unified audit trail across all application types in a single correlated surface requires SIEM integration. Mixed gap ownership — Opinion for enterprises with existing SIEM, Closeable for enterprises without. Score 2 reflects genuine per-product lifecycle governance without unified cross-product audit surface. DAMP correction (v1.2): Corrected from Delegated. NCM audit logging, NKP lifecycle governance opinions, and NAI model lifecycle management are Nutanix-proprietary. The enterprise cannot take its accumulated NCM blueprint governance history, NKP Flux GitOps configuration, or NAI model lifecycle policies and operate them on a competing platform without rebuilding. Ceded — Nutanix-captive lifecycle governance opinions across the product family. #### Developer experience and self-service *(universal)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Ceded Included: NCM Self-Service provides developer self-service for VM workloads — blueprint discovery through Nutanix Marketplace, parameter configuration within policy guardrails, deployment without operator intervention. Approval gates enforced by NCM policy — platform policy, not manual queue. Multi-hypervisor self-service: the same NCM portal serves AHV and ESXi VM provisioning during migration — developers do not experience a toolchain change. Additional Nutanix licensing (NKP): Kubernetes developer self-service through NKP interface. Additional Nutanix licensing (NAI): AI developer self-service through NAI portal. Additional Nutanix licensing (NDB): database self-service through NDB. Across the product family: strong developer self-service for VMs (NCM), Kubernetes (NKP), databases (NDB), and AI (NAI) — all workload types have platform-governed self-service with approval gates. Gap from 4: developer self-service for different workload types uses separate portals within the Nutanix product family — not a single unified interface across all workload types. This is a within-band qualitative gap, not a drop to F3=2. The F3=3 anchor requires strong self-service across primary workload types with approval gates enforced by platform policy — Nutanix meets this. Opinion gap — enterprise can configure consistent entry points using existing Nutanix primitives. Score corrected from v1.0 F3=2 following two-model consensus (Gemini, ChatGPT both score 3). Portal fragmentation is a within-F3=3-band gap, not a reason to score F3=2. DAMP correction (v1.2): Corrected from Delegated. NCM Self-Service portal configuration, approval gate workflows, and blueprint catalog publishing represent Nutanix-proprietary self-service opinions. Developer self-service for Kubernetes (NKP) and AI (NAI) similarly accumulates Nutanix-captive portal and policy configuration. The enterprise cannot lift these self-service opinions to a competing HCI platform without rebuilding the catalog, approval workflows, and portal configuration. Ceded. #### AI application and agent distribution *(ai-workload)* **Score:** 3 · **Gap ownership:** vendor-roadmap · **DAPM:** Ceded Additional Nutanix licensing required (NAI 2.6, GA March 2026): NAI provides AI application distribution through Models-as-a-Service catalog — model version management, RBAC-governed access, self-service endpoint provisioning, token quota enforcement. MCP server governance: API key injection at the gateway level (not per-server configuration), tool-level filtering controlling which capabilities agents can access (read-only vs. write), full audit trails for all MCP tool calls. This is platform-native AI governance — managed by Nutanix, not requiring enterprise-built governance infrastructure. NKP AI catalog provides open-source AI developer tools including notebooks, vector databases, MLOps engines, and agentic frameworks. Gap from 4: cross-framework agent distribution — governing agents from LangFlow, LangGraph, and A2A protocol alongside NAI-native agents — is part of the Nutanix Agentic AI full solution (early access, GA H2 2026). Vendor roadmap — H2 2026 GA confirmed. Score 3 reflects NAI 2.6 GA AI governance depth: model catalog, RBAC, MCP server governance with tool-level filtering and audit trails. DAMP correction (v1.2): Corrected from Delegated. NAI 2.6 model catalog governance — model versioning, RBAC policies, MCP server access governance, token quota configurations, and audit trails — is Nutanix-proprietary. An enterprise that has configured NAI MCP server governance policies governing which agents access which tools has accumulated Nutanix-captive AI governance opinions. Cannot be lifted to a competing AI inference platform without rebuilding. Ceded. *Notes: FC-3 F2 and F3 were corrected during documentation review. NCM Self-Service is an IaaS blueprint automation framework — strong Day 1 provisioning, scripted Day 2 — comparable to VCF Automation templates, not to OperatorHub operator-encoded Day 2 intelligence. Developer self-service is strong per workload type but fragmented across NCM (VMs), NKP (Kubernetes), and NAI (AI) portals. F3=2 (portal fragmentation) and F2=2 (per-product audit without unified surface) are the honest scores. F4=3 (NAI 2.6 MCP governance) and F1=3 (blueprint catalog with NKP operators for Kubernetes depth) are confirmed by primary documentation.* ### FC-4 — Integration Fabric *Event bus, API management, workflow orchestration, and system connectors.* #### Event fabric and messaging *(universal)* **Score:** 0 · **Gap ownership:** closeable · **DAPM:** Retained Nutanix has no event fabric product. NCM runbook automation can trigger actions in response to events through webhook integrations but this is event-driven IT automation, not a managed enterprise event bus with schema enforcement, fan-out, delivery guarantees, and replay. No Nutanix product provides managed enterprise messaging — no Kafka equivalent, no AMQ equivalent, no managed event streaming. The enterprise must acquire and deploy third-party tooling (Kafka, RabbitMQ) on Nutanix VMs or through NKP. Score 0 reflects: no platform-native managed event fabric. Closeable through third-party tooling. No Nutanix product closes this gap. #### API management and gateway *(universal)* **Score:** 0 · **Gap ownership:** closeable · **DAPM:** Retained NAI AI Gateway manages inference API endpoints — unified policy control over LLM endpoints with RBAC, rate limiting, and observability. This is AI-specific API management for inference endpoints, not enterprise API lifecycle management for application APIs. No publication workflow for business APIs, no developer portal for application API discovery, no versioning governance for enterprise service APIs, no transformation pipeline, no API-level audit for non-AI APIs. Flow Virtual Networking provides network-layer ingress — not API lifecycle management. Score 0 reflects: no enterprise API management platform. NAI AI Gateway is scoped to AI inference; it does not govern the enterprise's application or service APIs. Closeable through third-party tooling deployed on NKP. #### Workflow and process orchestration *(universal)* **Score:** 1 · **Gap ownership:** closeable · **DAPM:** Retained Included: NCM runbooks provide IT infrastructure automation — scripted workflows for provisioning, scaling, backup, remediation, and operational tasks across VMs, Kubernetes, databases, and storage. NCM runbooks can be triggered by events through webhook integrations, chained across systems, and published through NCM Self-Service as operator-initiated workflows. The NCM ServiceNow integration connects NCM runbook execution to ITSM service catalog items. Score 1 reflects: basic workflow automation for IT operations tasks through NCM runbooks — available without additional enterprise support, providing infrastructure automation patterns. Gap from 3: NCM runbooks are IT automation workflows, not BPMN-compliant business process orchestration. Long-running business processes, saga patterns, compensation logic, cross-system business workflows, and AI agent chain orchestration require separate tooling. The distinction matches the community Camel K precedent at OpenShift: basic automation patterns available without enterprise support, full enterprise business process orchestration requires separate acquisition. Closeable — BPMN-compliant workflow engines can be deployed on NKP. Score corrected from v1.0 F4=0 following two-model consensus (Gemini, ChatGPT both score 1). #### SaaS and enterprise system integration *(universal)* **Score:** 0 · **Gap ownership:** closeable · **DAPM:** Retained Nutanix has no maintained connector library to enterprise systems of record. NCM blueprints and runbooks can call external APIs through scripted tasks — an operator can write a runbook that calls a Salesforce API or SAP API. This is custom scripting, not maintained connector infrastructure. The NCM ServiceNow integration is one certified connector for one ITSM system, not a broad connector library for enterprise systems of record. Score 0 reflects: no platform-native maintained enterprise connector library. Custom API calls through runbook scripts do not constitute managed integration connectors. Closeable through third-party integration tooling deployed on NKP. #### AI-native integration *(ai-workload)* **Score:** 2 · **Gap ownership:** closeable · **DAPM:** Retained Additional Nutanix licensing required (NAI 2.6, GA March 2026): NAI AI Gateway provides MCP server access management with three genuine governance capabilities: (1) API key injection at the gateway interface rather than configuring it on every individual MCP server — centralized credential management for MCP connections; (2) tool-level filtering — controlling which specific tool capabilities (read-only vs. write access) agents can use; (3) enterprise observability — all MCP requests including latency and specific tools called are recorded with full audit trail for AI governance. This is access governance over MCP connections, not managed MCP connection infrastructure. The distinction: NAI governs which agents access which tools through what permissions; it does not discover MCP servers, maintain MCP server health, or route MCP connections dynamically. Score 2 reflects: AI-native integration available through platform governance framework applied to MCP patterns, with RBAC, tool-level filtering, and audit trails as genuine Nutanix-managed services. Stronger than basic access control (F5=1); below full managed connection infrastructure (F5=3). Gap: dynamic MCP connection routing, server discovery, and connection health management require enterprise-built infrastructure or additional tooling. Closeable. *Notes: FC-4 F3 corrected from 0 to 1 following two-model consensus: NCM runbooks constitute basic IT automation workflow patterns — same precedent as community Camel K scoring F4=1 at OpenShift. FC-4 F5=2 confirmed (our position between Gemini F5=0 and ChatGPT F5=3 — NAI AI Gateway provides MCP access governance not managed MCP connection infrastructure). FC-4 F1=0, F2=0, F4=0 unchanged.* --- # Oxide Computer — Fourth Cloud Assessment *Fourth Cloud Control Plane Assessment — Rack-Scale IaaS* **Version:** v1.2 **Date:** May 29, 2026 **Status:** complete **Evolution model:** continuous **Source:** Oxide Computer product documentation (docs.oxide.computer), Oxide specifications page, Oxide AI solutions page, Oxide compute product page, Oxide RFD-493 (Kubernetes integrations roadmap), The Register February 2026, $200M Series C announcement February 2026, Lawrence Livermore National Laboratory deployment November 2024, Fourth Cloud methodology v2.4, three-model comparative review (Gemini v2.4, ChatGPT v1.0) — corrections to FC-0 F1/F2/F3, FC-1 F2, FC-2A F3/F4, identity continuity, Oxide vendor feedback (May 2026), docs.oxide.computer/guides/integrations/cloud-controller-manager, docs.oxide.computer/guides/integrations/kubernetes, docs.oxide.computer/guides/architecture/networking, docs.oxide.computer/guides/configuring-access, docs.oxide.computer/guides/metrics/oxql-tutorial, docs.oxide.computer/guides/operator/system-update, docs.oxide.computer/api ## The IaaS Substrate, Not the Control Plane Oxide Computer is the most important finding in this instrument for what it reveals about the Fourth Cloud stack structure: Oxide is the IaaS layer on which a Fourth Cloud control plane runs, not a Fourth Cloud control plane itself. Every other vendor assessed — OpenShift, VCF, Dell DCAP — is a software control plane that runs on commodity OEM hardware. Oxide inverts this: it is purpose-built hardware with an integrated software control plane that provides VM provisioning, elastic block storage, VPC networking, and hardware lifecycle management as one product. The correct comparison for Oxide is AWS EC2, Azure Virtual Machines, or GCP Compute Engine — not OpenShift or VCF. This positioning has direct consequences for the buyer. Enterprises running serverless workloads — AWS Lambda, Azure Container Apps, Google Cloud Run — have no migration path to Oxide without architectural rewrite. Oxide has no function runtime, no event-driven execution model, and no scale-to-zero infrastructure. Serverless workloads cannot run on Oxide without being rewritten as long-running processes. This is not a gap in Oxide's roadmap; it is a gap in Oxide's architectural scope. Oxide is an IaaS platform. Serverless is a PaaS pattern. Oxide does not ship PaaS. Enterprises running containerized workloads face a different but equally material gap. Kubernetes is not a native Oxide platform service — the enterprise deploys and operates the Kubernetes control plane on Oxide-provisioned VMs. However, the operational burden is materially lower than self-managed Kubernetes on bare metal OEM servers. Oxide's control plane absorbs the infrastructure layer Kubernetes must otherwise manage itself: unified firmware and software updates, Service Processor health monitoring, automatic instance restart on sled failure, anti-affinity placement, and VPC networking. Oxide ships control-plane-integrated Kubernetes tooling — a Cloud Controller Manager providing LoadBalancer services via Oxide floating IPs, and Omni and Rancher provisioning integrations. The enterprise still owns the Kubernetes API server, etcd, scheduler, and cluster operations. It is not a managed Kubernetes service. But the substrate underneath it behaves more like a managed cloud than like bare metal, and the operational gap versus a hyperscaler managed Kubernetes service should not be overstated. Where Oxide genuinely leads the instrument is FC-0 — the substrate layer that every other vendor treats as someone else's problem. FC-0 F1 (hardware lifecycle management) scores 3 — the strongest F1 score of any on-premises vendor in the instrument, and the only F1=3 earned through co-design rather than through software integration with OEM-provided firmware tools. Oxide's hardware Root of Trust on every sled and switch, its co-designed Service Processor replacing the traditional BMC, and its unified firmware update mechanism through the control plane API constitute hardware lifecycle integration that no software-only control plane can match. VCF, OpenShift, and Nutanix all integrate with OEM-provided firmware management tools (vLCM+HSM, Ansible, LCM); Oxide builds and owns the firmware management layer as part of the same control plane that manages workloads. FC-2A F4 (substrate lifecycle integration) scores 3 for the same reason — Service Processor health monitoring triggers automatic workload restart and anti-affinity-aware placement through one control plane, not through a separate OEM tool integration. These are the two functions where Oxide's co-designed model produces a structurally different and stronger result than software-only control planes. Every other function reflects the consequence of that same design choice: Oxide does one layer exceptionally well, and the layers above it are the enterprise's responsibility. The buyer trade is explicit and significant. Oxide delivers hyperscaler-grade IaaS operational automation — fluid resource pools, automatic failure recovery, cryptographically verified firmware, rack-scale unified management — on premises, with data that never leaves the enterprise's physical control. The enterprise pays for this with substrate portability (F3=1 — one deployment model, one location, no cloud path), workload universality (F2A F1=1 — VMs only, no managed containers, no serverless, no managed databases), and the full operational burden of assembling the Fourth Cloud control plane above the IaaS layer. Oxide is the right answer for enterprises whose primary requirements are data sovereignty, verifiable infrastructure security, and predictable IaaS economics. It is the wrong answer for enterprises expecting a complete Fourth Cloud control plane from a single vendor. v1.2 corrections applied following Oxide vendor feedback and primary source documentation review. Six corrections: (1) FC-2A F4 corrected from 2 to 3 — the v1.1 downgrade conflated hardware failure event integration (Service Processor → auto-restart → anti-affinity, fully implemented) with planned maintenance transparency (live migration during updates, Vendor roadmap H2 2026). These are distinct capabilities; the hardware event integration meets the FC-2A F4 definition. (2) AWS-compatible API claim removed from FC-0 F3 narrative — Oxide has a native OpenAPI-described API with Terraform/OpenTofu provider; no AWS API compatibility exists. (3) Kubernetes operational burden narrative corrected in FC-2A F1 and FC-2B F1 — Oxide's control plane absorbs materially more than bare metal OEM servers (Service Processor health, unified firmware updates, auto-restart, anti-affinity, CCM, Omni/Rancher); the bare metal equivalence claim was factually wrong. (4) IAM hierarchy corrected throughout — fleet → silo → project (not project-only); silo is the hard tenancy boundary for quotas and isolation; four roles including limited_collaborator delegation primitive; SAML+JIT and SAML+SCIM IdP federation. (5) Observability narrative corrected in FC-2B F3 — native telemetry is Oximeter/OxQL, not a native Prometheus scrape endpoint; Prometheus available via OpenTelemetry collector bridge; Grafana supported via native OxQL plugin; observability platforms do not need to run on Oxide VMs. (6) FC-4 F2 networking description expanded — full VPC stack including BGP/OSPF/BFD via Maghemite; score unchanged at 0 (Oxide is not an API gateway). ## Scoping note This assessment scores Oxide Computer's rack-scale cloud computer as a Fourth Cloud control plane candidate. Oxide is architecturally distinct from every other vendor in this instrument: it is a vertically integrated hardware-software system where the rack is the unit of purchase. The software control plane is inseparable from the hardware it was co-designed with. The instrument scores what Oxide's control plane governs — which workload types are visible to it, what lifecycle automation it provides, what data services it ships, and what integration fabric it includes. The honest finding that emerges from this assessment is stated in the summary: Oxide is the IaaS substrate layer on which a Fourth Cloud control plane runs, not a Fourth Cloud control plane itself. The layer-by-layer scores reflect this positioning. They are not indictments of Oxide's engineering — which is exceptional — but accurate characterizations of what layer Oxide occupies in the Fourth Cloud stack. ## Identity Plane Continuity **Score:** 2 **Classification:** partial **Gap ownership:** structural **Layers in plane:** fc0, fc2a, fc2b **Layers siloed:** fc1, fc2c, fc3, fc4 Oxide's IAM model provides a three-tier hierarchy — fleet → silo → project — with a single policy surface covering all IaaS resource types: compute (VM instances), storage (block disks, images, snapshots), and networking (VPCs, firewall rules, IP pools). Silo-level isolation provides hard tenancy boundaries with per-silo console and API endpoints. Four roles — admin, collaborator, limited_collaborator, viewer — apply across all scopes with enterprise IdP federation through SAML+JIT and SAML+SCIM. The limited_collaborator role enables meaningful delegation: teams can self-serve compute and storage operations without touching network policy. This unified IAM spans FC-0 (hardware/substrate access is fleet-admin governed), FC-2A (resource quota enforcement and workload policy through the silo/project model), and FC-2B (VM instance management self-service through the project model). Identity plane is Partial (score 2) because the unified IAM surface stops at the VM boundary — Kubernetes workload identity, application-layer access controls, and database governance are outside the Oxide identity plane. No bridge is required to carry Oxide identity into application workloads; that is simply outside Oxide's design scope as an IaaS substrate. **Buyer implication:** Partially yes, within the VM infrastructure scope. A project identity in Oxide controls who can provision VMs, what storage those VMs can access, and what network topology they join — three-layer identity consistency from one source without enterprise-built bridges. What it does not provide: identity propagation into guest OS or application runtimes inside VMs, data governance identity across enterprise data stores, application distribution identity governance, or integration boundary identity enforcement. The partial plane covers Oxide-managed infrastructure; everything above the VM boundary is the enterprise's identity responsibility. ## Layer-by-layer scoring | Layer | Avg score | Status | |---|---|---| | FC-0 — Physical & Virtual Substrate | 1.33 | Gap | | FC-1 — Distributed Data & Context Fabric | 0.25 | Absent | | FC-2A — Infrastructure Orchestration | 1.60 | Gap | | FC-2B — Execution & Runtime | 1.25 | Gap | | FC-2C — The Reasoning Plane | 0.00 | Absent | | FC-3 — Application Distribution and Governance | 1.00 | Gap | | FC-4 — Integration Fabric | 0.00 | Absent | **DAPM profile:** Retained 22 · Delegated 0 · Ceded 4 ### FC-0 — Physical & Virtual Substrate *The physical foundation the control plane lifecycles.* #### Hardware lifecycle management *(universal)* **Score:** 3 · **Gap ownership:** structural · **DAPM:** Ceded Oxide achieves the strongest hardware lifecycle integration of any on-premises vendor in this assessment through hardware-software co-design. Every sled and switch includes a hardware Root of Trust (RoT) and an embedded Service Processor replacing the traditional BMC. Firmware updates for sleds, switches, and power shelves are delivered through the same Oxide control plane update mechanism that manages VMs and networking. The control plane provides operator visibility into software version, status, and health for every major rack component through the metrics API. Hardware lifecycle — firmware updates, component health, failure detection — shares one control plane surface with workload provisioning. Gap from 4: Oxide release notes recommend shutting down running instances before system software updates rather than automatically draining and migrating them. This means maintenance and workload continuity are not fully transparent to operators at the hyperscaler benchmark level — operators must coordinate workload shutdown before some platform updates. The hyperscaler benchmark (F1=4) requires firmware and lifecycle updates to be fully coordinated with workload scheduling without operator intervention. Oxide is strong and co-designed at F1=3; the maintenance transparency gap prevents F1=4. Score 3 with Structural gap ownership — full maintenance transparency would require further platform maturity, not a new product acquisition. Two-model consensus (Gemini, ChatGPT) confirms F1=3. #### Substrate heterogeneity *(universal)* **Score:** 1 · **Gap ownership:** structural · **DAPM:** Ceded Oxide intentionally rejects heterogeneous OEM hardware assembly. The platform manages Oxide-designed sleds, switches, storage, firmware, and control plane as one system. It cannot manage Dell, HPE, Lenovo, Supermicro, or third-party accelerator configurations through unified primitives. Within its homogeneous hardware model, Oxide manages its substrate with complete authority — but the instrument measures whether the control plane manages diverse enterprise hardware through unified primitives. Score 1 reflects: unified management of one hardware type. No OEM heterogeneity management. Structural — Oxide's homogeneous design is deliberate. Two-model consensus (Gemini, ChatGPT) confirms F2=1. #### Substrate portability *(universal)* **Score:** 0 · **Gap ownership:** structural · **DAPM:** Ceded Oxide is an on-premises rack product. One deployment model: the enterprise purchases a rack, installs it in their data center, and operates it there. There is no Oxide cloud offering, no Oxide edge variant, no NC2 equivalent. Score 0 reflects this deliberate design scope — Oxide is a private cloud platform, not a hybrid or multi-cloud platform. Application portability derives from standard guest OSes and standard IaC tooling. Oxide exposes a native, OpenAPI-described API with a first-party CLI, SDKs (Rust, Go, TypeScript), and a Terraform/OpenTofu provider. Enterprises use the same Terraform provider and standard VM images across environments — portability is IaC-level, not API-level cloud compatibility. Oxide has no AWS-compatible API surface. Structural — on-premises only is a deliberate product scope decision, not a roadmap gap. *Notes: FC-0 F1 corrected from 4 to 3 following three-model comparison: Oxide release notes recommend shutting down instances before system updates, confirming that maintenance transparency is not yet at the hyperscaler benchmark. FC-0 F2 corrected from 2 to 1: two-model consensus that managing one hardware type does not constitute heterogeneity management. FC-0 F3 corrected from 1 to 0: two-model consensus that AWS-compatible API is application-level, not substrate portability. Oxide's FC-0 profile: F1=3 (strong co-designed lifecycle, not yet fully transparent maintenance), F2=1 (homogeneous by design), F3=0 (on-premises only by design).* ### FC-1 — Distributed Data & Context Fabric *The data fabric the reasoning plane queries for placement decisions.* #### Data location and gravity awareness *(universal)* **Score:** 1 · **Gap ownership:** structural · **DAPM:** Retained Oxide's control plane knows where VMs are placed — which sled hosts which VM instance — and where block storage volumes are provisioned through the metrics API. This is infrastructure topology awareness: the control plane can answer 'which sled is this VM on' and 'which storage pool is this volume in.' It cannot answer 'what data does this volume contain' or 'what regulatory classification applies to this data.' A placement decision requiring data gravity awareness — is this GDPR-regulated data on a GDPR-compliant substrate — cannot be answered by Oxide's control plane. No data catalog. No federated metadata layer across enterprise data types. No programmatic interface for data classification or residency enforcement. The enterprise deploys data catalog tooling on VMs inside the Oxide rack independently of the Oxide control plane. Score 1 reflects infrastructure topology awareness without enterprise data awareness. Structural — Oxide is a compute infrastructure platform. Providing enterprise data catalog capability would require Oxide to become a data platform, which is outside its architectural scope. #### Governance and compliance metadata *(universal)* **Score:** 0 · **Gap ownership:** structural · **DAPM:** Retained Oxide provides a three-tier resource hierarchy: fleet → silo → project. Resource quotas, hard tenancy isolation, and per-silo console and API endpoints are scoped at the silo level — the silo is the hard tenant boundary. The project is the finer-grained resource container within a silo. VPC network isolation enforces network-level tenant separation. These are IaaS-layer tenant isolation primitives — resource limits, network boundaries, and hard multi-tenancy. They are not compliance metadata in the FC-1 F2 sense: Oxide's isolation model does not classify data payloads, tag workloads with regulatory attributes, or propagate compliance metadata to placement decisions. Score 0 reflects: strong IaaS-layer tenant isolation through the silo/project hierarchy; no data-payload compliance metadata or regulatory classification capability. Structural — Oxide is an IaaS substrate; compliance classification is an application-layer responsibility. #### Retrieval and context services *(ai-workload)* **Score:** 0 · **Gap ownership:** structural · **DAPM:** Retained Oxide provides no platform-native managed vector search, embedding management, retrieval pipelines, or RAG services. The 2nd Gen Turin sleds support AVX-512 for CPU-based vector compute — Oxide explicitly positions this for embedding generation, vector operations, and retrieval pipelines including FAISS indexing. The enterprise can deploy Weaviate, Qdrant, Chroma, or FAISS on Oxide VMs and benefit from AVX-512 SIMD acceleration for vector similarity search. This is substrate capability for retrieval workloads, not platform-managed retrieval services. The distinction: Oxide provides the CPU on which the enterprise runs retrieval software; the platform does not manage embeddings, retrieval pipelines, or RAG context as platform services. Score 0 reflects: no platform-native retrieval services. AVX-512 CPU compute is substrate capability. Structural — providing managed retrieval services would require Oxide to ship a data services layer above the IaaS boundary. #### Data pipeline and lineage *(universal)* **Score:** 0 · **Gap ownership:** structural · **DAPM:** Retained Oxide provides no ETL service, no CDC capability, no streaming pipeline infrastructure, no ML pipeline orchestration, and no lineage tracking. The enterprise deploys Kafka, Airflow, Spark, dbt, or equivalent on Oxide VMs — Oxide's AI solutions page explicitly lists these as tooling that runs on Oxide. But running pipeline software on Oxide VMs is the same as running it on any IaaS platform. Oxide provides the compute substrate; the enterprise owns the pipeline operational model. Score 0 reflects: no data pipeline or lineage capability within the Oxide platform. Structural — Oxide is infrastructure, not a data platform. *Notes: FC-1 is entirely outside Oxide's architectural scope. FC-1 F2 corrected from 1 to 0 following Gemini comparison and confirmed by three-model analysis: project quotas and VPC isolation are tenant isolation mechanisms, not compliance metadata in the FC-1 sense. FC-1 F1 stays at 1: infrastructure topology awareness (where volumes are placed) without data gravity awareness (what data they contain). ChatGPT's FC-1 F1=2 makes the same error corrected at OpenShift — storage location awareness is not data awareness.* ### FC-2A — Infrastructure Orchestration *Unified orchestration of the full enterprise workload portfolio.* #### Workload universality *(universal)* **Score:** 1 · **Gap ownership:** structural · **DAPM:** Retained Oxide's control plane provisions and manages VM instances natively. Containers and Kubernetes workloads run inside VMs — Kubernetes is not a native Oxide platform service. However, the operational burden of running Kubernetes on Oxide is materially lower than on bare metal OEM servers. Oxide's control plane absorbs the infrastructure layer that Kubernetes must otherwise manage itself: unified firmware and software updates, Service Processor health monitoring, rack-wide fluid resource pool, automatic instance restart on sled failure, anti-affinity placement, and VPC networking. Oxide ships and maintains control-plane-integrated Kubernetes tooling: a Cloud Controller Manager providing LoadBalancer services via Oxide floating IPs and node lifecycle integration; Omni and Rancher provisioning with native integrations. The enterprise still owns and operates the Kubernetes control plane itself — the API server, etcd, scheduler, and all cluster operations. Score 1 reflects: VM workloads are the one workload type the Oxide platform natively orchestrates. Kubernetes operational burden is materially reduced by Oxide's control plane absorption of the hardware infrastructure layer, but Kubernetes remains an enterprise-operated service on Oxide infrastructure, not an Oxide-managed platform service. Structural — Oxide's design scope is IaaS substrate. #### Resource lifecycle automation *(universal)* **Score:** 2 · **Gap ownership:** structural · **DAPM:** Retained Oxide's elastic resource pool draws vCPUs and memory from a fluid rack-wide pool rather than pre-allocating resources to fixed physical sled boundaries. A VM request draws from whatever capacity is available across all sleds in the rack through the custom backplane. Auto-restart policies automatically recover VMs from sled failures by restarting them on available capacity elsewhere in the rack. Anti-affinity groups spread instances across sleds automatically — a sled failure does not take down all instances of a service. This is more demand-driven than traditional hypervisor VM management where operators pre-configure resource pools and balance workloads across hosts manually. Within available rack capacity, resource allocation is automatic and failure recovery is platform-managed. The physical supply chain constraint applies: Oxide cannot provision new sleds in response to workload demand. When the rack's pool is exhausted, no new physical capacity appears. New capacity requires purchasing additional rack hardware. Score 2 reflects the on-premises structural constraint. Oxide's fluid pool architecture is a genuine operational differentiator within the F2=2 band — it eliminates per-host resource pre-staging that operators manage on traditional hypervisor platforms. Structural — physical supply chain constraint applies universally to on-premises platforms. #### Policy and quota enforcement *(universal)* **Score:** 2 · **Gap ownership:** structural · **DAPM:** Retained Oxide provides unified IAM governance through a three-tier hierarchy: fleet → silo → project. Resource quotas and hard tenancy isolation are silo-scoped — the silo provides per-tenant console and API endpoints, hard resource limits, and complete network isolation. The project is the finer-grained resource container within a silo. Four roles apply across all scopes: admin, collaborator, limited_collaborator, and viewer. The limited_collaborator role is a genuine delegation primitive — it allows delegation of instance, disk, snapshot, and image management while retaining network control, enabling teams to self-serve compute without touching network policy. Roles attach to users or IdP groups through SAML+JIT or SAML+SCIM federation. This IAM model applies uniformly across compute (VM instances), storage (block disks, images, snapshots), and networking (VPCs, firewall rules, IP pools) — one policy surface covering all IaaS resource types. Score 2 reflects: genuine unified policy enforcement across all IaaS resource types through the silo/project hierarchy with enterprise IdP federation; limited_collaborator provides meaningful delegation without over-privileging. Gap from 3: policy does not span application-layer workloads running inside VMs — Kubernetes RBAC, database access controls, and application-layer governance are outside the Oxide policy surface. Structural. #### Substrate lifecycle integration *(universal)* **Score:** 3 · **Gap ownership:** structural · **DAPM:** Ceded Oxide integrates hardware lifecycle events into workload management through the Service Processor architecture. Every sled includes a Service Processor that continuously monitors hardware health — power, thermal, component failure — and reports to the control plane. Hardware event integration with workload scheduling: when a sled's Service Processor reports a failure, affected instances transition to failed-state and the control plane automatically restarts them on healthy sleds. Anti-affinity placement ensures restart targets respect workload distribution policies. Unified firmware and software updates execute through one control plane operation — the same system that manages workload placement manages firmware lifecycle. This is the FC-2A F4 function definition met: hardware lifecycle events integrated with workload scheduling through one control plane. Maintenance transparency (live migration during planned maintenance): today, planned system updates require instance shutdown before the update proceeds. Live migration during planned updates — allowing zero-downtime maintenance — is on the Oxide roadmap for H2 2026. This is the gap from 4, not from 3. Score 3 reflects genuine hardware-event-to-workload-scheduling integration through the Service Processor architecture. The live migration gap is a maintenance transparency gap, not a hardware lifecycle integration gap — these are distinct capabilities and should not be conflated. Structural gap from 4: live migration during planned maintenance is Vendor roadmap (H2 2026). Note: v1.1 scored this function at 2 based on release note evidence that instances must be shut down before system updates. That evidence addresses planned maintenance transparency, not hardware failure event integration. The v1.2 correction separates these two distinct capabilities and scores hardware event integration independently. The shutdown-before-update evidence correctly describes the live migration gap but does not negate the Service Processor → auto-restart → anti-affinity integration that meets the FC-2A F4 definition. #### Accelerator and GPU management *(ai-workload)* **Score:** 0 · **Gap ownership:** structural · **DAPM:** Retained Oxide has no GPU sled and no discrete accelerator management capability. The 2nd Gen Turin sleds include AMD EPYC 9005 with AVX-512 — CPU-based vector compute that Oxide explicitly positions for AI inference, RAG, similarity search, and classical machine learning. This is a deliberate architectural position: Oxide's AI compute answer is high-core-count CPU with AVX-512 rather than discrete GPU accelerators. The enterprise can run CPU-based inference (LoRA/PEFT fine-tuned models, XGBoost, FAISS, Weaviate) on Turin VMs and benefit from AVX-512 SIMD acceleration. This is not GPU acceleration and it is not accelerator management. There is no GPU quota management, no MIG partitioning, no multi-tenant GPU isolation, and no GPU scheduling policy — because there are no GPUs to manage. Score 0 reflects: no accelerator management capability in the current product. Structural — Oxide's current architecture is CPU-only AI compute. A GPU sled has not been announced. The $200M Series C may fund GPU hardware development but no timeline or product has been confirmed. If a GPU sled is announced, this gap ownership would move to Vendor roadmap. *Notes: FC-2A F3 corrected from 1 to 2: two-model consensus confirms unified IAM covering compute, storage, and networking is three-dimensional policy enforcement stronger than basic tenant isolation. FC-2A F4 corrected from 3 to 2: ChatGPT release note evidence that instances must be shut down before system updates confirms planned maintenance is not yet fully automatic. FC-2A profile: F1=1 (VM-only), F2=2 (fluid pool, structural supply chain constraint), F3=2 (unified three-dimensional IAM), F4=2 (co-designed lifecycle, operator-mediated maintenance), F5=0 (no GPU sled).* ### FC-2B — Execution & Runtime *The execution plane where workloads actually run.* #### Runtime universality *(universal)* **Score:** 1 · **Gap ownership:** structural · **DAPM:** Retained Oxide executes VM instances natively. Containers execute inside VMs under Kubernetes or another container runtime the enterprise deploys and operates. The Oxide control plane manages VM lifecycle — provisioning, start, stop, restart, snapshot — not container or pod lifecycle. Oxide provides control-plane-integrated Kubernetes tooling (Cloud Controller Manager, Omni/Rancher provisioning) that materially reduces the operational burden of running Kubernetes on Oxide versus bare metal. However, the Kubernetes control plane itself — API server, etcd, scheduler, cluster operations — remains enterprise-operated. Score 1 reflects: VM runtime is natively managed by Oxide. Container and Kubernetes runtime is enterprise-operated on Oxide infrastructure with meaningful platform support. Structural — Oxide's design scope is IaaS substrate. #### Persona abstraction at execution *(universal)* **Score:** 2 · **Gap ownership:** structural · **DAPM:** Retained Oxide provides a self-service developer experience through the control plane API, CLI, and web console — developers provision VM instances, configure networking, attach storage, and manage SSH keys without filing infrastructure tickets. The web console provides operator visibility into sled health, VM placement, and resource utilization. Per-project quotas enforce resource limits for developer self-service without operator intervention. The experience is cloud-like for VM provisioning: comparable to AWS EC2 self-service in pattern and API surface. The gap from 3: persona abstraction at execution exists only for the VM provisioning layer. Developers provisioning containerized applications must stand up their own Kubernetes cluster first — the container persona has no self-service abstraction at the Oxide platform level. Data engineering personas, AI inference personas, and database administrator personas have no Oxide-native self-service abstractions. Score 2 reflects: strong developer persona abstraction for VM provisioning, absent for all workload types above the VM boundary. Structural — extending persona abstraction to container, serverless, database, and AI workload types requires platform layers Oxide does not ship. #### Execution lifecycle and observability *(universal)* **Score:** 2 · **Gap ownership:** structural · **DAPM:** Retained Oxide provides native platform telemetry through Oximeter — the built-in metrics system queried via OxQL (Oximeter Query Language) through the system timeseries API. Oximeter captures VM-level metrics (CPU utilization, memory consumption, disk I/O, network throughput) and rack-level hardware telemetry (sled health, power consumption, thermal state, Service Processor events) — all queryable through the OxQL API without deploying additional tooling inside the rack. Prometheus integration is available through the Oxide OpenTelemetry collector, which re-exports Oximeter metrics in Prometheus exposition format. Grafana is supported directly via a native OxQL data-source plugin — no Prometheus intermediary required. Observability platforms consuming Oxide metrics do not need to run on Oxide VMs; the OxQL API is accessible externally. Gap from 3: what runs inside VMs — application-level traces, container metrics, Kubernetes control plane telemetry, database query performance — is outside Oxide's observability layer. Cross-workload correlation across the application stack requires the enterprise to deploy and operate their own APM tooling (Datadog, Dynatrace, or self-managed Prometheus/Grafana stacks). Score 2 reflects: native platform telemetry through Oximeter/OxQL covering VM and hardware layers, with Prometheus and Grafana integrations. Application-layer observability above the VM boundary remains enterprise responsibility. Structural. Note: v1.1 incorrectly stated Oxide exposes a native Prometheus scrape endpoint and that observability platforms must run on Oxide VMs. Both claims were factually wrong. Oxide's native telemetry system is Oximeter with OxQL; Prometheus is reached through the OpenTelemetry collector bridge. #### AI inference and agent execution *(ai-workload)* **Score:** 0 · **Gap ownership:** structural · **DAPM:** Retained Oxide provides no platform-managed AI inference service. The enterprise deploys vLLM, Ollama, TorchServe, or equivalent on Oxide VMs and runs CPU-based inference using AVX-512 SIMD acceleration on Turin sleds. Oxide explicitly positions the Turin sled for fine-tuned model inference using LoRA and PEFT, expert agents, customer service bots, and recommendation engines — all CPU-based. This is valid inference capability for models that fit within CPU memory constraints. It is not a managed inference service: no token quota management, no rate limiting, no self-service inference endpoints, no showback dashboards, no multi-model serving infrastructure. The enterprise operates the inference stack as software on VMs. Score 0 reflects: no platform-managed AI inference. CPU-based inference on Turin VMs is enterprise-operated software, not a platform service. Structural — providing managed AI inference would require Oxide to ship a services layer above the IaaS boundary. *Notes: FC-2B reflects the same IaaS positioning as FC-2A. Oxide executes VM instances and provides strong VM-level lifecycle management and observability. Everything above the VM boundary — containers, AI inference, databases, batch jobs — executes inside VMs as the enterprise's operational responsibility. The F2=2 score at persona abstraction reflects genuine Oxide cloud-like self-service for VM provisioning — the developer experience for VM workloads is comparable to public cloud IaaS.* ### FC-2C — The Reasoning Plane *Autonomous, policy-driven placement deriving from live data governance metadata.* #### Autonomous placement reasoning *(universal)* **Score:** 0 · **Gap ownership:** structural · **DAPM:** Retained Oxide has no FC-2C reasoning plane. VM placement within the rack uses Oxide's scheduler to allocate resources from the fluid pool — this is demand-driven IaaS scheduling, not autonomous reasoning from data governance metadata. Anti-affinity groups spread instances across sleds based on operator-defined groups — pre-configured rules, not derived placement. When a new GDPR residency constraint arrives, an operator configures VM placement through project and network policy — Oxide's scheduler executes the configuration but does not derive placement from the constraint. Oxide has none of the FC-1 data governance metadata inputs that a reasoning plane would consume, and no reasoning layer that would consume them if they existed. Score 0 reflects: absent. Structural — FC-2C requires FC-1 data governance metadata that Oxide does not provide, and a reasoning layer that Oxide's architectural scope does not include. *Notes: FC-2C is absent for Oxide — structurally, not as a roadmap gap. FC-2C requires a platform that both provides FC-1 data governance metadata and connects it to an autonomous placement reasoning engine. Oxide provides neither. The FC-2C gap is downstream of the FC-1 gap: without data governance metadata in the platform, there is nothing for a reasoning plane to consume.* ### FC-3 — Application Distribution and Governance *The governed surface through which enterprise applications are published, versioned, discovered, and consumed.* #### Application catalog and distribution *(universal)* **Score:** 1 · **Gap ownership:** structural · **DAPM:** Retained Oxide provides VM images as the application distribution mechanism — custom images can be imported through Packer integration, and the Oxide console provides image management. VM images are the catalog item: the enterprise packages their application as a VM image and deploys instances from it. This is IaaS-layer image distribution, not a platform-native application catalog with operator-encoded Day 2 operational intelligence, versioning governance, dependency resolution, or upgrade path management. There is no equivalent to OperatorHub, VMware Automation catalog, or AWS Service Catalog in Oxide's platform. The enterprise deploys application catalog tooling — Helm, OperatorHub, internal artifact registries — on VMs inside the rack. Score 1 reflects: VM image management as the application distribution mechanism. No governed application catalog with versioning, dependency resolution, or operational intelligence. Structural — Oxide's application distribution scope matches its execution scope: the VM image boundary. #### Application lifecycle governance *(universal)* **Score:** 1 · **Gap ownership:** structural · **DAPM:** Retained Oxide provides no application lifecycle governance at the platform level. There are no upgrade channels, no approval gates, no compliance enforcement for applications, and no audit trails for application changes beyond VM instance state changes in the control plane API. The enterprise deploys application lifecycle governance tooling — OLM, Helm release management, GitOps, CI/CD pipelines — on VMs inside the rack. Score 1 reflects: minimal platform-level application lifecycle governance. VM instance lifecycle (start, stop, restart, delete) is governed by the Oxide control plane; application lifecycle above the VM boundary is the enterprise's operational responsibility. Structural. #### Developer experience and self-service *(universal)* **Score:** 2 · **Gap ownership:** structural · **DAPM:** Retained Oxide provides cloud-like self-service for VM provisioning through the API, CLI, and web console — developers can provision instances, configure networking, attach storage, and manage SSH keys without operator intervention. Terraform and OpenTofu integration enables infrastructure-as-code workflows for VM provisioning. The developer self-service experience for VM workloads is comparable to public cloud IaaS: self-service provisioning, project-level isolation, and resource quota enforcement without ticket queues. The gap from 3: developer self-service exists only for the VM provisioning layer. Developers building containerized applications must operate their own Kubernetes cluster. Developers building AI applications must deploy their own inference stack. Data engineers must deploy their own pipeline tooling. The platform provides no self-service abstractions above the VM boundary. Score 2 reflects: strong developer self-service for VM provisioning, absent for application-layer workload types. Structural — the VM boundary defines the scope of Oxide's developer self-service. #### AI application and agent distribution *(ai-workload)* **Score:** 0 · **Gap ownership:** structural · **DAPM:** Retained Oxide provides no AI application distribution or governance capability. AI applications are deployed as VM images — the enterprise packages their AI application as a VM image and provisions instances. There is no model version tracking, no agent tool authorization, no prompt injection controls, no inference governance, and no AI-specific distribution mechanism at the platform level. Score 0 reflects: no AI application distribution or governance capability within the Oxide platform. Structural. *Notes: FC-3 reflects Oxide's IaaS positioning consistently: VM images are the distribution unit, VM instance lifecycle is the governance scope, and developer self-service exists for VM provisioning. Application governance above the VM boundary is the enterprise's operational responsibility.* ### FC-4 — Integration Fabric *Event bus, API management, workflow orchestration, and system connectors.* #### Event fabric and messaging *(universal)* **Score:** 0 · **Gap ownership:** structural · **DAPM:** Retained Oxide provides no managed event fabric or messaging infrastructure. The enterprise deploys Kafka, RabbitMQ, or equivalent on Oxide VMs — Oxide's AI solutions page lists Apache Kafka as tooling that runs on Oxide. Running messaging software on Oxide VMs is the same as running it on any IaaS platform: the enterprise owns the operational model. Score 0 reflects: no platform-native managed event fabric. Structural. #### API management and gateway *(universal)* **Score:** 0 · **Gap ownership:** structural · **DAPM:** Retained Oxide provides a full VPC networking stack through the Oxide Packet Transformation Engine (OPTE): VPC subnets and routers, firewall rules, internet gateways, ephemeral and floating external IPs, IP pools, and boundary routing with BGP, OSPF, and BFD support via the Maghemite routing daemon. This is enterprise-grade network infrastructure — not a minimal NAT/firewall implementation. Score 0 is correct: Oxide is not an API gateway and provides no API lifecycle management, rate limiting, developer portal, versioning governance, or API-level audit for application APIs. The networking description correction does not affect the score — a complete VPC stack is not API management. Structural. #### Workflow and process orchestration *(universal)* **Score:** 0 · **Gap ownership:** structural · **DAPM:** Retained Oxide provides no workflow or process orchestration capability. The enterprise deploys Airflow, Temporal, or equivalent on Oxide VMs — Oxide's AI solutions page lists Apache Airflow as tooling that runs on Oxide. Score 0 reflects: no platform-native workflow orchestration. Structural. #### SaaS and enterprise system integration *(universal)* **Score:** 0 · **Gap ownership:** structural · **DAPM:** Retained Oxide provides no maintained connectors to enterprise systems of record. The enterprise deploys integration tooling on Oxide VMs. Score 0 reflects: no enterprise system integration capability within the Oxide platform. Structural. #### AI-native integration *(ai-workload)* **Score:** 0 · **Gap ownership:** structural · **DAPM:** Retained Oxide provides no AI-native integration capability — no MCP tool governance, no agent-to-agent identity propagation, no semantic model routing, no AI workflow event streaming. The enterprise deploys AI integration tooling on Oxide VMs. Score 0 reflects: no AI-native integration capability within the Oxide platform. Structural. *Notes: FC-4 is entirely absent for Oxide — five Structural zeros. This is expected and consistent: Oxide is an IaaS platform. Integration fabric is a platform service layer above IaaS. The enterprise assembles FC-4 capabilities on Oxide VMs using the same tooling they would use on any IaaS platform. Oxide does not differentiate in this layer — nor does it claim to.*