Cross-vendor comparison
Layer status grid, identity plane continuity table, and FC-2C reasoning plane side-by-side for all four assessed on-prem control planes. The instrument identifies gaps; it does not rank vendors.
How to read these scores
The Fourth Cloud instrument scores functions within layers, not layers as aggregates. Each function gets a 0–4 score, a gap ownership classification, and a DAPM authority classification. The layer is a grouping; the function score is the finding.
Score gradient (0–4)
- 4 — Hyperscaler. AWS/hyperscaler equivalent — fully managed, fully automated.
- 3 — Strong. Meaningful automation and integration. Narrow, well-understood gaps.
- 2 — Moderate. Partial coverage within constraints the vendor does not control.
- 1 — Weak. Addressed for some workload types but not others; manual-assisted.
- 0 — Absent. Vendor provides nothing. Enterprise owns the function entirely.
Gap ownership (every score < 4)
- Closeable. Enterprise must acquire new capability — new software, vendor, or contract.
- Opinion. Primitives exist; enterprise applies configuration without new acquisition.
- Vendor roadmap. Vendor has announced product intent with a timeline.
- Structural. Consequence of the on-prem operating model — no near-term close.
DAPM authority
- Retained. Enterprise can swap providers without rebuilding. Default when vendor provides nothing.
- Delegated. Substitutable partner provides this capability — alternatives exist.
- Ceded. Vendor's opinions are proprietary with no open exit; lift-to-leave requires rebuild.
- Absent. No capability exists at this layer.
Three of these vendors are software control planes assessed against the full Fourth Cloud stack — VMware Cloud Foundation, Red Hat OpenShift, and Nutanix Cloud Platform. Oxide is a vertically integrated IaaS substrate, not a Fourth Cloud control plane. Its honest comparison is to AWS EC2 or Azure Virtual Machines, not OpenShift or VCF.
The grid below scores all four against the same FC-0 → FC-4 functions because that is the methodology. Read Oxide's row as evidence of the IaaS substrate scope it ships: class-leading at FC-0 hardware lifecycle and substrate-level orchestration, deliberately absent at PaaS layers (FC-1 data services, FC-2B AI runtimes, FC-3 application distribution, FC-4 integration fabric). The control plane that runs on Oxide hardware to close those layers is a separate buying decision.
Class-leading functions: each vendor's strongest scores ranked against the other three. Sole lead means the vendor strictly beats all peers at that function. Tied lead means the vendor ties at the maximum score ≥3. A vendor with no sole leads is a different finding than a vendor with several, but neither is a verdict — the buyer's gap portfolio is the verdict.
Layer status is the average of function scores within that layer (Strong ≥ 3.0, Moderate ≥ 2.0, Gap ≥ 1.0, Absent < 1.0). The small chips beneath each status show the individual function scores so spikes inside a layer remain visible. A vendor with one hyperscaler-grade function and three weak ones is a different finding than a vendor at uniform Moderate.
Top-level assessment: does one identity context reach every layer, or do enterprises build cross-layer identity bridges? Lower scores mean more material Closeable gaps.
| Vendor | Score | Classification | Layers in plane | Layers siloed |
|---|---|---|---|---|
| vmware-vcf-fourthcloud | 1 | Siloed | fc2a, fc2b-vm-container | fc0, fc1, fc2b-inference, fc2c, fc3, fc4 |
| redhat-openshift-fourthcloud | 3 | Federated | fc2a, fc2b, fc3, fc4 | fc0, fc1, fc2c |
| nutanix-fourthcloud | 2 | Partial federation | fc2a, fc2b-vm, fc3, fc1-nus | fc0-substrate, fc2b-kubernetes, fc2c, fc4 |
| oxide-fourthcloud | 2 | Partial federation | fc0, fc2a, fc2b | fc1, fc2c, fc3, fc4 |
| Canonical | 2 | Partial federation | fc2a, fc2b, fc3 | fc0, fc1, fc2c, fc4 |
| bounded-kubernetes-fourthcloud | 2 | Partial federation | fc2b | fc0, fc1, fc2a, fc2c, fc3, fc4 |
| hpe-private-cloud | 2 | Partial federation | fc2a, fc2b, fc3 | fc0, fc1, fc2c, fc4 |
| SUSE | 3 | Federated | fc2a, fc2b, fc3 | fc0, fc1, fc2c, fc4 |
The defining Fourth Cloud layer. The methodology expectation is that every on-prem vendor scores 0 or 1 here today, with Structural gap ownership unless a specific product with a confirmed timeline exists.
| Vendor | Score | Gap ownership | Finding |
|---|---|---|---|
| vmware-vcf-fourthcloud | 0 | structural | 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 s… |
| redhat-openshift-fourthcloud | 0 | structural | 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 a… |
| nutanix-fourthcloud | 0 | structural | 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 topo… |
| oxide-fourthcloud | 0 | structural | 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 ba… |
| Canonical | 0 | structural | 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 aggrega… |
| bounded-kubernetes-fourthcloud | 0 | structural | 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. |
| hpe-private-cloud | 0 | structural | 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 engi… |
| SUSE | 0 | structural | 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… |