How to Read Layer2C Assessments
Layer2C assessments are opinionated architectural analyses — not certifications, lab validations, or paid rankings. This page explains what the assessments evaluate, how they are scored, and how to interpret them correctly.
What the Assessments Evaluate
Each assessment analyzes a vendor's AI infrastructure offering across eight layers of the 4+1 AI Infrastructure Model. Every vendor is scored on all eight layers — the model defines the functions AI infrastructure requires, and they exist whether or not a given vendor provides them.
Three independent readings come out of every cell. Capability: what the vendor ships at the layer, graded strong, moderate, gap, or partner on what an architect can deploy to production today. Portability: whether the enterprise can lift its accumulated opinions out without rebuilding, the DAPM badge on each component. Decision authority: who makes the runtime tradeoff at the layer, whether the enterprise can see it, and whether it can override it, read once per layer, gaps included. A cell moves only on public evidence: a vendor's product documentation, a published post, or a published lab result. A briefing can point to the document; it can't move the cell.
| Layer | What Is Being Evaluated |
|---|---|
| Layer 0 — Compute & Network Fabric | What compute hardware and networking does the vendor provide? Is the compute substrate commodity (x86, substitutable across OEMs) or proprietary? For accelerators, NVIDIA included, does the workload reach them through an open runtime or a proprietary one? Are networking opinions portable or captive to a proprietary stack? |
| Layer 1A — Data Storage & Governance | Who controls the data substrate, metadata layer, and governance catalog? Can the enterprise take its storage opinions to a competing platform, or are they captive? |
| Layer 1B — Context Management & Retrieval | What retrieval infrastructure does the vendor provide? Is the context layer built on open-source components or proprietary systems? |
| Layer 1C — Data Movement & Pipelines | Who orchestrates data movement, KV cache tiering, and pipeline automation? Is the pipeline logic portable or vendor-captive? |
| Layer 2A — Infrastructure Orchestration | Who controls GPU scheduling, workload placement, and infrastructure lifecycle management? Can the enterprise take its orchestration opinions elsewhere? |
| Layer 2B — Application Runtime & Execution | Who owns the model serving layer, inference engine, agent runtime, and guardrails? Is the runtime open-source or proprietary? |
| Layer 2C — Agentic Infrastructure | Does the vendor have a policy-driven reasoning plane — one that makes placement decisions, not just routing decisions? Can it govern agent behavior at the infrastructure level? |
| Layer 3 (+1) — AI Application Layer | What AI applications and ISV ecosystem does the vendor enable? Is the application layer open or captive? |
The Decision Authority Placement Model (DAPM): Portability and Decision Authority
DAPM carries two readings, and they are independent. The component badge measures portability. Every layer also carries a decision-authority reading: who makes the runtime tradeoff at that layer, whether the enterprise can see it, and whether the enterprise can override it. Every assessed component receives a portability classification. The classification answers one question from the customer's perspective: can I take my accumulated opinions at this layer and operate them independently of this vendor?
| Classification | The Customer Question | What It Means |
|---|---|---|
| Retained | Can I leave without rebuilding? | I possess the capability and can operate it independently of this provider. A commodity substrate the enterprise can swap (x86 compute across OEMs) and open-source software the enterprise runs (Kubernetes, Airflow, Ray, Ceph) are the usual ways that becomes true, not additional criteria. A layer where the vendor provides nothing has no portability reading; its decision authority is read explicitly, never defaulted to Retained. |
| Delegated | Can I swap the provider? | Someone else provides the capability, but I can substitute that provider without reconstructing my accumulated opinions: a managed service or proprietary implementation behind a multi-vendor standard interface, or a delivery partner another could replace. The test is substitution of the provider, not the license of the software. |
| Ceded | Am I locked in? | Changing providers requires reconstructing those opinions. A closed system is a closed system: the vendor's opinions are proprietary with no open exit, and the enterprise cannot take its accumulated configs, policies, governance logic, or operational model to a different vendor's platform without rebuilding. This applies to any proprietary platform, storage, networking, orchestration, or management software, regardless of who operates it or where it runs. |
| Decision authority (per layer) | Who decides | What It Means |
|---|---|---|
| Retained | The enterprise, or code the enterprise writes or controls | The runtime tradeoff is made by the enterprise or by deterministic code it authors and can change, even where the platform evaluating it is captive. If the customer writes or controls the code, the customer decides. |
| Delegated | The vendor or a model, and the enterprise can override at runtime | The vendor's service or a model makes the call, the enterprise can see the decision path and pull the decision back: a human in the loop, a policy it sets, a switchable provider. |
| Ceded | The vendor or a model, and the enterprise can't override | The tradeoff is made beneath the service, often invisibly. This is the reading for layers the vendor absorbs entirely, and it's where decoupled capture hides. |
| Absent | Nobody | Nothing is offered at this layer and nothing is inherited. The function stays with the enterprise, unplaced. Absent is a reading, not a default. |
The two readings diverge in both directions. A platform can be Ceded on portability and Retained on decision authority (enterprise-authored policy, vendor-evaluated). A vendor can offer nothing at a layer and still decide everything beneath it, invisibly. Gap layers carry a decision-authority reading and no portability badge, because there is nothing to lift.
The open-source seam is universal. Open source is a portability fact, never a decision-authority fact. An open harness, framework, engine, or set of weights the enterprise runs is Retained on portability; wherever a model makes the runtime call inside it, decision authority reads at the model boundary: Delegated if the enterprise's own deterministic code gates the effect, Ceded if it can't. Open weights change who can run the model, not who decides at runtime.
DAPM is not a quality score. A Ceded capability can be excellent — cloud vendors routinely provide world-class capability that the enterprise consumes without governance authority. The classification describes the governance relationship, not the capability's fitness for purpose. The most complete vendor can also be the most captive. Completeness and authority are orthogonal.
The Litmus Test
A closed system is a closed system. If the enterprise cannot take its accumulated opinions — configs, policies, governance logic, operational model — and operate them on a different vendor's platform without rebuilding, the component is Ceded. This test applies uniformly across all layers.
The commodity-substrate test determines the boundary. Where a commodity substrate exists — x86 servers substitutable across OEMs, or open-source software with real alternatives — the enterprise can swap vendors without rebuilding, and the component is Retained when the enterprise provides it and Delegated when someone else does. Where no commodity substrate exists — proprietary networking, proprietary storage, proprietary management software — the enterprise cannot swap vendors without rebuilding, and the component is Ceded.
Several common patterns do not change the classification:
Self-deployable does not mean Retained. Running proprietary software on your own hardware gives the enterprise operational control, not authority. The test is lift-to-leave: if the enterprise cannot take the vendor's opinions to a competing platform without rebuilding, it is Ceded regardless of where it runs.
Vendor ownership does not mean Retained. A vendor owning the software — rather than licensing it from a partner — does not change the customer's authority position. The customer still cannot take the opinions elsewhere.
Data portability does not mean authority. "Your data is open / in Iceberg / stays in your cloud" says nothing about authority over the platform. The data was always the cheap-to-rebuild part. The litmus applies to the layer where the proprietary dependence accumulates, not to whether the bytes can move.
An open API does not mean portable. Oracle Database has an open API and runs anywhere, yet leaving it is a multi-year lift because the accumulated opinions — stored procedures, optimizer behavior, dialect — are captive. The test is lift-to-leave, not "is there an API."
The assessment scores the presented architecture, not the theoretical maximum. If the vendor could theoretically be made portable with additional tooling they are not selling, the assessment scores what they are selling.
Layer Status Indicators
Each layer receives a status indicator summarizing the vendor's capability strength at that layer. Every vendor has all eight layers — the 4+1 model defines the functions AI infrastructure requires, and they exist whether or not the vendor provides them.
| Indicator | Meaning |
|---|---|
| ● Strong | The vendor provides differentiated, complete capability at this layer |
| ◑ Moderate | The vendor provides partial or developing capability at this layer |
| ○ Gap | The vendor provides little or nothing at this layer. The function remains the enterprise's responsibility. This is a finding — it may be by design (a software vendor has no Layer 0) or a strategic absence (an infrastructure vendor has no Layer 2C). The summary interprets which. |
| ◇ Partner | Used at Layer 3 when the layer is addressed entirely through an ISV ecosystem. The vendor provides the infrastructure substrate; partners provide the application logic. |
What Assessments Do Not Claim
- They are not lab validations or benchmark results
- They are not exhaustive product reviews covering every feature
- They are not procurement recommendations — they do not tell you which vendor to buy
- They are not certifications — no vendor pays to be assessed or approved
- They are not permanent — architecture evolves; assessments reflect a point in time
Evidence Sources
Assessments draw from publicly available materials. Each assessment lists its primary sources, which may include:
- Vendor conference presentations and technical sessions (GTC, re:Invent, Google Cloud Next, HPE Discover, etc.)
- Official product documentation, white papers, and architecture guides
- Press releases and earnings call transcripts
- Analyst coverage and independent technical reporting
- Published Layer2C Labs results, and third parties\' published, reproducible tests
- The CTO Advisor's independent architectural judgment
Vendor briefings inform where to look; they never move a cell. A grade changes only when a public document, post, or published lab result supports the change, and the assessment cites it. Where a vendor has reviewed an assessment prior to publication, this is noted on the assessment page. Vendor review does not imply vendor approval or endorsement — factual corrections are incorporated; editorial positions are retained.
Commercial Disclosure
The CTO Advisor is an independent analyst firm. Vendors do not pay to be assessed on Layer2C. Where The CTO Advisor has a commercial relationship with an assessed vendor (advisory, consulting, sponsored content), this is disclosed on the relevant assessment page.
Assessments are not influenced by vendor relationships. If you believe an assessment contains a factual error, contact The CTO Advisor at thectoadvisor.com.