# Fourth Cloud — Full Dataset > https://cloud.layer2c.com/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.5 **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 an operationally mature Fourth Cloud control plane for on-prem environments. The core finding: 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 is 3. 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. 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. 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 F5=2 bar: access governance with audit, above access-control-only (F5=1) and below full managed connection infrastructure (F5=3). 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. FC-2B F4 gap ownership is Opinion: the structural on-prem inference ceiling (narrower backends, less cloud-like auto-scaling) is configured around with existing primitives, not a Vendor roadmap item. Against the AWS=4 benchmark, FC-4 F5=2 remains two full gradient steps below the hyperscaler managed-integration model. ## 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 · Substrate — Physical & Virtual Substrate | 3.00 | Strong | | FC-1 · Context — Distributed Data & Context Fabric | 1.75 | Gap | | FC-2A · Orchestration — Infrastructure Orchestration | 2.80 | Moderate | | FC-2B · Runtime — Execution & Runtime | 2.75 | Moderate | | FC-2C · Reasoning — The Reasoning Plane | 0.00 | Absent | | FC-3 · Catalog — Application Distribution and Governance | 2.75 | Moderate | | FC-4 · Integration — Integration Fabric | 0.40 | Absent | **DAPM profile:** Retained 8 · Delegated 1 · Ceded 17 ### FC-0 · Substrate — 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: broad multi-accelerator management across AMD, NVIDIA, and Intel. 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 genuine multi-vendor substrate heterogeneity (AMD + NVIDIA + Intel) rather than NVIDIA-only. #### 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. F2 and F3 are strong because VCF is hardware-agnostic by design: one control plane across any supported OEM's hardware, not a single vendor's.* ### FC-1 · Context — 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 · Orchestration — 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. 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. 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 · Runtime — 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 · Reasoning — 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 low because those prerequisites already exist internally; but the absence of a product announcement requires the Structural classification today. *Notes: VCF's FC-2C structural advantage: VCF already has cross-OEM visibility from the hypervisor up. An eventual VCF reasoning plane could query VCF Operations, vSAN, and vSphere Supervisor internally for the metadata a placement engine needs. The architectural prerequisites are largely present inside the control plane; the gap is the reasoning engine itself, not the plumbing to feed it.* ### FC-3 · Catalog — 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 for its containerized and AI workloads. 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. The Tanzu + VCF Automation + MCP Server Governance combination provides a coherent governed application distribution surface across containers, AI agents, and infrastructure blueprints. The remaining gaps are Opinion-class: catalog depth for traditional enterprise middleware and uniform self-service for traditional application types are extended using existing VCF Automation primitives.* ### FC-4 · Integration — 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. That places this at F5=2: access governance with audit is above basic access control (F5=1) and below full managed connection infrastructure (F5=3). 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. Within the F5=2 band, VCF governs access at the group-to-tool level rather than providing per-tool read/write capability filtering. 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. *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 buyer must acquire and maintain a separate event/messaging fabric, API management, workflow orchestration, and maintained system-of-record connectors.* --- # Red Hat OpenShift — Fourth Cloud Assessment *Fourth Cloud Control Plane Assessment — Red Hat Vendor Boundary* **Version:** v2.6 **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. Scope: OpenShift is assessed at the Red Hat vendor boundary: the base OpenShift Container Platform subscription plus Red Hat-licensed add-on subscriptions (Application Foundations, Red Hat AI Enterprise), each named inline where it carries a score; capabilities requiring a different vendor (e.g. IBM watsonx, IBM Process Automation Manager) remain Closeable gaps. 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. OpenShift GitOps (Argo CD) is included in the base OpenShift Container Platform subscription, so FC-3 F2 scores 3 (Opinion). FC-4 F3 scores 2 because Red Hat Process Automation Manager has moved to IBM for new purchases (Closeable via IBM Process Automation Manager Open Edition). FC-4 F5 gap ownership is Vendor roadmap: the Connectivity Link MCP Gateway is in technical preview in OpenShift AI 3.4. On-premises watsonx closure paths require OpenShift as substrate and are noted for competitive context only, without crediting IBM capability to OpenShift's scores. ## 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 · Substrate — Physical & Virtual Substrate | 2.33 | Moderate | | FC-1 · Context — Distributed Data & Context Fabric | 2.25 | Moderate | | FC-2A · Orchestration — Infrastructure Orchestration | 2.80 | Moderate | | FC-2B · Runtime — Execution & Runtime | 3.00 | Strong | | FC-2C · Reasoning — The Reasoning Plane | 0.00 | Absent | | FC-3 · Catalog — Application Distribution and Governance | 3.00 | Strong | | FC-4 · Integration — Integration Fabric | 2.60 | Moderate | **DAPM profile:** Retained 14 · Delegated 6 · Ceded 6 ### FC-0 · Substrate — 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 · Context — 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 · Orchestration — 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 · Runtime — 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 · Reasoning — 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 · Catalog — 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: F1=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=2: Red Hat OpenShift GitOps is a separately licensed product; community Argo CD through OperatorHub is the unsupported community path. F3=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 — is 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 — 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. #### 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: 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, which is why FC-4 F3 scores 2. FC-4 F5 gap ownership is 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.4 **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 an architecturally complete on-premises control plane spanning VMs, Kubernetes, databases, and AI inference, rather than a pure IaaS substrate or a developer-platform-first stack. Its defining strength is the unified management plane across VMs, Kubernetes, databases, AI inference, and cloud burst through a single Prism Central surface — broad workload management coverage across the full portfolio. 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. The HCL constraint is the most consequential finding: Nutanix's hardware compatibility list is component-combination-specific, so the enterprise cannot bring existing OEM servers. The layer profile: FC-0 F1=3 (LCM manages firmware on certified nodes) and F2=2; FC-2A F2=2 (NC2 cloud burst is a deployment-option advantage, not the platform's on-premises position) and F5=2 (GPU topology-aware placement is Vendor roadmap, H2 2026); FC-1 F2=2 and F3=2; FC-3 F3=3; FC-4 F3=1. FC-4 is entirely absent. 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: 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. FC-2C is absent. 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 (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 · Substrate — Physical & Virtual Substrate | 2.67 | Moderate | | FC-1 · Context — Distributed Data & Context Fabric | 1.75 | Gap | | FC-2A · Orchestration — Infrastructure Orchestration | 2.60 | Moderate | | FC-2B · Runtime — Execution & Runtime | 3.00 | Strong | | FC-2C · Reasoning — The Reasoning Plane | 0.00 | Absent | | FC-3 · Catalog — Application Distribution and Governance | 2.75 | Moderate | | FC-4 · Integration — Integration Fabric | 0.60 | Absent | **DAPM profile:** Retained 8 · Delegated 1 · Ceded 17 ### FC-0 · Substrate — 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. 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. #### 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. *Notes: FC-0 F1=3: LCM manages firmware, BIOS, and BMC on certified HCL nodes through the Nutanix toolchain. FC-0 F2=2: genuine heterogeneity management across certified configurations, but HCL component-combination specificity prevents arbitrary OEM hardware. FC-0 F3=3 through NC2: same-control-plane substrate portability across on-premises and three major hyperscalers.* ### FC-1 · Context — 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, within its 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. 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. #### 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. 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=2: Data Lens file/object governance is genuine data governance within NUS scope, not zero. FC-1 F3=2: 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.* ### FC-2A · Orchestration — 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 is a genuine operational capability: a managed cloud capacity expansion path through the same control plane. Structural — physical supply chain constraint applies universally to on-premises deployments. #### 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. 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. *Notes: FC-2A F2=2: NC2 cloud burst approaches F2=3 on cloud substrate, but the platform is scored at its on-premises position per the delivery-model rule. FC-2A F5=2: GPU scheduling intelligence above vGPU is NVIDIA-provided; Nutanix GPU topology-aware placement is Vendor roadmap (H2 2026). The layer profile: F1=3, F2=2, F3=3, F4=3, F5=2.* ### FC-2B · Runtime — 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. 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 across all four functions. Within the score band: NCM Intelligent Operations with native anomaly detection and remediation recommendations is included and stronger than telemetry exposure alone. NAI 2.6 MCP server governance provides tool-level filtering. Multi-hypervisor self-service continuity through ESXi-to-AHV migration is a genuine included differentiator for the VMware migration market.* ### FC-2C · Reasoning — 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 a developed infrastructure-intelligence signal but 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. Nutanix's infrastructure intelligence layer (NCM Intelligent Operations, upcoming AHV GPU topology-aware placement) is well developed, but the structural gap remains: compliance metadata from FC-1 does not drive placement decisions. If the Agentic AI solution (GA H2 2026) connects NCM's placement intelligence to Data Lens governance signals, that would be a plausible on-premises path toward FC-2C.* ### FC-3 · Catalog — 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 provides strong Day 1 provisioning and configuration, with 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. 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. 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. Portal fragmentation is a within-F3=3-band gap, not a reason to score F3=2. 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. 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 and scripted Day 2 operations, rather than continuously running operators that encode 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 — 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: basic automation patterns are available, but full enterprise business process orchestration requires separate acquisition. Closeable — BPMN-compliant workflow engines can be deployed on NKP. #### 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:** Ceded 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=1: NCM runbooks constitute basic IT automation workflow patterns (basic automation available; full business-process orchestration requires separate acquisition). FC-4 F5=2: NAI AI Gateway provides MCP access governance, not managed MCP connection infrastructure. FC-4 F1=0, F2=0, F4=0.* --- # Oxide Computer — Fourth Cloud Assessment *Fourth Cloud Control Plane Assessment — Rack-Scale IaaS* **Version:** v1.4 **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. Conventional control planes are software 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: a cloud IaaS substrate, not an enterprise control plane. 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. Oxide's genuine strength is FC-0 — the substrate layer that software-only control planes leave to the enterprise. FC-0 F1 (hardware lifecycle management) scores 3, earned through co-design rather than 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 built into the control plane itself. Where software-only control planes integrate with OEM-provided firmware management tools, 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 result: Oxide owns the substrate layer rather than integrating with it. 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. FC-2A F4 scores 3: the Service Processor integrates hardware-failure events with workload scheduling (auto-restart, anti-affinity); the gap from 4 is live migration during planned maintenance, which is Vendor roadmap (H2 2026). 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). Oxide exposes a native OpenAPI-described API with a Terraform/OpenTofu provider; it is not AWS-API-compatible. Its IAM hierarchy is fleet to silo to project, with the silo as the hard tenancy boundary. Native telemetry is Oximeter/OxQL, with Prometheus via an OpenTelemetry collector and Grafana via a native OxQL plugin; observability platforms do not need to run on Oxide VMs. ## 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 · Substrate — Physical & Virtual Substrate | 1.33 | Gap | | FC-1 · Context — Distributed Data & Context Fabric | 0.25 | Absent | | FC-2A · Orchestration — Infrastructure Orchestration | 1.60 | Gap | | FC-2B · Runtime — Execution & Runtime | 1.25 | Gap | | FC-2C · Reasoning — The Reasoning Plane | 0.00 | Absent | | FC-3 · Catalog — Application Distribution and Governance | 1.00 | Gap | | FC-4 · Integration — Integration Fabric | 0.00 | Absent | **DAPM profile:** Retained 17 · Delegated 1 · Ceded 8 ### FC-0 · Substrate — Physical & Virtual Substrate *The physical foundation the control plane lifecycles.* #### Hardware lifecycle management *(universal)* **Score:** 3 · **Gap ownership:** structural · **DAPM:** Ceded Oxide achieves strong hardware lifecycle integration 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. #### 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. #### 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=3: Oxide release notes recommend shutting down instances before system updates, confirming that maintenance transparency is not yet at the hyperscaler benchmark. FC-0 F2=1: managing one hardware type does not constitute heterogeneity management. FC-0 F3=0: an 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 · Context — 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=0: 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).* ### FC-2A · Orchestration — 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:** Ceded 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:** Ceded 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). #### 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=2: unified IAM covering compute, storage, and networking is three-dimensional policy enforcement, stronger than basic tenant isolation. FC-2A F4=2: 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 · Runtime — 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:** Ceded 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:** Delegated 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. #### 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 · Reasoning — 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 · Catalog — 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. Oxide's platform has no governed application or service catalog. 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:** Ceded 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 — 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.* --- # Canonical OpenStack — Fourth Cloud Assessment *Fourth Cloud Control Plane Assessment — Self-Managed at the Ubuntu Pro Boundary* **Version:** v1.0 **Date:** June 11, 2026 **Status:** complete **Evolution model:** forklift **Source:** Canonical OpenStack documentation (Sunbeam architecture, release cycle, GPU passthrough), Charmed OpenStack documentation and charm guide, MAAS documentation and support pages, Ubuntu Pro support boundary statements, Canonical data and AI portfolio announcements (Charmed OpenSearch GA, Charmed Spark, Charmed Feast), Charmed Apache Kafka 4 release notes (Karapace, Kafka Connect), Charmed OpenStack Upgrader documentation, canonical/openstack-migrate repository, OpenStack governance records (Murano retirement, OSSN-0093, Sunbeam TC reference), Powered By OpenStack trademark program, Fourth Cloud Assessment Methodology v2.4. Three-model comparative review conducted; deltas documented in audit trail. Editorial register pass applied prior to publication: cross-vendor comparisons and ranking superlatives removed, narratives normalized to reason in the platform's own terms; no scores, classifications, or structure changed. ## Canonical OpenStack — Maximum Authority, Assembled Canonical OpenStack is the open-source, commodity-hardware occupant of the VM-tenancy niche: the platform to deploy when you need to slice shared hardware into self-service tenant units smaller than a node, with a hard distrust boundary between them. That is the question that decides this assessment. Answer yes — as carriers, sovereign clouds, research federations, and GPU operators structurally do — and OpenStack remains the commercially supported open-source platform built around hard multi-tenancy as a first-class object. Answer no, and every "Why not OpenStack?" is "Why not Kubernetes?" in disguise, and the function scores below answer it. Almost nothing in this assessment is Ceded: almost everything is Opinion or Closeable, and that pairing is the product. Delegated authority dominates the row — open-source platform, substitutable vendor — and the gap ownership column prices what that authority costs: the enterprise does the work. The pattern repeats at every layer. The firmware lifecycle ships as a harness; the curation is yours. The data layer ships as a supported parts catalog — vector databases, Kafka with a stable schema registry, ML pipelines, all inside one subscription — with no fabric joining them and nothing feeding a reasoning plane. Credit for being packaged; minus for not being integrated. The defining capability gap is the one OpenStack never closed: VMs and containers remain two estates that never share a scheduler, a runtime surface, or a policy domain. This is not an industry impossibility — the seam has been closed elsewhere, both from above the hypervisor and from below the container runtime — it is an architecture decision this platform's community attempted four times (nova-docker, Magnum's original scope, Zun, Kuryr) and abandoned, settling on hosting. The OpenStack-versus-Kubernetes debate ended with Kubernetes on both sides of OpenStack: as the substrate its own control plane now runs on under the Sunbeam architecture, and as the tenant workload running on top. OpenStack settled into the middle as the VM-tenancy layer, which is also exactly why it settled into telco, where mutually distrusting vendors' workloads — first VNFs, then CNF clusters — are permanently sub-node-granular. The choice is precise: a closed seam inside a closed system, or an open seam inside an open one. Nobody currently sells a closed seam in an open system. Identity plane continuity is where the parts-catalog model presents its bill: 2, partial federation. Inside the OpenStack estate, Keystone is a genuinely strong native identity unification — substrate-to-execution continuity with zero bridges, because the layers were never separate identity systems. But the Ubuntu Pro breadth that lifted the capability scores arrived as products, and the products arrived with identity models: Keystone, MAAS, Juju, and the Canonical Identity Platform are four identity planes, and the seams between them belong to the enterprise. The buyer's trade is stated honestly by Canonical's own tooling. The row scores forklift: evolution is continuous and genuinely efficient within each architecture generation — Canonical solved the upgrade problem that emptied OpenStack conference halls in the 2010s, twice — but the succession from Charmed to Sunbeam, the transition every production estate faces, is a side-by-side workload evacuation through the public APIs, performed by the same tool that would migrate the enterprise to a different vendor entirely. That equivalence is the finding in one sentence: the OpenStack API surface and everything accumulated against it ports — across architectures, across distributions, away from Canonical itself — and everything below it is rebuilt, even when you stay. The buyer gets exceptionally strong exit rights and a standing engineering organization as the price of holding them. For the operator whose tenancy requirements leave no alternative, that is a fair trade knowingly made. For everyone else, it is the measurement that says so. ## Scoping note Assessed product: Canonical OpenStack, self-managed on customer-owned hardware, at the Ubuntu Pro + Support boundary — which covers OpenStack, MAAS, Ceph, Canonical Kubernetes, and the full charmed data and AI portfolio (PostgreSQL, MySQL, MongoDB, OpenSearch, Kafka, Spark, Kubeflow, MLflow, Feast) under one per-node subscription without additional software license fees. The product spans two reference architectures mid-transition: Charmed OpenStack (Juju machine charms, mature, full-featured) and Canonical OpenStack based on Sunbeam (control plane as Kubernetes operators on Canonical Kubernetes, strategic, parity in progress); scoring follows Charmed where Sunbeam lacks parity, with the transition itself assessed under evolutionModel. Canonical's Managed OpenStack and Private Cloud Build offerings are deployment-mode notes, not scored: managed Canonical operates software on hardware the enterprise still procures, with no pre-staged capacity buffer, so even the managed model would not reach the FC-2A F2 consumption-model bar. The OpenStack distribution landscape: Mirantis MOSK/k0rdent (OpenStack-on-Kubernetes pattern) is queued for separate assessment; Red Hat OpenStack Services on OpenShift runs its control plane as pods on OpenShift and is an OpenShift extension scored there, not a standalone candidate; Rackspace and OVH managed/hosted OpenStack are out of scope per the self-managed comparison baseline; vanilla upstream OpenStack has no vendor support boundary to score and serves as reference architecture only. Canonical OpenStack is the actual downstream distribution of upstream code — the Powered By OpenStack program requires unmodified code in designated sections plus API interoperability tests — though RefStack, the program's verification tooling, was retired in September 2025, so the guarantee now rests on Canonical's sub-two-week upstream packaging model rather than active third-party certification. ## Identity Plane Continuity **Score:** 2 **Classification:** partial **Gap ownership:** mixed **Layers in plane:** fc2a, fc2b, fc3 **Layers siloed:** fc0, fc1, fc2c, fc4 Inside the OpenStack estate, Keystone is a genuinely strong native identity unification — not federation but a single identity service whose domain/project/role model is enforced at every OpenStack API. The same token and project scope that authorizes Ironic bare-metal provisioning authorizes Nova execution, Cinder attachment, Neutron networking, Heat orchestration, and Glance image publication, with zero bridges, because these were never separate identity systems. But the Ubuntu Pro breadth that lifted this row's capability scores arrived as products, and the products arrived with identity models. A Canonical enterprise operates four identity planes: Keystone for the OpenStack estate; MAAS's own user model for the hardware lifecycle surface; Juju's own users for the operational plane that deploys and lifecycles everything; and the Canonical Identity Platform (Ory-based) federating the charmed application estate — the Kafka OAuth integration credited at FC-4 F1 propagates Identity Platform identity, not Keystone identity. Two bridges exist as configuration-grade primitives: the k8s-keystone-auth webhook brings tenant Kubernetes into Keystone's plane (Opinion), and Keystone-to-Identity-Platform OIDC federation is buildable from shipped components (Opinion). MAAS and Juju identity remain islands requiring enterprise-built bridges (Closeable, pending verification of current MAAS and Juju/JIMM OIDC maturity, which could soften the classification without moving the score). This is where the parts-catalog model gets expensive: every point the subscription's breadth earned at FC-1, FC-2B, and FC-4 is partially repaid here, because capability arrived as products and products arrived with identity models. Per the methodology, siloed identity is the largest single source of Closeable gap burden. **Buyer implication:** Within the OpenStack estate: yes — FC-0-adjacent substrate identity (Ironic) natively controls FC-2B execution (Nova) with no bridge and no cost. Across the full Canonical stack: no — the buyer operates four identity systems (Keystone, MAAS, Juju, Canonical Identity Platform), and the seams between them belong to the enterprise. Two seams close with configuration of shipped primitives; the MAAS and Juju seams are built, at Section 2.6 gap lifecycle cost per bridge. ## Layer-by-layer scoring | Layer | Avg score | Status | |---|---|---| | FC-0 · Substrate — Physical & Virtual Substrate | 1.67 | Gap | | FC-1 · Context — Distributed Data & Context Fabric | 1.50 | Gap | | FC-2A · Orchestration — Infrastructure Orchestration | 2.00 | Moderate | | FC-2B · Runtime — Execution & Runtime | 2.25 | Moderate | | FC-2C · Reasoning — The Reasoning Plane | 0.00 | Absent | | FC-3 · Catalog — Application Distribution and Governance | 1.00 | Gap | | FC-4 · Integration — Integration Fabric | 1.00 | Gap | **DAPM profile:** Retained 13 · Delegated 13 · Ceded 0 ### FC-0 · Substrate — Physical & Virtual Substrate *The physical foundation the control plane lifecycles, scored on the control plane's relationship to substrate.* #### Hardware lifecycle management *(universal)* **Score:** 2 · **Gap ownership:** closeable · **DAPM:** Delegated MAAS gives Canonical deep bare-metal lifecycle: machines move through a managed lifecycle (enlist, commission, ready, deploy, release) in which commissioning boots an ephemeral image, probes CPU, memory, storage, network, and accelerators, applies baseline firmware settings, and runs hardware health tests; Redfish is preferred over IPMI where available; hardware changes are detected on recommissioning. MAAS support is included per-machine within Ubuntu Pro for Infrastructure — the same boundary as the assessed product. What caps the score at 2 is firmware and driver content: updates run through a commissioning harness in which administrators author their own per-OEM scripts, targeting hardware by PCI ID or model, with the script defining where to obtain proprietary firmware and tools. Canonical publishes example scripts pinning specific Dell and HPE firmware binary URLs against specific mainboard products; the content is enterprise-authored and OEM-supplied, not vendor-maintained. Scaled across a heterogeneous fleet, the enterprise has not automated firmware lifecycle — it has become its own firmware lifecycle vendor with MAAS as the execution harness. The harness automates execution; the expensive part, curation — which firmware, in what order, validated against which OpenStack release — stays with the enterprise as a standing engineering function at full Section 2.6 lifecycle cost. The architectural cap: MAAS and OpenStack are two operational surfaces bridged at deployment time by Juju or Sunbeam, not one surface. Closeable: the enterprise acquires OEM firmware lifecycle tooling and integrates it through the harness, a gap a vendor program that contracts OEM firmware lifecycle would close. The pattern here is abstraction — unify the BMC protocols, leave the firmware content to the enterprise — which is why the firmware-content dependency, not the lifecycle mechanics, sets the ceiling at 2. #### Substrate heterogeneity *(universal)* **Score:** 2 · **Gap ownership:** structural · **DAPM:** Retained Heterogeneity is what MAAS exists to do: it controls machines through standard BMC services (IPMI, Redfish-preferred, PXE), supports chassis controllers and custom BMC plugins, provisions Windows, Ubuntu, CentOS/RHEL, and ESXi across x86, ARM64, POWER, and Z, and inventories accelerators as constraints for machine selection. Accelerator exposure is real: arbitrary PCI devices are whitelisted for passthrough through the Canonical OpenStack manifest (accelerator-vendor-agnostic), and NVIDIA vGPU lands through a supported subordinate charm — with the boundary note that the charm requires the proprietary NVIDIA vGPU software package as a customer-supplied, separately licensed resource, supported under Ubuntu Pro for customers holding current NVIDIA licenses. The score lands at 2 rather than 3 on two facts: the firmware-content dependency established at F1, and the accelerator story being shallow (NVIDIA vGPU plus generic passthrough; no MIG orchestration depth, no AMD or Intel accelerator management beyond passthrough). Decisively, MAAS and the OpenStack control plane are separated planes. Canonical earns full credit for packaging and loses the point for integration: a separated control plane is exactly the pattern this instrument was created to identify, and the same portfolio-versus-platform rationale that excludes multi-product management suites from the instrument caps this function inside it. MAAS is exceptionally capable; it is not integrated. Retained: the function rests on commodity x86 substrate the enterprise can swap across OEMs. #### Substrate portability *(universal)* **Score:** 1 · **Gap ownership:** structural · **DAPM:** Retained Canonical OpenStack is on-prem software by strategic scope: there is no marketed Canonical-OpenStack-on-public-cloud control plane, which is what holds this function at 1. Canonical's edge product is MicroCloud, an LXD-based platform — a different control plane that earns no credit here under the rule that a separate product is not the assessed control plane. Sunbeam's small-footprint deployments shrink the minimum cluster size but do not change the substrate type. Retained by default: nobody has claimed the function, and the enterprise that needs hybrid substrate portability assembles it from tooling outside this product's scope. *Notes: MAAS predates and outlived the composable-infrastructure era it was originally marketed into (Intel RSD, HP Moonshot, composable UCS — all discontinued) because it abstracted at the durable layer: BMC protocols, PXE, image deployment, inventory. Its survival niches — telco, bare-metal clouds, GPU cluster provisioning — are the substrate beneath Canonical's stack. MAAS's independence (multi-OS, multi-architecture, separable support) strengthens the Delegated authority finding: bare-metal opinions accumulated in MAAS survive an OpenStack exit, and vice versa. The same independence is the F1/F2 integration cap.* ### FC-1 · Context — Distributed Data & Context Fabric *The data fabric the reasoning plane queries for placement decisions, covering the full enterprise data estate.* #### Data location and gravity awareness *(universal)* **Score:** 1 · **Gap ownership:** closeable · **DAPM:** Retained The Canonical Observability Stack (Prometheus-based) plus Ceph topology gives the platform infrastructure and storage awareness — which node, which pool, which volume. That is storage awareness, not data awareness, and it holds the function at 1. No catalog anywhere in Canonical's portfolio tells a reasoning plane where enterprise data lives by type, residency, or classification, across structured, unstructured, streaming, transactional, and AI-specific data. A compliance query — where is the PII? — has no programmatic answer at the platform level. The control plane knows where a Cinder volume is; it does not know what is in it. The enterprise acquires cataloging capability (Closeable) and owns the integration. #### Governance and compliance metadata *(universal)* **Score:** 1 · **Gap ownership:** closeable · **DAPM:** Retained OpenStack carries free-form metadata on nearly every resource type — image properties, instance tags, volume metadata, Swift object headers — and even offers an enforcement primitive: Nova scheduler filters such as AggregateImagePropertiesIsolation can route instances whose image carries a given property onto designated host aggregates, and Cinder volume types can pin classified data to specific backends. An operator can build 'PII images land only on hardened hosts' from stock parts. What is missing is everything the function definition asks for. Nothing classifies: the tag is whatever a human typed, with no scanner, no validation, no schema — pii, PII, and personal-data are three different strings the platform carries with equal indifference. Nothing propagates: tag the image and the attached volumes inherit nothing, the network path knows nothing, the object store where output lands knows nothing; the operator re-expresses the policy independently in scheduler filters, volume types, network policy, and object ACLs, and keeps them consistent by hand. Nothing audits: no surface can prove to a compliance officer that everything tagged PII stayed on the hardened aggregate, because the platform does not know the tag is load-bearing. That is the rubric's 1 nearly verbatim: manual compliance tagging, no automatic propagation, operator duplicates policy across enforcement layers. What earns a higher score is an engine that understands the metadata: continuous evaluation of workloads against named compliance frameworks with policy enforced at admission. Canonical's nearest equivalents are Ubuntu Security Guide (CIS and DISA-STIG hardening at the node-OS level — a hardening tool, not a governance surface) and Keystone (access policy, not compliance metadata). The distinction between carrying metadata and understanding it is the function. #### Retrieval and context services *(ai-workload)* **Score:** 2 · **Gap ownership:** opinion · **DAPM:** Delegated The Ubuntu Pro boundary moves this function above the vanilla-upstream baseline of zero. Canonical markets pgvector on Charmed PostgreSQL for vector search and Charmed OpenSearch for GPU-accelerated vector and hybrid search — passing the marketed-vs-possible test — and both deploy on OpenStack with enterprise support under the same per-node subscription, no additional license fees. What Canonical ships are supported vector databases, not retrieval services: there is no managed ingest-chunk-embed-index pipeline, no embedding management, no retrieval orchestration — the enterprise composes and operates the stack via Juju. A 3 on this function would require an actual retrieval pipeline (managed ingest, embedding, and orchestration) with platform-assisted data-services management; Canonical ships the databases a tier below that. The point of FC-1 is feeding FC-2C reasoning, and supported components that nothing consumes do not feed anything. Opinion: closing the gap requires composing components the subscription already covers, no new procurement. Delegated: open source with real alternatives. #### Data pipeline and lineage *(universal)* **Score:** 2 · **Gap ownership:** closeable · **DAPM:** Delegated Charmed Kafka covers streaming (with Kafka Connect stable and MirrorMaker 2 in the current release), Charmed Spark covers processing, and Charmed Kubeflow covers ML pipelines — all supported within the Ubuntu Pro boundary, all lifecycle-managed by their charms. The rubric's 2 describes the result almost verbatim: pipeline capability for some data types, ML tooling present, traditional data pipeline tooling absent. What is missing is what a 3 requires: a maintained connector library (the Kafka Connect integrators Canonical maintains connect Canonical's own portfolio to itself, not a broad third-party catalog), change-data-capture from operational databases, and any lineage capability at all. Closeable: connectors and lineage require capability Canonical does not sell. *Notes: Layer shape 1/1/2/2. The layer's one-sentence story: Canonical's data layer is a parts catalog with a single subscription and no opinions — every component is supported, nothing is integrated into a fabric, and nothing tells the reasoning plane anything. This previews FC-2C's zero: the integration question (can FC-2C consume FC-1 metadata?) is foreclosed before it is asked, because no metadata fabric exists to consume.* ### FC-2A · Orchestration — Infrastructure Orchestration *Unified orchestration of the full enterprise workload portfolio.* #### Workload universality *(universal)* **Score:** 2 · **Gap ownership:** structural · **DAPM:** Retained Nova schedules VMs and — genuinely notable — bare metal through the same API via nova-ironic, with one tenancy model carrying both. But Kubernetes arrives as a hosted workload: Magnum-provisioned or Juju-deployed onto Nova instances, with its own scheduler, its own RBAC, and resource sharing only in the accounting sense that the cluster consumes Nova quota. Two scheduling surfaces coexisting without coordination is the rubric's 2 verbatim. The history matters and belongs in the record: OpenStack pioneered multi-workload IaaS and never unified the container plane — not from neglect but from repeated attempts the project walked back. nova-docker tried to make containers a hypervisor type and was abandoned; Zun's native container API never achieved ecosystem traction; Kuryr's unified network plane withered. Magnum is the survivor, and it survived by abandoning the unification goal: launched in 2015 as the container service, it redefined itself within two years as Container Infrastructure Management, and today (2025.1, Cluster-API-driven) it is an actively maintained, native multi-tenant API for provisioning Kubernetes clusters on OpenStack — hosting done well, not container-plane scheduling. The community attempted the unification repeatedly across a decade and the market declined every offer, settling on hosting. Meanwhile the unification has shipped elsewhere, both from below (pulling VMs up into the container platform's API) and from above (an umbrella over both units) — which is what separates a 2 here from a 3, and what makes the gap Structural in its precise sense: not an industry impossibility, but an architecture decision outside this vendor's current scope to reverse. The modern hosting path has at least improved as hosting: Cluster API's OpenStack provider and Canonical's supported, Juju-lifecycled Kubernetes are good hosting. It is still hosting. #### Resource lifecycle automation *(universal)* **Score:** 2 · **Gap ownership:** structural · **DAPM:** Delegated The delivery-model anchor: Canonical OpenStack self-managed automates workload lifecycle within fixed, enterprise-owned capacity. Heat provides auto-scaling within the estate, Masakari provides automated instance HA, charm-driven operations automate scaling, patching, and upgrades. Nothing provisions a physical node that does not exist; the control plane neither owns nor pre-stages the supply chain. Note for completeness: Canonical's Managed OpenStack would not change this score — Canonical operates software on hardware the enterprise still procures, with no pre-staged capacity buffer in the customer facility, so the consumption-model 3 (a managed model with pre-staged capacity) is out of reach in any Canonical delivery mode currently sold. #### Policy and quota enforcement *(universal)* **Score:** 2 · **Gap ownership:** closeable · **DAPM:** Delegated Within its domain, Keystone is a strongly unified policy surface: one tenancy model carrying identity, RBAC, and per-project quotas across compute, storage, network, and bare metal simultaneously, stronger intra-domain unification than this function usually sees. The score nonetheless lands at 2: a 3 requires policy spanning the VM/container divide from one surface, and Canonical's Kubernetes workloads live in a separate policy domain — Kubernetes RBAC and ResourceQuotas the operator keeps consistent with Keystone by hand. Since AI workloads in Canonical's reference architecture land on Kubeflow-on-Kubernetes, the rubric's 2 — AI workloads and traditional workloads have separate quota and policy management that the operator must keep consistent manually — describes the actual deployment. The hosted-Kubernetes seam is scored at full price here, with no carve-out. Exceptional capability inside the domain; minus for the domain boundary. #### Substrate lifecycle integration *(universal)* **Score:** 2 · **Gap ownership:** closeable · **DAPM:** Delegated Masakari provides automated VM evacuation on host failure; planned maintenance is operator-initiated live migration through host maintenance workflows. What is missing for a 3: nothing flows upward from MAAS into scheduling. A hardware health event MAAS detects does not trigger Nova action; firmware operations are planned separately from workload scheduling; there is no automatic cross-workload-type drain. This is the third appearance of the two-plane finding (after FC-0 F1 and F2): MAAS below for metal, OpenStack above for workloads, bridged at deployment time, not integrated at event time. Closeable: the integration is buildable (MAAS webhooks into operator tooling driving Nova APIs) but requires enterprise construction. #### Accelerator and GPU management *(ai-workload)* **Score:** 2 · **Gap ownership:** closeable · **DAPM:** Delegated Two points above the vanilla-upstream baseline of zero, and the Ubuntu Pro verification is what moves it: the NVIDIA vGPU subordinate charm is a validated, supported integration with multi-tenant isolation through vGPU profiles and MIG-backed types, placement traits for GPU-type targeting, and flavor-based allocation, supported under Ubuntu Pro for customers holding current NVIDIA vGPU licenses — the proprietary NVIDIA vGPU manager is a customer-supplied, separately licensed component, a dependency this assessment notes consistently with FC-0 F2. Generic PCI passthrough covers other accelerator vendors without isolation sophistication. What caps it at 2 is scheduling intelligence: a 3 requires GPU-aware automated balancing or fair-share queueing with multi-vendor quota. Canonical has allocation, not arbitration — no queueing, no fair-share, no preemption, no GPU-aware rebalancing. Closeable: arbitration requires tooling Canonical does not ship. *Notes: Layer shape 2/2/2/2/2 — flat, and honestly flat: every function caps at the same seam, pressure-tested individually. The layer narrative in one sentence: Canonical orchestrates two estates well and one estate not at all. Supported-charm status for Magnum, Masakari, and Watcher is treated as inside the all-Canonical-maintained-charms support statement; the precise supported-charm list should be confirmed with Canonical AR. Trove (database-as-a-service) is not in Canonical's supported set.* ### FC-2B · Runtime — Execution & Runtime *The execution plane where workloads actually run.* #### Runtime universality *(universal)* **Score:** 2 · **Gap ownership:** structural · **DAPM:** Retained A VM-native, containers-in-hosted-Kubernetes architecture, which earns a 2 rather than a 1 on two facts. First, the Kubernetes is first-party: Canonical ships and supports its own Kubernetes inside the same Ubuntu Pro boundary, with Magnum as a native OpenStack API for tenant cluster lifecycle, rather than handing off to a third-party Kubernetes with a separate support relationship. Second, the rubric's 2 requires multiple execution surfaces coexisting under a shared management plane — unified governance above, fragmented execution below — and that sentence nearly describes Juju: one management plane deploying and lifecycling both estates, one support contract, Keystone reaching into Magnum clusters for authentication via the keystone-auth webhook. Under the buyer test, Magnum is the VM-tenancy niche operating correctly: the tenancy layer handing each tenant their own sub-node-granular Kubernetes is the one configuration where hosted Kubernetes is the point rather than the limitation. The execution seam itself is Structural in the vendor-scope sense: a unified surface (VMs as first-class peers of pods in the same namespace and RBAC) is buildable and has been built, but it took owning the platform end to end, and every function such a unification touches becomes Ceded. The choice at this layer: a closed seam inside a closed system, or an open seam inside an open one. #### Persona abstraction at execution *(universal)* **Score:** 2 · **Gap ownership:** opinion · **DAPM:** Delegated Horizon gives developers genuine ticket-free self-service — instances, networks, volumes, Heat stacks — with per-project quotas and application credentials; operators get Horizon administration, Juju status, and COS dashboards; the persona primitives are real. But the abstraction is workload-type-specific: the Kubernetes estate has its own developer interface and toolchain, and security audit surfaces require assembly (CADF audit middleware exists as a primitive; nothing ships turnkey). Primitives present, opinionated implementation not shipped: Opinion, configured from what the subscription already covers. #### Execution lifecycle and observability *(universal)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Delegated The strongest function in this row, and the one place the parts-catalog model genuinely pays off — because observability is where Canonical ships an integrated opinion rather than components on either side of a seam. The Canonical Observability Stack is a shipped, supported observability platform — Grafana, Prometheus/Mimir, Loki, Alertmanager, Tempo — and the Juju relation model is what lifts it past telemetry export: charms integrate with COS and bring their own dashboards and alert rules, so the OpenStack services, the Kubernetes estate, and charmed applications land in one Grafana without the enterprise building the correlation surface. Three pillars in standard formats plus partial shipped correlation is the rubric's 3. Lifecycle management is charm-automated across the estate (scaling, upgrades, Masakari HA). Opinion rather than Closeable: the correlation component is usually Closeable for buyers without an existing observability platform, but Canonical ships the platform inside the subscription boundary, so the residual is configuration. Verification flag: Tempo's support status in full COS versus COS Lite should be confirmed before publication. #### AI inference and agent execution *(ai-workload)* **Score:** 2 · **Gap ownership:** mixed · **DAPM:** Delegated The Ubuntu Pro boundary moves this off zero: Charmed Kubeflow ships KServe model serving with Canonical support, plus Charmed MLflow, on the Kubernetes estate — vendor-supported, charm-lifecycled, multi-tenant through namespaces and Kubeflow profiles. Against a deploy-the-serving-runtime-yourself baseline, a supported serving stack is a real point. What it is not is a managed service of the control plane: the enterprise deploys and operates it two layers up, there is no inference API gateway, no token quotas, no model catalog, no showback — nothing answering a platform-native, in-subscription model runtime or models-as-a-service. And agent execution is absent entirely: no agent runtime, no MCP governance, no tool authorization. Mixed gap ownership: the inference residual is Opinion (compose what the subscription already covers); the agent residual is Closeable (nothing in Canonical's portfolio to compose). Verification flag: KServe's inclusion and support depth within Charmed Kubeflow should be confirmed against Canonical documentation. *Notes: Layer shape 2/2/3/2 — Canonical's strongest layer. The deeper frame for F1, recorded for the narrative: VMs and pods are abstractions of different things — a hardware abstraction with its own kernel, NICs, and NUMA topology versus an application abstraction with a shared kernel and deliberately hidden interfaces. The unit distinction is industry property; the unmanaged seam is OpenStack property. The same boundary has been closed elsewhere from above and from below; OpenStack alone settled on hosting.* ### FC-2C · Reasoning — The Reasoning Plane *Autonomous, policy-driven, multi-variable placement derivation for all workload types.* #### Autonomous placement reasoning *(universal)* **Score:** 0 · **Gap ownership:** structural · **DAPM:** Retained Canonical OpenStack has no reasoning plane, and two anticipated objections are addressed in advance. First, host aggregates and scheduler filters: the AggregateImagePropertiesIsolation mechanism — routing instances whose image carries a given property onto designated host aggregates — is OpenStack's closest approach to metadata-derived placement, and it fails the litmus precisely. The metadata participates in placement only because an operator authored a filter binding that specific property to that specific aggregate; when a new GDPR residency requirement arrives, a human writes new filter configuration. Pre-configured rule dispatch, single workload type, no derivation. The same disposition applies to Juju constraints, MAAS tags and zones, availability zones, and Kubernetes node selectors: operator-authored control primitives, not reasoning. Second, Watcher: OpenStack's optimization service computes and applies resource-optimization actions — consolidation, load balancing — from infrastructure telemetry. That is resource-signal-driven placement, the same mechanism class as any resource-optimization scheduler, which this instrument rules non-qualifying: it optimizes where capacity says to move things; it cannot answer whether this workload, with this data classification, may run in this jurisdiction. No FC-1 metadata exists for it to consume even if it could — the data layer ships no catalog and no compliance fabric, foreclosing the integration question before it is asked. The structural finding is two-fold, stated precisely: the derivation engine is missing industry-wide (the universal structural gap — no on-prem platform ships one, because a unified body is not a brain; resource-signal optimization over a merged estate is still optimization, not reasoning), and OpenStack additionally lacks the unified substrate a derivation engine would act upon. This platform is two steps from FC-2C: the substrate is not unified, and the reasoning plane does not exist. *Notes: FC-2C remains the universal unmet gap on this instrument. The Canonical-specific addition is the missing precondition: workload universality, which a reasoning plane would require and which this platform has not met.* ### FC-3 · Catalog — Application Distribution and Governance *The governed surface through which enterprise applications of all types are published, versioned, discovered, and consumed.* #### Application catalog and distribution *(universal)* **Score:** 1 · **Gap ownership:** structural · **DAPM:** Retained Glance images and Heat templates are deployment mechanisms, which the methodology's catalog standard explicitly disqualifies: no publication governance, no consumption governance. The historically interesting note: Canonical does operate a real catalog with channels, versioning, and publication review — Charmhub — but it distributes the platform's own components, not the enterprise's applications. The catalog governs the infrastructure; the tenant estate gets image membership and signature verification. Murano, OpenStack's application catalog project, is retired upstream, and the OpenStack security team advises its complete removal from all deployments — closing the historical objection preemptively. The catalog item available to the tenant estate is the VM image, which the rubric scores at 1. #### Application lifecycle governance *(universal)* **Score:** 1 · **Gap ownership:** structural · **DAPM:** Retained Version tracking exists at the image level — Glance image membership, visibility controls, signature verification — but there is no compliance state tracking, no deprecation enforcement, no platform-level proof that only approved application versions ran. A registry capability, not a governance surface. The enterprise builds lifecycle governance for the tenant estate or operates without it. #### Developer experience and self-service *(universal)* **Score:** 2 · **Gap ownership:** structural · **DAPM:** Retained Horizon is genuine ticket-free self-service — developers provision instances, networks, volumes, and Heat stacks without operator intervention, gated by per-project quotas, with operator visibility through the admin surface. The score lands at 2 rather than 3: a 3 requires intent-based self-service spanning workload types with platform-enforced approval gates. The self-service is real for the IaaS estate and inconsistent beyond it: the Kubernetes estate exposes its own developer experience, and approval workflows are process, not platform policy. #### AI application and agent distribution *(ai-workload)* **Score:** 0 · **Gap ownership:** structural · **DAPM:** Retained No AI-specific distribution or governance capability: no model version tracking at distribution time, no agent tool authorization, no prompt injection controls, no data access scope enforcement, no output audit trails. Kubeflow distributes AI workloads through its own mechanisms on the tenant Kubernetes estate, outside any platform governance model. *Notes: Layer shape 1/1/2/0. At the application layer, Canonical ships deployment mechanisms and self-service for the IaaS estate but no governed catalog and no AI-specific distribution. The row diverges from a bare IaaS substrate only where Canonical ships products (FC-2B F3, FC-4 F1); at this layer it does not.* ### FC-4 · Integration — Integration Fabric *The event bus, API management, workflow orchestration, and system connectors that connect enterprise applications to each other and to systems of record.* #### Event fabric and messaging *(universal)* **Score:** 2 · **Gap ownership:** mixed · **DAPM:** Delegated A strong 2. Charmed Apache Kafka's current release ships Karapace as a stable schema registry, Kafka Connect stable with maintained integrators, MirrorMaker 2 for replication, Kafka UI, and OAuth integration with the Canonical Identity Platform — all inside the Ubuntu Pro subscription. Schema enforcement shipped, replay native to Kafka, fan-out and delivery guarantees present, identity propagation partially answered. Two facts hold it from a 3: it is a supported stack the enterprise composes and operates — the same in-boundary-composition ceiling applied consistently at FC-1 F3, FC-1 F4, and FC-2B F4, never platform-native — and there is no legacy protocol story at all (no JMS, AMQP, or MQTT product; the RabbitMQ charm exists for OpenStack's internal messaging and is not marketed as a tenant messaging product, so marketed-vs-possible excludes it). Mixed gap ownership: the composition residual is Opinion; the legacy protocol residual is Closeable. Note the identity caveat for the identity plane finding: the OAuth integration propagates Canonical Identity Platform identity, not Keystone identity. #### API management and gateway *(universal)* **Score:** 0 · **Gap ownership:** closeable · **DAPM:** Retained Octavia is network-layer load balancing — SSL termination, balancing, basic limits — disqualified by the rule that network-layer gateway functions are not API lifecycle management. No publication, versioning, access control, transformation, or audit for enterprise APIs anywhere in the Canonical portfolio. The enterprise acquires an API management platform and owns its integration. #### Workflow and process orchestration *(universal)* **Score:** 2 · **Gap ownership:** closeable · **DAPM:** Delegated Kubeflow Pipelines is marketed, supported AI pipeline orchestration within the Ubuntu Pro boundary — the rubric's 2 verbatim: AI pipeline orchestration present, traditional business process orchestration absent. There is no engine for order-to-cash processes, long-running transactions, saga patterns, or compensation logic, and no unified governance spanning AI chains and business workflows. Two boundary notes: Mistral remains maintained upstream but is absent from Canonical's supported set (no charm, not in Sunbeam's plugin list) — the SKU boundary excludes it without prejudice to its upstream health. And the Canonical-maintained Temporal charm is a genuine boundary ambiguity: it exists, Canonical built it and uses it, but it is unmarketed and absent from the data portfolio's support statements; credit waits on Canonical AR's answer to whether it falls inside the all-Canonical-maintained-charms support commitment. Closeable: traditional process orchestration requires acquisition. #### SaaS and enterprise system integration *(universal)* **Score:** 1 · **Gap ownership:** closeable · **DAPM:** Delegated Kafka Connect is a supported integration framework, but the maintained integrators connect Canonical's own portfolio to itself: PostgreSQL, MySQL, S3, OpenSearch, MongoDB. There is no SAP, Salesforce, ServiceNow, Workday, Oracle, or mainframe connector anywhere in the catalog. Framework without maintained system-of-record connectors is the rubric's 1; a 3 would require a broad maintained connector library. Per the methodology, this is the most operationally expensive function in the instrument when absent: every point-to-point integration the enterprise builds on the framework carries full Section 2.6 lifecycle cost. #### AI-native integration *(ai-workload)* **Score:** 0 · **Gap ownership:** closeable · **DAPM:** Retained Nothing: no MCP tool governance, no agent-to-agent identity propagation, no model API federation, no semantic routing, no AI workflow event streaming. The row's classical-integration strength does not extend here: there is no MCP story at all. The enterprise assembles AI integration from open-source components with no platform support. *Notes: Layer shape 2/0/2/1/0. The charmed data-platform portfolio gives Canonical a real classical-integration story — an event fabric and workflow orchestration inside the subscription — while the absence of an API management product, a maintained connector library, and any AI-native integration holds the layer down. Strong on event and workflow, absent on API management and AI-native integration.* --- # Bounded Kubernetes (k3s on NVIDIA DGX Spark) — Fourth Cloud Assessment *Fourth Cloud Control Plane Assessment - Kubernetes, bounded by a workload* **Version:** v1.1 **Date:** July 7, 2026 **Status:** complete **Evolution model:** continuous **Source:** Scored on the Fourth Cloud methodology (v2.4) against the assembled stack a single production workload requires. Each score was earned by a validator that executed during a live, cloud-free deployment on the node. Fixed function taxonomy; gap ownership on every score below 4; DAPM per function. v1.1 adds day-2 evidence from a serving-model replacement executed on the same deployment (July 7, 2026): four function narratives and one layer note; no scores changed. ## Full Authority, Fully Assembled This assessment scores a Kubernetes control plane assembled from open-source components on a single node and bounded by one production workload, which supplies the product boundary that makes each function testable. k3s provides the orchestration kernel; the data plane (CloudNativePG with pgvector, MinIO), model serving (vLLM), local embeddings, identity (Keycloak), and ingress (Traefik) are assembled and operated by the enterprise. The gap portfolio is dominated by Closeable gaps at the catalog and integration layers: application catalog, developer self-service, event fabric, workflow orchestration, and API management are absent and must be acquired and operated as additional open-source components. The context fabric is provided at retrieval, where the vector store and local inference are self-hosted and drilled, while the estate-scale data functions — gravity awareness, governance metadata, lineage — are absent. FC-0 substrate is Ceded to the hardware vendor. FC-2C reasoning is Structural and absent, consistent with on-prem. Identity continuity is partial: the self-hosted Keycloak plane reaches the workload runtime but not the remaining layers, and the enterprise owns extending it. The buyer's trade is authority for operational responsibility. Under DAPM the assembly is Retained above the substrate: every capability is open-source and swappable without rebuilding, so no vendor holds the enterprise's accumulated opinions. The cost is that the enterprise operates every layer it retains. Each provided function carries a lifecycle the enterprise owns, and each absent function is a component it must acquire, deploy, and maintain. The substrate is the single Ceded exception, bound to the hardware vendor. ## Scoping note This row scores a Kubernetes control plane bounded by a single production workload. Kubernetes has no product boundary to assess in the abstract because it is an assembly; the workload supplies that boundary, and each function is scored against what the assembled, deployed stack provides, earned by a validator that executed during the deployment. The assessed assembly is k3s with CloudNativePG and pgvector, MinIO, Keycloak, vLLM, a local embedding model, and Traefik, on a single NVIDIA DGX Spark. Every open gap names the component the enterprise would acquire, deploy, and operate to close it. ## Identity Plane Continuity **Score:** 2 **Classification:** partial **Gap ownership:** closeable **Layers in plane:** fc2b **Layers siloed:** fc0, fc1, fc2a, fc2c, fc3, fc4 A federated identity plane is present as a self-hosted Keycloak instance running on the platform's own Postgres, issuing OIDC tokens with RS256 signing. It reaches the workload runtime: the application validates realm tokens and authenticates against them, rejecting unauthenticated requests. It does not yet span orchestration, catalog, or integration, so continuity is partial. The enterprise owns the identity provider and must extend it — additional clients and single sign-on — to reach the remaining layers. **Buyer implication:** Can FC-0 identity control FC-2B runtime execution? Partially. The workload authenticates against the self-hosted Keycloak plane, but identity is not yet enforced across orchestration, catalog, and integration. The enterprise owns extending it, and the cost is configuration of additional clients and single sign-on across services it already runs, not a new acquisition. ## Layer-by-layer scoring | Layer | Avg score | Status | |---|---|---| | FC-0 · Substrate — Physical & Virtual Substrate | 1.33 | Gap | | FC-1 · Context — Distributed Data & Context Fabric | 1.75 | Gap | | FC-2A · Orchestration — Infrastructure Orchestration | 2.00 | Moderate | | FC-2B · Runtime — Execution & Runtime | 2.25 | Moderate | | FC-2C · Reasoning — The Reasoning Plane | 0.00 | Absent | | FC-3 · Catalog — Application Distribution and Governance | 1.25 | Gap | | FC-4 · Integration — Integration Fabric | 1.20 | Gap | **DAPM profile:** Retained 24 · Delegated 0 · Ceded 2 ## Lab Validations Hands-on Layer2C Labs builds on real hardware that test where authority actually holds for Bounded Kubernetes (k3s on NVIDIA DGX Spark) at the layers below. Labs validate the assessment against reality; they are not paid certifications. | Lab | Layers validated | Finding | Link | |---|---|---|---| | Lab 005: Authority you reclaim is authority you run | FC-0 · Substrate, FC-1 · Context, FC-2A · Orchestration, FC-2B · Runtime, FC-2C · Reasoning, FC-3 · Catalog, FC-4 · Integration | A cloud-free serve path is provable end to end; every layer moved from Ceded to Retained is a decision you now own and a system you now operate. | https://labs.layer2c.com/labs/vctoa-to-spark | ### FC-0 · Substrate — Physical & Virtual Substrate *The physical foundation the control plane lifecycles.* #### Hardware lifecycle management *(universal)* **Score:** 1 · **Gap ownership:** closeable · **DAPM:** Ceded Provided: none. k3s runs on the host operating system but does not lifecycle node hardware, firmware, or the OS. The substrate is a single vendor appliance whose accelerator and driver are vendor-maintained. The enterprise provisions and updates the node manually; a managed model requires fleet tooling (Cluster API, Metal3) the platform does not include. #### Substrate heterogeneity *(universal)* **Score:** 1 · **Gap ownership:** structural · **DAPM:** Ceded Provided: none. The substrate is one aarch64 node, so there is no heterogeneity to manage until additional or dissimilar nodes exist. Adding nodes is a separate deployment, not a capability the platform closes here. #### Substrate portability *(universal)* **Score:** 2 · **Gap ownership:** structural · **DAPM:** Retained Provided: the assembled workload is portable — containers, a served model, and an embedder that move to any conformant Kubernetes. The accelerator path is bound to the vendor appliance and its driver. The enterprise keeps the software's portability; the GPU binding is a constraint of the chosen hardware. **Validated in Labs:** [Lab 005: Authority you reclaim is authority you run](https://labs.layer2c.com/labs/vctoa-to-spark) *Notes: The substrate is a single vendor appliance. The control plane does not lifecycle hardware; the accelerator and driver are vendor-maintained, and substrate authority is Ceded. Only the portability of the assembled software above it is Retained.* ### FC-1 · Context — 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 Provided: none. The platform has no data-location or gravity awareness; all data is local to the single node. The enterprise owns any multi-location placement, and closing this at estate scale requires a data-fabric layer the platform does not include. #### Governance and compliance metadata *(universal)* **Score:** 1 · **Gap ownership:** closeable · **DAPM:** Retained Provided: none. No governance or compliance metadata layer is present. The enterprise must acquire and operate a data catalog and policy tooling (for example OpenMetadata) to close it. #### Retrieval and context services *(ai-workload)* **Score:** 3 · **Gap ownership:** closeable · **DAPM:** Retained Provided: a self-hosted document and vector store on the CloudNativePG operator with pgvector, serving grounded retrieval to the workload and surviving a force-kill restart with full vector recovery. The enterprise owns the operator lifecycle, the index build, and the recovery-point policy. No managed vector service is included; the capability is assembled from open-source components the enterprise runs itself. #### Data pipeline and lineage *(universal)* **Score:** 2 · **Gap ownership:** closeable · **DAPM:** Retained Provided: an ingest path that chunks, embeds, and loads the corpus. No lineage or provenance tracking is present. The enterprise owns pipeline orchestration and must acquire lineage tooling to close the gap. **Validated in Labs:** [Lab 005: Authority you reclaim is authority you run](https://labs.layer2c.com/labs/vctoa-to-spark) *Notes: The context fabric is provided at retrieval, where a self-hosted vector store and local inference are assembled and drilled. The estate-scale data functions — location awareness, governance metadata, lineage — are absent and Closeable.* ### FC-2A · Orchestration — Infrastructure Orchestration *Unified orchestration of the full enterprise workload portfolio.* #### Workload universality *(universal)* **Score:** 3 · **Gap ownership:** structural · **DAPM:** Retained Provided: the Kubernetes API surface schedules containers of any shape across the node. VM and bare-metal workload types are not addressed by this assembly, so coverage is container-scoped. The enterprise holds full control of workload placement. #### Resource lifecycle automation *(universal)* **Score:** 3 · **Gap ownership:** closeable · **DAPM:** Retained Provided: operator-driven resource lifecycle for the data tenant — the CloudNativePG operator handles provisioning, failover, backup, and replica creation without operator action, demonstrated by an automatic standby provision on scale-out. The enterprise owns operator selection and upgrades; lifecycle automation for other tenants requires deploying their operators. #### Policy and quota enforcement *(universal)* **Score:** 1 · **Gap ownership:** closeable · **DAPM:** Retained Provided: Kubernetes-native RBAC and resource limits. No admission-control policy engine and no GPU quota are present. The enterprise must acquire and operate a policy engine (Kyverno, OPA Gatekeeper) and, for GPU quota, extend the open-source device plugin. #### Substrate lifecycle integration *(universal)* **Score:** 1 · **Gap ownership:** closeable · **DAPM:** Retained Provided: none. The control plane does not integrate substrate lifecycle. The gap is high-effort to close on a single node with limited return, and the enterprise owns it. #### Accelerator and GPU management *(ai-workload)* **Score:** 2 · **Gap ownership:** closeable · **DAPM:** Retained Provided: GPU access to scheduled pods through runtime-class injection. GPU accounting and quota are not provided: the driver cannot report unified memory, so the standard device plugin schedules no GPU capacity. The enterprise can close accounting by extending the open-source device plugin; the platform ships no supported path. Day-2 evidence: memory reservation is tenant-declared, not platform-accounted. A serving-model replacement re-sized its reservation and returned a large share of unified memory that the platform can neither observe nor allocate to other tenants; the headroom ledger is operator-kept. **Validated in Labs:** [Lab 005: Authority you reclaim is authority you run](https://labs.layer2c.com/labs/vctoa-to-spark) *Notes: Orchestration is container-scoped. Operator-driven resource lifecycle is provided for the data tenant; policy, quota, and substrate integration are absent and must be assembled. Accelerator management provides access without accounting.* ### FC-2B · Runtime — Execution & Runtime *The execution plane where workloads actually run.* #### Runtime universality *(universal)* **Score:** 3 · **Gap ownership:** structural · **DAPM:** Retained Provided: a container runtime for any workload the enterprise packages, over the Kubernetes API. Non-container runtimes are out of scope for this assembly. The enterprise holds runtime control. #### Persona abstraction at execution *(universal)* **Score:** 1 · **Gap ownership:** closeable · **DAPM:** Retained Provided: none. There is no persona or tenant abstraction at the execution layer. The enterprise must build or acquire it. #### Execution lifecycle and observability *(universal)* **Score:** 2 · **Gap ownership:** mixed · **DAPM:** Retained Provided: pod lifecycle and self-healing. A force-killed pod is recreated without operator action, and the bare pod state survives a full node reboot on etcd. Observability is not included, and the default liveness check that ships is misleading. Twice the vLLM reasoning engine wedged while the pod stayed Running, restartCount held, and /health returned 200. A false green. The only reliable liveness signal was out-of-band GPU power draw, roughly 17W idle against 35W-plus under load, so a stack scraped against /health reports healthy straight through the stall. The stack itself (Prometheus, Grafana, Loki) is low effort. The load-bearing half is knowing that container liveness is not workload liveness: the true signal for the reasoning engine is request throughput and accelerator draw, invisible to the container instruments. The enterprise must acquire, operate, and correctly aim that stack to close the second half of the function. #### AI inference and agent execution *(ai-workload)* **Score:** 3 · **Gap ownership:** closeable · **DAPM:** Retained Provided: model serving on the cluster via vLLM, delivering the workload's grounded, cited generation end to end over the ingress with no external dependency. The enterprise owns the model, the memory budget, and serving uptime. No managed inference is included; the capability is self-hosted. Day-2 evidence: a serving-model replacement executed as a manifest change with a sequential pod swap, revalidated end to end over the ingress at equivalent grounded-output quality. The swap is declarative; image logistics, memory sequencing, and revalidation remain enterprise-owned. **Validated in Labs:** [Lab 005: Authority you reclaim is authority you run](https://labs.layer2c.com/labs/vctoa-to-spark) *Notes: Runtime is container-scoped and self-healing, with model serving provided and drilled. Observability and persona abstraction are absent and Closeable. On a unified-memory substrate, model precision functions as the capacity instrument: a 4-bit quantized serving replacement freed the majority of the reservation at equivalent grounded-output quality under the same validators.* ### FC-2C · Reasoning — The Reasoning Plane *Autonomous, policy-driven placement deriving from live data governance metadata.* #### Autonomous placement reasoning *(universal)* **Score:** 0 · **Gap ownership:** structural · **DAPM:** Retained Provided: none. No policy-driven placement reasoning derives from live metadata, and no such reasoning plane exists in this assembly. Placement decisions rest with the enterprise and its operators. The gap is structural: the reasoning plane is unavailable on-prem. **Validated in Labs:** [Lab 005: Authority you reclaim is authority you run](https://labs.layer2c.com/labs/vctoa-to-spark) *Notes: No reasoning plane is present. Placement is operator-driven, not derived from live metadata. Structural and absent, consistent with on-prem.* ### FC-3 · Catalog — 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:** closeable · **DAPM:** Retained Provided: none. Deployments are applied as manifests directly. The enterprise must acquire and operate a GitOps or catalog layer (Argo CD, a Helm-based catalog) to close it. Day-2 evidence: the runtime's image store is separate from the build-side store, so every new serving image enters the cluster by a manual, root-privileged import. An in-cluster registry (Harbor) closes the distribution path. #### Application lifecycle governance *(universal)* **Score:** 2 · **Gap ownership:** closeable · **DAPM:** Retained Provided: operator-level day-2 governance for the data tenant (backup, restore, and replica lifecycle). No application-wide governance layer spans the estate. The enterprise owns broader lifecycle governance and must assemble it. Day-2 evidence: deployed configuration drifted from its manifest source within days; two runtime-safety settings were corrected live and not written back until a later change surfaced the divergence. No reconciliation loop converges live state to a declared source. A GitOps controller (Argo CD, Flux) closes drift detection and correction. #### Developer experience and self-service *(universal)* **Score:** 1 · **Gap ownership:** closeable · **DAPM:** Retained Provided: none. There is no self-service portal or golden-path tooling. The enterprise must acquire and operate a developer portal (Backstage) to close it. #### AI application and agent distribution *(ai-workload)* **Score:** 1 · **Gap ownership:** closeable · **DAPM:** Retained Provided: none. There is no packaging or distribution mechanism for AI applications or agents. The enterprise owns it. **Validated in Labs:** [Lab 005: Authority you reclaim is authority you run](https://labs.layer2c.com/labs/vctoa-to-spark) *Notes: No application catalog, developer self-service, or AI-application distribution is provided. Application lifecycle governance exists only at the operator level for the data tenant. The layer is Closeable in full.* ### FC-4 · Integration — Integration Fabric *Event bus, API management, workflow orchestration, and system connectors.* #### Event fabric and messaging *(universal)* **Score:** 1 · **Gap ownership:** closeable · **DAPM:** Retained Provided: none. There is no managed event or messaging fabric. The enterprise must acquire and operate a broker (NATS, Kafka) if the workload requires one. #### API management and gateway *(universal)* **Score:** 2 · **Gap ownership:** closeable · **DAPM:** Retained Provided: ingress and TLS termination via Traefik, routing external traffic to the workload over HTTPS. API management is not included: no rate limiting, authentication, or lifecycle at the edge. The enterprise must acquire an API management layer (Kong, an equivalent gateway) to close it. #### Workflow and process orchestration *(universal)* **Score:** 1 · **Gap ownership:** closeable · **DAPM:** Retained Provided: none. There is no workflow or process orchestration. The enterprise must acquire and operate a workflow engine (Argo Workflows, Temporal). #### SaaS and enterprise system integration *(universal)* **Score:** 1 · **Gap ownership:** opinion · **DAPM:** Retained Provided: none, by design. The deployment carries no external SaaS or enterprise-system connectors; external integration was deliberately excluded. The runtime can host connectors the enterprise applies if integration is later required. #### AI-native integration *(ai-workload)* **Score:** 1 · **Gap ownership:** closeable · **DAPM:** Retained Provided: the workload integrates its own retrieval and model internally. No platform-level AI-native integration fabric is present. The enterprise owns cross-application AI integration. **Validated in Labs:** [Lab 005: Authority you reclaim is authority you run](https://labs.layer2c.com/labs/vctoa-to-spark) *Notes: Ingress and TLS are provided as a gateway. API management, event fabric, workflow orchestration, and external integration are absent; external integration is excluded by design. The layer is Closeable, some of it by choice.* --- # HPE Private Cloud — Fourth Cloud Assessment *Fourth Cloud Control Plane Assessment — HPE Morpheus + VM Essentials on HPE Private Cloud* **Version:** v1.2 **Date:** July 30, 2026 **Status:** complete **Evolution model:** continuous **Source:** HPE Discover 2026 press materials (June 2026) and HPE Discover 2025 (June 2025); HPE Morpheus Enterprise Software and HPE Morpheus VM Essentials product pages and QuickSpecs; HPE Private Cloud Business Edition, Private Cloud Enterprise, and Private Cloud AI product pages; HPE Compute Ops Management product page, QuickSpecs, and subscription-tier documentation; HPE Data Fabric Software and HPE Ezmeral Unified Analytics documentation; HPE AI Essentials documentation; HPE OpsRamp documentation and the OpsRamp Operations Copilot announcement; HPE GreenLake identity-governance and IAM documentation; HPE Alletra Storage MP B10000/X10000 materials; Juniper acquisition close (July 2025) and Apstra/Mist integration coverage; analyst and trade coverage (Futurum, NAND Research, Moor Insights & Strategy, HyperFRAME, Virtualization Review, StorageReview, Network World, TechTarget, Blocks & Files); Fourth Cloud methodology v2.4. GA-versus-roadmap verified against mid-2026 sources; roadmap capability is flagged, not scored. v1.1 prose revision: added the coverage-versus-continuity closing verdict and a maturity-caveat scoping note explaining why this row alone carries it; no score changes. v1.2 (vendor feedback, July 2026 HPE/Morpheus call): corrected FC-0 F2 to reflect that VM Essentials third-party host qualification is now generally available rather than roadmap, held the score at 1 because that support is migration-scoped and does not extend the HPE lifecycle plane a Fourth Cloud outcome depends on, sharpened FC-4 F2 against the workload-orchestration-gateway argument, and folded the surface-fragmentation and documented-seam findings into the closing verdict; no score changes. ## One Platform, or One Storefront? HPE Private Cloud, orchestrated by HPE Morpheus with VM Essentials as HPE's own hypervisor, is a genuine Fourth Cloud control plane. This row scores the vendor-recommended path for the audience the instrument primarily serves: the architect building a Fourth Cloud to land new applications on, or to migrate applications to. Where some vendors deploy other vendors' control planes, HPE kept and rebuilt its own. Morpheus supplies the unified orchestration, governance, and self-service surface. VM Essentials supplies a native runtime. Both run under one HPE vendor relationship. The strength concentrates in the operational tri-plane. FC-2A orchestration, FC-2B runtime, and FC-3 catalog all land at the strong band. Morpheus unifies VMs, containers, bare metal, and multi-tier application stacks under one catalog with per-business-unit quota, policy, and approval governance, and the consumer effectively gets workload universality whether or not a single scheduler sits underneath. VM Essentials runs VMs natively with high availability and live migration. The persona-separation and self-service primitives are complete, and observability through OpsRamp ships genuine cross-workload correlation. FC-1 is where the audience split matters, and the instrument states it plainly. On HPE's recommended path, HPE Data Fabric is the data layer, and it is a deep one: a global namespace across the estate, catalog federation, and classification with policy-driven data placement. For the Fourth Cloud native designing around that path, FC-1 is a real strength. For the buyer migrating off an existing virtualization estate who keeps existing or competing storage, Data Fabric's contribution must be weighed heavily. It is a workload-shape-dependent data platform, not a capability the migration inherits, and for that buyer FC-1 reads as a structural gap. The governance metadata, however deep, still lacks workload awareness. It can place data against a residency constraint. It cannot derive where a workload runs. Two structural gaps set the ceiling. FC-2C, the reasoning plane, scores zero. Morpheus places VMs on capacity and topology, and the agentic operations roadmap is IT-operations automation, not compliance-metadata-derived workload placement. HPE holds both prerequisites internally, a strong metadata fabric and its own scheduler, but the derivation engine that would wire them does not exist, and no product with a confirmed timeline closes it. FC-4, the integration fabric, is the second gap portfolio: no managed API platform, no business-process orchestration, no maintained system-of-record connectors. A Kafka-compatible event store and an IT-automation workflow engine are the only partial credit, and both sit low. Identity plane continuity scores 2, partial. GreenLake identity and access management is a real federation spine that pulls Morpheus, VM Essentials, Private Cloud AI, and OpsRamp under one workspace sign-on, but FC-0 substrate identity does not natively control FC-2B runtime execution, and Morpheus carries its own role model federated in rather than one native context. The profile is assembled from several subscriptions under one vendor relationship: Private Cloud with Morpheus and VM Essentials, plus Data Fabric, AI Essentials with Private Cloud AI, OpsRamp, and Compute Ops Management, each named where it carries a score. The buyer's trade is explicit. A broad, mostly generally-available Fourth Cloud control plane, with real orchestration, runtime, and catalog maturity and a deep optional data fabric, in exchange for owning the reasoning plane and a full integration fabric, and for composing the data layer to fit the workload. A closing discipline, and the reason it applies to this row and not the field-established ones. This instrument scores documented capability and names no winner. Every capability here is real. What a document cannot establish is whether the pieces operate as one platform, and that question weighs more here than elsewhere because of when and how the claims were assembled. This control plane is recent: the orchestration layer arrived by acquisition and relaunched in 2025, the owned hypervisor in late 2024, the AI pieces through 2026. The claim is also broad, a full platform stood up across several products the operator crosses in the life of one workload, from Morpheus and VM Essentials to Data Fabric, Private Cloud AI, OpsRamp, and Compute Ops Management. Morpheus is the front door to that portfolio, the surface for provisioning and catalog, but the operational depth of a Fourth Cloud, its lifecycle, data, observability, AI, and networking, lives in the other products, each its own pane and identity model; the storefront is unified, the store behind it is assembled. Where integration has years in production behind it, its maturity is a known quantity and the assessment can lean on demonstrated experience. Here it is neither demonstrated nor disproven. Whether identity, policy, state, and telemetry survive the seams, whether Morpheus stays the operational surface after provisioning rather than handing off to separate consoles, whether a firmware event drives workload evacuation and return as one lifecycle, is unverified. One seam is not a question but a fact already in the documentation: run the hypervisor on non-HPE hardware and the firmware and health lifecycle plane does not follow it. Coverage is not continuity. That is the decisive question for this platform, the one a document cannot answer and a score does not capture, and it is settled by operating the stack, not by counting its parts. The gap portfolio counts 10 structural, 6 closeable, 6 opinion, 2 mixed, and 2 vendor-roadmap, a map of what to test, not a rank. ## Scoping note This assessment scores the HPE Private Cloud family — Private Cloud Business Edition, Private Cloud Enterprise, and Private Cloud AI — orchestrated by HPE Morpheus (Morpheus Enterprise Software plus Morpheus VM Essentials, HPE's own KVM hypervisor) under one HPE vendor relationship. HPE's own add-on subscriptions are named inline where they carry a score: HPE Compute Ops Management at FC-0, HPE Data Fabric and HPE Ezmeral Unified Analytics at FC-1 and FC-4, HPE AI Essentials with Private Cloud AI at FC-1 and FC-2B, and HPE OpsRamp at FC-2B. The row scores the vendor-recommended Fourth Cloud path for the audience the instrument primarily serves: the architect building a Fourth Cloud to land new applications on, or to migrate applications to. On that path HPE Data Fabric is the recommended data layer and is scored as such. A second audience — the buyer replacing an existing virtualization estate who retains separate or competing storage — does not inherit Data Fabric, which is a workload-shape-dependent data platform rather than a capability the migration carries with it; for that buyer FC-1 must be weighed as a structural gap. That distinction is named in the FC-1 narratives, not scored twice. Scoring is on generally available capability as of mid-2026; announced and roadmap capability is flagged in the narratives and does not lift a score. This row carries a maturity caveat the instrument's field-established rows do not, and for a specific reason: the HPE control plane is recently assembled and broad in scope, and its integrated operation is not yet demonstrated in production. The instrument scores documented capability the same way for every vendor; whether these products operate as one platform across their seams is unverified here, and it is the question a hands-on validation resolves, not this row. ## Identity Plane Continuity **Score:** 2 **Classification:** partial **Gap ownership:** mixed **Layers in plane:** fc2a, fc2b, fc3 **Layers siloed:** fc0, fc1, fc2c, fc4 HPE GreenLake identity and access management is a genuine federation spine: SAML and OpenID Connect federation to the enterprise identity provider, SCIM provisioning, and dynamic role-based access evaluated per session, with Morpheus, VM Essentials, Private Cloud AI, and OpsRamp consolidating under one workspace sign-on. That federation spans the operational plane from Compute Ops Management and GreenLake through Morpheus orchestration (FC-2A), VM Essentials and Private Cloud AI runtime (FC-2B), and catalog access (FC-3). The plane is partial rather than continuous. Morpheus carries its own role model federated into the workspace rather than one native context; per-runtime identity persists, with governance reaching Morpheus-managed workloads but not every runtime uniformly; and FC-0 substrate identity does not reach FC-2B runtime enforcement. The data fabric governs data access through its own catalog identity model at FC-1, the reasoning plane at FC-2C does not exist, and there is no integration fabric identity at FC-4. **Buyer implication:** No, not natively. FC-0 substrate identity cannot control what application runtimes execute at FC-2B without operator-configured policy bridges. The GreenLake spine federates administrator and operator sign-on across the operational layers, but workload-identity enforcement from substrate to runtime, and reconciling Morpheus's own role model with per-runtime identity, is the enterprise's configuration and bridge burden. The federation is real and reduces the number of identity islands; it does not yet make one identity context enforceable at every layer. ## Layer-by-layer scoring | Layer | Avg score | Status | |---|---|---| | FC-0 · Substrate — Physical & Virtual Substrate | 2.00 | Moderate | | FC-1 · Context — Distributed Data & Context Fabric | 2.75 | Moderate | | FC-2A · Orchestration — Infrastructure Orchestration | 2.40 | Moderate | | FC-2B · Runtime — Execution & Runtime | 3.00 | Strong | | FC-2C · Reasoning — The Reasoning Plane | 0.00 | Absent | | FC-3 · Catalog — Application Distribution and Governance | 2.50 | Moderate | | FC-4 · Integration — Integration Fabric | 0.60 | Absent | **DAPM profile:** Retained 4 · Delegated 4 · Ceded 18 ### FC-0 · Substrate — 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:** structural · **DAPM:** Ceded HPE Compute Ops Management provides cloud-delivered hardware lifecycle management for the HPE ProLiant fleet: firmware, BIOS, and driver baselines with compliance tracking, staged and policy-driven updates, delta-based downloads across large fleets, health monitoring, and provisioning. The enterprise operates a genuine hardware lifecycle plane rather than assuming healthy hardware. The gap from 4 is that the hardware pane and the workload pane are distinct surfaces. Compute Ops Management runs firmware and health; VM Essentials and Morpheus run workloads; the two converge at the operations-view level rather than as one lifecycle operation. Coordinated firmware-to-workload maintenance is generally available only where the hypervisor is VMware and vSphere Lifecycle Manager drives the workload evacuation. An HPE-native path from a firmware event to automated workload draining, patching, and rejoin on HPE's own hypervisor is not shipped. Structural: the distinct-surface reality and the physical operating model hold this below fully integrated, invisible hardware lifecycle. The lifecycle opinions accumulate in HPE-proprietary, HPE-hardware-bound tooling. Ceded. #### Substrate heterogeneity *(universal)* **Score:** 1 · **Gap ownership:** structural · **DAPM:** Ceded A Fourth Cloud outcome on the recommended path relies on the integrated HPE stack, and that integration is built around HPE hardware. VM Essentials now qualifies the HVM hypervisor on multiple server vendors: the current qualification matrix lists Cisco UCS, Dell PowerEdge, Supermicro, and xFusion hosts alongside HPE ProLiant and Synergy, expanded through a partner self-validation program. That capability is real and generally available, not roadmap. But it serves a virtualization outcome rather than a Fourth Cloud one. The heterogeneity reaches the hypervisor and its storage interop; it does not reach the lifecycle. Firmware and health run through Compute Ops Management, which is HPE-hardware-bound, so a qualified non-HPE host runs the hypervisor while its firmware and health return to that vendor's own tooling, and the wider integrated stack the outcome depends on is built around HPE hardware. Putting a third-party host under the hypervisor advances a VMware-replacement goal and steps outside the HPE lifecycle plane rather than extending it. Score 1 reflects that the substrate the control plane fully lifecycles and integrates with is a single vendor's, even though the hypervisor itself now runs more widely. Accelerator handling is GPU passthrough and pooling, generally available, centered on NVIDIA, with vGPU in the management interface not yet generally available. Structural: the split between hypervisor reach and lifecycle reach follows from binding lifecycle and integration to HPE hardware. The management primitives are HPE-proprietary and HPE-hardware-bound. Ceded. #### Substrate portability *(universal)* **Score:** 2 · **Gap ownership:** structural · **DAPM:** Ceded The same VM Essentials and Morpheus control plane runs on-premises and at the edge, the latter through SimpliVity with VM Essentials, and Morpheus manages public clouds as first-class deployment targets. What the control plane does not do is run on public-cloud substrate: the VM Essentials hypervisor does not run on cloud bare metal, cloud is reached as a managed target through cloud interfaces, and Morpheus Central, delivered as a cloud service, is a governance federation overlay rather than the provisioning control plane running on cloud substrate. Edge consistency is achieved through differently sized appliances rather than one identical artifact everywhere. Score 2 reflects on-premises and edge on one control plane with cloud addressed as a separate managed capability, short of a control plane that runs unchanged across on-premises, cloud, and edge. Structural. The control-plane opinions are HPE-proprietary. Ceded. *Notes: FC-0 shows the shape of hardware ownership. F1=3 because Compute Ops Management is a genuine cloud-delivered firmware-through-health lifecycle plane, bound to HPE's own fleet. F2=1 despite the hypervisor now qualifying on Cisco, Dell, Supermicro, and xFusion hosts, because that multi-vendor support serves a VMware-replacement outcome and does not extend the lifecycle plane a Fourth Cloud outcome depends on; the substrate the control plane fully lifecycles and integrates with is still a single vendor's. F3=2 because the control plane anchors on-premises and at the edge, with cloud reached as a managed target rather than substrate it runs on.* ### FC-1 · Context — 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:** 3 · **Gap ownership:** structural · **DAPM:** Ceded On the vendor-recommended path, HPE Data Fabric is the data layer, and it provides a genuine location and gravity picture: a global namespace spanning edge, core, and public cloud across heterogeneous storage protocols, Apache Polaris catalog federation, and a programmatic query interface over unified metadata. The architect designing an estate around this path can ask where data lives across the estate programmatically. Two gaps hold it below 4. No reasoning plane consumes this metadata to derive workload placement, and the coverage is the estate conformed to the fabric rather than any data anywhere. A buyer migrating from an existing virtualization estate who retains separate or competing storage does not inherit this capability; Data Fabric is a workload-shape-dependent data platform, and for that buyer the location picture is bounded to infrastructure telemetry. Structural: the gap from 4 is the absent reasoning-plane consumer, and extending the fabric to an unconformed estate is a data re-architecture rather than a configuration. The namespace and placement opinions are HPE-proprietary; catalog-format portability is not authority. Ceded. #### Governance and compliance metadata *(universal)* **Score:** 2 · **Gap ownership:** structural · **DAPM:** Ceded Data Fabric performs classification, tagging, and policy-driven data mobility across the estate it manages, with Polaris maintaining governance consistency across distributed platforms and object storage adding automatic metadata tagging and policy enforcement for unstructured data. This is real governance metadata. It stops short of the function's defining requirement: the metadata has no workload awareness, so it cannot enforce placement of a workload against a compliance constraint. A new residency requirement can move or pin the data; it cannot derive where a workload runs. Governance also reaches the fabric-conformed estate rather than the full enterprise data estate, and for the migrating buyer who keeps existing storage it does not reach the workloads at all. Score 2 reflects genuine classification and propagation to data placement without workload-placement enforcement. Structural: closing the workload-awareness gap is the reasoning-plane problem, and extending governance to an unconformed estate is a data re-architecture. Ceded. #### Retrieval and context services *(ai-workload)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Ceded HPE AI Essentials, included with Private Cloud AI, ships a managed retrieval experience: automatic conversion of source data into embeddings, a managed vector database, automated embedding management and data synchronization, and configurable chunking and retrieval built on NVIDIA NIM microservices. This is platform-native managed retrieval in the base AI offering rather than a bare vector store. The gap from 4 is the on-premises, enterprise-operated ceiling: the enterprise configures and operates retrieval within the platform rather than consuming a fully managed service it never touches. Opinion: closing the gap is configuration within the acquired AI Essentials primitives, not a new capability. The managed retrieval opinions are HPE-proprietary; the underlying vector store is open-source and substitutable. Ceded. #### Data pipeline and lineage *(universal)* **Score:** 3 · **Gap ownership:** closeable · **DAPM:** Delegated HPE Ezmeral Unified Analytics delivers managed machine-learning and analytics pipelines through a curated open-source tool set, with connectors to common enterprise data sources, and Data Fabric adds event streaming and cross-engine lineage through the lakehouse catalog. Primary analytical and machine-learning data types are covered with lineage. The gap from 4 is the traditional and general estate: managed change-data-capture and movement from systems of record and mainframe sources is assembled rather than delivered as one named managed service, and enterprise-wide lineage across every type is partial. Closeable: covering the traditional-estate movement requires acquiring integration capability with its own lifecycle burden. The pipeline stack is curated open-source with real alternatives; lineage within the fabric is the proprietary component. Delegated. *Notes: FC-1 is scored on the vendor-recommended path, where HPE Data Fabric is the data layer, and it is the layer where the two audiences diverge. For the Fourth Cloud native building around that path, F1=3 and F4=3 are real strengths. For the buyer replacing an existing virtualization estate who keeps separate or competing storage, Data Fabric is not inherited by the migration and FC-1 reads as a structural gap. F2 is capped at 2 regardless of audience: the governance metadata has no workload awareness, so it cannot derive placement against a compliance constraint.* ### FC-2A · Orchestration — 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 HPE Morpheus provides one orchestration and governance surface across VMs, containers, bare metal, and multi-tier application stacks, with a unified catalog, per-business-unit quota, policy, and visibility. HPE's own runtimes cover the major workload types: VM Essentials for VMs, container runtimes for Kubernetes workloads, bare metal, and Private Cloud AI for AI. The consumer requests any workload type from one surface under one governance model. The gap from 4 is that Morpheus is a unifying orchestration plane rather than a single scheduler with shared pools: scheduling and resource pools live in the underlying runtimes, and GPU scheduling is held by the accelerator vendor. Whether one scheduler sits underneath is not visible to the consumer, who effectively receives workload universality. Structural: the delegated-scheduling model and the accelerator-vendor GPU dependency are inherent. The orchestration opinions are HPE-proprietary. Ceded. #### Resource lifecycle automation *(universal)* **Score:** 2 · **Gap ownership:** structural · **DAPM:** Ceded Morpheus and VM Essentials automate provisioning, scaling within capacity, high availability, live compute and storage migration, distributed placement, and blueprint-driven lifecycle. The automation operates within the capacity the enterprise already owns; the platform does not control the physical supply chain. Expandable capacity beyond owned hardware is achievable only through a vendor-managed consumption model, where the vendor pre-stages and operates buffer capacity. That is a managed control plane, structurally distinct from a platform the enterprise operates, and the instrument scores the capability the enterprise operates and sustains rather than the managed path. Score 2 reflects strong automated lifecycle within fixed capacity. Structural by definition: crossing into expandable capacity requires becoming a vendor-managed consumption model, which is outside what the platform itself provides. The lifecycle opinions are HPE-proprietary. Ceded. #### Policy and quota enforcement *(universal)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Ceded Policy and quota is core Morpheus capability: role-based access mapped from identity into fine-grained guardrails, a governance and policy engine, per-business-unit quotas, approval workflows, audit trails, and budget enforcement, all across the managed estate from one surface. The gap from 4 is that policy does not propagate automatically to every enforcement layer; network policy and in-cluster Kubernetes policy are configured separately in the underlying platforms. Opinion: the enterprise configures per-layer enforcement using existing Morpheus primitives, not a new capability. The policy opinions accumulate in HPE-proprietary formats. Ceded. #### Substrate lifecycle integration *(universal)* **Score:** 2 · **Gap ownership:** closeable · **DAPM:** Ceded VM Essentials integrates workload lifecycle with host maintenance for VM workloads: maintenance mode drains a host by live-migrating running VMs, high availability recovers workloads from host failure, and distributed placement rebalances. On the VMware path, Compute Ops Management feeds firmware into vSphere Lifecycle Manager. The gap is that firmware and workload maintenance are separate panes on HPE's own hypervisor: there is no automated path from a firmware event to workload draining, patching, and rejoin as one operation, and event-time integration between hardware failures and scheduling is not shipped. Score 2 reflects real maintenance-window integration without firmware-integrated or event-time coordination. Closeable: Compute Ops Management exposes health and event webhooks and VM Essentials exposes maintenance interfaces, so the coordination loop is buildable by the enterprise. Ceded. #### Accelerator and GPU management *(ai-workload)* **Score:** 2 · **Gap ownership:** structural · **DAPM:** Delegated VM Essentials provides GPU passthrough and GPU pooling, discovering host GPUs into an assignable pool, and Private Cloud AI adds multi-tenant GPU isolation and fractional and quota management through the accelerator vendor's software, with GPU observability through OpsRamp. The scheduling intelligence — fractional sharing, quota, and topology awareness — is held by the accelerator vendor rather than native to the control plane, and native vGPU in the management interface is not yet generally available. Score 2 reflects accelerator management through validated integration with scheduling owned by the accelerator vendor. Structural: the accelerator-vendor scheduling dependency is common to the on-premises model. The accelerator software is the de facto standard, substitutable in principle. Delegated. *Notes: FC-2A is the strongest layer alongside FC-2B. F1=3 because Morpheus delivers unified orchestration and governance across the major workload types, scored on the buyer outcome rather than whether one scheduler sits underneath. F2=2 is structural by definition: automated lifecycle within owned capacity, with expandable capacity reachable only through a vendor-managed consumption model the instrument does not score. F3=3 is a Morpheus strength; F4=2 and F5=2 reflect the separate firmware pane and the accelerator-vendor scheduling dependency.* ### FC-2B · Runtime — 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 HPE's own runtimes execute the major workload types: VM Essentials runs VMs natively with high availability and live migration, container runtimes execute Kubernetes workloads, bare metal is native, and Private Cloud AI executes AI workloads, all provisioned and managed through Morpheus. The gap from 4 is that these are separate execution surfaces under a shared management plane rather than one intent-declared surface, and the developer experience differs by type. The consumer nonetheless runs every major workload type on HPE runtimes through one management surface. Structural: the multi-surface runtime and the AI workload's separate interface are inherent to the composition. The runtime opinions are HPE-proprietary. Ceded. #### Persona abstraction at execution *(universal)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Ceded The persona-separation primitives are present and complete across the managed estate: developer intent through the self-service catalog, blueprints, and infrastructure-as-code; operator substrate visibility and override through the governance surface; and security audit through audit trails, role-based access, and approval gates. The catalog and blueprint model shields developers from substrate detail across VMs, containers, bare metal, and application stacks. The gap from 4 is that complete separation is not shipped as uniform defaults across every type, and the AI persona runs through the Private Cloud AI surface. Opinion: extending uniform abstraction uses existing Morpheus primitives. The self-service opinions accumulate in HPE-proprietary formats. Ceded. #### Execution lifecycle and observability *(universal)* **Score:** 3 · **Gap ownership:** mixed · **DAPM:** Ceded HPE OpsRamp ships a genuine cross-workload correlation layer: AI-driven event correlation across VMs, containers, GPU and AI infrastructure, applications, network, and storage in one pane, with automated remediation, and an operations copilot adding agent and large-language-model observability with token-consumption governance. Morpheus provides the execution lifecycle across types. The gap from 4 is that lifecycle and correlated observability are integrated products rather than one plane, and correlation across sources outside the HPE estate is configured. Mixed ownership: for buyers who adopt OpsRamp the extension is configuration; for buyers without it OpsRamp is a separate acquisition. The correlation intelligence is captive to HPE's operations service. Ceded. #### AI inference and agent execution *(ai-workload)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Ceded Private Cloud AI delivers platform-native inference in the base offering through NVIDIA NIM microservices, with a managed retrieval pipeline through AI Essentials, as a co-engineered turnkey AI runtime. The score rests on that generally available inference and retrieval. The gap from 4 is the on-premises managed ceiling, and the depth of agent execution: a unified model gateway for governed multi-model access and an agent toolkit for policy enforcement and behavior monitoring are recent or roadmap rather than long-established generally available capability. Opinion: the enterprise operates within the Private Cloud AI primitives to close the ceiling. The inference governance layer is HPE-proprietary; the underlying serving engines are the accelerator vendor's. Ceded. *Notes: FC-2B lands at the strong band across all four functions on generally available capability. F1=3 for native runtimes across the major workload types under one management plane; F2=3 for complete persona primitives; F3=3 for OpsRamp cross-workload correlation shipped as one layer; F4=3 for platform-native inference and managed retrieval, with the model gateway and agent-execution depth flagged as recent or roadmap rather than the basis for the score.* ### FC-2C · Reasoning — The Reasoning Plane *Autonomous, policy-driven placement for ALL workload types — derives placement from live FC-1 and FC-2A metadata without operator rule-writing.* #### Autonomous placement reasoning *(universal)* **Score:** 0 · **Gap ownership:** structural · **DAPM:** Retained Applying the integration-versus-coexistence test: no HPE component derives placement by consuming live data-governance metadata simultaneously with capacity and topology state. Morpheus distributed placement schedules VMs on capacity and topology within a cluster, the policy engine executes operator-written rules, and the agentic operations layer — spanning the operations copilot, agent registry, and telemetry correlation — performs IT-operations automation and root-cause analysis with a human in the loop. Routing and capacity-based scheduling are not reasoning. Applying the workload-universality test: the only autonomous placement is VM-scoped within a cluster. Documented cross-constraint flow: when a new residency requirement arrives, Data Fabric can move or pin the data against it, but an operator must hand-write the workload placement policy; the system does not derive where the workload runs from the constraint. Score 0. HPE holds both prerequisites internally, a strong metadata fabric and its own scheduler, so an eventual reasoning plane would face a low wiring cost, but the derivation engine does not exist and no product with a confirmed timeline closes it. Structural. The enterprise owns the function because nobody provides it. Retained. *Notes: FC-2C is absent, as it is across the on-premises category. What distinguishes HPE is that both prerequisites sit inside the boundary: a strong metadata fabric at FC-1 and a scheduler HPE owns at FC-2A. The gap is the derivation engine that would consume the metadata to place workloads, not the plumbing to feed it, but that engine does not exist and no product with a confirmed timeline addresses it.* ### FC-3 · Catalog — 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 Morpheus provides a governed self-service catalog for VMs, containers, bare metal, application services, and multi-tier application stacks, with governance at publication through authored and validated blueprints and at consumption through role-based access and approval gates. These are application-topology templates rather than a bare deployment mechanism. The gap from 4 is that catalog depth for traditional enterprise middleware is narrower than for containerized and application-stack workloads, short of a uniform native catalog across every type. Opinion: additional application types are configured with existing blueprint primitives. The blueprint opinions are HPE-proprietary. Ceded. #### Application lifecycle governance *(universal)* **Score:** 2 · **Gap ownership:** mixed · **DAPM:** Ceded Morpheus governs the application lifecycle from one surface: blueprint versioning, approval-gated publication and consumption, role-based access, audit trails, policy enforcement, and budget policy across the managed estate. The gap is that the governance surface sits over an estate whose identity plane is federated rather than continuous: Morpheus carries its own role model, and per-runtime identity persists, so a unified audit across every application type still requires bridging identity contexts. Score 2 reflects genuine per-scope lifecycle governance without one continuous identity plane backing a unified audit. Mixed ownership: for buyers who federate everything through the workspace identity provider the bridging is configuration; where cross-runtime identity bridging is required it is closeable. The governance opinions are HPE-proprietary. Ceded. #### Developer experience and self-service *(universal)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Ceded Developer self-service is strong: catalog discovery, parameter configuration within guardrails, deployment without operator intervention, and policy-enforced approval gates, extended by a Terraform provider, REST interfaces, a browser cloud shell, and developer project workspaces with continuous integration. The gap from 4 is per-type interface variance across VM, container, and AI self-service, a within-band quality gap rather than a drop. Opinion: consistent entry points are configured with existing primitives. The self-service opinions are HPE-proprietary. Ceded. #### AI application and agent distribution *(ai-workload)* **Score:** 2 · **Gap ownership:** vendor-roadmap · **DAPM:** Ceded Private Cloud AI provides native AI distribution: one-click-deploy AI applications and a role-based model catalog. The AI-specific governance that would distinguish a stronger score — agent tool authorization, model-version enforcement, and output audit — is announced for delivery later in the year through the accelerator vendor's agent toolkit and HPE's agent registration, rather than generally available today. Score 2 reflects native AI distribution without shipped AI-specific governance. Vendor roadmap: specific products with a confirmed timeline are announced to close the gap. The distribution and governance opinions are HPE-proprietary. Ceded. *Notes: FC-3 is a Morpheus strength at F1 and F3. F2=2 because the governance surface sits over a federated, not continuous, identity plane, so a unified audit across every application type still requires bridging identity contexts. F4=2 on generally available AI distribution without shipped AI-specific governance, which is announced for delivery later in the year.* ### FC-4 · Integration — 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:** 1 · **Gap ownership:** closeable · **DAPM:** Delegated On the recommended path, HPE Data Fabric includes a Kafka-compatible event store with topics, consumer-group fan-out, offset replay, global replication, and multi-tenancy. It is a data-plane streaming component of a self-operated data platform positioned for data pipelines rather than an operated enterprise application event fabric with schema-registry enforcement, dead-letter handling, and identity propagation across integrations. The platform's own event catalog carries only HPE platform audit and subscription events, not a customer event bus. Score 1 reflects a real streaming engine short of an operated application event fabric. Closeable: a full enterprise event fabric is a separate platform acquisition. The engine is Kafka-compatible with real alternatives. Delegated. #### API management and gateway *(universal)* **Score:** 0 · **Gap ownership:** closeable · **DAPM:** Retained There is no capability for managing the customer's own APIs, and several adjacent things get mistaken for it. The platform's own API gateway registers a client application to call HPE's platform interfaces, which is access to HPE's APIs, not lifecycle management of the customer's. Morpheus provides a workload-orchestration gateway, a common interface to deploy, manage, and orchestrate diverse workloads across hypervisors and clouds, which governs the deployment of workloads rather than the publication and lifecycle of the APIs those workloads expose. And data services are a different surface again: a shared embedding or vector service and a shared database platform are retrieval and data capabilities, scored at FC-1 and in the orchestration and catalog layers, not API management. The function asks for API lifecycle itself: publishing and versioning the customer's own endpoints, rate limiting, transformation, a developer portal, API-level audit, and the software-defined controls an application team wraps around its endpoints and its delivery pipeline. Deploying an inference endpoint is a workload action; lifecycling that endpoint as a managed, versioned, governed API is the surface that is absent. Score 0. Closeable through acquiring an API-management platform. The enterprise owns the function because nobody provides it. Retained. #### Workflow and process orchestration *(universal)* **Score:** 1 · **Gap ownership:** closeable · **DAPM:** Retained Morpheus provides genuine IT and infrastructure automation: a task and workflow library, Terraform and Ansible orchestration, provisioning pipelines, and a natural-language orchestration copilot. This is infrastructure automation rather than business-process orchestration; there is no long-running-transaction engine, no saga or compensation, and no business-process modeling. Score 1 reflects basic workflow automation for operational tasks. Closeable: business-process orchestration requires separate tooling. The enterprise owns the business-process function. Retained. #### SaaS and enterprise system integration *(universal)* **Score:** 0 · **Gap ownership:** closeable · **DAPM:** Retained Morpheus advertises a large integration library, but its integrations are infrastructure and IT-service-management tools: hypervisors, clouds, infrastructure-as-code engines, service-management and configuration-management systems, backup, and identity providers. There are no maintained managed connectors to systems of record: no enterprise resource planning, customer relationship management, human capital management, or mainframe integration as a managed service. The service-management tie is IT-service-management, not a system-of-record data connector. Score 0, the most operationally expensive function to own when absent. Closeable through acquiring an integration platform. The enterprise owns the function. Retained. #### AI-native integration *(ai-workload)* **Score:** 1 · **Gap ownership:** vendor-roadmap · **DAPM:** Delegated Generally available today is basic AI interface connectivity: inference endpoints and retrieval reachable and governed by role-based access. The managed AI-integration fabric is roadmap rather than shipped: a unified model gateway for model interface federation is recent and unverified as delivered, the data fabric's tool-connection support for agentic workflows is dated later in the year, and agent governance through the accelerator vendor's toolkit and an agent registry is announced for later delivery. There is no generally available managed tool-connection gateway, agent-to-agent identity propagation, or semantic routing. Score 1 reflects basic AI connectivity below a managed AI-integration fabric. Vendor roadmap: specific products with a confirmed timeline are announced. The connectivity rests on the accelerator vendor's interfaces. Delegated. *Notes: FC-4 is HPE's gap portfolio. F2 and F4 are 0: no customer API management, no maintained system-of-record connectors. F1=1 and F3=1 are the only partial credit, a Kafka-compatible event store within Data Fabric and IT-automation workflow within Morpheus, both short of an operated application event fabric and business-process orchestration. F5=1 on generally available basic AI connectivity, with the managed AI-integration fabric announced for later delivery.* --- # SUSE Rancher Prime — Fourth Cloud Assessment *Fourth Cloud Control Plane Assessment — SUSE Vendor Boundary* **Version:** v1.1 **Date:** July 28, 2026 **Status:** complete **Evolution model:** continuous **Source:** SUSE Rancher Prime v2.14 product documentation and support terms, SUSE Rancher Suite packaging, KubeCon + CloudNativeCon Europe 2026 announcements (Liz agent crew GA, embedded MCP server GA, Virtual Cluster GPU multi-tenancy GA via K3k, NVIDIA MIG vGPU GA, VM Auto Balancing early access, Longhorn v2 tech preview), SUSECON 2026 coverage, SUSE Virtualization (Harvester) v1.7 release notes and hardware requirements, SUSE Edge 3.3 documentation (Metal3/Cluster API/Elemental), SUSE AI 1.0 documentation (AI Library, deployment, observability), SUSE Observability documentation (Rancher Prime entitlement), SUSE Application Collection documentation (subscriptions, reference guides), K3k product documentation v1.1.0, NeuVector/SUSE Security Rancher SSO documentation, Rancher OIDC provider documentation, Fourth Cloud methodology v2.4, SUSE vendor feedback via review workbook (July 28, 2026 — naming and narrative corrections, support-scope and guest-VM observability clarifications; no scores moved), SUSE AI Factory with NVIDIA GA announcement (July 9, 2026), AMD/SUSE initial validation blog (2026) ## Summary Finding SUSE Rancher Prime is a multi-cluster Kubernetes control plane whose defining characteristic is estate-wide reach: one management plane federating identity, RBAC, policy, and GitOps across on-premises, cloud, and edge clusters — including managed cloud Kubernetes the enterprise already runs — with VMs joining through SUSE Virtualization. Scope: the SUSE vendor boundary — the SUSE Rancher Prime base subscription plus Suite-tier components, the SUSE AI Factory subscription, and SUSE Edge, each named inline where it carries a score; capabilities requiring a different vendor remain Closeable gaps. The gap portfolio is Opinion-dominant in the platform core and Closeable-dominant at the edges. Across orchestration, runtime, and catalog, the primitives are included and the enterprise applies them — configuration, not acquisition. At the data and integration layers the shape inverts: SUSE has no data estate and no integration products, and the SUSE Application Collection's supported artifacts set floors — messaging components, an API gateway — without delivering managed capabilities. FC-2C is absent and Structural, as it is across the on-premises category. Delivery model: self-managed software on customer-owned hardware; hosted offerings cover management planes only, which anchors resource lifecycle automation at the on-premises position. The authority finding is this row's distinctive profile. Delegated dominates the DAPM column because the stack is open source with real exits — RKE2, K3s, KubeVirt, Fleet, K3k, NeuVector — so the operational opinions an enterprise accumulates on this platform are unusually portable. The exceptions: SUSE Observability, whose correlation configurations are proprietary and captive, and the NVIDIA-held GPU management layers. Identity plane continuity is federated through SUSE Rancher Prime itself as the broker: orchestration, execution across both VMs and containers, and catalog consumption are governed by one federated enterprise identity across every managed cluster. Substrate, data, reasoning, and integration layers sit outside the plane — substrate-to-runtime identity enforcement is operator-built configuration, and data governance identity awaits a data estate that does not exist in the portfolio. The agentic layer deserves precise placement. The Liz agent crew and the MCP servers embedded in SUSE Rancher Prime and SUSE Multi-Linux Manager (both GA) constitute a developed operations-tier agentic surface: agents that consume live estate topology and act on infrastructure through governed interfaces with human approval. That is operations assistance, not a reasoning plane — no component derives placement from governance metadata, and the FC-1 metadata a reasoning plane would consume does not exist in the estate. Universal Proxy, in tech preview, is the named path for AI-native integration governance and is not scored. The buyer's trade: a broad, open, low-lock-in control plane with a shipped observability platform in the base subscription — in exchange for owning the data fabric and the integration fabric entirely, and accepting component-grade rather than product-grade depth in AI governance and API lifecycle. The assembly burden sits at the edges, not the core. v1.1 records the SUSE vendor review (workbook returned July 28, 2026). No scores moved. Changes: product naming aligned (SUSE AI Factory, SUSE Application Collection, SUSE Rancher Prime); AI Library support scope documented as two labeled tiers (SUSE-built: installation through code fix; SUSE-supported community: installation and configuration, upstream code fixes); SUSE AI Factory with NVIDIA (generally available July 2026) recorded as the in-boundary NVIDIA AI Enterprise path at accelerator management; SUSE Telco Cloud added alongside SUSE Edge for bare-metal lifecycle; SUSE Storage named as the substrate-tier persistence anchor in the FC-1 note; AMD accelerator support recorded as initial validation, not scored. Two vendor requests were declined under instrument rules: crediting hardware partnerships against the resource-lifecycle delivery model, and crediting a partner ecosystem against the integration fabric — the composition boundary holds. ## Scoping note This assessment scores SUSE Rancher Prime v2.14 using the SUSE vendor support boundary as the scope line. The base SUSE Rancher Prime subscription (Rancher Manager, RKE2/K3s with up to five-year lifecycle support, Fleet GitOps, Cluster API, SUSE Application Collection Prime tier, Prime OCI registry, SUSE Observability entitlement, the Liz agent crew and embedded MCP server) is scored as included. SUSE-licensed add-ons are in scope and named inline where they carry a score: the SUSE Rancher Suite tier (SUSE Security, SUSE Private Registry, SUSE Virtualization with SUSE Storage, FIPS content, NVIDIA MIG sharing), the SUSE AI Factory subscription (AI Library: vLLM, Ollama, Open WebUI, Milvus, Qdrant, LiteLLM, mcpo, PyTorch, MLflow, Kubeflow), SUSE Edge (Metal3/Cluster API bare-metal lifecycle, Elemental onboarding), Kubewarden (certified Rancher project, add-on subscription), and Rancher Developer Access (separately purchased). Capabilities requiring a different vendor remain Closeable gaps. Two support-boundary facts inform scoring throughout. First, delivery model: SUSE sells self-managed software on customer-owned hardware; SUSE Rancher Prime Hosted and SUSE Observability Hosted Prime host management planes only — there is no managed hardware consumption offering, which anchors FC-2A F2. Second, support tiers within the boundary: SUSE Application Collection applications carry artifact-level guarantees (signatures, SBOM/VEX, SLSA Level 3 provenance, validation against RKE2) rather than documented production-runtime support, and the SUSE AI Factory AI Library carries two labeled support tiers (vendor-confirmed, July 2026 review): SUSE-built applications are supported by SUSE from installation through configuration to code fix, while SUSE-supported community applications receive installation and configuration support with code fixes flowing through the upstream community into the next release. Registry applications are mirrored upstream projects with SUSE supply-chain attestation. Functions scored on these paths carry those distinctions in their narratives. Universal Proxy (centralized MCP endpoint governance) is tech preview and not scored, per the New Capability Rule. ## Identity Plane Continuity **Score:** 3 **Classification:** federated **Gap ownership:** mixed **Layers in plane:** fc2a, fc2b, fc3 **Layers siloed:** fc0, fc1, fc2c, fc4 SUSE Rancher Prime is itself the federation broker, with Rancher Manager as the broker component. Enterprise identity providers — Active Directory, LDAP, SAML 2.0, OIDC, Okta with SCIM automated provisioning and deprovisioning — federate once into Rancher, and Rancher enforces that identity as RBAC across every managed cluster, including imported EKS, AKS, and GKE clusters. FC-2A: cluster, project, and namespace authority is governed estate-wide by the federated identity, natively. FC-2B: namespace execution is governed by propagated RBAC for both containers and VMs — SUSE Virtualization in Rancher-managed mode uses Rancher authentication, so both workload types sit in one identity plane. FC-3: catalog consumption through Rancher Apps & Marketplace is governed by the same identity; SUSE Application Collection registry access uses SUSE Customer Center accounts and service accounts, a seam at the artifact-consumption edge. The product extensions ride the same broker: SUSE Security (Suite tier) has native Rancher single sign-on with role mapping to its permission model; SUSE Observability and Open WebUI (SUSE AI Factory) join through Rancher acting as an OIDC identity provider — documented configuration of included capability, an Opinion gap. Outside the plane: FC-0 substrate identity does not gate workload execution without operator-built node label, affinity, and admission-policy bridges (Opinion, included primitives); FC-1 data governance identity has no data estate to attach to (Closeable); FC-2C is absent; FC-4 has no integration fabric to propagate identity through — SUSE Application Collection integration artifacts carry their own authentication, and the embedded MCP server governs platform operations, not application integration. **Buyer implication:** Can FC-0 identity control FC-2B runtime execution? Not natively — substrate identity influences what runs where only through operator-configured node labels, affinity rules, and admission policies, built from included primitives. What the enterprise does get: one federated identity governs what a person can orchestrate (FC-2A), what executes in their namespaces across both VMs and containers (FC-2B), and what they consume from the catalog (FC-3) — uniformly across on-premises, hosted-cloud, and edge clusters, including managed cloud Kubernetes the enterprise already runs — without building identity bridges between the layers the plane covers. The cost of the siloed layers: substrate-to-runtime enforcement is operator-maintained configuration, and data governance identity requires acquiring a data governance platform first. ## Layer-by-layer scoring | Layer | Avg score | Status | |---|---|---| | FC-0 · Substrate — Physical & Virtual Substrate | 2.33 | Moderate | | FC-1 · Context — Distributed Data & Context Fabric | 2.00 | Moderate | | FC-2A · Orchestration — Infrastructure Orchestration | 2.60 | Moderate | | FC-2B · Runtime — Execution & Runtime | 3.00 | Strong | | FC-2C · Reasoning — The Reasoning Plane | 0.00 | Absent | | FC-3 · Catalog — Application Distribution and Governance | 2.75 | Moderate | | FC-4 · Integration — Integration Fabric | 1.00 | Gap | **DAPM profile:** Retained 9 · Delegated 16 · Ceded 1 ### FC-0 · Substrate — Physical & Virtual Substrate *The physical foundation the control plane lifecycles.* #### Hardware lifecycle management *(universal)* **Score:** 2 · **Gap ownership:** closeable · **DAPM:** Delegated Included: Rancher lifecycles Kubernetes clusters and nodes through Cluster API. SUSE Rancher Suite tier (SUSE Virtualization): cluster upgrades move the SUSE Linux Micro node OS, the hypervisor stack, and storage as one orchestrated operation, with per-node pause-and-resume upgrade control — node OS lifecycle is genuinely integrated with workload management. SUSE Edge and SUSE Telco Cloud (separate SUSE product lines): Metal3 and Cluster API provide bare-metal lifecycle over Redfish BMC protocols — automated inspection, cleaning, provisioning, and deprovisioning — and Elemental provides node onboarding and OS lifecycle for edge estates. The boundary of the capability: no SUSE product manages firmware, BIOS, or BMC lifecycle. SUSE Multi-Linux Manager patches Linux estates but does not push firmware. OEM firmware tooling remains a separate management surface the enterprise operates alongside the platform. Closeable — firmware lifecycle automation requires acquiring and operating OEM or third-party tooling outside the SUSE boundary. #### Substrate heterogeneity *(universal)* **Score:** 2 · **Gap ownership:** structural · **DAPM:** Retained SUSE Rancher Suite tier (SUSE Virtualization): runs on commodity x86_64 and ARM64 servers, with YES certification recommended rather than a strict component-combination compatibility list — enterprises can generally bring existing OEM estate hardware rather than purchasing certified node configurations. The hypervisor layer provides unified virtualization primitives across heterogeneous OEM hardware. Accelerators: NVIDIA vGPU and Multi-Instance GPU (MIG) support with automatic detection and hardware-isolated partitioning (MIG at the Suite tier; NVIDIA vGPU licensing is a separate NVIDIA relationship), and PCI passthrough for other devices. Gap from 3: accelerator management covers a single vendor family (NVIDIA), and OEM hardware management depth — firmware, out-of-band health — remains OEM-tool-specific beneath the unified virtualization layer. Bare-metal RKE2 with GPU operators is also a supported deployment shape for accelerated workloads — heterogeneity management is not bound to the hypervisor path alone. AMD accelerator support is in initial validation: AMD and SUSE began testing AMD inference microservices and enterprise blueprints on AMD Instinct MI350P in 2026. A validation effort is not a shipped product, so the productized accelerator path remains a single vendor family today. Structural — accelerator ecosystem breadth is an architectural scope constraint; this cell re-scores when a multi-vendor accelerator product reaches general availability. #### Substrate portability *(universal)* **Score:** 3 · **Gap ownership:** structural · **DAPM:** Delegated Included: one Rancher management plane manages RKE2 and K3s clusters on-premises (SUSE Virtualization, bare metal), in cloud (RKE2 on cloud instances, plus imported EKS, AKS, and GKE under the same authentication, policy, and GitOps surface), and at edge (K3s, SUSE Edge) — the multi-cluster estate is one management boundary rather than per-substrate silos. The workload cluster stack runs across all substrate types without architectural change. Bounds stated honestly: SUSE Virtualization itself is on-premises only — VM workload portability is bounded to the on-premises estate, and cross-substrate portability lives at the Kubernetes layer. Gap from 4: the 4 anchor is reserved for cloud-native platforms where the hyperscaler is the substrate. Structural. *Notes: FC-0 F1=2: node OS lifecycle is integrated (SUSE Virtualization one-operation upgrades, SUSE Edge Metal3/Elemental bare-metal lifecycle) but no SUSE product touches firmware — and unlike vendors with in-boundary firmware automation paths, there is none to name inline. F2=2: broad commodity hardware entry through hypervisor abstraction, single accelerator family. F3=3 is the layer's strength: one management plane across on-premises, cloud, and edge, including foreign managed-Kubernetes clusters.* ### FC-1 · Context — 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: SUSE Observability (250-node HA entitlement in the SUSE Rancher Prime subscription) provides programmatic, queryable topology and telemetry across the multi-cluster estate — clusters, workloads, and dependencies correlated in one model. SUSE Storage (Suite tier) exposes volume topology. This is infrastructure and storage awareness, not data awareness: no component knows what data a persistent volume contains or what regulatory classification applies to it, and there is no data catalog anywhere in the SUSE portfolio — no vendor data services estate exists to anchor one. A placement query asking where regulated data lives and whether a workload may access it from a given cluster cannot be answered by the platform. Closeable through third-party data catalog acquisition — a new vendor relationship and integration surface the enterprise owns. #### Governance and compliance metadata *(universal)* **Score:** 2 · **Gap ownership:** closeable · **DAPM:** Retained SUSE Rancher Suite tier (SUSE Security): admission control, runtime enforcement, network microsegmentation, and compliance scanning against CIS, PCI DSS, NIST, and HIPAA frameworks at the infrastructure and Kubernetes workload level — and network-layer data loss prevention that inspects payloads in flight, a genuine data-adjacent enforcement capability. Kubewarden (certified Rancher project, add-on subscription) adds policy-as-code admission control. These governance capabilities propagate to workload admission and runtime enforcement. The boundary: none of it classifies or governs enterprise data — database records, files by sensitivity, SaaS system data — and no compliance metadata propagates to placement enforcement. Score 2 reflects genuine workload and infrastructure governance bounded at the data line. Closeable through data governance platform acquisition. #### Retrieval and context services *(ai-workload)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Delegated SUSE AI Factory subscription required: purpose-built vector databases — Milvus and Qdrant — ship in the base SUSE AI Factory offering as AI Library applications, with out-of-the-box observability wiring into SUSE Observability, alongside vLLM and Ollama model serving and Open WebUI pipelines for retrieval-augmented patterns. One SUSE vendor relationship, no SI gate. Provenance stated precisely: AI Library registry applications are mirrored upstream projects with SUSE supply-chain attestation, supported at the product level within the SUSE AI Factory subscription — vendor-delivered open source with per-application support labels: SUSE-built applications are supported from installation through configuration to code fix, and SUSE-supported community applications receive installation and configuration support with code fixes flowing through upstream into the next release (vendor-confirmed, July 2026). Pre-validated blueprints — retrieval-augmented generation and inference-endpoint stacks assembled from SUSE Application Collection applications and AI components, in SUSE-curated and NVIDIA AI Enterprise variants — provide vetted starting assemblies. Gap from 4: this is not a managed RAG pipeline service — the enterprise deploys from AI Library and operates the retrieval stack itself. Opinion — applying what the subscription already contains, no new capability acquisition. #### Data pipeline and lineage *(universal)* **Score:** 2 · **Gap ownership:** closeable · **DAPM:** Delegated SUSE AI Factory subscription required: MLflow and Kubeflow ship as AI Library applications — ML pipeline orchestration and experiment/artifact lineage for AI workloads, vendor-delivered and product-supported. For traditional data: SUSE Application Collection carries Apache Kafka as an attested, validated artifact — deployable within the SUSE boundary with artifact-level support — but an artifact is not a managed pipeline service, and this function requires managed pipeline capability: no SUSE product provides ETL, change data capture, streaming pipeline management, or enterprise data lineage. The profile is exactly the gradient's middle: ML pipelines present through the SUSE AI Factory subscription, traditional pipeline capability absent. Closeable — estate-scale pipeline and lineage capability requires platform acquisition outside the boundary. *Notes: FC-1 reflects a Kubernetes-platform vendor's profile, not a data-platform vendor's: SUSE has no data services estate — no managed database or higher-order data-services products. The substrate exception is SUSE Storage (Longhorn), a shipped, generally available distributed block and replicated-storage layer anchoring persistent data at the platform tier; location awareness and governance metadata above that layer have nothing to anchor to. The layer's strength is AI-scoped: purpose-built vector databases and ML pipeline tooling delivered inside the SUSE AI Factory subscription. The estate-scale data functions are Closeable acquisitions.* ### FC-2A · Orchestration — Infrastructure Orchestration *Unified orchestration of the full enterprise workload portfolio.* #### Workload universality *(universal)* **Score:** 3 · **Gap ownership:** structural · **DAPM:** Delegated Included: containers orchestrated natively across the estate — RKE2 and K3s clusters plus imported EKS, AKS, and GKE under one Rancher plane with shared authentication, RBAC, and projects. SUSE Rancher Suite tier (SUSE Virtualization): VMs join through unified VM-and-container management in a single Rancher pane. Batch runs as Kubernetes Jobs; AI workloads run as Kubernetes workloads (SUSE AI Factory on RKE2). The architecture is federated — VMs execute on HCI clusters, containers on workload clusters, often provisioned as guest clusters sharing the same HCI capacity pool — with management unified above. No managed database service exists in the portfolio; databases run as workloads the enterprise operates. Gap from 4: shared pools and quota do not span workload types as a single scheduler, and GPU scheduling intelligence is partly held by the accelerator vendor. Structural — single-scheduler workload universality is not productized on-premises. #### Resource lifecycle automation *(universal)* **Score:** 2 · **Gap ownership:** structural · **DAPM:** Retained Included: automated lifecycle within fixed capacity — Cluster API node provisioning, Rancher auto-provisioning RKE2 nodes as SUSE Virtualization VMs (genuinely elastic within the HCI pool), cluster autoscaler on cloud substrate, SUSE Storage replica management. VM Auto Balancing (utilization-based VM redistribution) is early access and not scored. Delivery model, which is part of this score: SUSE sells self-managed software on customer-owned hardware. SUSE Rancher Prime Hosted and SUSE Observability Hosted Prime host management planes only — there is no managed hardware consumption offering with pre-staged capacity. On-premises capacity is bounded by owned physical nodes; the physical supply chain remains outside the platform's control. Structural — the on-premises operating model constraint. #### Policy and quota enforcement *(universal)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Retained Included: estate-wide RBAC — one authentication and role surface enforced across every managed cluster, including imported EKS, AKS, and GKE clusters, so policy authority extends across control planes the enterprise does not host. Projects apply resource quotas across namespaces; Fleet distributes policy and configuration declaratively at fleet scale with drift detection. Kubewarden (certified Rancher project, add-on subscription): policy-as-code admission control with a policy library. SUSE Rancher Suite tier (SUSE Security): admission and runtime security enforcement. Gap from 4: enforcement layers — admission, network, runtime — are configured per layer from included primitives rather than propagating from a single policy engine. Opinion — the enterprise configures consistent enforcement using what the subscription contains. #### Substrate lifecycle integration *(universal)* **Score:** 2 · **Gap ownership:** closeable · **DAPM:** Delegated SUSE Rancher Suite tier (SUSE Virtualization): maintenance mode live-migrates VMs before node maintenance; integrated upgrades move node OS, hypervisor, and storage as one orchestrated operation with per-node pause-and-resume control; Kubernetes node health drives workload rescheduling; SUSE Storage rebuilds replicas on node failure. Gap from 3: no hardware-event layer — out-of-band hardware health telemetry (IPMI, Redfish) does not feed scheduling or update decisions during operations. SUSE Edge's Metal3 inspection is provisioning-time, not operational. Firmware lifecycle sits entirely outside the platform (see FC-0 F1). Planned maintenance evacuates workloads correctly; what is missing is the substrate health signal informing the control plane's decisions. Closeable — hardware-event integration requires acquiring and integrating OEM management tooling. #### Accelerator and GPU management *(ai-workload)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Delegated SUSE Rancher Suite tier: NVIDIA vGPU and Multi-Instance GPU (MIG) support on SUSE Virtualization with automatic detection and hardware-isolated partitioning (NVIDIA vGPU capability is also delivered in-boundary through SUSE AI Factory with NVIDIA, which embeds NVIDIA AI Enterprise into the SUSE offering, generally available July 2026, with NVIDIA AI Enterprise certification extending to SUSE Linux Enterprise Server; standalone NVIDIA vGPU licensing otherwise remains a separate NVIDIA relationship). Included in SUSE Rancher Prime: NVIDIA GPU Operator validated on RKE2, backed by RKE2's CNCF Kubernetes AI Conformance certification — independently validated GPU device plugin integration, gang scheduling, and high-performance networking — and Virtual Cluster GPU multi-tenancy via K3k (GA): isolated Kubernetes control planes on shared GPU infrastructure in shared GPU mode, with per-virtual-cluster GPU usage restriction as the documented quota mechanism. The platform provides hardware-enforced partitioning plus a shipped multi-tenancy and quota layer. Gap from 4: scheduling intelligence — topology-aware placement, fair-share queueing — remains with NVIDIA components or enterprise-applied upstream tooling rather than native platform scheduling. Opinion — advanced patterns are configured from validated primitives already in the boundary. *Notes: FC-2A F1=3 on the federated-planes-unified-management pattern, with the distinctive reach that policy and RBAC extend to imported managed-cloud clusters. F2=2 per the delivery-model rule: self-managed software, no managed consumption offering; elasticity within the HCI pool is real but bounded by owned hardware. F4=2 is the layer's honest gap: maintenance orchestration is strong but no out-of-band hardware health signal informs the control plane. F5=3: hardware partitioning (MIG/vGPU) plus K3k virtual-cluster GPU multi-tenancy as the shipped quota layer.* ### FC-2B · Runtime — Execution & Runtime *The execution plane where workloads actually run.* #### Runtime universality *(universal)* **Score:** 3 · **Gap ownership:** structural · **DAPM:** Delegated Included: containers execute across the RKE2/K3s estate; batch runs as Kubernetes Jobs. SUSE Rancher Suite tier (SUSE Virtualization): VMs execute as KubeVirt custom resources — kubectl-manageable, Kubernetes-native API surface. SUSE AI Factory subscription: AI inference runs as Kubernetes workloads with OpenAI-compatible endpoints. Every workload type speaks the Kubernetes API — the developer toolchain is consistent in kind across the portfolio. The structural shape: workload types execute in separate cluster domains — HCI clusters for VMs, workload clusters for containers, often as guest clusters on the same HCI capacity — unified at the Rancher management layer rather than sharing one cluster boundary. Gap from 4: a single execution surface spanning all workload types in one namespace and scheduler is not productized on-premises. Structural. #### Persona abstraction at execution *(universal)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Retained Platform-gap versus opinion-gap, stated explicitly: the primitives exist and are complete; the shipped opinion covers some workload types. Included primitives: Rancher projects and RBAC separate developer and operator personas across the estate; K3k virtual clusters give developers an entire isolated Kubernetes control plane while operators retain the substrate — control-plane-grain persona separation, a stronger isolation unit than namespace scoping; Fleet separates application-team GitOps from infrastructure configuration. SUSE Rancher Suite tier: SUSE Virtualization VM templates and instance types abstract substrate details when operators pre-configure them; SUSE Security provides the security-audit persona surface at runtime, and SUSE Observability (included) provides estate-wide operator visibility. The opinion gap: turnkey separation is shipped for container workloads through the Rancher UI and project model; VM workloads expose more network and storage substrate to developers unless operators pre-configure templates. Opinion — configuration of existing primitives, no acquisition. #### Execution lifecycle and observability *(universal)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Ceded Two components scored together, per the function definition. Telemetry exposure: standard formats across the estate — Prometheus, OpenTelemetry, OTLP — including out-of-the-box OpenTelemetry instrumentation for SUSE AI Factory components (Ollama, Open WebUI, Milvus). Correlation layer: shipped in the base subscription — SUSE Observability (250-node HA entitlement with SUSE Rancher Prime) is a dedicated topology-correlation platform, correlating topology, telemetry, and traces across the multi-cluster estate in one model, with an AI agent surface over it. Buyer situation, per the function's discipline: for buyers without an observability platform, the correlation layer is included rather than a separate acquisition; for buyers with one, standard-format telemetry integrates as configuration. Gap from 4: correlation across VM guest interiors and AI surfaces requires configuration and agents, and the enterprise operates the observability platform itself — it is software in the subscription, not a managed service. Opinion. #### AI inference and agent execution *(ai-workload)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Delegated SUSE AI Factory subscription required: model serving is platform-native in the base offering — vLLM and Ollama from AI Library, Open WebUI as the serving front end, LiteLLM as the model-API proxy layer (API keys, multi-provider routing, cost tracking), mcpo for MCP-to-OpenAPI bridging, MLflow for model lifecycle, and out-of-the-box AI observability into SUSE Observability. Universal Proxy — centralized MCP endpoint governance — is tech preview and not scored. Gap from 4, and the within-band character stated plainly: governance depth (token quotas, showback, gateway policy) comes from applying LiteLLM, a mirrored-upstream component inside the supported stack, rather than from a shipped governance product; inference auto-scaling is Kubernetes-native (HPA/KEDA) rather than serverless. Opinion — the components are in the subscription; the enterprise configures the governance depth it needs. *Notes: FC-2B scores 3 across all four functions. The layer's distinctive included capability is the shipped correlation layer: a dedicated topology-correlation observability platform in the base control-plane subscription, which removes an acquisition burden for buyers without an existing observability estate — at the cost that its accumulated correlation opinions are proprietary (the row's single Ceded cell). AI serving is component-grade: real capability assembled from vendor-delivered open source, with productized governance depth as the visible difference from a managed inference service.* ### FC-2C · Reasoning — The Reasoning Plane *Autonomous, policy-driven placement deriving from live data governance metadata.* #### Autonomous placement reasoning *(universal)* **Score:** 0 · **Gap ownership:** structural · **DAPM:** Retained What exists: Kubernetes scheduler primitives (affinity, taints and tolerations), Fleet's cluster-label targeting for GitOps placement at fleet scale, Kubewarden admission policies, SUSE Virtualization VM scheduling (VM Auto Balancing, early access, is utilization rebalancing, not policy reasoning). The Liz agent crew (GA) correlates live estate signals and executes operations through governed MCP interfaces with human approval. Applying the derivation test to a concrete scenario — a new GDPR residency requirement arrives: the constraint enters through a human, because no data-classification plane exists to receive it programmatically (see FC-1); the operator translates it into Fleet cluster selectors, Kubewarden admission policies, and network segmentation rules; the platform dispatches those rules exactly as written. Liz can assist — draft the policy, audit drift, correlate violations — but with human approval, as operator tooling. The constraint-to-rule translation remains the operator's job. This is rule dispatch executed well, not derivation. The agentic layer is genuine scaffolding at the operations tier — agents consuming live topology and acting on infrastructure through governed interfaces — but operations assistance is not placement reasoning, and the gap is doubly structural: the reasoning plane is absent, and the FC-1 governance metadata it would consume is also absent. Structural — no product with a confirmed timeline addresses placement derivation from governance metadata. *Notes: FC-2C is absent. The platform's agentic surface — the Liz agent crew and embedded MCP servers — is a developed operations-tier capability and should not be mistaken for a reasoning plane: agents assist operators who retain the constraint-to-rule translation. If a future release grants agents placement authority without human approval, or a data-governance metadata source enters the portfolio, this cell is the first to re-examine.* ### FC-3 · Catalog — 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:** Delegated Included: a supply-chain-first catalog. SUSE Application Collection (Prime tier, approximately 141 applications) delivers curated applications as coherent units — base image, runtime, application, Helm chart — with signatures, SBOM/VEX, SLSA Level 3 provenance attestation, and subscription- and service-account-gated consumption. Rancher Apps & Marketplace provides Helm-based deployment with repository control. SUSE Rancher Suite tier (SUSE Private Registry, Harbor-based): the enterprise's own governed publication surface — RBAC, scanning, signing, retention. Kubewarden (certified Rancher project, add-on subscription) closes the consumption loop by enforcing signature verification at admission. VM images are governed at the SUSE Virtualization image and template level; AI components distribute through AI Library (SUSE AI Factory subscription). Gap from 4: this is a chart-and-image catalog — strong publication governance with thinner day-2 operational intelligence, Helm upgrades rather than operators encoding application-specific operational knowledge; traditional applications inside VMs are governed at the image level, not the application payload. Opinion — extending governance uses registry and admission primitives already in the boundary. #### Application lifecycle governance *(universal)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Delegated Included: Fleet GitOps, first-party and fleet-scale — declarative application lifecycle with every change Git-tracked, drift detected, and reconciliation logged: audit trail as architecture. One engine spans the entire estate — the same GitOps lifecycle governance applies to every managed cluster and workload type rather than separate per-product lifecycle domains, which is what earns the score. SUSE Application Collection provides version streams with chart comparison for upgrade evaluation. SUSE Rancher Suite tier: Harbor-based retention and immutability policies in Private Registry; SUSE Security provides runtime compliance drift detection. Rancher audit logging records management-plane actions. Gap from 4: no channel-based deprecation and retirement semantics for catalog content, and unified audit across all application types in one correlated surface requires SIEM integration — configuration against standard audit telemetry. Opinion. #### Developer experience and self-service *(universal)* **Score:** 3 · **Gap ownership:** opinion · **DAPM:** Delegated Included: self-service deployment from the Rancher catalog within project RBAC and quota guardrails — approval is platform policy, not a ticket queue. K3k virtual clusters as self-service units: a developer receives an entire isolated Kubernetes control plane on shared infrastructure, a coarser and cleaner self-service grain than namespace vending. SUSE Rancher Suite tier: VM self-service through the unified Rancher pane. Rancher Developer Access (separately purchased subscription): SUSE Application Collection integrated into Rancher Desktop with zero-CVE images — workstation-to-production artifact continuity. SUSE AI Factory subscription: AI self-service through Open WebUI and AI Library. Gap from 4: no internal developer portal product — golden-path platform engineering (a Backstage-class portal) is enterprise assembly — and the self-service grain varies across workload types. Opinion — consistent entry points are configured from included primitives. #### AI application and agent distribution *(ai-workload)* **Score:** 2 · **Gap ownership:** closeable · **DAPM:** Delegated SUSE AI Factory subscription: AI components distribute through AI Library and Helm with supply-chain attestation — governed distribution through general-purpose mechanisms. Model versioning exists as an applied component: the MLflow model registry within the SUSE AI Factory subscription, and Ollama model management. What is absent is a productized AI-specific governance surface: no model catalog shipped as a product with RBAC and token quotas, no agent tool authorization, no prompt-injection controls, no AI output audit trails. Universal Proxy (tech preview, not scored) targets MCP connection governance — an integration-layer capability, not distribution governance. Score 2: distribution via general-purpose mechanisms without AI-specific audit. Closeable — partial hardening is available by applying MLflow and admission primitives, but AI-specific governance at the next band requires capability no SUSE subscription currently contains. *Notes: FC-3's character is supply-chain-first: publication-side governance (signatures, SBOM/VEX, SLSA-3 provenance, gated consumption) is the strength; day-2 operational intelligence is the within-band thinness — charts and images, not operators encoding operational knowledge. F2=3 rests on one Fleet engine spanning the whole estate. F4=2 is the layer's gap: AI distribution rides general-purpose mechanisms without a shipped AI governance product.* ### FC-4 · Integration — Integration Fabric *Event bus, API management, workflow orchestration, and system connectors.* #### Event fabric and messaging *(universal)* **Score:** 1 · **Gap ownership:** closeable · **DAPM:** Delegated No event fabric product exists in the SUSE portfolio. What the boundary provides: Apache Kafka and NATS ship as SUSE Application Collection artifacts — attested images and charts validated on RKE2, with artifact-level support inside the one-vendor boundary. Deploying them yields messaging the enterprise operates; it does not yield a managed event fabric — schema governance, filtering, fan-out, dead-letter handling, replay, and delivery guarantees as operated capability remain enterprise-built on top of the deployed components. The artifact tier sets the floor at 1 (messaging components available within the vendor boundary); the managed-fabric capability is Closeable — reaching it requires either acquiring a managed streaming platform from a different vendor or building and operating the fabric layer as an enterprise capability. #### API management and gateway *(universal)* **Score:** 2 · **Gap ownership:** opinion · **DAPM:** Delegated No API management product exists in the SUSE portfolio. What the boundary provides: Apache APISIX — an API gateway with authentication, rate limiting, and transformation capability — ships as an SUSE Application Collection artifact, and Traefik Gateway API is the supported ingress path on RKE2 with long-term support. This is a gateway component, enterprise-operated: the gateway function is real and in-boundary, with artifact-level support. Gap from 3: no productized API lifecycle — publication workflow, developer portal, versioning governance, and API analytics as vendor-operated capability; the enterprise assembles these from APISIX's own feature set and operates the result. Opinion — the component is already in the subscription and the enterprise applies it; support is artifact-level, and the operational lifecycle of the gateway is the enterprise's own. #### Workflow and process orchestration *(universal)* **Score:** 0 · **Gap ownership:** closeable · **DAPM:** Retained No workflow or process orchestration capability exists anywhere in the boundary. Fleet is GitOps continuous delivery, not process orchestration. No workflow engine ships in any SUSE product or in the SUSE Application Collection. The Liz agent crew executes operational tasks with human approval and is not a business-process engine. BPMN-compliant business process orchestration — long-running transactions, saga patterns, compensation logic, human task management — and AI agent chain orchestration require acquisition entirely outside the SUSE boundary and enterprise operation of the result. Closeable. #### SaaS and enterprise system integration *(universal)* **Score:** 0 · **Gap ownership:** closeable · **DAPM:** Retained No connector library exists in the SUSE portfolio — no maintained connectors to ERP, CRM, HCM, mainframe, or SaaS systems of record, and no integration framework product. Every system-of-record integration is enterprise-built and enterprise-maintained, with the enterprise absorbing upstream API changes itself. This is the most operationally expensive absence in the row: each cross-system governance gap carries its own multi-year build-and-maintain burden. Closeable through third-party integration platform acquisition — the same path available on any substrate, credited to none. #### AI-native integration *(ai-workload)* **Score:** 2 · **Gap ownership:** vendor-roadmap · **DAPM:** Delegated SUSE AI Factory subscription, GA today as applied components: LiteLLM provides model API federation — multi-provider routing, API keys, quotas — and mcpo bridges MCP servers to OpenAPI endpoints; both are mirrored-upstream components inside the supported stack that the enterprise configures. Adjacent but not credited here: the GA MCP server embedded in SUSE Rancher Prime and SUSE Multi-Linux Manager exposes platform operations to AI agents — an operations-management surface, not an application integration fabric. The named roadmap product: Universal Proxy — centralized MCP endpoint management, automated server discovery and registration, smart traffic routing, cost control, and shadow-AI discovery — is in tech preview. Score 2 reflects the GA component layer: AI-native integration patterns available through in-boundary components without managed connection infrastructure. Vendor roadmap — a specific product in confirmed development addresses the managed-infrastructure gap; GA would move this function toward 3, re-scored on evidence at that time. *Notes: FC-4 is the row's assembly burden. SUSE ships no integration products — no event fabric, API management, workflow, or connector offerings. The supported-artifact tier (Kafka, NATS, APISIX through SUSE Application Collection) sets floors above absence without delivering managed capability, and the identity-propagation test fails at the first hop: there is no fabric for identity to propagate through. The AI-specific function is the exception in motion: GA federation and MCP-bridging components today, with Universal Proxy in tech preview as the named managed-infrastructure path.*