FC-0 — Physical & Virtual Substrate

Hardware lifecycle management · score 3, gap structural, DAPM Ceded Oxide achieves the strongest hardware lifecycle integration of any on-premises vendor in this assessment through hardware-software co-design. Every sled and switch includes a hardware Root of Trust (RoT) and an embedded Service Processor replacing the traditional BMC. Firmware updates for sleds, switches, and power shelves are delivered through the same Oxide control plane update mechanism that manages VMs and networking. The control plane provides operator visibility into software version, status, and health for every major rack component through the metrics API. Hardware lifecycle — firmware updates, component health, failure detection — shares one control plane surface with workload provisioning. Gap from 4: Oxide release notes recommend shutting down running instances before system software updates rather than automatically draining and migrating them. This means maintenance and workload continuity are not fully transparent to operators at the hyperscaler benchmark level — operators must coordinate workload shutdown before some platform updates. The hyperscaler benchmark (F1=4) requires firmware and lifecycle updates to be fully coordinated with workload scheduling without operator intervention. Oxide is strong and co-designed at F1=3; the maintenance transparency gap prevents F1=4. Score 3 with Structural gap ownership — full maintenance transparency would require further platform maturity, not a new product acquisition. Two-model consensus (Gemini, ChatGPT) confirms F1=3.

Substrate heterogeneity · score 1, gap structural, DAPM Ceded Oxide intentionally rejects heterogeneous OEM hardware assembly. The platform manages Oxide-designed sleds, switches, storage, firmware, and control plane as one system. It cannot manage Dell, HPE, Lenovo, Supermicro, or third-party accelerator configurations through unified primitives. Within its homogeneous hardware model, Oxide manages its substrate with complete authority — but the instrument measures whether the control plane manages diverse enterprise hardware through unified primitives. Score 1 reflects: unified management of one hardware type. No OEM heterogeneity management. Structural — Oxide's homogeneous design is deliberate. Two-model consensus (Gemini, ChatGPT) confirms F2=1.

Substrate portability · score 0, gap structural, DAPM Ceded Oxide is an on-premises rack product. One deployment model: the enterprise purchases a rack, installs it in their data center, and operates it there. There is no Oxide cloud offering, no Oxide edge variant, no NC2 equivalent. Score 0 reflects this deliberate design scope — Oxide is a private cloud platform, not a hybrid or multi-cloud platform. Application portability derives from standard guest OSes and standard IaC tooling. Oxide exposes a native, OpenAPI-described API with a first-party CLI, SDKs (Rust, Go, TypeScript), and a Terraform/OpenTofu provider. Enterprises use the same Terraform provider and standard VM images across environments — portability is IaC-level, not API-level cloud compatibility. Oxide has no AWS-compatible API surface. Structural — on-premises only is a deliberate product scope decision, not a roadmap gap.

FC-1 — Distributed Data & Context Fabric

Data location and gravity awareness · score 1, gap structural, DAPM Retained Oxide's control plane knows where VMs are placed — which sled hosts which VM instance — and where block storage volumes are provisioned through the metrics API. This is infrastructure topology awareness: the control plane can answer 'which sled is this VM on' and 'which storage pool is this volume in.' It cannot answer 'what data does this volume contain' or 'what regulatory classification applies to this data.' A placement decision requiring data gravity awareness — is this GDPR-regulated data on a GDPR-compliant substrate — cannot be answered by Oxide's control plane. No data catalog. No federated metadata layer across enterprise data types. No programmatic interface for data classification or residency enforcement. The enterprise deploys data catalog tooling on VMs inside the Oxide rack independently of the Oxide control plane. Score 1 reflects infrastructure topology awareness without enterprise data awareness. Structural — Oxide is a compute infrastructure platform. Providing enterprise data catalog capability would require Oxide to become a data platform, which is outside its architectural scope.

Governance and compliance metadata · score 0, gap structural, DAPM Retained Oxide provides a three-tier resource hierarchy: fleet → silo → project. Resource quotas, hard tenancy isolation, and per-silo console and API endpoints are scoped at the silo level — the silo is the hard tenant boundary. The project is the finer-grained resource container within a silo. VPC network isolation enforces network-level tenant separation. These are IaaS-layer tenant isolation primitives — resource limits, network boundaries, and hard multi-tenancy. They are not compliance metadata in the FC-1 F2 sense: Oxide's isolation model does not classify data payloads, tag workloads with regulatory attributes, or propagate compliance metadata to placement decisions. Score 0 reflects: strong IaaS-layer tenant isolation through the silo/project hierarchy; no data-payload compliance metadata or regulatory classification capability. Structural — Oxide is an IaaS substrate; compliance classification is an application-layer responsibility.

Retrieval and context services · score 0, gap structural, DAPM Retained Oxide provides no platform-native managed vector search, embedding management, retrieval pipelines, or RAG services. The 2nd Gen Turin sleds support AVX-512 for CPU-based vector compute — Oxide explicitly positions this for embedding generation, vector operations, and retrieval pipelines including FAISS indexing. The enterprise can deploy Weaviate, Qdrant, Chroma, or FAISS on Oxide VMs and benefit from AVX-512 SIMD acceleration for vector similarity search. This is substrate capability for retrieval workloads, not platform-managed retrieval services. The distinction: Oxide provides the CPU on which the enterprise runs retrieval software; the platform does not manage embeddings, retrieval pipelines, or RAG context as platform services. Score 0 reflects: no platform-native retrieval services. AVX-512 CPU compute is substrate capability. Structural — providing managed retrieval services would require Oxide to ship a data services layer above the IaaS boundary.

Data pipeline and lineage · score 0, gap structural, DAPM Retained Oxide provides no ETL service, no CDC capability, no streaming pipeline infrastructure, no ML pipeline orchestration, and no lineage tracking. The enterprise deploys Kafka, Airflow, Spark, dbt, or equivalent on Oxide VMs — Oxide's AI solutions page explicitly lists these as tooling that runs on Oxide. But running pipeline software on Oxide VMs is the same as running it on any IaaS platform. Oxide provides the compute substrate; the enterprise owns the pipeline operational model. Score 0 reflects: no data pipeline or lineage capability within the Oxide platform. Structural — Oxide is infrastructure, not a data platform.

FC-2A — Infrastructure Orchestration

Workload universality · score 1, gap structural, DAPM Retained Oxide's control plane provisions and manages VM instances natively. Containers and Kubernetes workloads run inside VMs — Kubernetes is not a native Oxide platform service. However, the operational burden of running Kubernetes on Oxide is materially lower than on bare metal OEM servers. Oxide's control plane absorbs the infrastructure layer that Kubernetes must otherwise manage itself: unified firmware and software updates, Service Processor health monitoring, rack-wide fluid resource pool, automatic instance restart on sled failure, anti-affinity placement, and VPC networking. Oxide ships and maintains control-plane-integrated Kubernetes tooling: a Cloud Controller Manager providing LoadBalancer services via Oxide floating IPs and node lifecycle integration; Omni and Rancher provisioning with native integrations. The enterprise still owns and operates the Kubernetes control plane itself — the API server, etcd, scheduler, and all cluster operations. Score 1 reflects: VM workloads are the one workload type the Oxide platform natively orchestrates. Kubernetes operational burden is materially reduced by Oxide's control plane absorption of the hardware infrastructure layer, but Kubernetes remains an enterprise-operated service on Oxide infrastructure, not an Oxide-managed platform service. Structural — Oxide's design scope is IaaS substrate.

Resource lifecycle automation · score 2, gap structural, DAPM Retained Oxide's elastic resource pool draws vCPUs and memory from a fluid rack-wide pool rather than pre-allocating resources to fixed physical sled boundaries. A VM request draws from whatever capacity is available across all sleds in the rack through the custom backplane. Auto-restart policies automatically recover VMs from sled failures by restarting them on available capacity elsewhere in the rack. Anti-affinity groups spread instances across sleds automatically — a sled failure does not take down all instances of a service. This is more demand-driven than traditional hypervisor VM management where operators pre-configure resource pools and balance workloads across hosts manually. Within available rack capacity, resource allocation is automatic and failure recovery is platform-managed. The physical supply chain constraint applies: Oxide cannot provision new sleds in response to workload demand. When the rack's pool is exhausted, no new physical capacity appears. New capacity requires purchasing additional rack hardware. Score 2 reflects the on-premises structural constraint. Oxide's fluid pool architecture is a genuine operational differentiator within the F2=2 band — it eliminates per-host resource pre-staging that operators manage on traditional hypervisor platforms. Structural — physical supply chain constraint applies universally to on-premises platforms.

Policy and quota enforcement · score 2, gap structural, DAPM Retained Oxide provides unified IAM governance through a three-tier hierarchy: fleet → silo → project. Resource quotas and hard tenancy isolation are silo-scoped — the silo provides per-tenant console and API endpoints, hard resource limits, and complete network isolation. The project is the finer-grained resource container within a silo. Four roles apply across all scopes: admin, collaborator, limited_collaborator, and viewer. The limited_collaborator role is a genuine delegation primitive — it allows delegation of instance, disk, snapshot, and image management while retaining network control, enabling teams to self-serve compute without touching network policy. Roles attach to users or IdP groups through SAML+JIT or SAML+SCIM federation. This IAM model applies uniformly across compute (VM instances), storage (block disks, images, snapshots), and networking (VPCs, firewall rules, IP pools) — one policy surface covering all IaaS resource types. Score 2 reflects: genuine unified policy enforcement across all IaaS resource types through the silo/project hierarchy with enterprise IdP federation; limited_collaborator provides meaningful delegation without over-privileging. Gap from 3: policy does not span application-layer workloads running inside VMs — Kubernetes RBAC, database access controls, and application-layer governance are outside the Oxide policy surface. Structural.

Substrate lifecycle integration · score 3, gap structural, DAPM Ceded Oxide integrates hardware lifecycle events into workload management through the Service Processor architecture. Every sled includes a Service Processor that continuously monitors hardware health — power, thermal, component failure — and reports to the control plane. Hardware event integration with workload scheduling: when a sled's Service Processor reports a failure, affected instances transition to failed-state and the control plane automatically restarts them on healthy sleds. Anti-affinity placement ensures restart targets respect workload distribution policies. Unified firmware and software updates execute through one control plane operation — the same system that manages workload placement manages firmware lifecycle. This is the FC-2A F4 function definition met: hardware lifecycle events integrated with workload scheduling through one control plane. Maintenance transparency (live migration during planned maintenance): today, planned system updates require instance shutdown before the update proceeds. Live migration during planned updates — allowing zero-downtime maintenance — is on the Oxide roadmap for H2 2026. This is the gap from 4, not from 3. Score 3 reflects genuine hardware-event-to-workload-scheduling integration through the Service Processor architecture. The live migration gap is a maintenance transparency gap, not a hardware lifecycle integration gap — these are distinct capabilities and should not be conflated. Structural gap from 4: live migration during planned maintenance is Vendor roadmap (H2 2026). Note: v1.1 scored this function at 2 based on release note evidence that instances must be shut down before system updates. That evidence addresses planned maintenance transparency, not hardware failure event integration. The v1.2 correction separates these two distinct capabilities and scores hardware event integration independently. The shutdown-before-update evidence correctly describes the live migration gap but does not negate the Service Processor → auto-restart → anti-affinity integration that meets the FC-2A F4 definition.

Accelerator and GPU management · score 0, gap structural, DAPM Retained Oxide has no GPU sled and no discrete accelerator management capability. The 2nd Gen Turin sleds include AMD EPYC 9005 with AVX-512 — CPU-based vector compute that Oxide explicitly positions for AI inference, RAG, similarity search, and classical machine learning. This is a deliberate architectural position: Oxide's AI compute answer is high-core-count CPU with AVX-512 rather than discrete GPU accelerators. The enterprise can run CPU-based inference (LoRA/PEFT fine-tuned models, XGBoost, FAISS, Weaviate) on Turin VMs and benefit from AVX-512 SIMD acceleration. This is not GPU acceleration and it is not accelerator management. There is no GPU quota management, no MIG partitioning, no multi-tenant GPU isolation, and no GPU scheduling policy — because there are no GPUs to manage. Score 0 reflects: no accelerator management capability in the current product. Structural — Oxide's current architecture is CPU-only AI compute. A GPU sled has not been announced. The $200M Series C may fund GPU hardware development but no timeline or product has been confirmed. If a GPU sled is announced, this gap ownership would move to Vendor roadmap.

FC-2B — Execution & Runtime

Runtime universality · score 1, gap structural, DAPM Retained Oxide executes VM instances natively. Containers execute inside VMs under Kubernetes or another container runtime the enterprise deploys and operates. The Oxide control plane manages VM lifecycle — provisioning, start, stop, restart, snapshot — not container or pod lifecycle. Oxide provides control-plane-integrated Kubernetes tooling (Cloud Controller Manager, Omni/Rancher provisioning) that materially reduces the operational burden of running Kubernetes on Oxide versus bare metal. However, the Kubernetes control plane itself — API server, etcd, scheduler, cluster operations — remains enterprise-operated. Score 1 reflects: VM runtime is natively managed by Oxide. Container and Kubernetes runtime is enterprise-operated on Oxide infrastructure with meaningful platform support. Structural — Oxide's design scope is IaaS substrate.

Persona abstraction at execution · score 2, gap structural, DAPM Retained Oxide provides a self-service developer experience through the control plane API, CLI, and web console — developers provision VM instances, configure networking, attach storage, and manage SSH keys without filing infrastructure tickets. The web console provides operator visibility into sled health, VM placement, and resource utilization. Per-project quotas enforce resource limits for developer self-service without operator intervention. The experience is cloud-like for VM provisioning: comparable to AWS EC2 self-service in pattern and API surface. The gap from 3: persona abstraction at execution exists only for the VM provisioning layer. Developers provisioning containerized applications must stand up their own Kubernetes cluster first — the container persona has no self-service abstraction at the Oxide platform level. Data engineering personas, AI inference personas, and database administrator personas have no Oxide-native self-service abstractions. Score 2 reflects: strong developer persona abstraction for VM provisioning, absent for all workload types above the VM boundary. Structural — extending persona abstraction to container, serverless, database, and AI workload types requires platform layers Oxide does not ship.

Execution lifecycle and observability · score 2, gap structural, DAPM Retained Oxide provides native platform telemetry through Oximeter — the built-in metrics system queried via OxQL (Oximeter Query Language) through the system timeseries API. Oximeter captures VM-level metrics (CPU utilization, memory consumption, disk I/O, network throughput) and rack-level hardware telemetry (sled health, power consumption, thermal state, Service Processor events) — all queryable through the OxQL API without deploying additional tooling inside the rack. Prometheus integration is available through the Oxide OpenTelemetry collector, which re-exports Oximeter metrics in Prometheus exposition format. Grafana is supported directly via a native OxQL data-source plugin — no Prometheus intermediary required. Observability platforms consuming Oxide metrics do not need to run on Oxide VMs; the OxQL API is accessible externally. Gap from 3: what runs inside VMs — application-level traces, container metrics, Kubernetes control plane telemetry, database query performance — is outside Oxide's observability layer. Cross-workload correlation across the application stack requires the enterprise to deploy and operate their own APM tooling (Datadog, Dynatrace, or self-managed Prometheus/Grafana stacks). Score 2 reflects: native platform telemetry through Oximeter/OxQL covering VM and hardware layers, with Prometheus and Grafana integrations. Application-layer observability above the VM boundary remains enterprise responsibility. Structural. Note: v1.1 incorrectly stated Oxide exposes a native Prometheus scrape endpoint and that observability platforms must run on Oxide VMs. Both claims were factually wrong. Oxide's native telemetry system is Oximeter with OxQL; Prometheus is reached through the OpenTelemetry collector bridge.

AI inference and agent execution · score 0, gap structural, DAPM Retained Oxide provides no platform-managed AI inference service. The enterprise deploys vLLM, Ollama, TorchServe, or equivalent on Oxide VMs and runs CPU-based inference using AVX-512 SIMD acceleration on Turin sleds. Oxide explicitly positions the Turin sled for fine-tuned model inference using LoRA and PEFT, expert agents, customer service bots, and recommendation engines — all CPU-based. This is valid inference capability for models that fit within CPU memory constraints. It is not a managed inference service: no token quota management, no rate limiting, no self-service inference endpoints, no showback dashboards, no multi-model serving infrastructure. The enterprise operates the inference stack as software on VMs. Score 0 reflects: no platform-managed AI inference. CPU-based inference on Turin VMs is enterprise-operated software, not a platform service. Structural — providing managed AI inference would require Oxide to ship a services layer above the IaaS boundary.

FC-2C — The Reasoning Plane

Autonomous placement reasoning · score 0, gap structural, DAPM Retained Oxide has no FC-2C reasoning plane. VM placement within the rack uses Oxide's scheduler to allocate resources from the fluid pool — this is demand-driven IaaS scheduling, not autonomous reasoning from data governance metadata. Anti-affinity groups spread instances across sleds based on operator-defined groups — pre-configured rules, not derived placement. When a new GDPR residency constraint arrives, an operator configures VM placement through project and network policy — Oxide's scheduler executes the configuration but does not derive placement from the constraint. Oxide has none of the FC-1 data governance metadata inputs that a reasoning plane would consume, and no reasoning layer that would consume them if they existed. Score 0 reflects: absent. Structural — FC-2C requires FC-1 data governance metadata that Oxide does not provide, and a reasoning layer that Oxide's architectural scope does not include.

FC-3 — Application Distribution and Governance

Application catalog and distribution · score 1, gap structural, DAPM Retained Oxide provides VM images as the application distribution mechanism — custom images can be imported through Packer integration, and the Oxide console provides image management. VM images are the catalog item: the enterprise packages their application as a VM image and deploys instances from it. This is IaaS-layer image distribution, not a platform-native application catalog with operator-encoded Day 2 operational intelligence, versioning governance, dependency resolution, or upgrade path management. There is no equivalent to OperatorHub, VMware Automation catalog, or AWS Service Catalog in Oxide's platform. The enterprise deploys application catalog tooling — Helm, OperatorHub, internal artifact registries — on VMs inside the rack. Score 1 reflects: VM image management as the application distribution mechanism. No governed application catalog with versioning, dependency resolution, or operational intelligence. Structural — Oxide's application distribution scope matches its execution scope: the VM image boundary.

Application lifecycle governance · score 1, gap structural, DAPM Retained Oxide provides no application lifecycle governance at the platform level. There are no upgrade channels, no approval gates, no compliance enforcement for applications, and no audit trails for application changes beyond VM instance state changes in the control plane API. The enterprise deploys application lifecycle governance tooling — OLM, Helm release management, GitOps, CI/CD pipelines — on VMs inside the rack. Score 1 reflects: minimal platform-level application lifecycle governance. VM instance lifecycle (start, stop, restart, delete) is governed by the Oxide control plane; application lifecycle above the VM boundary is the enterprise's operational responsibility. Structural.

Developer experience and self-service · score 2, gap structural, DAPM Retained Oxide provides cloud-like self-service for VM provisioning through the API, CLI, and web console — developers can provision instances, configure networking, attach storage, and manage SSH keys without operator intervention. Terraform and OpenTofu integration enables infrastructure-as-code workflows for VM provisioning. The developer self-service experience for VM workloads is comparable to public cloud IaaS: self-service provisioning, project-level isolation, and resource quota enforcement without ticket queues. The gap from 3: developer self-service exists only for the VM provisioning layer. Developers building containerized applications must operate their own Kubernetes cluster. Developers building AI applications must deploy their own inference stack. Data engineers must deploy their own pipeline tooling. The platform provides no self-service abstractions above the VM boundary. Score 2 reflects: strong developer self-service for VM provisioning, absent for application-layer workload types. Structural — the VM boundary defines the scope of Oxide's developer self-service.

AI application and agent distribution · score 0, gap structural, DAPM Retained Oxide provides no AI application distribution or governance capability. AI applications are deployed as VM images — the enterprise packages their AI application as a VM image and provisions instances. There is no model version tracking, no agent tool authorization, no prompt injection controls, no inference governance, and no AI-specific distribution mechanism at the platform level. Score 0 reflects: no AI application distribution or governance capability within the Oxide platform. Structural.

FC-4 — Integration Fabric

Event fabric and messaging · score 0, gap structural, DAPM Retained Oxide provides no managed event fabric or messaging infrastructure. The enterprise deploys Kafka, RabbitMQ, or equivalent on Oxide VMs — Oxide's AI solutions page lists Apache Kafka as tooling that runs on Oxide. Running messaging software on Oxide VMs is the same as running it on any IaaS platform: the enterprise owns the operational model. Score 0 reflects: no platform-native managed event fabric. Structural.

API management and gateway · score 0, gap structural, DAPM Retained Oxide provides a full VPC networking stack through the Oxide Packet Transformation Engine (OPTE): VPC subnets and routers, firewall rules, internet gateways, ephemeral and floating external IPs, IP pools, and boundary routing with BGP, OSPF, and BFD support via the Maghemite routing daemon. This is enterprise-grade network infrastructure — not a minimal NAT/firewall implementation. Score 0 is correct: Oxide is not an API gateway and provides no API lifecycle management, rate limiting, developer portal, versioning governance, or API-level audit for application APIs. The networking description correction does not affect the score — a complete VPC stack is not API management. Structural.

Workflow and process orchestration · score 0, gap structural, DAPM Retained Oxide provides no workflow or process orchestration capability. The enterprise deploys Airflow, Temporal, or equivalent on Oxide VMs — Oxide's AI solutions page lists Apache Airflow as tooling that runs on Oxide. Score 0 reflects: no platform-native workflow orchestration. Structural.

SaaS and enterprise system integration · score 0, gap structural, DAPM Retained Oxide provides no maintained connectors to enterprise systems of record. The enterprise deploys integration tooling on Oxide VMs. Score 0 reflects: no enterprise system integration capability within the Oxide platform. Structural.

AI-native integration · score 0, gap structural, DAPM Retained Oxide provides no AI-native integration capability — no MCP tool governance, no agent-to-agent identity propagation, no semantic model routing, no AI workflow event streaming. The enterprise deploys AI integration tooling on Oxide VMs. Score 0 reflects: no AI-native integration capability within the Oxide platform. Structural.