CAP AI Capability, Service Outcome and Demand Management

The capability owner shall maintain a capability register in which each Capability Instance has a unique identifier, a description of the AI work it delivers (training, fine-tuning, inference, data preparation), its physical and logical location (site, hall, pods, clusters), its tenancy model, its lifecycle status, its accountable owner, its Service Outcomes and its current ArchitectureSnapshot reference. The capability owner shall reconcile the register to the scheduler or orchestration inventory and to the facility asset register at no more than the register reconciliation interval and after every material change.

Evidence required: E1 Documentary and declarative; E2 Configuration and technical state; E7 Derived and analytical. Optional: E6. Operating states: NORMAL.

The accountable executive shall appoint, for each Capability Instance, one capability owner with documented authority over the Service Outcomes, impact tolerances, risk acceptance within delegated limits, and the commitment of facility, platform and provider resources needed to meet them. The capability owner shall be identified in the capability register, the RACI and the decision-rights matrix, and a deputy shall be named for EMERGENCY and RECOVERY states.

Evidence required: E1 Documentary and declarative; E6 Human and experiential. Optional: E2. Operating states: NORMAL, EMERGENCY, RECOVERY.

The capability owner shall define lifecycle status values and transition criteria for Capability Instances, shall record each status transition with date, approver and the evidence that the transition criteria were met, and shall not transition an instance to in-service until commissioning acceptance (MCF-CAP-022) is recorded. The assurance programme lead shall use the recorded status to select claim types and Assurance Levels for each assessment.

Evidence required: E1 Documentary and declarative; E3 Operational and observational. Optional: E2, E7. Operating states: NORMAL, TRANSITION.

The capability architect shall maintain, for each Capability Instance, a current ArchitectureSnapshot linked in the assurance graph that identifies the Required Functions of each Service Outcome and the InfrastructureSystems, AssetInstances and Interfaces implementing them, including shared and external elements. The capability architect shall version the snapshot after every material change and shall reconcile it to as-built and as-configured evidence at no more than the architecture reconciliation interval.

Evidence required: E1 Documentary and declarative; E2 Configuration and technical state; E7 Derived and analytical. Optional: E6, E3. Operating states: NORMAL.

The capability owner shall approve, for each Capability Instance, availability Service Outcomes that state the unit of availability (for example fraction of committed accelerators schedulable and healthy, or fraction of inference requests served), the target, the measurement window, the maximum single-interruption duration, permitted exclusions (for example planned maintenance) and the data source for measurement. The capability owner shall ensure the outcomes are consistent with customer commitments (MCF-GOV-019) and impact tolerances (MCF-CAP-010).

Evidence required: E1 Documentary and declarative; E7 Derived and analytical. Optional: E3, E6. Operating states: NORMAL, MAINTENANCE, DEGRADED.

The capability owner shall approve, for each Capability Instance, performance Service Outcomes that state the metric (for example training goodput fraction, median and tail step time, inference latency at a stated percentile, sustained accelerator power without thermal or power throttling), target, measurement method, measurement window, workload or benchmark reference, and the infrastructure conditions under which the target applies. The AI platform owner shall ensure the measurement method is implemented and its data retained.

Evidence required: E1 Documentary and declarative; E7 Derived and analytical. Optional: E3, E4. Operating states: NORMAL, DEGRADED.

The capability owner shall approve, for each Capability Instance, integrity Service Outcomes stating which data and states are protected (model weights, optimiser state, checkpoints, datasets, configuration), the integrity property required (no undetected corruption, verified completeness, version provenance), the detection mechanism expected (checksums, end-to-end verification, accelerator error reporting), the tolerated detection latency and the required response. The data platform owner shall confirm that each detection mechanism exists.

Evidence required: E1 Documentary and declarative; E2 Configuration and technical state. Optional: E7, E6. Operating states: NORMAL, RECOVERY.

The capability owner shall approve, for each Capability Instance, recovery Service Outcomes that state the recovery time objective for restoring a stated fraction of capacity, the recovery point objective (for training expressed as maximum lost training time, driving checkpoint interval; for inference as maximum state or configuration loss), the restoration order of dependent services (facility power, cooling, control plane, storage, fabric, compute, scheduler), and the verification required before declaring recovery. The capability owner shall ensure these outcomes are consistent with impact tolerances and customer commitments.

Evidence required: E1 Documentary and declarative; E2 Configuration and technical state. Optional: E7, E4. Operating states: RECOVERY, FAILED, EMERGENCY.

The accountable executive shall approve criticality criteria that classify Capability Instances, Service Outcomes and Required Functions into defined classes using stated consequence dimensions (safety, customer and contractual, financial, regulatory, reputational, societal dependency) and thresholds. The capability owner shall apply the criteria to every in-scope item, record the class and rationale, and re-apply them after every material change.

Evidence required: E1 Documentary and declarative; E7 Derived and analytical. Optional: E6. Operating states: NORMAL.

The capability owner shall set, and the accountable executive shall approve, for each Service Outcome of each Capability Instance, impact tolerances stating maximum tolerable interruption duration, maximum tolerable capacity reduction and its duration, maximum tolerable loss of work (for example training progress), and tolerated integrity loss, each with units and the operating states to which it applies. Tolerances shall lie within risk appetite limits (MCF-GOV-014) or have governing-body approval of the exceedance.

Evidence required: E1 Documentary and declarative; E7 Derived and analytical. Optional: E6. Operating states: NORMAL, DEGRADED, EMERGENCY, RECOVERY.

The capability owner shall record, for each Service Outcome, the stakeholder groups affected by its failure, the consequence mechanism (for example lost training progress, failed inference for a dependent service, breach of a regulatory obligation), the consequence severity under each operating state and any downstream dependency outside the boundary. The capability owner shall review the analysis with representatives of affected stakeholder groups at least once per planning period.

Evidence required: E1 Documentary and declarative; E6 Human and experiential. Optional: E7. Operating states: NORMAL, DEGRADED, FAILED.

The capability owner shall define priority classes for workloads, tenants and Capability Instances derived from criticality, and the AI platform owner and facility operator shall implement those classes in scheduler pre-emption policies, power-capping and load-shedding sequences and thermal curtailment procedures. The capability owner shall confirm at the priority reconciliation interval that implemented sequences match the defined classes.

Evidence required: E1 Documentary and declarative; E2 Configuration and technical state. Optional: E3, E4. Operating states: NORMAL, DEGRADED, EMERGENCY.

The capacity manager shall establish, for each Capability Instance, a demand baseline derived from telemetry over at least the baseline period, covering electrical demand at rack, row, pod and hall level, heat load to air and to liquid, facility water flow and temperatures, and fabric and storage utilisation. The capacity manager shall state telemetry sources, resolution, gaps and calibration status, and refresh the baseline at the baseline refresh interval and after material change.

Evidence required: E2 Configuration and technical state; E3 Operational and observational; E7 Derived and analytical. Optional: E1. Operating states: NORMAL, MAINTENANCE.

The capacity manager, with the electrical and mechanical leads, shall characterise for each Capability Instance the peak demand and the transient demand profile, stating the maximum step change, ramp rate and repetition frequency of electrical load and heat load, measured at a resolution sufficient to resolve the transients, under representative workloads including job start, synchronous training, checkpointing and job failure. The capacity manager shall provide the characterisation to the POW and THM design owners and to the grid connection owner, and refresh it after any change in accelerator generation, workload type or power-management configuration.

Evidence required: E2 Configuration and technical state; E3 Operational and observational; E7 Derived and analytical. Optional: E4, E1. Operating states: NORMAL, TRANSITION, RECOVERY.

The capacity manager shall maintain a growth forecast for each Capability Instance over the planning horizon stating expected accelerator deployments by generation, power per accelerator and rack, liquid-cooled fraction, fabric and storage scale, with the assumptions and their sources, an uncertainty range, and the date by which each infrastructure commitment must be made given supplier and utility lead times. The capability owner shall approve the forecast and review it against actuals at the forecast review interval.

Evidence required: E1 Documentary and declarative; E7 Derived and analytical. Optional: E3, E6. Operating states: NORMAL.

The capacity manager, with the resilience lead, shall model for each Capability Instance the demand on power, cooling, fabric and storage during the declared recovery and failover scenarios (including restart inrush, checkpoint-restore read bursts, re-scheduling storms and transfer of load to surviving fault domains), shall define the staging that keeps demand within supply during recovery, and shall validate the model and staging in at least one recovery exercise per exercise interval.

Evidence required: E1 Documentary and declarative; E3 Operational and observational; E4 Validation and test; E7 Derived and analytical. Optional: E2, E5. Operating states: RECOVERY, TRANSITION, DEGRADED.

The capability architect shall define, for each Capability Instance, the load envelope: maximum IT power per rack, row, pod and hall, maximum heat load per CDU or liquid loop, and permitted power per accelerator, each derived from the lowest-rated element in the power and cooling path in the declared redundancy state. The AI platform owner and facility operator shall implement enforcement (power capping, admission control for new racks or jobs, alarm thresholds) and shall verify that configured limits equal the envelope.

Evidence required: E1 Documentary and declarative; E2 Configuration and technical state. Optional: E3, E7. Operating states: NORMAL, DEGRADED, MAINTENANCE.

The capability architect shall define, for each Capability Instance, the environmental envelope covering air inlet temperature and humidity, technology cooling system and facility water supply temperature, minimum flow and differential pressure, and coolant quality, derived from accelerator and server OEM specifications and the applicable ASHRAE TC 9.9 classes. The facility operator shall configure BMS and CDU setpoints and alarm thresholds within the envelope and shall reconcile them to the envelope after every OEM specification revision.

Evidence required: E1 Documentary and declarative; E2 Configuration and technical state. Optional: E3. Operating states: NORMAL, DEGRADED.

The capability architect shall state, for each Capability Instance, duration limits for each declared degraded condition: battery autonomy at measured load, thermal ride-through time before equipment limits are reached on loss of chilled or facility water, generator fuel autonomy, and maximum time on reduced redundancy. The facility operator shall validate each limit by test, measurement or validated model at the duration validation interval and after material change, and shall align alarms and runbooks to the validated limits.

Evidence required: E2 Configuration and technical state; E3 Operational and observational; E4 Validation and test. Optional: E1, E5, E7. Operating states: DEGRADED, EMERGENCY, MAINTENANCE.

The capability architect shall define for each Capability Instance the limits applying in each non-normal operating state, including maximum permitted IT load, prohibited activities (for example concurrent maintenance on both power paths, firmware rollouts, large job starts), required approvals and maximum duration. The facility operator and AI platform owner shall implement these limits in maintenance permits, change freezes, scheduler policies and power-capping profiles, and shall record state entry and exit.

Evidence required: E1 Documentary and declarative; E2 Configuration and technical state; E3 Operational and observational. Optional: E6. Operating states: MAINTENANCE, DEGRADED, EMERGENCY, RECOVERY, TRANSITION.

The capability architect shall maintain traceability from each Service Outcome and envelope to design requirements, to as-built records, to commissioning results and to the current operating configuration for each Capability Instance, recording deviations at each stage with disposition. The facility operator and AI platform owner shall provide current configuration evidence for reconciliation at the traceability reconciliation interval.

Evidence required: E1 Documentary and declarative; E2 Configuration and technical state; E4 Validation and test. Optional: E7. Operating states: NORMAL.

The commissioning manager shall plan and execute integrated systems testing for each new or expanded Capability Instance that exercises power, cooling, control systems, compute, storage and fabric together at representative load, including declared failure transfers (for example loss of a UPS module, CDU pump failover, loss of a fabric link) and their effect on Service Outcomes. The capability owner shall sign acceptance only when acceptance criteria tied to Service Outcomes are met or deviations are dispositioned, and shall record the accepted configuration baseline.

Evidence required: E1 Documentary and declarative; E2 Configuration and technical state; E3 Operational and observational; E4 Validation and test. Optional: E5. Operating states: NORMAL, DEGRADED, TRANSITION.

The capability owner shall ensure that every change classified as material for a Capability Instance has a capability impact assessment before approval that identifies affected Service Outcomes, envelopes, fault domains, dependencies, controls, gates and evidence; defines post-change validation; and identifies assurance claims to be suspended or reassessed. The change authority shall not approve a material change without the impact assessment, and the capability owner shall confirm post-change validation before the change is closed.

Evidence required: E1 Documentary and declarative; E2 Configuration and technical state; E3 Operational and observational. Optional: E4, E7. Operating states: NORMAL, TRANSITION, MAINTENANCE.

The capability owner shall approve a retirement plan for each retirement of capability or infrastructure that identifies remaining Service Outcomes affected, dependencies to be removed or transferred, data sanitisation of storage media and accelerator memory, safe isolation and draining of liquid loops and disposal of batteries and coolant, and updates to the capability register, architecture snapshot and assurance graph. The facility operator shall confirm completion of each step with evidence.

Evidence required: E1 Documentary and declarative; E2 Configuration and technical state; E3 Operational and observational. Optional: E5. Operating states: SHUTDOWN, TRANSITION.