Executive Summary: Red Hat (OpenShift AI + RHEL AI + Ansible)

Red Hat is the instrument's open-source substrate vendor: an operating system, a Kubernetes platform, and an AI serving stack the enterprise can run on any hardware or cloud. It is strong where workloads are orchestrated (2A: OpenShift, Kueue, fleet policy) and run (2B: vLLM, llm-d, Models-as-a-Service), moderate across the data layers, a single enforcing gateway at 2C, and partner at Layer 3. Nearly every component reads Retained on the possess-and-operate line; this is the row the methodology's Red Hat standard describes.

The capture is decoupled and mostly not in the code. What accumulates is dependence on Red Hat's supported builds and on the OpenShift operating model (Routes, security context constraints, OLM-managed operators, Kuadrant policies), which lift to OKD and upstream projects without rebuilding but take rework on another Kubernetes distribution; the cost of leaving is support and operational familiarity, not reconstructed opinions. IBM's data, governance, agent, and application estate is scored on the IBM row. On-premises watsonx requires OpenShift, so the two rows compose in the common IBM deployment, and in that stack the authority above the substrate is IBM's.

The buyer's trade: the most portable AI infrastructure stack on the map, in exchange for assembling the data, retrieval, and agent-governance layers from parts, or buying them from IBM. Red Hat's agent surfaces (the MCP Gateway, the MCP catalog, the Llama Stack Responses API) are still in preview.

Layer-by-layer status: Layer 0 (Hardware-Agnostic Substrate: RHEL, OpenShift Virtualization, Multi-Accelerator Enablement), Layer 1A (Ceph-Based Storage in Platform Plus + Workload Compliance Governance; No Catalog), Layer 1B (Open-Source Retrieval Assembled on OpenShift AI), Layer 1C (Kafka, Debezium, Camel, and Kubeflow Pipelines on Red Hat Subscriptions; No Enterprise Lineage), Layer 2A (One Control Plane for Containers, VMs, and GPUs: OpenShift, OpenShift AI Kueue, ACM, Ansible), Layer 2B (Open Serving Stack: vLLM, llm-d, Models-as-a-Service), Layer 2C (Enforcing Inference Gateway; Agent Governance in Preview), Layer 3 (+1) (Certified ISV Ecosystem; No Business Applications).

Assessment framework: 4+1 Layer AI Infrastructure Model. Scoring model: Decision Authority Placement Model (DAPM) — Retained, Delegated, or Ceded. Published by The CTO Advisor LLC (DBA The Advisor Bench). Author: Keith Townsend. Date assessed: October 5, 2026. Version: v1.0 - 4+1 v2: Split from the IBM Row.

Red Hat (OpenShift AI + RHEL AI + Ansible)

Mapped to the 4+1 Layer AI Infrastructure Model

v1.0 - 4+1 v2: Split from the IBM RowAssessed October 5, 2026Sources & revision history
ACTIVE ASSESSMENT

Summary Finding

Red Hat is the instrument's open-source substrate vendor: an operating system, a Kubernetes platform, and an AI serving stack the enterprise can run on any hardware or cloud. It is strong where workloads are orchestrated (2A: OpenShift, Kueue, fleet policy) and run (2B: vLLM, llm-d, Models-as-a-Service), moderate across the data layers, a single enforcing gateway at 2C, and partner at Layer 3. Nearly every component reads Retained on the possess-and-operate line; this is the row the methodology's Red Hat standard describes.

The capture is decoupled and mostly not in the code. What accumulates is dependence on Red Hat's supported builds and on the OpenShift operating model (Routes, security context constraints, OLM-managed operators, Kuadrant policies), which lift to OKD and upstream projects without rebuilding but take rework on another Kubernetes distribution; the cost of leaving is support and operational familiarity, not reconstructed opinions. IBM's data, governance, agent, and application estate is scored on the IBM row. On-premises watsonx requires OpenShift, so the two rows compose in the common IBM deployment, and in that stack the authority above the substrate is IBM's.

The buyer's trade: the most portable AI infrastructure stack on the map, in exchange for assembling the data, retrieval, and agent-governance layers from parts, or buying them from IBM. Red Hat's agent surfaces (the MCP Gateway, the MCP catalog, the Llama Stack Responses API) are still in preview.

Strength
Moderate
Gap
Partner
Layer 0 · ComputeCompute & Network FabricHardware-Agnostic Substrate: RHEL, OpenShift Virtualization, Multi-Accelerator Enablementdecides: vendor · Delegated▼

Raw compute, networking, and acceleration fabric

Vendor-Provided

RHEL 10 and RHEL AI (Operating System)Retained

The enterprise operating system under every Red Hat path, open source the enterprise runs itself with Red Hat's subscription for updates and support. Retained on the open-source seam.

OpenShift Virtualization (KubeVirt; GPU Passthrough and vGPU)Retained

Virtual machines and containers on the same Kubernetes API, namespaces, and RBAC, with GPU passthrough and vGPU for accelerated VMs. Open-source virtualization the enterprise operates: Retained, the SUSE Harvester reading.

Multi-Vendor Hardware Support (x86, Arm; Every Major OEM and Cloud)Retained

OpenShift runs on Dell, HPE, Lenovo, Cisco, Supermicro, and the major clouds through one control plane. The enterprise's choice: Retained.

Accelerator Enablement Through Red Hat's Paper (NVIDIA GPU Operator, AMD ROCm, Intel Gaudi, IBM Spyre)Delegated

The accelerator vendors' drivers and operators, packaged and supported by Red Hat. Their technology, substitutable at the accelerator: Delegated.

NVIDIA-Provided

NVIDIA GPU Operator and vGPU

The most common accelerator path on OpenShift, packaged and supported on Red Hat's paper. AMD ROCm, Intel Gaudi, and IBM Spyre are enabled through the same operator model, so the dependency is real but not exclusive.

◆ Gap Analysis

Red Hat sells the software that turns any vendor's hardware into an AI substrate, and nothing below it. RHEL 10 and RHEL AI are the operating system; OpenShift Virtualization (KubeVirt) runs virtual machines and containers on one Kubernetes with GPU passthrough and vGPU; and operators enable NVIDIA, AMD ROCm, Intel Gaudi, and IBM Spyre accelerators on whatever x86 or Arm servers the enterprise buys, on premises or on any major cloud. The buyer gets one substrate abstraction over their own metal, with accelerator enablement handled. The architect's concern: Red Hat owns no silicon, no fabric, and no rack. Compute density, GPU-to-GPU bandwidth, and accelerator topology come from the OEM and the accelerator vendor, and OpenShift has no hypervisor layer abstracting OEM hardware management, so hardware tooling stays OEM-specific. Applying the exposure test: the substrate is the customer's and the abstraction is Red Hat's; GPU partitioning and VM placement the enterprise administers are real Layer 0 controls, on hardware Red Hat never touches. Calibration: SUSE reads moderate on SLES and SUSE Virtualization with GPU slicing, the closest shape on the instrument; VMware and Nutanix moderate on a hypervisor plus GPU integration; Dell, HPE, and Cisco strong on hardware they own or specify. Red Hat is SUSE's shape: moderate. IBM's own silicon and systems (z17, Power11, Spyre) are scored on the IBM row.

◆ Borrowed Judgment

Bounded and pinnable, on the open-source seam. RHEL and OpenShift Virtualization are open source the enterprise operates (Retained; the subscription buys updates and support). Multi-vendor hardware support is the enterprise's choice: Retained. Accelerator enablement is the accelerator vendors' technology through Red Hat's paper: Delegated. The scheduler places VMs and GPU workloads within the enterprise's policies, and a per-VM nodeSelector or required affinity rule is a pin the engine must honor: vendor decides, visible, overridable, Delegated under the override rule, the SUSE reading.

◆ Working Notes

Confidence flag: GPU passthrough for OpenShift Virtualization is documented; the vGPU and MIG detail for virtual machines is worded from the Fourth Cloud assessment and Red Hat material and should be checked against the current OpenShift Virtualization documentation. Public evidence that moves the cell: Red Hat-sold hardware.

Layer 1A · StorageData Storage & GovernanceCeph-Based Storage in Platform Plus + Workload Compliance Governance; No Catalogdecides: vendor · Delegated▼

Durable, governed data foundation — the Governance Catalog that Layer 2C queries

Vendor-Provided

OpenShift Data Foundation Essentials (Ceph via Rook; NooBaa S3 Gateway), in OpenShift Platform PlusRetained

Block, file, and S3 object storage for OpenShift workloads. IBM owns the product and sells the full tier as Fusion Data Foundation; Red Hat delivers Essentials through its own paper. Open-source Ceph the enterprise operates: Retained.

Red Hat Advanced Cluster Security (Compliance Enforcement over the Fleet)Retained

Continuous compliance against CIS, NIST, PCI DSS, and HIPAA for Kubernetes workloads: vulnerability scanning, runtime policy, network segmentation, image provenance, blocking non-compliant workloads at deploy time. Workload governance, not data governance. Open source (StackRox) the enterprise runs: Retained.

NVIDIA-Provided

Assessment pending

◆ Gap Analysis

On Red Hat's paper the enterprise gets Ceph-based block, file, and S3 object storage for OpenShift workloads through OpenShift Data Foundation Essentials, included in OpenShift Platform Plus, and compliance governance over the fleet through Red Hat Advanced Cluster Security, which enforces CIS, NIST, PCI DSS, and HIPAA controls on workloads at deploy time and at runtime. The architect's concern: there is no catalog of what the data is. ACS governs Kubernetes workloads, not enterprise data; nothing here answers sensitivity, classification, lineage, or freshness for the records a reasoning plane would place work against. And the storage roadmap belongs to IBM: Red Hat's storage portfolio moved to IBM in 2023, IBM sells the full product as Fusion Data Foundation, and Red Hat delivers the Essentials tier through its own paper. Moderate, on rule 9: owned storage with compliance governance over the fleet and no catalog reads moderate at the top of the band. Calibration: Elastic reads moderate on a tiered store with access control and no catalog; SUSE moderate on Longhorn and MinIO; Dell, NetApp, VAST, and IBM strong on storage plus a catalog. Composition: the IBM row carries the full storage and catalog estate (Fusion, Storage Ceph, Storage Scale, watsonx.data intelligence); in the common IBM-plus-Red Hat stack, the catalog a reasoning plane would query is IBM's.

◆ Borrowed Judgment

Low at the substrate. Ceph through Rook and the NooBaa S3 gateway are open source the enterprise operates: Retained, with IBM owning the product roadmap as a channel fact rather than an authority one. ACS is open source (the StackRox project) the enterprise runs: Retained. Ceph places data within the pool and bucket policies the enterprise sets per object, policies the engine must honor: vendor decides, visible, overridable, Delegated, the Elastic and SUSE reading.

◆ Working Notes

Confidence flag: where ODF Essentials ends and IBM's paid tier begins (encryption with an external key manager, Regional DR) wasn't confirmed against Red Hat's Platform Plus feature list. Public evidence that moves the cell: a data catalog with classification and lineage on Red Hat's paper.

Layer 1B · RetrievalContext Management & RetrievalOpen-Source Retrieval Assembled on OpenShift AIdecides: vendor · Delegated▼

Low-latency retrieval for RAG — vector/hybrid search, context windows

Vendor-Provided

Vector Database Integration (Milvus, pgvector, Elasticsearch as OpenShift AI Workloads)Retained

Vector and hybrid stores the enterprise deploys and operates on OpenShift AI. Open source the enterprise runs: Retained on the possess-and-operate line.

pgvector on OpenShift Data Services ManagerRetained

Red Hat-supported vector search on PostgreSQL, provisioned through Data Services Manager. Open-source extension the enterprise operates: Retained.

Llama Stack RAG on OpenShift AI (Vector I/O Providers, Docling Ingestion)Retained

Retrieval and embedding workflows with Docling handling structure-aware parsing and chunking. Open-source framework and parser the enterprise operates: Retained. General-availability status of the RAG surfaces flagged in the notes.

NVIDIA-Provided

NVIDIA cuVS and NeMo Retriever (Optional)

GPU-accelerated vector search and retrieval microservices are available on OpenShift AI; neither is required by the open retrieval path.

◆ Gap Analysis

Retrieval is assembled from open source on OpenShift AI. The enterprise deploys Milvus, pgvector, Elasticsearch, or another vector store as a workload, uses pgvector through OpenShift Data Services Manager with Red Hat support, and builds the ingestion path with Llama Stack's RAG APIs and Docling's structure-aware parsing and chunking. It runs anywhere OpenShift runs, and nothing in it is captive. The architect's concern: the enterprise assembles and operates the pipeline; there is no integrated, managed retrieval platform, and the retrieval intelligence (indexing, ranking, parsing) is borrowed from open-source communities. Moderate: general in kind under rule 4, but under rule 6 an assembled kit with parts of its RAG surface still maturing doesn't stand with the integrated retrieval platforms. Calibration: Elastic, Azure, and Vertex strong on integrated retrieval; Cloudflare moderate on an index plus open models; Redis moderate on a general open engine; IBM moderate on watsonx.data's Milvus service and its ingestion pipelines, scored on the IBM row.

◆ Borrowed Judgment

Low, and it doesn't compound. The vector stores, Llama Stack, and Docling are open source the enterprise runs: Retained on the possess-and-operate line. The vector engine ranks inside queries the enterprise composes per request: vendor decides, visible, overridable, Delegated, the Elastic reading.

◆ Working Notes

Inference flag: the general-availability status of Llama Stack's RAG surfaces in OpenShift AI 3.4; the Responses API is confirmed Technology Preview, and 3.4 adds official Llama Stack support on IBM Power. If the RAG surfaces are preview, that component moves here and the cell rests on the vector stores alone, still moderate. Docling is an IBM-originated Linux Foundation project, Retained wherever it runs.

Layer 1C · PipelinesData Movement & PipelinesKafka, Debezium, Camel, and Kubeflow Pipelines on Red Hat Subscriptions; No Enterprise Lineagedecides: code · Retained▼

Move/transform data — ETL/ELT, lineage, cost-aware movement, KV cache tiering

Vendor-Provided

Streams for Apache Kafka (Strimzi) + Apicurio Schema Registry, in Red Hat Application FoundationsRetained

Event streaming with schema registry and consumer-group management under a Red Hat support SLA. Open-source Kafka the enterprise runs: Retained, the open-core reading on the Confluent row.

Red Hat Build of Debezium (Change Data Capture), in Red Hat Application FoundationsRetained

Row-level change capture from operational databases into Kafka. Open source the enterprise operates: Retained.

Red Hat Build of Apache Camel (300+ Maintained Connectors), in Red Hat Application FoundationsRetained

Integration and ETL routes across enterprise and SaaS systems, with Red Hat updating connectors when upstream APIs change. Open source the enterprise operates: Retained.

OpenShift AI Data Science Pipelines (Kubeflow Pipelines on Argo) + Ray + MLflow, in Red Hat AI EnterpriseRetained

ML data preparation and training pipelines with experiment tracking and ML-artifact lineage. Open source the enterprise operates: Retained on the possess-and-operate line.

NVIDIA-Provided

Assessment pending

◆ Gap Analysis

A general, open-source data-movement toolkit on Red Hat's paper. Red Hat Application Foundations carries Streams for Apache Kafka (Strimzi) with the Apicurio schema registry, the Red Hat build of Debezium for change data capture out of operational databases, and the Red Hat build of Apache Camel with more than 300 Red Hat-maintained connectors for SAP, Salesforce, Oracle, and the major enterprise systems. Red Hat AI Enterprise adds OpenShift AI Data Science Pipelines (Kubeflow Pipelines on Argo), Ray, and MLflow, with lineage for ML artifacts: which pipeline step produced which model. All of it is self-run and lifts to any Kubernetes. The architect's concern: the enterprise assembles the pipeline from parts. There is no lineage across enterprise data (which operational record fed which training set), no managed stream-processing engine, and no lakehouse destination of Red Hat's own. Moderate at the top of the band: general under rule 4 (Camel routes, Kafka topologies, and Kubeflow pipelines take whatever shape the problem defines), but under rule 6 the strong 1C cohort (Snowflake Openflow, Databricks Lakeflow, Qlik CDC plus Talend, VAST DataEngine, Confluent, IBM) covers batch, streaming, CDC, declarative transformation, and lineage as one integrated surface. Above Elastic's moderate on Logstash and agents. IBM's Confluent and DataStage are scored on the IBM row; two Kafka offerings in one corporate family is a fact worth knowing at procurement.

◆ Borrowed Judgment

Low. Kafka, Debezium, Camel, Kubeflow Pipelines, Ray, and MLflow are open source the enterprise operates: Retained on the possess-and-operate line. The engines execute routes and pipelines the enterprise writes, with no vendor judgment in between: code decides, visible, overridable, Retained, the Elastic 1C reading.

◆ Working Notes

Watch-list, notes only: the Feast feature store (entered as Technology Preview in OpenShift AI 2.20; general availability not confirmed). Instrument follow-up: the Fourth Cloud Red Hat assessment (v2.6) reads Kafka and Camel Ceded; this instrument's possess-and-operate line reads them Retained. Public evidence that moves the cell: enterprise data lineage on Red Hat's paper, or an integrated pipeline surface.

Layer 2A · OrchestrationInfrastructure OrchestrationOne Control Plane for Containers, VMs, and GPUs: OpenShift, OpenShift AI Kueue, ACM, Ansibledecides: vendor · Delegated▼

GPU scheduling, quotas, RBAC, fair-share scheduling, utilization optimization

Vendor-Provided

OpenShift Container Platform (Including OpenShift Virtualization)Retained

Enterprise Kubernetes for containers, VMs, databases, and batch on one API, on premises and on every major cloud. Open source the enterprise runs (OKD upstream): Retained.

OpenShift AI 3.4 (Kueue GPU Queueing, Fair-Share, and Quotas)Retained

Native GPU queue management and multi-tenant quota enforcement across NVIDIA, AMD ROCm, Intel Gaudi, and IBM Spyre. Open source the enterprise operates (Open Data Hub upstream): Retained.

Red Hat Advanced Cluster Management (Fleet Policy), in Platform PlusRetained

Multi-cluster governance policies applied consistently across the fleet with drift detection. Open source (Open Cluster Management upstream): Retained.

Red Hat Ansible Automation PlatformRetained

Infrastructure automation across hybrid environments, including OEM firmware lifecycle coordinated with OpenShift maintenance. Open source (AWX upstream): Retained.

NVIDIA-Provided

NVIDIA GPU Operator (Run:ai Optional)

GPU node management on OpenShift. Kueue provides GPU queueing and fair-share natively, which makes Run:ai optional rather than required.

◆ Gap Analysis

One Kubernetes control plane for containers, virtual machines, databases, batch, and AI workloads, the same on premises and on every major cloud. OpenShift AI adds Kueue: GPU queueing, fair-share scheduling, and multi-tenant quotas across NVIDIA, AMD ROCm, Intel Gaudi, and IBM Spyre. Advanced Cluster Management (Platform Plus) enforces policy across the whole fleet from one place, and Ansible Automation Platform automates the infrastructure around it. The architect's concern: on premises, scheduling is bounded by the physical nodes the enterprise owns, and deep multi-node GPU scheduling still leans on NVIDIA's operators. Strong: the strong 2A cohort (AWS on EKS, GCP, Azure, Nutanix, CoreWeave, SUSE) reads on managed or self-run Kubernetes with GPU scheduling, and OpenShift with Kueue and fleet policy stands with it. In the common IBM deployment, IBM's own schedulers (Spectrum LSF, Turbonomic) sit beside and above this layer; they are scored on the IBM row.

◆ Borrowed Judgment

Low on portability, and pinnable at runtime. OpenShift, OpenShift AI, Advanced Cluster Management, and Ansible are open source the enterprise operates (OKD, Open Data Hub, Open Cluster Management, and AWX upstream): Retained. This is the behavior the methodology's Red Hat standard describes. Quotas, fair-share, and Kueue admission are bounds the scheduler works within, which is configuration; a nodeSelector or required affinity rule is a per-workload pin the engine must honor: vendor decides, visible, overridable, Delegated, the CoreWeave 2A reading.

◆ Working Notes

Instrument follow-up: SUSE, Nutanix, and VMware read Kubernetes pins Ceded at 2A from before the override rule; this cell and CoreWeave read them Delegated.

Layer 2B · RuntimeApplication Runtime & ExecutionOpen Serving Stack: vLLM, llm-d, Models-as-a-Servicedecides: model · Delegated▼

Model serving, agent execution, inference APIs, distributed inference

Vendor-Provided

Red Hat AI Inference (Supported vLLM; NVIDIA, AMD, Intel, IBM Spyre)Retained

Production model serving with an OpenAI-compatible API, tool calling, and structured outputs across accelerator vendors. Open source the enterprise runs: Retained on the possess-and-operate line, the SUSE vLLM reading; the standard interface is a further exit, not the basis.

llm-d Distributed Inference (Generally Available Since OpenShift AI 3.0)Retained

Kubernetes-native distributed inference with KV-cache-aware routing and disaggregated serving. Open source the enterprise operates: Retained.

Models-as-a-Service (Token Quotas, Rate Limits, API Keys, Showback; Generally Available in 3.4)Retained

Governed self-service model access for teams, built on Kuadrant policies. Open-source policy resources the enterprise operates: Retained on the possess-and-operate line.

Red Hat AI Validated Models, Including GraniteRetained

A validated catalog of open-weight models (Granite, Llama, Qwen, Mistral, gpt-oss) supported on Red Hat AI. Open weights the enterprise runs anywhere: Retained. Granite is also scored on the IBM row as the model's owner.

MLflow Tracing and Agent LifecycleRetained

LLM call tracing, tool execution tracking, and reasoning-step auditability. Open source the enterprise runs: Retained.

Customer-Created and Managed Tools (Function Calling / Client-Side)Retained

The business logic, APIs, and deterministic validators the enterprise invokes through tool calls on the OpenAI-compatible serving API. The enterprise's own code: Retained.

NVIDIA-Provided

NVIDIA GPUs (Dominant Serving Substrate); NIM Optional

Most production serving runs on NVIDIA GPUs, and NVIDIA NIM is an available path; the Red Hat runtime itself serves across NVIDIA, AMD, Intel, and IBM Spyre.

◆ Gap Analysis

A complete open serving stack under one support relationship. Red Hat AI Inference is supported vLLM with an OpenAI-compatible API across NVIDIA, AMD, Intel, and IBM Spyre accelerators; llm-d (generally available since OpenShift AI 3.0) adds Kubernetes-native, KV-cache-aware distributed inference, the open counterpart to NVIDIA's Dynamo; Models-as-a-Service (generally available in 3.4) adds token quotas, rate limits, self-service API keys, and showback; and a validated model catalog covers Granite, Llama, Qwen, Mistral, and gpt-oss. Tool calling and structured outputs are documented, so the runtime carries the enterprise's own agent loop. The architect's concern: Red Hat's hosted agent surfaces lag. The Llama Stack Responses API and the MCP Gateway are Technology Preview, and the OpenShell sandbox is NVIDIA's alpha. Strong, under the September 11 agent-execution note: strong is judged by whether the runtime carries the enterprise's own agent loop, and a hosted agent runtime is never the price of it (Cerebras and Groq hold strong with no hosted loop). Calibration: NVIDIA strong on NIM and Dynamo, which Red Hat matches in open source; SUSE moderate on packaged vLLM, Ollama, and NIM without a distributed-inference layer or governed serving of its own; IBM's watsonx.ai, which runs on this engine in the common IBM stack, is scored on the IBM row.

◆ Borrowed Judgment

Low, and the lowest on the instrument at this layer. vLLM, llm-d, the Kuadrant-based Models-as-a-Service policies, MLflow, the validated open-weight models, and the enterprise's own tools are all things the enterprise possesses and operates: Retained. Models-as-a-Service policies are Kuadrant resources that lift to any cluster running Kuadrant, not to another gateway product, which is the residual seam. The model decides which tool to call, and the enterprise's own tool code, executing client-side and able to refuse, gates the effect: model decides, visible, overridable, Delegated, the NVIDIA reading.

◆ Working Notes

Watch-list, notes only: the Llama Stack Responses API (Technology Preview in 3.4), the MCP Gateway (Technology Preview), the MCP catalog (Developer Preview), and the OpenShell agent sandbox (NVIDIA alpha). InstructLab is not scored: its status as a supported product, rather than a community project, wasn't confirmed.

Layer 2C · ReasoningAgentic Infrastructure — The Reasoning PlaneEnforcing Inference Gateway; Agent Governance in Previewdecides: code · Retained▼

Policy-driven placement and resource coordination — the Autonomy Layer

Vendor-Provided

Connectivity Link AI Inference Gateway (Kuadrant/Envoy; Access, Rate, and Token Policies; Generally Available in OpenShift AI 3.4)Retained

Request-time enforcement of the enterprise's authorization, rate-limit, and token-quota policies on inference endpoints. Open source the enterprise operates: Retained.

NVIDIA-Provided

Assessment pending

◆ Gap Analysis

The Connectivity Link AI inference gateway (Kuadrant on Envoy and Istio, generally available in OpenShift AI 3.4) enforces access control, rate limits, and token quotas on every inference call under policies the enterprise writes, and Models-as-a-Service adds per-team keys and showback. That is one leg of a plane, and it acts: it authorizes and blocks requests at runtime, which clears the action line. The architect's concern: it governs model calls, not agents. The MCP Gateway (identity-based tool filtering, OAuth token exchange, agent traceability) is Technology Preview in 3.4, the MCP catalog and lifecycle operator are Developer Preview, and there is no generally available agent identity, agent registry, or cross-agent orchestration. Moderate, at the thin end of the band. Calibration: Nutanix reads moderate on a single generally available gateway (RBAC, per-token rate limits, audit); Cloudflare moderate on a gateway over model calls plus endpoint firewalling; GCP and Azure strong on complete planes; IBM moderate on watsonx Orchestrate's control plane, scored on the IBM row. llm-d's KV-aware request routing is routing, not reasoning; the live per-inference placement gap and the missing deterministic outcome-validator are universal across the instrument, noted rather than charged to Red Hat. The Fourth Cloud assessment scores this layer 0 because it grades autonomous placement reasoning; this instrument grades action governance.

◆ Borrowed Judgment

Low. The gateway is open source the enterprise operates, and it exercises no judgment of its own: it enforces the access, rate, and token policies the enterprise writes. Under the override rule that reads code decides, visible, overridable, Retained, whoever runs the engine, the Azure, Salesforce, and Elastic reading. Cloudflare's and Nutanix's gateways read vendor and Delegated because they make vendor-side routing and failover decisions; this one executes the enterprise's declarative policy.

◆ Working Notes

Watch-list, notes only: the MCP Gateway (Technology Preview in OpenShift AI 3.4), the MCP catalog and lifecycle operator (Developer Preview), and Llama Stack agents. Public evidence that moves the cell: the MCP Gateway reaching general availability, or a generally available agent registry or agent identity on Red Hat's paper.

Layer 3 (+1) · ApplicationsAI Application Layer — The Value PlaneCertified ISV Ecosystem; No Business Applicationsdecides: vendor · Delegated▼

AI-powered business capabilities — business logic, workflow automation

Vendor-Provided

Red Hat Certified Partner Ecosystem (OpenShift and OpenShift AI Certified ISVs; Ecosystem Catalog)Delegated

ISV applications certified on OpenShift and OpenShift AI and deployed as operators under Red Hat's support matrix. Substitutable partners: Delegated.

NVIDIA-Provided

NVIDIA AI Enterprise and Blueprints (Certified Partner)

NVIDIA's software and reference blueprints are among the certified partner offerings on OpenShift; context, not a Red Hat application.

◆ Gap Analysis

Red Hat ships no business applications. Its first-party AI surfaces sit outside rule 8's grade: Ansible Lightspeed and OpenShift Lightspeed are assistants over Red Hat's own automation and console, Developer Hub and Dev Spaces are developer tools, and OperatorHub and the Ecosystem Catalog are distribution. What reaches the buyer at this layer is the certified partner ecosystem: ISVs certified on OpenShift and OpenShift AI, deployable as operators under Red Hat's support matrix. The architect's concern: the applications are the ISVs'. Red Hat supplies the substrate they run on and the certification that they run there, and certification is mostly a support statement rather than procurement on Red Hat's paper. Partner, on rule 8: the layer is addressed through an ISV ecosystem, the Nutanix and VMware reading. Red Hat's Quarkus and JBoss frameworks earn no Layer 3 grade, as VMware's Spring doesn't. IBM's business applications (watsonx Orchestrate domain agents, Maximo, Cognos, Planning Analytics) are credited on the IBM row.

◆ Borrowed Judgment

Distributed across certified ISVs, substitutable at the partner: Delegated, the rule 8 reading. Vendor decides what its platform certifies, visible, overridable by choosing another partner: Delegated, the Nutanix and VMware partner reading.

◆ Working Notes

Public evidence that moves the cell: a first-party business application on Red Hat's paper.

Sources & revision history · v1.0 - 4+1 v2: Split from the IBM Row

Red Hat OpenShift self-managed subscription guide; Red Hat Application Foundations subscription guide; OpenShift AI 3.0, 3.3, 3.4, and 3.5 release notes and documentation (Llama Stack, llm-d, Models-as-a-Service, Data Science Pipelines); Red Hat AI 3 announcement (October 2025); Red Hat AI Inference documentation (tool calling, supported accelerators); IBM documentation on Fusion Data Foundation and the 2022 move of Red Hat storage to IBM; Red Hat Developer articles (RAG on OpenShift AI, the Camel Q2 2026 digest, AI pipelines in OpenShift AI 3.3); the Fourth Cloud Red Hat OpenShift assessment v2.6 (May 29, 2026), including Red Hat vendor feedback; published 4+1 model. v1.0 (/reconcile, October 5, 2026): split from the former IBM / Red Hat OpenShift AI row along the vendor support boundary, every cell graded and reconciled against SUSE, VMware, Nutanix, CoreWeave, NVIDIA, Elastic, Confluent, Cloudflare, and the rescoped IBM row.

4+1 Layer AI Infrastructure Model · Vendor Assessment Series · The CTO Advisor LLC (DBA The Advisor Bench) · thectoadvisor.com