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.
| 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/NVIDIA, substitutable across OEMs) or proprietary? 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)
Every assessed component receives a DAPM 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? | Yes. The capability rests on a commodity substrate (x86 compute is substitutable across OEMs) or on open-source software with real alternatives (Kubernetes, Airflow, Ray, Ceph). The enterprise's accumulated opinions survive a vendor change. Also applies by default when the vendor provides nothing at a layer — the enterprise owns the function because nobody else does. |
| Delegated | Can I swap the provider? | Partially. The capability is provided by a substitutable partner or open-source tooling the enterprise could swap without rebuilding. The enterprise keeps the right to change providers — either because the tool is open-source with real alternatives, or because the delivery partner is genuinely substitutable. |
| Ceded | Am I locked in? | Yes. A closed system is a closed system. The vendor's opinions are proprietary with no open exit. 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, management software — regardless of who operates it or where it runs. |
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 or Delegated. 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
- Vendor briefings and technical conversations
- The CTO Advisor's independent architectural judgment
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.