CMP-01 Compute architecture and configuration
MCF-CMP-001 Accelerator Architecture
Claim designAssurance level AL2Tier CP-1Evidence floor S3Supports CG-08, CG-01
Objective. Establish a documented, approved accelerator architecture that links the Capability Instance's workload (training, fine-tuning, inference) to the accelerator type, memory capacity and bandwidth, scale-up domain size, scale-out fabric, power and cooling envelope, so that compute is sized and constrained by the Service Outcome rather than by procurement availability.
Requirement and evidence
The compute engineering authority shall maintain an accelerator architecture record per cluster stating accelerator model and generation, accelerator memory capacity and bandwidth, scale-up domain size and interconnect, host CPU and memory ratio, scale-out network attachment per accelerator, per-node and per-rack power and heat, and the cooling method required. The AI platform owner shall approve the record and shall confirm its sufficiency against the performance and integrity outcomes defined for the Capability Instance.
Evidence required: E1 Documentary and declarative; E7 Derived and analytical. Optional: E5, E6. Operating states: NORMAL, TRANSITION.
MCF-CMP-002 Node Configuration
Claim implementationAssurance level AL3Tier CP-2Evidence floor S3Supports CG-08, CG-15
Objective. Ensure each compute node's hardware and low-level configuration (BIOS/UEFI settings, BMC configuration, PCIe topology, NUMA and accelerator affinity, NIC attachment, power and thermal limits) matches the approved node specification, because silent configuration drift degrades performance and reliability of collective workloads.
Requirement and evidence
The AI platform operator shall define a node configuration specification per node type and shall verify, at provisioning and at a defined interval, that every node conforms, using automated collection from the BMC (for example via Redfish) and host OS. The AI platform operator shall secure BMC interfaces with unique credentials, management-network isolation and logged access.
Evidence required: E1 Documentary and declarative; E2 Configuration and technical state; E3 Operational and observational. Optional: E4, E6. Operating states: NORMAL, MAINTENANCE.
MCF-CMP-003 Rack-Scale Composition
Claim implementationAssurance level AL3Tier CP-2Evidence floor S3Supports CG-08, CG-06, CG-05
Objective. Ensure rack-scale systems (integrated compute trays, scale-up switch trays, power shelves, busbars, liquid manifolds) are composed, connected and accepted as a unit, with their facility interfaces (power, liquid, network, weight) verified against the facility design.
Requirement and evidence
The AI platform operator shall maintain a rack-scale composition record for each rack type (trays, switch trays, power shelves, manifold and QD layout, cable/backplane mapping) and shall verify each installed rack at acceptance. The facility operator and AI platform operator shall jointly sign the facility interface checklist covering power feeds, liquid connections and flow, floor loading and network uplinks before energisation.
Evidence required: E1 Documentary and declarative; E2 Configuration and technical state; E3 Operational and observational. Optional: E4, E6. Operating states: NORMAL, TRANSITION.
MCF-CMP-004 Approved Baseline
Claim implementationAssurance level AL3Tier CP-2Evidence floor S3Supports CG-02, CG-08, CG-14
Objective. Maintain a single, approved, version-controlled compute baseline (hardware bill of materials, firmware set, driver and runtime stack, OS image, configuration) against which every node can be reconciled and every change can be measured.
Requirement and evidence
The AI platform operator shall publish an approved compute baseline per node type that enumerates hardware components, firmware versions, driver and runtime versions, OS image hash and configuration profile, shall approve changes to it under change control, and shall reconcile the deployed fleet to it continuously, reporting the fraction of nodes on the current baseline.
Evidence required: E1 Documentary and declarative; E2 Configuration and technical state; E3 Operational and observational. Optional: E4, E6. Operating states: NORMAL, MAINTENANCE, TRANSITION.
CMP-02 Cluster and scale-up domains
MCF-CMP-005 Cluster Topology
Claim designAssurance level AL2Tier CP-1Evidence floor S3Supports CG-08, CG-02
Objective. Document the cluster topology (nodes, scale-up domains, scale-out rails, storage attachment, management plane) so that job placement, failure analysis and capacity statements can be reasoned about against physical and logical locality.
Requirement and evidence
The AI platform operator shall maintain a machine-readable cluster topology describing node-to-scale-up-domain membership, node-to-rail and leaf mapping, rack, power and cooling domain of every node, and storage and management attachment. The compute engineering authority shall reconcile the topology with the fabric (NET-01) and facility models at each change.
Evidence required: E1 Documentary and declarative; E7 Derived and analytical. Optional: E2, E5. Operating states: NORMAL, TRANSITION.
MCF-CMP-006 Scale-Up Domain Integrity
Claim effectivenessAssurance level AL5Tier CP-4Evidence floor S4Critical to CG-08Supports CG-09
Objective. Ensure each scale-up domain (the accelerator group joined by the high-bandwidth, low-latency interconnect, from a single node to a rack-scale domain) delivers its rated bandwidth with all links and switches healthy, and that a degraded domain is detected and withdrawn before it slows or corrupts a training job.
Requirement and evidence
The AI platform operator shall validate every scale-up domain at acceptance and at a defined interval by running an all-to-all or all-reduce bandwidth test against the platform's rated performance, shall monitor interconnect link errors, retrains and lane degradation continuously, and shall automatically drain domains that fall below the declared bandwidth threshold or exceed the link-error threshold.
Evidence required: E2 Configuration and technical state; E3 Operational and observational; E4 Validation and test. Optional: E5, E7. Operating states: NORMAL, DEGRADED, RECOVERY.
MCF-CMP-007 Partitioning
Claim implementationAssurance level AL3Tier CP-2Evidence floor S3Supports CG-09, CG-15
Objective. Ensure logical partitions of the cluster (tenant, project, production versus test, accelerator partitioning such as multi-instance modes) are enforced so that one partition's jobs, faults or administrators cannot consume, disrupt or read another's resources.
Requirement and evidence
The AI platform operator shall define partitions with membership, quotas, network and storage isolation, and administrator scope, shall enforce them in the scheduler, fabric and storage configuration, and shall verify enforcement after each change. Where accelerator-level partitioning is used, the AI platform operator shall document its isolation properties as stated by the OEM.
Evidence required: E1 Documentary and declarative; E2 Configuration and technical state; E3 Operational and observational. Optional: E4, E6. Operating states: NORMAL, MAINTENANCE.
MCF-CMP-008 Fault-Domain Design
Claim resilienceAssurance level AL5Tier CP-5Evidence floor S5Critical to CG-09Supports CG-08, CG-03
Objective. Ensure the cluster is laid out so that loss of any single facility or infrastructure fault domain (rack, power feed group, CDU loop, leaf switch, scale-up domain) removes no more than the declared fraction of capacity and does not halt the Service Outcome beyond tolerance.
Requirement and evidence
The compute engineering authority shall map each compute node to its facility and infrastructure fault domains, shall limit the fraction of a Capability Instance's capacity in any single fault domain to the declared maximum, and shall demonstrate, by controlled drain or real event, that loss of a representative fault domain is contained and that jobs resume on remaining capacity within the recovery tolerance.
Evidence required: E1 Documentary and declarative; E2 Configuration and technical state; E4 Validation and test; E7 Derived and analytical. Optional: E3, E5. Operating states: NORMAL, DEGRADED, FAILED, RECOVERY.
CMP-03 Capacity, scheduling and utilisation
MCF-CMP-009 Usable Accelerator Capacity
Claim operationAssurance level AL4Tier CP-4Evidence floor S4Critical to CG-08Supports CG-01
Objective. Measure the accelerator capacity actually usable by the Capability Instance (healthy, schedulable, at rated performance, not thermally or power-throttled) and compare it with the capacity the outcome requires, rather than reporting installed accelerator count.
Requirement and evidence
The AI platform operator shall compute and report, at least daily, usable accelerator capacity as installed accelerators minus those drained, failed, quarantined, under repair, reserved, or throttled below the declared performance threshold, and shall compare it with the outcome's required capacity. The AI platform owner shall be notified when usable capacity falls below the required level.
Evidence required: E2 Configuration and technical state; E3 Operational and observational; E7 Derived and analytical. Optional: E1, E6. Operating states: NORMAL, DEGRADED, MAINTENANCE.
MCF-CMP-010 Scheduler Controls
Claim implementationAssurance level AL3Tier CP-2Evidence floor S3Supports CG-08, CG-15
Objective. Ensure the workload scheduler (for example Slurm or Kubernetes-based schedulers) enforces placement, priority, quota, topology-awareness and health-gating so that jobs land only on healthy nodes in the right topology and privileged scheduler functions are restricted.
Requirement and evidence
The AI platform operator shall configure the scheduler to admit jobs only to nodes passing health checks, to apply topology-aware placement for scale-up and rail locality, to enforce quotas and priorities per partition, and shall restrict scheduler administrative actions (drain, reservation, priority override) to authorised roles with logging. The scheduler control plane shall have documented high availability.
Evidence required: E1 Documentary and declarative; E2 Configuration and technical state; E3 Operational and observational. Optional: E4, E6. Operating states: NORMAL, DEGRADED, MAINTENANCE.
MCF-CMP-011 Resource Reservation
Claim operationAssurance level AL4Tier CP-3Evidence floor S4Supports CG-10, CG-08
Objective. Ensure capacity required for priority outcomes, hot spares and recovery (re-running from checkpoint after failure) is reserved and actually available when needed, rather than consumed by lower-priority work.
Requirement and evidence
The AI platform operator shall reserve accelerator capacity for declared priority outcomes and for recovery (hot spare nodes or scale-up domains), shall verify daily that reservations are intact and healthy, and shall be able to reclaim reserved capacity from lower-priority jobs within the declared time.
Evidence required: E2 Configuration and technical state; E3 Operational and observational; E7 Derived and analytical. Optional: E1, E6. Operating states: NORMAL, DEGRADED, RECOVERY.
MCF-CMP-012 Contention Management
Claim operationAssurance level AL4Tier CP-3Evidence floor S4Supports CG-08
Objective. Detect and manage contention for shared resources (accelerators, fabric, storage bandwidth, power caps) so that one workload's demand does not degrade another priority outcome beyond tolerance, including coordinated facility power capping.
Requirement and evidence
The AI platform operator shall define contention policies (preemption, fair share, bandwidth QoS, power-cap allocation), shall monitor indicators of contention (queue wait, job slowdown, fabric and storage saturation), and shall act when priority outcomes degrade beyond tolerance. Where facility-driven power capping is used, the AI platform operator and facility operator shall agree the capping protocol and its effect on priority outcomes.
Evidence required: E2 Configuration and technical state; E3 Operational and observational; E7 Derived and analytical. Optional: E1, E6. Operating states: NORMAL, DEGRADED, EMERGENCY.
CMP-04 Firmware, driver and compatibility
MCF-CMP-013 Firmware Baseline
Claim implementationAssurance level AL3Tier CP-4Evidence floor S4Critical to CG-08Supports CG-14, CG-15
Objective. Ensure firmware on accelerators, NICs, BMCs, BIOS/UEFI, interconnect switches and power shelves is at approved, authenticated versions across the fleet, because firmware mismatch is a common-mode source of hangs, errors and security exposure.
Requirement and evidence
The AI platform operator shall maintain an approved firmware matrix per node and rack type, shall verify signature or provenance of each firmware image before deployment, shall measure firmware versions across the fleet automatically, and shall remediate drift within the declared time. Where the platform supports it, the AI platform operator shall use device attestation (for example SPDM measurements or TPM-based measured boot) to confirm firmware identity.
Evidence required: E1 Documentary and declarative; E2 Configuration and technical state; E3 Operational and observational. Optional: E4, E5. Operating states: NORMAL, MAINTENANCE, TRANSITION.
MCF-CMP-014 Driver Compatibility
Claim implementationAssurance level AL3Tier CP-2Evidence floor S3Supports CG-08
Objective. Ensure accelerator drivers, communication libraries, runtimes, kernel and container base images form a tested compatible stack, and that workloads run only on stacks in the compatibility matrix.
Requirement and evidence
The AI platform operator shall maintain a compatibility matrix linking firmware, kernel, accelerator driver, communication library, runtime and container base images, shall test each matrix entry before approval, and shall prevent workloads from running on unapproved combinations through image and node labelling.
Evidence required: E1 Documentary and declarative; E2 Configuration and technical state; E3 Operational and observational. Optional: E4, E6. Operating states: NORMAL, TRANSITION.
MCF-CMP-015 Upgrade Testing
Claim effectivenessAssurance level AL5Tier CP-4Evidence floor S4Critical to CG-14Supports CG-09, CG-08
Objective. Ensure firmware, driver and software upgrades are tested on representative workloads and rolled out in stages with soak periods and automatic halt criteria, so that a defective release cannot become a fleet-wide common-mode failure.
Requirement and evidence
The AI platform operator shall test each upgrade on a staging environment with representative workloads (including multi-node collective tests and checkpoint/restore), shall roll out in stages starting with a canary cohort spread across fault domains, shall define soak periods and halt criteria based on error rates and performance, and shall record each stage's go/no-go decision.
Evidence required: E1 Documentary and declarative; E2 Configuration and technical state; E3 Operational and observational; E4 Validation and test. Optional: E5. Operating states: TRANSITION, NORMAL, DEGRADED.
MCF-CMP-016 Rollback Readiness
Claim resilienceAssurance level AL5Tier CP-5Evidence floor S5Supports CG-10, CG-14
Objective. Ensure every firmware and software change can be rolled back to the previous known-good baseline within the declared time, including components where rollback is constrained (anti-rollback fuses, one-way firmware migrations).
Requirement and evidence
The AI platform operator shall define a rollback procedure for each change class, shall identify components where rollback is constrained or impossible and treat them as higher-risk changes, shall retain previous known-good images, and shall test rollback in staging for each change before production rollout.
Evidence required: E1 Documentary and declarative; E2 Configuration and technical state; E3 Operational and observational; E4 Validation and test. Optional: E5, E7. Operating states: TRANSITION, RECOVERY, DEGRADED.
CMP-05 Compute health and observability
MCF-CMP-017 GPU Telemetry
Claim operationAssurance level AL4Tier CP-3Evidence floor S4Supports CG-08, CG-06
Objective. Collect accelerator telemetry (temperature, power, clocks, throttle reasons, memory ECC counts, page/row retirement, interconnect errors, utilisation) at sufficient frequency and completeness to detect degradation and to correlate compute behaviour with facility events.
Requirement and evidence
The AI platform operator shall collect accelerator telemetry from every in-scope accelerator at the declared interval using vendor management interfaces, shall monitor collection completeness, shall time-synchronise telemetry with facility (BMS/EPMS) data, and shall retain it for the declared period.
Evidence required: E2 Configuration and technical state; E3 Operational and observational; E7 Derived and analytical. Optional: E1, E6. Operating states: NORMAL, DEGRADED, MAINTENANCE, EMERGENCY.
MCF-CMP-018 Node Health
Claim operationAssurance level AL4Tier CP-3Evidence floor S4Supports CG-08
Objective. Ensure each node's health is checked before, during and after jobs by automated checks (accelerator diagnostics, memory, interconnect, NIC, storage mount, thermal state) and unhealthy nodes are drained before they cause job failure.
Requirement and evidence
The AI platform operator shall run automated health checks at job prolog/epilog and at a periodic interval, shall define pass criteria per check, shall drain nodes failing a check automatically, and shall track drained nodes to repair or return-to-service.
Evidence required: E2 Configuration and technical state; E3 Operational and observational; E7 Derived and analytical. Optional: E1, E6. Operating states: NORMAL, DEGRADED, MAINTENANCE.
MCF-CMP-019 Error and Degradation Detection
Claim effectivenessAssurance level AL5Tier CP-5Evidence floor S4Critical to CG-08
Objective. Detect accelerator and node errors that threaten job integrity (uncorrectable ECC, rising correctable ECC, memory row remapping exhaustion, vendor fatal error events such as XID-type events, PCIe AER errors, interconnect CRC errors) and silent data corruption, and respond before corrupted results propagate into checkpoints or models.
Requirement and evidence
The AI platform operator shall classify accelerator and node error events by severity with defined automatic actions (drain, reset, RMA), shall trend correctable error rates against thresholds, and shall run periodic silent-data-corruption screening (known-answer tests) across the fleet. The AI platform operator shall link detected corruption to affected jobs and checkpoints for integrity assessment.
Evidence required: E2 Configuration and technical state; E3 Operational and observational; E4 Validation and test. Optional: E1, E5, E7. Operating states: NORMAL, DEGRADED, FAILED.
MCF-CMP-020 Performance Baselines
Claim operationAssurance level AL4Tier CP-3Evidence floor S4Supports CG-08
Objective. Maintain performance baselines (single-accelerator throughput, scale-up bandwidth, multi-node collective bandwidth, representative training step time) so that degradation from hardware, firmware, thermal or fabric causes is detected quantitatively.
Requirement and evidence
The AI platform operator shall define baseline benchmarks per node type and cluster scale, shall run them at acceptance, after changes and at a periodic interval, and shall investigate deviations beyond the declared threshold.
Evidence required: E2 Configuration and technical state; E3 Operational and observational; E7 Derived and analytical. Optional: E1, E6. Operating states: NORMAL, DEGRADED, TRANSITION.
CMP-06 Compute lifecycle and recovery
MCF-CMP-021 Provisioning
Claim implementationAssurance level AL3Tier CP-2Evidence floor S3Supports CG-08, CG-14
Objective. Ensure new and repaired hardware enters service only after verified identity, baseline conformance and burn-in acceptance, so that infant-mortality failures and counterfeit or mis-configured components are caught before production.
Requirement and evidence
The AI platform operator shall provision nodes through an automated pipeline that verifies component identity against the purchase and provenance records, applies the approved baseline, runs a burn-in and acceptance suite (stress, memory, interconnect, thermal, storage) for the declared duration, and records acceptance before the node becomes schedulable.
Evidence required: E1 Documentary and declarative; E2 Configuration and technical state; E3 Operational and observational. Optional: E4, E6. Operating states: TRANSITION, NORMAL.
MCF-CMP-022 Spares and RMA
Claim operationAssurance level AL4Tier CP-3Evidence floor S4Supports CG-10, CG-03
Objective. Ensure spare accelerators, nodes, trays, switch trays, NICs and cables are held in quantities and locations sufficient to restore usable capacity within tolerance, and that RMA turnaround is tracked against supplier obligations.
Requirement and evidence
The AI platform operator shall size spares from observed failure rates and lead times, shall hold spares on site or within the declared logistics time, shall track RMA turnaround against contractual obligations, and shall ensure returned parts are sanitised or tracked under custody.
Evidence required: E2 Configuration and technical state; E3 Operational and observational; E7 Derived and analytical. Optional: E1, E6. Operating states: NORMAL, DEGRADED, RECOVERY.
MCF-CMP-023 Node Rebuild
Claim resilienceAssurance level AL5Tier CP-5Evidence floor S5Critical to CG-10Supports CG-08
Objective. Ensure nodes and scale-up domains can be rebuilt from bare metal to an accepted, schedulable state within the declared time after failure, corruption or mass events (for example after a power or cooling outage), including re-qualification before rejoining production.
Requirement and evidence
The AI platform operator shall maintain an automated rebuild path (image, baseline, configuration, credentials, health and bandwidth re-qualification) that does not depend on services lost in the same event, shall define the rebuild time objective per node and for a mass rebuild of a declared fraction of the cluster, and shall exercise mass rebuild at a defined interval. After facility power or cooling events, the AI platform operator shall re-qualify affected nodes before readmission.
Evidence required: E1 Documentary and declarative; E2 Configuration and technical state; E3 Operational and observational; E4 Validation and test. Optional: E5, E7. Operating states: RECOVERY, FAILED, TRANSITION.
MCF-CMP-024 Secure Retirement
Claim implementationAssurance level AL3Tier CP-2Evidence floor S3Supports CG-02
Objective. Ensure retired or returned compute hardware (nodes, accelerators with memory, BMCs, boot drives, NICs with persistent configuration) is removed from inventory, sanitised, and disposed of with custody, so that data, credentials and model weights are not exposed and the asset register stays accurate.
Requirement and evidence
The AI platform operator shall execute a retirement procedure that revokes credentials and attestation identities, sanitises persistent storage per a recognised sanitisation standard with verification, resets BMC and firmware secrets, updates the asset register and topology, and records custody to disposal or resale.
Evidence required: E1 Documentary and declarative; E2 Configuration and technical state; E3 Operational and observational. Optional: E5, E6. Operating states: SHUTDOWN, TRANSITION.