# Red Hat OpenShift — Fourth Cloud Assessment

*Fourth Cloud Control Plane Assessment — Red Hat Vendor Boundary*

**Version:** v2.4  
**Date:** May 29, 2026  
**Status:** complete  
**Evolution model:** continuous

**Source:** Red Hat OpenShift self-managed subscription guide, Red Hat Application Services subscription guide, OpenShift 4.18/4.21 release notes, OpenShift AI 3.4 GA, Red Hat Summit 2026, IBM Think 2026, Fourth Cloud methodology v2.4, three-model comparative review (Gemini, ChatGPT), Red Hat vendor feedback (May 2026), Red Hat Application Services subscription guide (Sep 2025), Red Hat OpenShift GitOps packaging confirmation, Red Hat Connectivity Link MCP Gateway technical preview documentation


## Summary Finding

Red Hat OpenShift's strongest Fourth Cloud characteristics are at FC-3 and FC-4, anchored by an included federated identity plane that spans orchestration through integration. OperatorHub's operator model — encoding Day 2 operational intelligence in the operator rather than requiring the enterprise to build operational knowledge — is a genuine platform capability included in the base subscription. The Keycloak identity federation plane spanning FC-2A through FC-4 is an included architectural advantage that eliminates the enterprise's need to build cross-layer identity bridges for primary orchestration, execution, application distribution, and integration functions.

The Red Hat vendor boundary is the critical scoping decision in this assessment. Red Hat products requiring additional subscription purchases — OpenShift AI, Ansible Automation Platform, Red Hat Integration — are scored at their product family capability with explicit additional licensing flags. The rationale: all in-scope capabilities share a single Red Hat vendor relationship with no SI gate. IBM watsonx products are out of scope because they represent a separate IBM vendor relationship with a potential SI gate at the Red Hat/IBM boundary. These IBM products are equally deployable on other Kubernetes control planes and do not represent OpenShift-specific advantages.

The additional licensing structure within the Red Hat product family is the primary gap characteristic of this assessment. OpenShift AI (additional Red Hat licensing) closes FC-1 F3, FC-2A F5, FC-2B F4, and FC-3 F4. Ansible Automation Platform (additional Red Hat licensing) closes FC-0 F1 and FC-2A F4. Red Hat Integration (additional Red Hat licensing) provides FC-4 event fabric, API management, workflow orchestration, and system connectors. Each of these is a Red Hat product with a Red Hat support relationship, but each represents an additional procurement decision. The buyer assembling the full Red Hat Fourth Cloud stack makes multiple licensing decisions against a single vendor relationship.

FC-2C is absent. No Red Hat product addresses autonomous placement reasoning from live data governance metadata. Kubernetes scheduling through taints, tolerations, node affinity, and ACM placement policies is sophisticated rule dispatch — operators write placement rules, the platform executes them. The gap between rule dispatch and autonomous reasoning from first principles is the defining FC-2C characteristic, and no on-premises control plane assessed has closed it.

FC-1 is the layer where OpenShift's profile as an application and workload platform is most apparent. Without the IBM watsonx portfolio, OpenShift has infrastructure telemetry and Kubernetes workload governance through ACS, but no enterprise data catalog, no cross-platform data governance, and limited data pipeline capability beyond what Red Hat Integration provides for streaming and ETL patterns. The enterprise buyer requiring a complete Fourth Cloud data fabric must plan for IBM watsonx products as a separate procurement layer.

v2.4 corrections applied following Red Hat vendor review and primary source documentation checks. Eight changes: (1) Red Hat OpenShift GitOps (Argo CD) confirmed included in base OpenShift Container Platform subscription — FC-3 F2 corrected from 2 to 3; gap ownership updated to Opinion. (2) Red Hat Process Automation Manager confirmed transitioned to IBM for new purchases — FC-4 F3 corrected from 3 to 2; gap ownership updated to Closeable (IBM). (3) FC-4 F5 gap ownership corrected from Closeable to Vendor roadmap — MCP Gateway is technical preview in OpenShift AI 3.4 with confirmed active development. (4) FC-4 product names updated throughout — Red Hat Integration (renewals only) replaced with Red Hat Application Foundations (new subscriptions) where applicable. (5) Red Hat SSO renamed to Red Hat build of Keycloak throughout. (6) OpenShell characterization corrected — NVIDIA-founded open source project; Red Hat is a contributor. (7) Scoping note updated to reflect on-premises watsonx dependency on OpenShift substrate — not a score change; surfaces competitive gap closure advantage without crediting IBM capability to Red Hat scores. (8) FC-1 F1, FC-1 F2, FC-2C narratives updated to note on-premises watsonx closure paths are OpenShift-specific — not a score change; consistent with the instrument principle that third-party products requiring a specific control plane as substrate are noted for competitive context without being credited to the control plane score.


## Scoping note

This assessment scores Red Hat OpenShift using the vendor support boundary as the scope line. Red Hat products — including those requiring additional Red Hat subscription purchases — are in scope. The rationale: when something breaks, the enterprise calls Red Hat for all in-scope capabilities. One vendor relationship, no SI gate, regardless of whether the capability requires a separate Red Hat subscription. IBM watsonx products (watsonx.data, watsonx.governance, Confluent, DataStage, Concert, watsonx Orchestrate, IBM Sovereign Core) are out of scope — separate IBM vendor relationship, separate IBM support relationship, and a separate procurement decision from the Red Hat/OpenShift subscription. The instrument scores the vendor boundary, not the ecosystem.

Instrument consumers should be aware of one material fact confirmed during vendor review: on-premises watsonx deployment requires OpenShift specifically. Cloud Pak for Data requires an OpenShift substrate. An enterprise on Nutanix NKP, OpenStack, or any other Kubernetes control plane cannot deploy on-premises watsonx without first adopting OpenShift. This means OpenShift's FC-1 gap closure path — through on-premises watsonx.data for data location awareness and watsonx.governance for compliance metadata — is more capable and more accessible than the gap closure paths available to enterprises on other on-premises Kubernetes control planes. The gaps score the same; the closure options are not equivalent. Enterprises procuring the complete IBM stack — OpenShift as substrate plus IBM watsonx products — should evaluate this as an IBM assessment, not a Red Hat assessment. In that procurement model the FC-1 and FC-2C scores change materially because the full IBM product family from substrate to reasoning plane is in scope. The IBM/OpenShift full-stack assessment is a separate instrument entry. This note does not change any score in this assessment. It is consistent with the instrument's principle that the score reflects what the enterprise receives within the vendor's own subscription boundary. Third-party products that require a specific control plane as substrate are noted where they create a competitive closure advantage — without crediting the third-party capability to the control plane's score.

Additional Red Hat licensing flags reflect the current Red Hat product portfolio as of May 2026. Red Hat Integration is available for subscription renewals only; new subscriptions use Red Hat Application Foundations, which includes streams for Apache Kafka, Red Hat build of Apache Camel, Red Hat 3scale API Management, Red Hat build of Debezium, and Red Hat build of Apicurio Registry. Red Hat Process Automation Manager has transitioned to IBM for new purchases (IBM Process Automation Manager Open Edition). Where additional Red Hat licensing is required, the function narrative flags it explicitly using current product names.


## Identity Plane Continuity

**Score:** 3  
**Classification:** federated  
**Gap ownership:** mixed  
**Layers in plane:** fc2a, fc2b, fc3, fc4  
**Layers siloed:** fc0, fc1, fc2c


Red Hat build of Keycloak is included in the base OpenShift subscription and provides a federated identity plane spanning the orchestration, execution, application distribution, and integration layers. Keycloak federates enterprise identity providers — LDAP, Active Directory, SAML 2.0, OIDC — into the OpenShift Kubernetes RBAC surface. FC-2A: enterprise identity determines namespace access, resource quota application, and operator permissions — natively in the Keycloak plane, included. FC-2B: namespace execution is Keycloak-governed; OpenShift Service Mesh propagates service identity through mTLS within the cluster; service account to Keycloak token exchange for application-layer identity requires configuration of included primitives — Opinion gap. FC-3: application distribution through OperatorHub and Developer Console self-service approval gates (OLM, OPA/Gatekeeper) are Keycloak-governed — included. The FC-3 identity plane membership rests on OLM and the Developer Console, not on GitOps — Red Hat OpenShift GitOps is a separately licensed product and is not credited for identity plane membership. FC-4: 3scale API Management (additional Red Hat licensing, Red Hat Integration) integrates with Keycloak through OAuth 2.0 and OIDC — API caller enterprise identity propagates through the gateway to backend services. 3scale has no community equivalent — this requires additional Red Hat licensing, but the identity propagation capability is genuine and Red Hat-supported. FC-0 is siloed: substrate node compliance tagging connects to workload placement through operator-configured node affinity rules, not through the Keycloak plane — Opinion gap using included primitives. FC-1 is siloed: data governance identity requires additional IBM licensing. FC-2C is siloed: agent identity governance requires additional IBM licensing.


**Buyer implication:** Yes for orchestration, execution, application distribution, and integration layers within the Red Hat product family. An enterprise developer Keycloak-federated identity controls what they deploy in OpenShift (FC-2A), what executes in their namespace (FC-2B), what they can access from OperatorHub and the Developer Console (FC-3), and — with Red Hat Integration — what API calls carry their identity to backend services (FC-4). The identity plane spans these layers without the enterprise building point-to-point identity bridges. Substrate identity control — ensuring a compliance-tagged physical node automatically restricts application runtime execution — requires operator-configured node affinity rules using included OpenShift primitives, an Opinion gap requiring no new capability acquisition. Data governance identity and agent identity require additional IBM licensing.


## Layer-by-layer scoring

| Layer | Avg score | Status |
|---|---|---|
| FC-0 — Physical & Virtual Substrate | 2.33 | Moderate |
| FC-1 — Distributed Data & Context Fabric | 2.25 | Moderate |
| FC-2A — Infrastructure Orchestration | 2.80 | Moderate |
| FC-2B — Execution & Runtime | 3.00 | Strong |
| FC-2C — The Reasoning Plane | 0.00 | Absent |
| FC-3 — Application Distribution and Governance | 3.00 | Strong |
| FC-4 — Integration Fabric | 2.60 | Moderate |

**DAPM profile:** Retained 14 · Delegated 6 · Ceded 6


### FC-0 — Physical & Virtual Substrate

*The physical foundation the control plane lifecycles.*


#### Hardware lifecycle management *(universal)*
**Score:** 2 · **Gap ownership:** closeable · **DAPM:** Delegated

Included: Machine Config Operator (MCO) manages node OS configuration and OS-level updates across the cluster as part of the control plane lifecycle — nodes are drained, OS updated, and rejoined automatically. Metal3 (included for bare metal deployments) extends node lifecycle management to bare metal infrastructure — provisioning, inspection, and decommissioning of bare metal nodes through the Kubernetes-native BareMetalHost CRD. This is meaningful for enterprises running OpenShift on bare metal without a virtualization layer. Kubernetes node health monitoring detects failures and triggers workload recovery. Additional Red Hat licensing required (Ansible): Red Hat Ansible Automation Platform provides OEM firmware lifecycle automation using vendor-specific Ansible collections for Dell, HPE, Lenovo — bringing firmware update scheduling into coordination with OpenShift maintenance mode. With Ansible: MCO + Metal3 + Ansible together constitute the F1=2 anchor — full hardware lifecycle for supported substrate, enterprise retains hardware vendor choice but not management burden. The physical supply chain constraint applies at FC-2A F2, not here — F1 measures lifecycle management of existing substrate, not provisioning of new substrate. Note: OEM-layer compositions such as IBM Fusion HCI and Dell DCAP provide tighter substrate lifecycle integration for their respective hardware platforms when deployed alongside OpenShift — these are additional vendor licensing decisions that do not affect the OpenShift control plane score.


#### Substrate heterogeneity *(universal)*
**Score:** 2 · **Gap ownership:** structural · **DAPM:** Retained

Included: OpenShift runs on Dell, HPE, Lenovo, Cisco, Supermicro, AWS, Azure, GCP, OCI, and IBM Cloud through the same Kubernetes control plane — workload scheduling is unified across heterogeneous substrate at the Kubernetes layer. Node Feature Discovery discovers hardware capabilities and exposes them to the scheduler. NVIDIA GPU Operator (OperatorHub, available without additional licensing) provides basic GPU node management. Additional Red Hat licensing required (OpenShift AI): full multi-accelerator management across NVIDIA, AMD ROCm, Intel Gaudi, and IBM Spyre through unified Kubernetes primitives. Score 2 reflects: workload scheduling is unified across OEM hardware, but hardware management remains OEM-specific. OpenShift has no hypervisor providing a hardware-abstraction layer — Node Feature Discovery and device plugins expose OEM hardware capabilities to the Kubernetes scheduler without abstracting OEM management differences. Operators managing mixed OEM hardware nodes experience unified Kubernetes scheduling but OEM-specific hardware management tooling. The F2=2 anchor applies: single control plane manages multiple OEM hardware types through unified scheduling primitives, but OEM-specific tools surface to operators at the hardware management layer. Structural — architectural constraint of hypervisor-less control planes.


#### Substrate portability *(universal)*
**Score:** 3 · **Gap ownership:** structural · **DAPM:** Ceded

Included: OpenShift runs on-prem (bare metal, virtualized), AWS (ROSA), Azure (ARO), GCP, OCI, IBM Cloud, and edge through the same control plane with the same operational model — Developer Console, Administrator Console, OperatorHub, OLM — consistent across all substrate types. OCI support is confirmed and relevant for enterprises with Oracle estates. Red Hat OpenShift Virtualization Service on IBM Cloud (GA June 2026) extends VM workload support to managed cloud substrate. ROSA on AWS provides genuine elastic node provisioning through cluster auto-scaler — the platform provisions new nodes in response to workload demand on cloud substrate. Gap from 4: each deployment is a separate cluster — a single OpenShift control plane does not span on-prem and cloud under one management boundary. Structural — multi-substrate single-plane management is not productized on any on-premises control plane.


*Notes: FC-0 F1 and F2 both reflect the absence of a hypervisor abstraction layer. OpenShift manages node OS lifecycle through Machine Config Operator and bare metal node lifecycle through Metal3, but hardware-level OEM management remains vendor-specific. Ansible Automation Platform (additional Red Hat licensing) closes the firmware lifecycle gap. Substrate portability is OpenShift's defining architectural strength — the same control plane, operational model, and developer interface runs across on-prem, AWS (ROSA), Azure (ARO), GCP, OCI, and IBM Cloud. ROSA on AWS provides genuine cluster auto-scaler capability where Red Hat and AWS jointly provide elastic node provisioning — a managed offering advantage on cloud substrate.*


### FC-1 — Distributed Data & Context Fabric

*The data fabric the reasoning plane queries — full enterprise data estate.*


#### Data location and gravity awareness *(universal)*
**Score:** 1 · **Gap ownership:** closeable · **DAPM:** Retained

Included: OpenShift monitoring (Prometheus) provides programmatically queryable infrastructure telemetry — node utilization, pod resource consumption. OpenShift Data Foundation (Platform Plus) provides storage topology visibility — which nodes hold which persistent volumes, storage pool utilization. This is storage awareness, not data awareness. The distinction is material for FC-2C placement purposes: the control plane knows where a persistent volume is placed but not what data that volume contains or what regulatory classification applies to it. A placement query asking whether GDPR-regulated data is on a GDPR-compliant node cannot be answered by OpenShift's infrastructure telemetry. Score 1 reflects: programmatic storage topology awareness available, enterprise data catalog absent. Gap closure note: on-premises watsonx.data (IBM licensed, separate IBM vendor relationship) provides a unified data lakehouse with federated catalog spanning structured, unstructured, streaming, and transactional data sources — and on-premises deployment requires OpenShift specifically through Cloud Pak for Data. This gap closure path is an OpenShift competitive advantage versus other on-premises Kubernetes control planes, which cannot deploy on-premises watsonx.data without first adopting OpenShift. The closure path is IBM-licensed and IBM-supported; it does not change this score.


#### Governance and compliance metadata *(universal)*
**Score:** 2 · **Gap ownership:** closeable · **DAPM:** Retained

Included (Platform Plus): Red Hat Advanced Cluster Security (ACS) provides continuous security compliance enforcement against CIS, NIST, PCI DSS, and HIPAA frameworks at the infrastructure and Kubernetes workload level — vulnerability scanning, runtime security policy, network segmentation compliance, image provenance tracking. OPA/Gatekeeper provides policy-as-code admission control across all workload types. These governance capabilities propagate to workload admission enforcement — ACS blocks non-compliant workloads at deploy time and detects violations at runtime. The gap from 3: ACS governs Kubernetes workloads and infrastructure comprehensively but does not govern enterprise data — relational database records, mainframe files, SaaS system data — at the compliance metadata layer. Score 2 reflects ACS's genuine included infrastructure governance — automated compliance enforcement for Kubernetes workloads across industry frameworks. Gap closure note: on-premises watsonx.governance (IBM licensed, separate IBM vendor relationship) provides AI governance and enterprise data compliance metadata spanning the full data estate — and on-premises deployment requires OpenShift specifically through Cloud Pak for Data. This gap closure path is an OpenShift competitive advantage versus other on-premises Kubernetes control planes. The closure path is IBM-licensed and IBM-supported; it does not change this score.


#### Retrieval and context services *(ai-workload)*
**Score:** 3 · **Gap ownership:** opinion · **DAPM:** Delegated

Additional Red Hat licensing required (OpenShift AI): pgvector on OpenShift Data Services Manager provides platform-assisted vector search with Red Hat support. NVIDIA NeMo Retriever integration provides GPU-accelerated retrieval pipelines. Red Hat product — one vendor relationship, no SI gate. Score at product family capability: F3=3 with OpenShift AI flag. Gap from 4: backend options are narrower than hyperscaler managed retrieval services; retrieval configuration requires enterprise setup of existing OpenShift AI primitives rather than fully managed intent declaration. Opinion gap — no new capability acquisition required beyond OpenShift AI subscription.


#### Data pipeline and lineage *(universal)*
**Score:** 3 · **Gap ownership:** opinion · **DAPM:** Ceded

Additional Red Hat licensing required — three Red Hat products compose this score: (1) Red Hat Application Foundations (streams for Apache Kafka): managed Kafka streaming pipeline with schema registry, consumer group management, and Red Hat support SLA — streaming data ingestion and event-driven data movement. (2) Red Hat build of Apache Camel (Red Hat Application Foundations): 300+ Red Hat-maintained connectors for ETL and data movement across SAP, Salesforce, Oracle, and major enterprise systems. (3) OpenShift AI Data Science Pipelines (Red Hat AI Enterprise): Kubeflow-based ML pipeline orchestration with experiment tracking and pipeline lineage for ML artifacts — knowing which pipeline step produced which model artifact. All three are Red Hat products — one vendor relationship, no SI gate. Gap from 4: enterprise data lineage across all data types — knowing which operational database record was used as training input — requires additional IBM licensing. Score 3 reflects the Red Hat pipeline stack: streaming (Kafka), ETL (Camel), and ML pipeline orchestration (OpenShift AI Data Science Pipelines) under one Red Hat support relationship.


*Notes: FC-1 reflects OpenShift's profile as an application and workload platform rather than an enterprise data platform. ACS (Platform Plus) provides genuine infrastructure and workload governance that earns F2=2 — automated compliance enforcement against industry frameworks at the Kubernetes workload layer. The data governance gap at F2 is the enterprise data estate: databases, mainframe records, SaaS data. Red Hat Integration provides a genuine data pipeline capability through Kafka streaming and Camel K ETL that is a Red Hat product family strength. Enterprise data lineage beyond ML pipeline artifacts requires additional IBM licensing.*


### FC-2A — Infrastructure Orchestration

*Unified orchestration of the full enterprise workload portfolio.*


#### Workload universality *(universal)*
**Score:** 3 · **Gap ownership:** structural · **DAPM:** Retained

Included: OpenShift manages containers, VMs (OpenShift Virtualization — KubeVirt CRDs, VMs deployed through kubectl and Kubernetes YAML in the same namespace and RBAC as containers), databases (OpenShift Data Services Manager), and batch jobs (Kubernetes Jobs) through the same Kubernetes API surface. OpenShift Virtualization is included — VMs are Kubernetes-native, not a separate operational domain. All workload types share RBAC, namespace quotas, and network policy. Additional Red Hat licensing required (OpenShift AI): AI workload scheduling through Kueue, multi-accelerator model serving. Score at product family capability: F1=3 with OpenShift AI flag. Gap from 4: GPU scheduling intelligence for the most demanding AI workloads remains partially dependent on accelerator-specific operators. Structural — unified scheduling authority for all workload types at hyperscaler equivalent level is not productized on any on-premises platform.


#### Resource lifecycle automation *(universal)*
**Score:** 2 · **Gap ownership:** structural · **DAPM:** Retained

Included: Kubernetes HPA and KEDA for workload auto-scaling based on resource metrics and custom metrics. Machine Config Operator manages node OS state. OpenShift cluster auto-scaler provisions new worker nodes on cloud substrate (ROSA, ARO, GCP, OCI) in response to workload demand — on cloud substrate this approaches the managed consumption model. On-premises: bounded by available physical nodes, cannot provision new hardware. The physical supply chain constraint applies universally to on-premises deployments regardless of control plane choice. Additional Red Hat licensing (Ansible): partially closes the on-prem gap through infrastructure provisioning workflow automation. Additional IBM licensing for demand-driven automated workload placement is out of scope and does not represent an OpenShift-specific advantage. Single score of 2 reflects the on-premises structural constraint — the platform is scored as a platform, not split by deployment model. Structural on-premises.


#### Policy and quota enforcement *(universal)*
**Score:** 3 · **Gap ownership:** opinion · **DAPM:** Retained

Included: ResourceQuotas, LimitRanges, NetworkPolicies, PodSecurityAdmission, OPA/Gatekeeper admission controllers — consistent policy enforcement across all workload types through the Kubernetes API. Red Hat Advanced Cluster Management (ACM, Platform Plus): multi-cluster policy enforcement — governance policies applied consistently across all OpenShift clusters in the fleet with centralized visibility and drift detection. ACM is a genuine included differentiator at scale: enterprises running OpenShift across multiple sites benefit from centralized fleet-level policy enforcement from a single control plane. Gap from 4: policy propagation across all enforcement layers requires per-layer configuration — admission controllers, ACM governance policies, and network policies are independently configured. Opinion gap — enterprise configures consistent enforcement using included primitives.


#### Substrate lifecycle integration *(universal)*
**Score:** 3 · **Gap ownership:** opinion · **DAPM:** Delegated

Included: Node drain and cordon for planned maintenance — workloads automatically evacuated across all workload types before maintenance. Machine Config Operator manages node OS state changes in coordination with workload drain — a node OS update triggers drain, update, and rejoin automatically. Kubernetes node health monitoring detects failures and triggers workload recovery via pod rescheduling and VM live migration (OpenShift Virtualization). Rolling cluster upgrades with workload continuity. Additional Red Hat licensing required (Ansible): OEM firmware lifecycle automation using vendor-specific Ansible collections — firmware update scheduling coordinated with OpenShift maintenance mode. With Ansible: MCO + Ansible + maintenance mode together approach the F4=3 anchor — planned maintenance triggers automatic workload migration, firmware management partially integrated. Score at product family capability: F4=3 with Ansible flag. Gap from 4: accelerator-specific hardware events (GPU failures) are not fully integrated into scheduling decisions across all accelerator types. Opinion gap — configure NVIDIA GPU Operator integration using existing OpenShift AI primitives.


#### Accelerator and GPU management *(ai-workload)*
**Score:** 3 · **Gap ownership:** opinion · **DAPM:** Retained

Additional Red Hat licensing required (OpenShift AI): Kueue provides native GPU queue management, fair-share scheduling, and multi-tenant quota enforcement across NVIDIA, AMD ROCm, Intel Gaudi, and IBM Spyre. Kueue makes NVIDIA Run:ai optional through Kubernetes-native GPU scheduling — the enterprise governs GPU allocation through Kubernetes primitives without requiring a commercial GPU scheduling layer. Score at product family capability: F5=3 with OpenShift AI flag. Gap from 4: deep GPU scheduling for large-scale distributed AI workloads across multiple nodes still benefits from NVIDIA GPU Operator integration. Opinion gap — Kueue provides the baseline; enterprises configure NVIDIA GPU Operator for advanced patterns using existing OpenShift AI primitives. Capability distinction: OpenShift uses Kubernetes-native queue management with software-enforced scheduling; hypervisor-based platforms use hardware-enforced GPU partitioning. Different isolation models address different enterprise requirements.


*Notes: FC-2A is OpenShift's strongest orchestration layer. The unified Kubernetes control plane across containers, VMs (OpenShift Virtualization), databases, and AI workloads reflects OpenShift's design as a workload-universal platform. ACM multi-cluster fleet governance (Platform Plus) is a genuine included capability for enterprises running OpenShift at scale across multiple sites — fleet-level policy enforcement from a central control plane. The on-premises resource lifecycle automation constraint at F2=2 is structural: on-premises deployments are bounded by available physical nodes. On cloud substrate (ROSA, ARO), cluster auto-scaler provides elastic node provisioning that approaches the managed consumption model.*


### FC-2B — Execution & Runtime

*The execution plane where workloads actually run.*


#### Runtime universality *(universal)*
**Score:** 3 · **Gap ownership:** structural · **DAPM:** Retained

Included: OpenShift executes containers and VMs through the same Kubernetes API surface — KubeVirt CRDs for VMs (kubectl, same namespace and RBAC as containers), standard pod specs for containers, Kubernetes Jobs for batch, OpenShift Data Services Manager for databases. All workload types share the same scheduler, resource pools, and Developer Console. OpenShift Virtualization brings VMs into the Kubernetes-native execution surface — VMs and containers share the same developer toolchain, namespace model, and RBAC governance. Additional Red Hat licensing required (OpenShift AI): managed AI inference through Models-as-a-Service. Score at product family capability: F1=3 with OpenShift AI flag. Gap from 4: AI inference uses a different API surface (Models-as-a-Service API) than kubectl-based workloads — the developer interface for AI inference remains workload-type-specific. Structural — collapsing inference APIs and Kubernetes deployment APIs into a single surface is not productized on any on-premises platform.


#### Persona abstraction at execution *(universal)*
**Score:** 3 · **Gap ownership:** opinion · **DAPM:** Retained

Included: OpenShift Developer Console provides workload-type-agnostic self-service — containers, VMs, database operators, integration components through the same intent-based interface. For VMs: VM instance types (CPU/memory profiles) and image catalog abstract substrate details when pre-configured by operators. ACS (Platform Plus) provides security audit surfaces across all workload types at runtime. OpenShift Dev Spaces (included): governed developer workspaces where AI coding assistants — Claude CLI, GitHub Copilot, Continue, Cline, Roo — inherit the enterprise security posture. Developer AI tool usage is governed by the enterprise security posture without requiring developers to change their toolchain; the security persona gains visibility into AI tool usage across developer teams. Gap from 4: VM workloads expose more network and storage substrate to developers than container workloads when VM instance types are not pre-configured. Opinion gap — extending complete abstraction uses existing OpenShift Virtualization primitives. No new capability acquisition required.


#### Execution lifecycle and observability *(universal)*
**Score:** 3 · **Gap ownership:** mixed · **DAPM:** Delegated

Included: OpenShift monitoring (Prometheus, Alertmanager, Thanos) provides cluster-level metrics across all workload types in standard formats. OpenShift Logging provides log aggregation. OpenShift distributed tracing (Jaeger/Tempo operator through OperatorHub) provides trace data. Three observability pillars — metrics, logs, traces — in standard formats (Prometheus, OpenTelemetry, OTLP). OpenShift Service Mesh (included) provides native correlation at the application request layer — distributed traces across container service-to-service calls are natively correlated. Partial native correlation: container-to-container request paths correlated natively through Service Mesh; VM-to-container and AI-to-container correlation requires enterprise assembly against OpenShift's standard telemetry streams. Gap from 4: cross-workload correlation spanning all workload types in a single surface requires either existing enterprise observability platform integration (Opinion gap) or additional observability platform acquisition (Closeable). Mixed gap ownership.


#### AI inference and agent execution *(ai-workload)*
**Score:** 3 · **Gap ownership:** opinion · **DAPM:** Retained

Additional Red Hat licensing required (OpenShift AI): Models-as-a-Service with token quotas, rate limiting, self-service API keys, showback dashboards, and multi-accelerator model serving across NVIDIA, AMD, Intel Gaudi, IBM Spyre. AI gateway via Connectivity Link (Envoy/Kuadrant/Istio) provides governed access to inference endpoints. OpenShell integration (Red Hat co-engineering with NVIDIA) provides sandboxed agent execution with infrastructure-level policy enforcement. Token quota enforcement and showback dashboards provide AI operational management depth — which teams consumed which model capacity — that is relevant for enterprise chargeback and capacity planning. Score at product family capability: F4=3 with OpenShift AI flag. Gap from 4: inference auto-scaling is Kubernetes-native (HPA/KEDA) rather than serverless — less elastic than hyperscaler managed inference. Model backend breadth is narrower than hyperscaler multi-provider model catalogs. Opinion gap — enterprises configure scaling using existing Kubernetes primitives. Additional IBM licensing required for cross-framework agent orchestration — not an OpenShift-specific capability.


*Notes: FC-2B reflects OpenShift's design as an execution platform for all primary enterprise workload types. The unified Kubernetes API surface across containers and VMs (OpenShift Virtualization) is included and genuine. OpenShift Dev Spaces is a distinctive included capability: governed developer workspaces where AI coding assistants inherit the enterprise security posture. AI inference management at production depth — token quotas, showback dashboards, multi-accelerator serving — requires OpenShift AI (additional Red Hat licensing). Cross-workload observability correlation for non-OpenShift-managed systems requires either existing enterprise observability tooling or additional acquisition.*


### FC-2C — The Reasoning Plane

*Autonomous, policy-driven placement deriving from live data governance metadata.*


#### Autonomous placement reasoning *(universal)*
**Score:** 0 · **Gap ownership:** structural · **DAPM:** Retained

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 and policy expressions authored by operators. OPA/Gatekeeper — admission-time policy enforcement against operator-defined rules. Applying the first-principles derivation test: when a new GDPR residency constraint arrives, an operator writes a new ACM placement rule expressing the GDPR requirement. ACM executes the rule; it does not derive the rule from the constraint. The constraint-to-rule translation is the operator's responsibility. This is sophisticated rule dispatch, not autonomous reasoning. No Red Hat product derives placement from live FC-1 governance metadata without operator rule authoring. Gap closure note: on-premises IBM Concert (the closest available approach to FC-2C) requires OpenShift specifically — making OpenShift the only on-premises Kubernetes control plane with an accessible path toward FC-2C through a cohesive IBM platform. IBM Concert provides demand-driven workload placement optimization (Infrastructure-2C) rather than compliance-metadata-derived placement from FC-1 signals (the full FC-2C definition). This closure path is IBM-licensed and IBM-supported; it does not change this score. Gap ownership Structural: no Red Hat product with a confirmed timeline addresses autonomous placement reasoning from data governance metadata.


*Notes: FC-2C is absent in the Red Hat OpenShift subscription. The technical primitives that an eventual reasoning plane would require — ACM placement policies, OPA/Gatekeeper admission controls, Kubernetes node affinity, ACS compliance enforcement — are present in OpenShift. What is absent is the product that connects these primitives to live FC-1 data governance metadata and derives placement decisions from first principles without operator rule authoring. ACM placement policies are the closest signal: a cluster labeled HIPAA-compliant can receive designated workloads. But when a new GDPR residency constraint arrives, an operator writes a new placement rule — ACM executes it. The constraint-to-rule translation is the operator's job. No Red Hat product with a confirmed timeline addresses autonomous placement reasoning from data governance metadata.*


### FC-3 — Application Distribution and Governance

*The governed surface through which enterprise applications are published, versioned, discovered, and consumed.*


#### Application catalog and distribution *(universal)*
**Score:** 3 · **Gap ownership:** opinion · **DAPM:** Retained

Included: OperatorHub provides a broad platform-native application catalog governed through OLM. Coverage spans databases (PostgreSQL, MySQL, MongoDB, Redis, CockroachDB), messaging middleware (Kafka, ActiveMQ, RabbitMQ operators), security tools (Vault, cert-manager, Falco), AI/ML frameworks (Kubeflow, Ray, MLflow, KServe, NVIDIA GPU Operator), monitoring (Prometheus Operator, Grafana, Jaeger), integration components (Camel K community operator, Debezium CDC), and traditional enterprise application support tooling. Red Hat Marketplace extends to certified third-party applications with formal Red Hat support SLAs. The operator model is a qualitative differentiator: an operator encodes application-specific Day 2 operational knowledge — the PostgreSQL operator knows how to provision replicas, handle failover, manage backups, and upgrade schema. Template-based catalog approaches provide deployment templates without this operational intelligence. Gap from 4: traditional enterprise applications running inside VMs (SAP ABAP, Oracle E-Business Suite, COBOL batch) are governed at the VM level through OLM — the VM is the catalog item, not the application inside it. The application payload inside the VM is governed by its own lifecycle management, not by OLM. Governance applies to the workload container, not the application payload.


#### Application lifecycle governance *(universal)*
**Score:** 3 · **Gap ownership:** opinion · **DAPM:** Retained

Included: Operator Lifecycle Manager (OLM) governs operator versioning, upgrade approval channels (stable, fast, candidate), dependency resolution, and channel-based deprecation across the OperatorHub catalog. ACS (Platform Plus) provides continuous compliance enforcement with drift detection. OpenShift audit logging provides per-resource audit trails across all workload types. Red Hat OpenShift GitOps (Argo CD) is included in the base OpenShift Container Platform subscription — declarative application lifecycle management with every application change tracked in Git, drift detected, and reconciliation logged as audit-trail-as-architecture. The Argo CD Agent component (multi-cluster fleet management) requires OpenShift Platform Plus. Score 3 reflects: OLM provides operator lifecycle governance; included Argo CD provides declarative GitOps lifecycle management with audit trails; ACS provides continuous compliance drift detection. Gap from 4: unified audit trail across all application types — containers, VMs, databases, AI models — in a single correlated surface requires SIEM integration. Opinion gap — enterprises with existing SIEM configure against OpenShift's standard audit telemetry using included primitives.


#### Developer experience and self-service *(universal)*
**Score:** 3 · **Gap ownership:** opinion · **DAPM:** Retained

Included: OpenShift Developer Console provides platform-native self-service across containers, VMs, database operators, integration components through the same intent-based interface. OLM and OPA/Gatekeeper enforce approval gates as platform policy — developers deploy from the approved catalog without manual operator approval for standard containerized and VM deployments. OpenShift Dev Spaces (included): governed developer workspaces where AI coding assistants — Claude CLI, GitHub Copilot, Continue, Cline, Roo — inherit the enterprise security posture. Developer AI tool usage is governed by the enterprise without requiring developers to change their toolchain. Gap from 4: unevenness across traditional enterprise applications and non-operatorized middleware — developers deploying traditional enterprise applications through OpenShift Virtualization experience more substrate-aware workflows than developers deploying containerized applications. Score 3 reflects strong developer self-service for cloud-native and Kubernetes-native workload types with genuine included differentiators. Opinion gap — extending consistent abstraction to all workload types uses existing OpenShift Virtualization primitives.


#### AI application and agent distribution *(ai-workload)*
**Score:** 3 · **Gap ownership:** opinion · **DAPM:** Delegated

Included: AI applications distributed through OperatorHub as standard operators — Kubeflow, Ray, KServe, NVIDIA GPU Operator with catalog governance. No AI-specific governance (model version tracking, agent tool authorization, prompt injection controls) in the base subscription. Additional Red Hat licensing required (Red Hat AI Enterprise — single subscription includes OpenShift + OpenShift AI): Models-as-a-Service governance for inference workloads — model version management, token quota enforcement, self-service API keys with rate limiting. OpenShell (NVIDIA-founded open source project for sandboxed agent execution; Red Hat is a contributor and integrating it with the Red Hat AI platform) provides infrastructure-level policy enforcement for agent workloads. Score at product family capability: F4=3 with Red Hat AI Enterprise flag. Gap from 4: cross-framework agent distribution governing agents from LangFlow, LangGraph, and A2A protocol requires additional IBM licensing — not an OpenShift-specific advantage. Prompt injection controls and output audit trails require configuration of existing ACS and OpenShift audit primitives. Opinion gap — existing Red Hat platform primitives address these without new capability acquisition.


*Notes: FC-3 scores reflect three-model comparative review corrections from v2.1. F1 corrected from 4 to 3: governance applies to the operator or VM wrapper, not to the application payload inside it — traditional enterprise applications inside VMs are governed at the VM level by OLM, not at the application level. F2 corrected from 3 to 2: Red Hat OpenShift GitOps is a separately licensed product; community Argo CD through OperatorHub is the unsupported community path. F3 corrected from 4 to 3: unevenness across traditional enterprise applications and non-operatorized middleware prevents F3=4. OperatorHub's operator model — encoding Day 2 operational intelligence in the operator — remains a genuine qualitative differentiator from template-based catalog approaches within the F1=3 score band. Dev Spaces is an included differentiator at F3.*


### FC-4 — Integration Fabric

*Event bus, API management, workflow orchestration, and system connectors.*


#### Event fabric and messaging *(universal)*
**Score:** 3 · **Gap ownership:** opinion · **DAPM:** Ceded

Additional Red Hat licensing required (Red Hat Application Foundations): streams for Apache Kafka provides managed event streaming with schema registry, consumer group management, and exactly-once delivery semantics — Red Hat support SLA. AMQ broker (included in Red Hat Runtimes, part of Application Foundations) provides JMS, AMQP, MQTT, STOMP, and OpenWire protocol support for enterprise messaging patterns. Both are Red Hat products — one vendor relationship, Red Hat support, no SI gate. Included: OpenShift Serverless (Knative Eventing) provides cluster-internal event routing — intra-cluster only, not enterprise event bus. Community Kafka operator through OperatorHub available without additional licensing — community support, no Red Hat SLA. Score at product family capability: F1=3 with Red Hat Application Foundations flag. Gap from 4: mainframe messaging depth at full protocol integration requires additional IBM tooling — not an OpenShift-specific capability. Note: Red Hat Application Foundations is designed and validated for OpenShift — operator installation, OLM lifecycle, and certificate management are OpenShift-native, providing lower integration friction than deploying the same products on other Kubernetes control planes.


#### API management and gateway *(universal)*
**Score:** 3 · **Gap ownership:** opinion · **DAPM:** Ceded

Included (Platform Plus): OpenShift API Management up to 100,000 API calls per day — developer tier only, insufficient for enterprise production scale. OpenShift Service Mesh provides service-level API governance within the cluster. Additional Red Hat licensing required (Red Hat Application Foundations): Red Hat 3scale API Management provides full API lifecycle — publication workflow, versioning governance, developer portal, access control, rate limiting at enterprise scale, transformation, and analytics for internal and external APIs. 3scale integrates with Red Hat build of Keycloak through OAuth 2.0 and OIDC — API caller enterprise identity propagates through the gateway to backend services, originating identity surviving API gateway traversal. Red Hat product — one vendor relationship, Red Hat support, no SI gate. Score at product family capability: F2=3 with Red Hat Application Foundations flag. Gap from 4: serverless scaling and transformation pipeline depth are narrower than hyperscaler API gateway services. Opinion gap — enterprises configure 3scale capabilities using existing Red Hat Application Foundations primitives.


#### Workflow and process orchestration *(universal)*
**Score:** 2 · **Gap ownership:** closeable · **DAPM:** Ceded

Included: Community Camel K operator through OperatorHub — basic integration workflow patterns, community-maintained connectors, no Red Hat support SLA. OpenShift Pipelines (Tekton) — CI/CD pipeline automation, not business process orchestration. Additional Red Hat licensing required (Red Hat Application Foundations): Red Hat build of Apache Camel provides cloud-native integration workflow orchestration with 300+ Red Hat-maintained connectors, long-running process patterns, and Red Hat support SLA — covering event-driven integration workflows and ETL orchestration patterns. Score 2 reflects: Red Hat build of Apache Camel provides genuine cloud-native workflow orchestration within the Red Hat Application Foundations subscription. Gap from 3: BPMN-compliant business process orchestration — approval workflows with saga patterns, compensation logic, long-running human task management — is not available as a Red Hat product for new subscriptions. Red Hat Process Automation Manager has transitioned to IBM for new purchases (IBM Process Automation Manager Open Edition). This requires a separate IBM vendor relationship. Gap ownership Closeable through IBM Process Automation Manager Open Edition (separate IBM procurement) or third-party BPMN tooling deployed on OpenShift. Score corrected from v2.3 F3=3 following confirmation that Red Hat Process Automation Manager is no longer available for new Red Hat subscriptions.


#### SaaS and enterprise system integration *(universal)*
**Score:** 3 · **Gap ownership:** opinion · **DAPM:** Ceded

Additional Red Hat licensing required (Red Hat Application Foundations): Red Hat build of Apache Camel provides 300+ Red Hat-maintained connectors spanning SAP, Salesforce, ServiceNow, Oracle, Workday, IBM MQ (protocol-level), Slack, GitHub, Microsoft 365, and major SaaS platforms. Red Hat build of Debezium (included in Application Foundations) provides CDC capability — row-level database change capture for streaming enterprise data changes to downstream consumers. Red Hat maintains these connectors under support SLA — when an upstream API changes, Red Hat updates the connector. Included: community Apache Camel connectors available through OperatorHub without additional licensing — community-maintained, no Red Hat SLA for connector updates. Enterprise production system integration requires the Red Hat Application Foundations subscription for support guarantees. Red Hat product — one vendor relationship, no SI gate. Score at product family capability: F4=3 with Red Hat Application Foundations flag. Gap from 4: deep mainframe integration (CICS transactions, z/OS data sets, IMS databases beyond IBM MQ protocol support) requires additional IBM tooling — not an OpenShift-specific advantage. Opinion gap for primary enterprise connectors — Red Hat maintains them under the support SLA.


#### AI-native integration *(ai-workload)*
**Score:** 2 · **Gap ownership:** vendor-roadmap · **DAPM:** Delegated

Included: OpenShift Service Mesh (Istio) provides service-to-service mTLS governing AI service calls within the cluster — basic intra-cluster AI service governance. Additional Red Hat licensing required (Red Hat AI Enterprise): Connectivity Link (Envoy/Kuadrant/Istio) provides managed AI gateway with rate limiting, token quota enforcement, and access control for inference endpoints — AI-specific API management built on the same Istio/Envoy foundation as OpenShift Service Mesh. Connectivity Link manages AI inference API access at the gateway level and is included in OpenShift AI 3.4 at no additional cost beyond Red Hat AI Enterprise. MCP Gateway (built on Kuadrant/Envoy, developed with OpenShift networking team): provides identity-based tool filtering so agents only see authorized tools, OAuth2 token exchange for scoped per-backend access, credential management for sensitive tool calls, and MLflow integration for end-to-end agent traceability. MCP catalog in OpenShift AI provides a governed, centralized space for validated MCP server discovery, deployment, and lifecycle management. Current GA status: Connectivity Link inference gateway is GA in OpenShift AI 3.4. MCP Gateway is technical preview in OpenShift AI 3.4; MCP catalog and MCP lifecycle operator are developer preview. Score 2 reflects GA Connectivity Link inference endpoint governance. Gap from 3: MCP Gateway — which would provide full tool-level filtering, agent identity propagation, and audit trails — is technical preview. Vendor roadmap: MCP Gateway capability is confirmed in active development with technical preview status; GA expected in a near-term OpenShift AI release.


*Notes: FC-4 product names updated following Red Hat vendor feedback. Red Hat Integration is available for renewals only; new subscriptions use Red Hat Application Foundations (streams for Apache Kafka, Red Hat build of Apache Camel, Red Hat 3scale API Management, Red Hat build of Debezium, Red Hat build of Apicurio Registry). Red Hat Process Automation Manager has transitioned to IBM for new purchases — FC-4 F3 score corrected from 3 to 2 as a result. FC-4 F5 gap ownership corrected from Closeable to Vendor roadmap: Red Hat's MCP Gateway (Connectivity Link-based) provides identity-based tool filtering, OAuth2 token exchange, and credential management — currently in technical preview in OpenShift AI 3.4. This capability would move FC-4 F5 to 3 when GA.*