What Fourth Cloud means

Fourth Cloud is an operational pattern, not a product category: a uniform, AI-native operational substrate spanning cloud, on-prem, and edge, with intelligent governance and autonomous control integrated across the entire environment, operable with product discipline in enterprise environments that do not have hyperscaler engineering cultures.

Based on the canonical essay, “Before You Build a Private Cloud, Ask This One Question”. Read it alongside the vendor assessment.

The critical distinction

Fourth Cloud platforms operate AI workloads and non-AI workloads (VMs, containers, databases, batch jobs) through the same reasoning plane. A platform that orchestrates only AI inference is not Fourth Cloud — it is an AI infrastructure platform. The instrument scores accordingly.

The seven layers

Layer	Name	Defining test
FC-0	Physical & Virtual Substrate	Does the control plane lifecycle hardware, or does the enterprise?
FC-1	Distributed Data & Context Fabric	Is metadata queryable by a reasoning plane for placement, across the full data estate?
FC-2A	Infrastructure Orchestration	Does one scheduler see VMs, containers, databases, and AI through a shared resource pool?
FC-2B	Execution & Runtime	Is the runtime unified across all workload types with consistent developer experience and persona abstraction?
FC-2C	The Reasoning Plane	Does a policy-driven engine derive placement from live FC-1 + FC-2A metadata for all workload types — or does an operator write rules?
FC-3	Application Distribution and Governance	Is the application catalog governed at publication and consumption — for containers, traditional apps, agents, and MCP servers alike?
FC-4	Integration Fabric	Is there a managed event fabric, API gateway, workflow engine, and connector library, or does the enterprise build point-to-point integrations?

This is a gap identification instrument, not a ranking

No vendor currently delivers a complete Fourth Cloud platform equivalent to a hyperscaler control plane on-premises. Every function score below 4 represents a gap the enterprise must own, close with a partner, or accept as a structural constraint of the on-prem operating model. The instrument's job is to make those gaps visible, nameable, and comparable.

The instrument does not produce a winner. It produces a gap portfolio map. Read it alongside Townsend's Section 2.6 gap lifecycle framework — the instrument identifies gaps; Section 2.6 estimates what each gap costs over five years.

The DAPM authority axis

DAPM answers one customer-side question per function: can I take my accumulated opinions at this layer and operate them independently of this vendor?

Retained — yes. Enterprise can swap vendors without rebuilding. Default when the vendor provides nothing at the function.
Delegated — partially. Substitutable partner provides the capability; alternatives exist.
Ceded — no. Vendor's opinions are proprietary with no open exit.

Critical sub-rules: self-deployable is not Retained. Open API is not portable. The test is lift-to-leave for the opinions, not whether data can move.

Identity plane continuity

A top-level finding above the layer scores: does the platform provide a single identity context that is visible and enforceable at all layers simultaneously — FC-0 through FC-4 — without the enterprise building layer-specific identity bridges? Each layer can score well on its own capabilities while the identity chain between layers is broken. Siloed identity is the largest single source of Closeable gap burden in the instrument.