FC-0 — Physical & Virtual Substrate

Hardware lifecycle management · score 2, gap closeable, DAPM Delegated MAAS gives Canonical deep bare-metal lifecycle: machines move through a managed lifecycle (enlist, commission, ready, deploy, release) in which commissioning boots an ephemeral image, probes CPU, memory, storage, network, and accelerators, applies baseline firmware settings, and runs hardware health tests; Redfish is preferred over IPMI where available; hardware changes are detected on recommissioning. MAAS support is included per-machine within Ubuntu Pro for Infrastructure — the same boundary as the assessed product. What caps the score at 2 is firmware and driver content: updates run through a commissioning harness in which administrators author their own per-OEM scripts, targeting hardware by PCI ID or model, with the script defining where to obtain proprietary firmware and tools. Canonical publishes example scripts pinning specific Dell and HPE firmware binary URLs against specific mainboard products; the content is enterprise-authored and OEM-supplied, not vendor-maintained. Scaled across a heterogeneous fleet, the enterprise has not automated firmware lifecycle — it has become its own firmware lifecycle vendor with MAAS as the execution harness. The harness automates execution; the expensive part, curation — which firmware, in what order, validated against which OpenStack release — stays with the enterprise as a standing engineering function at full Section 2.6 lifecycle cost. The architectural cap: MAAS and OpenStack are two operational surfaces bridged at deployment time by Juju or Sunbeam, not one surface. Closeable: the enterprise acquires OEM firmware lifecycle tooling and integrates it through the harness, a gap a vendor program that contracts OEM firmware lifecycle would close. The pattern here is abstraction — unify the BMC protocols, leave the firmware content to the enterprise — which is why the firmware-content dependency, not the lifecycle mechanics, sets the ceiling at 2.

Substrate heterogeneity · score 2, gap structural, DAPM Retained Heterogeneity is what MAAS exists to do: it controls machines through standard BMC services (IPMI, Redfish-preferred, PXE), supports chassis controllers and custom BMC plugins, provisions Windows, Ubuntu, CentOS/RHEL, and ESXi across x86, ARM64, POWER, and Z, and inventories accelerators as constraints for machine selection. Accelerator exposure is real: arbitrary PCI devices are whitelisted for passthrough through the Canonical OpenStack manifest (accelerator-vendor-agnostic), and NVIDIA vGPU lands through a supported subordinate charm — with the boundary note that the charm requires the proprietary NVIDIA vGPU software package as a customer-supplied, separately licensed resource, supported under Ubuntu Pro for customers holding current NVIDIA licenses. The score lands at 2 rather than 3 on two facts: the firmware-content dependency established at F1, and the accelerator story being shallow (NVIDIA vGPU plus generic passthrough; no MIG orchestration depth, no AMD or Intel accelerator management beyond passthrough). Decisively, MAAS and the OpenStack control plane are separated planes. Canonical earns full credit for packaging and loses the point for integration: a separated control plane is exactly the pattern this instrument was created to identify, and the same portfolio-versus-platform rationale that excludes multi-product management suites from the instrument caps this function inside it. MAAS is exceptionally capable; it is not integrated. Retained: the function rests on commodity x86 substrate the enterprise can swap across OEMs.

Substrate portability · score 1, gap structural, DAPM Retained Canonical OpenStack is on-prem software by strategic scope: there is no marketed Canonical-OpenStack-on-public-cloud control plane, which is what holds this function at 1. Canonical's edge product is MicroCloud, an LXD-based platform — a different control plane that earns no credit here under the rule that a separate product is not the assessed control plane. Sunbeam's small-footprint deployments shrink the minimum cluster size but do not change the substrate type. Retained by default: nobody has claimed the function, and the enterprise that needs hybrid substrate portability assembles it from tooling outside this product's scope.

FC-1 — Distributed Data & Context Fabric

Data location and gravity awareness · score 1, gap closeable, DAPM Retained The Canonical Observability Stack (Prometheus-based) plus Ceph topology gives the platform infrastructure and storage awareness — which node, which pool, which volume. That is storage awareness, not data awareness, and it holds the function at 1. No catalog anywhere in Canonical's portfolio tells a reasoning plane where enterprise data lives by type, residency, or classification, across structured, unstructured, streaming, transactional, and AI-specific data. A compliance query — where is the PII? — has no programmatic answer at the platform level. The control plane knows where a Cinder volume is; it does not know what is in it. The enterprise acquires cataloging capability (Closeable) and owns the integration.

Governance and compliance metadata · score 1, gap closeable, DAPM Retained OpenStack carries free-form metadata on nearly every resource type — image properties, instance tags, volume metadata, Swift object headers — and even offers an enforcement primitive: Nova scheduler filters such as AggregateImagePropertiesIsolation can route instances whose image carries a given property onto designated host aggregates, and Cinder volume types can pin classified data to specific backends. An operator can build 'PII images land only on hardened hosts' from stock parts. What is missing is everything the function definition asks for. Nothing classifies: the tag is whatever a human typed, with no scanner, no validation, no schema — pii, PII, and personal-data are three different strings the platform carries with equal indifference. Nothing propagates: tag the image and the attached volumes inherit nothing, the network path knows nothing, the object store where output lands knows nothing; the operator re-expresses the policy independently in scheduler filters, volume types, network policy, and object ACLs, and keeps them consistent by hand. Nothing audits: no surface can prove to a compliance officer that everything tagged PII stayed on the hardened aggregate, because the platform does not know the tag is load-bearing. That is the rubric's 1 nearly verbatim: manual compliance tagging, no automatic propagation, operator duplicates policy across enforcement layers. What earns a higher score is an engine that understands the metadata: continuous evaluation of workloads against named compliance frameworks with policy enforced at admission. Canonical's nearest equivalents are Ubuntu Security Guide (CIS and DISA-STIG hardening at the node-OS level — a hardening tool, not a governance surface) and Keystone (access policy, not compliance metadata). The distinction between carrying metadata and understanding it is the function.

Retrieval and context services · score 2, gap opinion, DAPM Delegated The Ubuntu Pro boundary moves this function above the vanilla-upstream baseline of zero. Canonical markets pgvector on Charmed PostgreSQL for vector search and Charmed OpenSearch for GPU-accelerated vector and hybrid search — passing the marketed-vs-possible test — and both deploy on OpenStack with enterprise support under the same per-node subscription, no additional license fees. What Canonical ships are supported vector databases, not retrieval services: there is no managed ingest-chunk-embed-index pipeline, no embedding management, no retrieval orchestration — the enterprise composes and operates the stack via Juju. A 3 on this function would require an actual retrieval pipeline (managed ingest, embedding, and orchestration) with platform-assisted data-services management; Canonical ships the databases a tier below that. The point of FC-1 is feeding FC-2C reasoning, and supported components that nothing consumes do not feed anything. Opinion: closing the gap requires composing components the subscription already covers, no new procurement. Delegated: open source with real alternatives.

Data pipeline and lineage · score 2, gap closeable, DAPM Delegated Charmed Kafka covers streaming (with Kafka Connect stable and MirrorMaker 2 in the current release), Charmed Spark covers processing, and Charmed Kubeflow covers ML pipelines — all supported within the Ubuntu Pro boundary, all lifecycle-managed by their charms. The rubric's 2 describes the result almost verbatim: pipeline capability for some data types, ML tooling present, traditional data pipeline tooling absent. What is missing is what a 3 requires: a maintained connector library (the Kafka Connect integrators Canonical maintains connect Canonical's own portfolio to itself, not a broad third-party catalog), change-data-capture from operational databases, and any lineage capability at all. Closeable: connectors and lineage require capability Canonical does not sell.

FC-2A — Infrastructure Orchestration

Workload universality · score 2, gap structural, DAPM Retained Nova schedules VMs and — genuinely notable — bare metal through the same API via nova-ironic, with one tenancy model carrying both. But Kubernetes arrives as a hosted workload: Magnum-provisioned or Juju-deployed onto Nova instances, with its own scheduler, its own RBAC, and resource sharing only in the accounting sense that the cluster consumes Nova quota. Two scheduling surfaces coexisting without coordination is the rubric's 2 verbatim. The history matters and belongs in the record: OpenStack pioneered multi-workload IaaS and never unified the container plane — not from neglect but from repeated attempts the project walked back. nova-docker tried to make containers a hypervisor type and was abandoned; Zun's native container API never achieved ecosystem traction; Kuryr's unified network plane withered. Magnum is the survivor, and it survived by abandoning the unification goal: launched in 2015 as the container service, it redefined itself within two years as Container Infrastructure Management, and today (2025.1, Cluster-API-driven) it is an actively maintained, native multi-tenant API for provisioning Kubernetes clusters on OpenStack — hosting done well, not container-plane scheduling. The community attempted the unification repeatedly across a decade and the market declined every offer, settling on hosting. Meanwhile the unification has shipped elsewhere, both from below (pulling VMs up into the container platform's API) and from above (an umbrella over both units) — which is what separates a 2 here from a 3, and what makes the gap Structural in its precise sense: not an industry impossibility, but an architecture decision outside this vendor's current scope to reverse. The modern hosting path has at least improved as hosting: Cluster API's OpenStack provider and Canonical's supported, Juju-lifecycled Kubernetes are good hosting. It is still hosting.

Resource lifecycle automation · score 2, gap structural, DAPM Delegated The delivery-model anchor: Canonical OpenStack self-managed automates workload lifecycle within fixed, enterprise-owned capacity. Heat provides auto-scaling within the estate, Masakari provides automated instance HA, charm-driven operations automate scaling, patching, and upgrades. Nothing provisions a physical node that does not exist; the control plane neither owns nor pre-stages the supply chain. Note for completeness: Canonical's Managed OpenStack would not change this score — Canonical operates software on hardware the enterprise still procures, with no pre-staged capacity buffer in the customer facility, so the consumption-model 3 (a managed model with pre-staged capacity) is out of reach in any Canonical delivery mode currently sold.

Policy and quota enforcement · score 2, gap closeable, DAPM Delegated Within its domain, Keystone is a strongly unified policy surface: one tenancy model carrying identity, RBAC, and per-project quotas across compute, storage, network, and bare metal simultaneously, stronger intra-domain unification than this function usually sees. The score nonetheless lands at 2: a 3 requires policy spanning the VM/container divide from one surface, and Canonical's Kubernetes workloads live in a separate policy domain — Kubernetes RBAC and ResourceQuotas the operator keeps consistent with Keystone by hand. Since AI workloads in Canonical's reference architecture land on Kubeflow-on-Kubernetes, the rubric's 2 — AI workloads and traditional workloads have separate quota and policy management that the operator must keep consistent manually — describes the actual deployment. The hosted-Kubernetes seam is scored at full price here, with no carve-out. Exceptional capability inside the domain; minus for the domain boundary.

Substrate lifecycle integration · score 2, gap closeable, DAPM Delegated Masakari provides automated VM evacuation on host failure; planned maintenance is operator-initiated live migration through host maintenance workflows. What is missing for a 3: nothing flows upward from MAAS into scheduling. A hardware health event MAAS detects does not trigger Nova action; firmware operations are planned separately from workload scheduling; there is no automatic cross-workload-type drain. This is the third appearance of the two-plane finding (after FC-0 F1 and F2): MAAS below for metal, OpenStack above for workloads, bridged at deployment time, not integrated at event time. Closeable: the integration is buildable (MAAS webhooks into operator tooling driving Nova APIs) but requires enterprise construction.

Accelerator and GPU management · score 2, gap closeable, DAPM Delegated Two points above the vanilla-upstream baseline of zero, and the Ubuntu Pro verification is what moves it: the NVIDIA vGPU subordinate charm is a validated, supported integration with multi-tenant isolation through vGPU profiles and MIG-backed types, placement traits for GPU-type targeting, and flavor-based allocation, supported under Ubuntu Pro for customers holding current NVIDIA vGPU licenses — the proprietary NVIDIA vGPU manager is a customer-supplied, separately licensed component, a dependency this assessment notes consistently with FC-0 F2. Generic PCI passthrough covers other accelerator vendors without isolation sophistication. What caps it at 2 is scheduling intelligence: a 3 requires GPU-aware automated balancing or fair-share queueing with multi-vendor quota. Canonical has allocation, not arbitration — no queueing, no fair-share, no preemption, no GPU-aware rebalancing. Closeable: arbitration requires tooling Canonical does not ship.

FC-2B — Execution & Runtime

Runtime universality · score 2, gap structural, DAPM Retained A VM-native, containers-in-hosted-Kubernetes architecture, which earns a 2 rather than a 1 on two facts. First, the Kubernetes is first-party: Canonical ships and supports its own Kubernetes inside the same Ubuntu Pro boundary, with Magnum as a native OpenStack API for tenant cluster lifecycle, rather than handing off to a third-party Kubernetes with a separate support relationship. Second, the rubric's 2 requires multiple execution surfaces coexisting under a shared management plane — unified governance above, fragmented execution below — and that sentence nearly describes Juju: one management plane deploying and lifecycling both estates, one support contract, Keystone reaching into Magnum clusters for authentication via the keystone-auth webhook. Under the buyer test, Magnum is the VM-tenancy niche operating correctly: the tenancy layer handing each tenant their own sub-node-granular Kubernetes is the one configuration where hosted Kubernetes is the point rather than the limitation. The execution seam itself is Structural in the vendor-scope sense: a unified surface (VMs as first-class peers of pods in the same namespace and RBAC) is buildable and has been built, but it took owning the platform end to end, and every function such a unification touches becomes Ceded. The choice at this layer: a closed seam inside a closed system, or an open seam inside an open one.

Persona abstraction at execution · score 2, gap opinion, DAPM Delegated Horizon gives developers genuine ticket-free self-service — instances, networks, volumes, Heat stacks — with per-project quotas and application credentials; operators get Horizon administration, Juju status, and COS dashboards; the persona primitives are real. But the abstraction is workload-type-specific: the Kubernetes estate has its own developer interface and toolchain, and security audit surfaces require assembly (CADF audit middleware exists as a primitive; nothing ships turnkey). Primitives present, opinionated implementation not shipped: Opinion, configured from what the subscription already covers.

Execution lifecycle and observability · score 3, gap opinion, DAPM Delegated The strongest function in this row, and the one place the parts-catalog model genuinely pays off — because observability is where Canonical ships an integrated opinion rather than components on either side of a seam. The Canonical Observability Stack is a shipped, supported observability platform — Grafana, Prometheus/Mimir, Loki, Alertmanager, Tempo — and the Juju relation model is what lifts it past telemetry export: charms integrate with COS and bring their own dashboards and alert rules, so the OpenStack services, the Kubernetes estate, and charmed applications land in one Grafana without the enterprise building the correlation surface. Three pillars in standard formats plus partial shipped correlation is the rubric's 3. Lifecycle management is charm-automated across the estate (scaling, upgrades, Masakari HA). Opinion rather than Closeable: the correlation component is usually Closeable for buyers without an existing observability platform, but Canonical ships the platform inside the subscription boundary, so the residual is configuration. Verification flag: Tempo's support status in full COS versus COS Lite should be confirmed before publication.

AI inference and agent execution · score 2, gap mixed, DAPM Delegated The Ubuntu Pro boundary moves this off zero: Charmed Kubeflow ships KServe model serving with Canonical support, plus Charmed MLflow, on the Kubernetes estate — vendor-supported, charm-lifecycled, multi-tenant through namespaces and Kubeflow profiles. Against a deploy-the-serving-runtime-yourself baseline, a supported serving stack is a real point. What it is not is a managed service of the control plane: the enterprise deploys and operates it two layers up, there is no inference API gateway, no token quotas, no model catalog, no showback — nothing answering a platform-native, in-subscription model runtime or models-as-a-service. And agent execution is absent entirely: no agent runtime, no MCP governance, no tool authorization. Mixed gap ownership: the inference residual is Opinion (compose what the subscription already covers); the agent residual is Closeable (nothing in Canonical's portfolio to compose). Verification flag: KServe's inclusion and support depth within Charmed Kubeflow should be confirmed against Canonical documentation.

FC-2C — The Reasoning Plane

Autonomous placement reasoning · score 0, gap structural, DAPM Retained Canonical OpenStack has no reasoning plane, and two anticipated objections are addressed in advance. First, host aggregates and scheduler filters: the AggregateImagePropertiesIsolation mechanism — routing instances whose image carries a given property onto designated host aggregates — is OpenStack's closest approach to metadata-derived placement, and it fails the litmus precisely. The metadata participates in placement only because an operator authored a filter binding that specific property to that specific aggregate; when a new GDPR residency requirement arrives, a human writes new filter configuration. Pre-configured rule dispatch, single workload type, no derivation. The same disposition applies to Juju constraints, MAAS tags and zones, availability zones, and Kubernetes node selectors: operator-authored control primitives, not reasoning. Second, Watcher: OpenStack's optimization service computes and applies resource-optimization actions — consolidation, load balancing — from infrastructure telemetry. That is resource-signal-driven placement, the same mechanism class as any resource-optimization scheduler, which this instrument rules non-qualifying: it optimizes where capacity says to move things; it cannot answer whether this workload, with this data classification, may run in this jurisdiction. No FC-1 metadata exists for it to consume even if it could — the data layer ships no catalog and no compliance fabric, foreclosing the integration question before it is asked. The structural finding is two-fold, stated precisely: the derivation engine is missing industry-wide (the universal structural gap — no on-prem platform ships one, because a unified body is not a brain; resource-signal optimization over a merged estate is still optimization, not reasoning), and OpenStack additionally lacks the unified substrate a derivation engine would act upon. This platform is two steps from FC-2C: the substrate is not unified, and the reasoning plane does not exist.

FC-3 — Application Distribution and Governance

Application catalog and distribution · score 1, gap structural, DAPM Retained Glance images and Heat templates are deployment mechanisms, which the methodology's catalog standard explicitly disqualifies: no publication governance, no consumption governance. The historically interesting note: Canonical does operate a real catalog with channels, versioning, and publication review — Charmhub — but it distributes the platform's own components, not the enterprise's applications. The catalog governs the infrastructure; the tenant estate gets image membership and signature verification. Murano, OpenStack's application catalog project, is retired upstream, and the OpenStack security team advises its complete removal from all deployments — closing the historical objection preemptively. The catalog item available to the tenant estate is the VM image, which the rubric scores at 1.

Application lifecycle governance · score 1, gap structural, DAPM Retained Version tracking exists at the image level — Glance image membership, visibility controls, signature verification — but there is no compliance state tracking, no deprecation enforcement, no platform-level proof that only approved application versions ran. A registry capability, not a governance surface. The enterprise builds lifecycle governance for the tenant estate or operates without it.

Developer experience and self-service · score 2, gap structural, DAPM Retained Horizon is genuine ticket-free self-service — developers provision instances, networks, volumes, and Heat stacks without operator intervention, gated by per-project quotas, with operator visibility through the admin surface. The score lands at 2 rather than 3: a 3 requires intent-based self-service spanning workload types with platform-enforced approval gates. The self-service is real for the IaaS estate and inconsistent beyond it: the Kubernetes estate exposes its own developer experience, and approval workflows are process, not platform policy.

AI application and agent distribution · score 0, gap structural, DAPM Retained No AI-specific distribution or governance capability: no model version tracking at distribution time, no agent tool authorization, no prompt injection controls, no data access scope enforcement, no output audit trails. Kubeflow distributes AI workloads through its own mechanisms on the tenant Kubernetes estate, outside any platform governance model.

FC-4 — Integration Fabric

Event fabric and messaging · score 2, gap mixed, DAPM Delegated A strong 2. Charmed Apache Kafka's current release ships Karapace as a stable schema registry, Kafka Connect stable with maintained integrators, MirrorMaker 2 for replication, Kafka UI, and OAuth integration with the Canonical Identity Platform — all inside the Ubuntu Pro subscription. Schema enforcement shipped, replay native to Kafka, fan-out and delivery guarantees present, identity propagation partially answered. Two facts hold it from a 3: it is a supported stack the enterprise composes and operates — the same in-boundary-composition ceiling applied consistently at FC-1 F3, FC-1 F4, and FC-2B F4, never platform-native — and there is no legacy protocol story at all (no JMS, AMQP, or MQTT product; the RabbitMQ charm exists for OpenStack's internal messaging and is not marketed as a tenant messaging product, so marketed-vs-possible excludes it). Mixed gap ownership: the composition residual is Opinion; the legacy protocol residual is Closeable. Note the identity caveat for the identity plane finding: the OAuth integration propagates Canonical Identity Platform identity, not Keystone identity.

API management and gateway · score 0, gap closeable, DAPM Retained Octavia is network-layer load balancing — SSL termination, balancing, basic limits — disqualified by the rule that network-layer gateway functions are not API lifecycle management. No publication, versioning, access control, transformation, or audit for enterprise APIs anywhere in the Canonical portfolio. The enterprise acquires an API management platform and owns its integration.

Workflow and process orchestration · score 2, gap closeable, DAPM Delegated Kubeflow Pipelines is marketed, supported AI pipeline orchestration within the Ubuntu Pro boundary — the rubric's 2 verbatim: AI pipeline orchestration present, traditional business process orchestration absent. There is no engine for order-to-cash processes, long-running transactions, saga patterns, or compensation logic, and no unified governance spanning AI chains and business workflows. Two boundary notes: Mistral remains maintained upstream but is absent from Canonical's supported set (no charm, not in Sunbeam's plugin list) — the SKU boundary excludes it without prejudice to its upstream health. And the Canonical-maintained Temporal charm is a genuine boundary ambiguity: it exists, Canonical built it and uses it, but it is unmarketed and absent from the data portfolio's support statements; credit waits on Canonical AR's answer to whether it falls inside the all-Canonical-maintained-charms support commitment. Closeable: traditional process orchestration requires acquisition.

SaaS and enterprise system integration · score 1, gap closeable, DAPM Delegated Kafka Connect is a supported integration framework, but the maintained integrators connect Canonical's own portfolio to itself: PostgreSQL, MySQL, S3, OpenSearch, MongoDB. There is no SAP, Salesforce, ServiceNow, Workday, Oracle, or mainframe connector anywhere in the catalog. Framework without maintained system-of-record connectors is the rubric's 1; a 3 would require a broad maintained connector library. Per the methodology, this is the most operationally expensive function in the instrument when absent: every point-to-point integration the enterprise builds on the framework carries full Section 2.6 lifecycle cost.

AI-native integration · score 0, gap closeable, DAPM Retained Nothing: no MCP tool governance, no agent-to-agent identity propagation, no model API federation, no semantic routing, no AI workflow event streaming. The row's classical-integration strength does not extend here: there is no MCP story at all. The enterprise assembles AI integration from open-source components with no platform support.