15 domains · AI technology chain

STO AI Storage and Data Infrastructure

6 families and 24 controls. Critical to CG-08 Compute, storage and network functional integrity, CG-09 Failure containment, CG-10 Recovery readiness.

STO domain guide See it in the explorer

Proposed text. Requirements are from registry v1.1 (status CANDIDATE), proposed under amendment AMD-002. Intervals and thresholds are set by the assessed organisation in its capability profile. The approved v1.0 baseline uses the same identifiers.

STO-01 Storage architecture and tiering

MCF-STO-001 Training Data Tier

Claim designAssurance level AL2Tier CP-1Evidence floor S3Supports CG-08, CG-01

Objective. Ensure the storage tier holding training and fine-tuning datasets is designed for the read pattern of data loaders at cluster scale, preserves dataset versions and lineage, and keeps data within declared sovereignty and residency boundaries.

Requirement and evidence

The storage engineering authority shall document the training data tier (system type, for example parallel file system or object store with cache; capacity; read throughput per accelerator; dataset versioning and lineage mechanism; locations and jurisdictions of every copy). The data owner shall approve the residency and sovereignty constraints and shall confirm that every copy, cache and replica lies within them.

Evidence required: E1 Documentary and declarative; E7 Derived and analytical. Optional: E2, E5. Operating states: NORMAL, TRANSITION.

MCF-STO-002 Checkpoint Tier

Claim designAssurance level AL2Tier CP-1Evidence floor S3Supports CG-08, CG-10

Objective. Ensure the checkpoint tier is sized so that model and optimiser state can be written within the declared checkpoint window at the declared interval, with the interval chosen against observed failure rates, and that checkpoints are placed in a fault domain independent of the compute they protect.

Requirement and evidence

The storage engineering authority shall document checkpoint size per job class, required write bandwidth (checkpoint size ÷ checkpoint window), checkpoint interval and its derivation from job-level failure rate and checkpoint cost, retention count, and the fault-domain separation between the checkpoint tier and the protected compute. The AI platform operator shall confirm the parameters per production job class.

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

MCF-STO-003 Model and Artifact Tier

Claim implementationAssurance level AL3Tier CP-2Evidence floor S3Supports CG-08, CG-10

Objective. Ensure trained models, adapters, tokenisers, configurations and release artefacts are stored in a versioned, access-controlled, integrity-protected registry from which deployments and recoveries draw known-good, hash-verified artefacts.

Requirement and evidence

The AI platform operator shall store model and release artefacts in a registry that assigns immutable versions, records content hashes and provenance (training run, dataset version, checkpoint), restricts write and delete to authorised roles, and verifies hashes at deployment. The storage service owner shall protect the registry under MCF-STO-013 to MCF-STO-016.

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

MCF-STO-004 Archive Tier

Claim implementationAssurance level AL3Tier CP-2Evidence floor S3Supports CG-10

Objective. Ensure long-term retention of datasets, model versions and checkpoints needed for reproducibility, audit or regulatory purposes is held on a durable archive tier with defined retention, retrievability, integrity checking and media-refresh plans.

Requirement and evidence

The storage service owner shall define retention classes for archived AI data, shall store archives with fixity checks and at least the declared number of geographically or administratively separate copies, shall test retrieval at a defined interval, and shall plan media or format migration before end of support.

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

STO-02 Performance and capacity

MCF-STO-005 Throughput and IOPS

Claim effectivenessAssurance level AL5Tier CP-5Evidence floor S4Critical to CG-08

Objective. Demonstrate that the storage system delivers the aggregate read throughput for data loading and the aggregate write throughput for checkpointing that the outcome requires, at full cluster concurrency and in degraded states (failed server, rebuild in progress).

Requirement and evidence

The storage engineering authority shall demonstrate, by benchmark at acceptance and after material change, that aggregate read and write throughput and IOPS meet the required values at the declared client concurrency, including with one storage server or enclosure failed and during erasure-coding or RAID rebuild. The AI platform operator shall measure production checkpoint write times and compare them with the window in MCF-STO-002.

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

MCF-STO-006 Metadata Performance

Claim operationAssurance level AL4Tier CP-3Evidence floor S4Supports CG-08

Objective. Ensure metadata operations (open, create, stat, list) scale to the concurrency of AI jobs, because many-small-file datasets and synchronous checkpoint creation can saturate metadata services and stall entire clusters.

Requirement and evidence

The storage service owner shall define required metadata operation rates and latency at peak concurrency, shall monitor metadata latency and queue depth continuously, and shall apply workload guidance (file packing, sharded checkpoints, directory fan-out limits) agreed with the AI platform operator.

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

MCF-STO-007 Capacity Headroom

Claim operationAssurance level AL4Tier CP-3Evidence floor S4Supports CG-08

Objective. Maintain free capacity above the level at which the storage system's performance, rebuild ability or checkpoint retention degrade, so that capacity exhaustion never halts checkpointing.

Requirement and evidence

The storage service owner shall define a capacity headroom threshold per tier that accounts for performance degradation at high fill, rebuild space and retention of N checkpoints, shall alert at warning and critical thresholds, and shall enforce quotas so that one job or tenant cannot exhaust a shared tier.

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

MCF-STO-008 Burst Handling

Claim effectivenessAssurance level AL5Tier CP-4Evidence floor S4Supports CG-08, CG-09

Objective. Ensure the storage system absorbs synchronised write bursts (many ranks checkpointing simultaneously, several jobs checkpointing at once, restart storms after an outage) without timeouts, job failure or degradation of other tenants.

Requirement and evidence

The storage engineering authority shall characterise peak burst demand (concurrent checkpoints, restart read storm), shall provide burst absorption (client-side or burst-buffer tier, QoS, admission control or staggered checkpoint scheduling), and shall demonstrate by test or production evidence that the declared burst completes within the window without client timeouts or impact beyond tolerance on other workloads.

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

STO-03 Integrity and consistency

MCF-STO-009 Data Integrity

Claim effectivenessAssurance level AL5Tier CP-5Evidence floor S4Critical to CG-08

Objective. Ensure data, checkpoints and model artefacts are protected end-to-end against undetected corruption from client to media and back, so that silent corruption cannot enter training or deployment.

Requirement and evidence

The storage engineering authority shall implement end-to-end integrity protection (application or file-level checksums on checkpoints and artefacts, plus storage-level checksums or protection information) and shall verify checksums on read and on restore. The AI platform operator shall verify checkpoint checksums before resuming training from them and shall treat a verification failure as an integrity incident.

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

MCF-STO-010 Metadata Integrity

Claim effectivenessAssurance level AL5Tier CP-5Evidence floor S4Critical to CG-08Supports CG-10

Objective. Ensure file-system or object-store metadata (namespace, layout, allocation, object maps) is protected, consistent and recoverable, because metadata loss can render intact data unreachable for the whole tier.

Requirement and evidence

The storage engineering authority shall protect metadata with redundancy independent of the data path (replicated metadata servers or volumes), shall run consistency checks at a defined interval, shall back up metadata where the platform supports it, and shall demonstrate metadata service failover and recovery on a test system or in a controlled test.

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

MCF-STO-011 Checksum and Scrubbing

Claim operationAssurance level AL4Tier CP-3Evidence floor S4Supports CG-08

Objective. Detect latent media and data errors before they are needed by scrubbing stored data and verifying checksums on a schedule that completes within the declared cycle.

Requirement and evidence

The storage service owner shall schedule scrubbing so that all data on in-scope tiers is verified within the declared cycle, shall monitor scrub completion and error rates, and shall repair detected errors from redundancy promptly.

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

MCF-STO-012 Configuration Consistency

Claim implementationAssurance level AL3Tier CP-2Evidence floor S3Supports CG-14, CG-08

Objective. Ensure storage configuration (protection schemes, quotas, exports, client mount options, QoS, replication policies, retention locks) matches the approved baseline across all storage systems and clients.

Requirement and evidence

The storage service owner shall maintain an approved storage configuration baseline, shall detect drift automatically, shall apply changes under change control with post-change verification, and shall verify client mount options and versions across the fleet.

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

STO-04 Protection and replication

MCF-STO-013 Snapshot Protection

Claim operationAssurance level AL4Tier CP-3Evidence floor S4Supports CG-10

Objective. Ensure snapshots of datasets, artefact registries and checkpoint directories are taken at the declared frequency, retained, protected from deletion by ordinary users, and actually restorable, to recover from accidental deletion or logical corruption.

Requirement and evidence

The storage service owner shall configure snapshot schedules and retention per protected namespace, shall restrict snapshot deletion to authorised roles, shall monitor snapshot success, and shall restore from snapshot on a sample basis at a defined interval.

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

MCF-STO-014 Replication

Claim resilienceAssurance level AL5Tier CP-5Evidence floor S5Supports CG-10, CG-09, CG-03

Objective. Ensure data required for recovery is replicated to a target in an independent fault domain (another hall, site or region) within the declared recovery point objective, within permitted jurisdictions, and that replication lag and failures are detected.

Requirement and evidence

The storage service owner shall define replication scope, target, mode (synchronous or asynchronous) and RPO per data class, shall place targets outside the source's power, cooling, network and administrative fault domains as declared, shall keep targets within permitted jurisdictions, shall monitor lag, and shall demonstrate failover or restore from the replica.

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

MCF-STO-015 Erasure Coding

Claim resilienceAssurance level AL5Tier CP-5Evidence floor S5Critical to CG-09Supports CG-08

Objective. Ensure erasure coding or RAID protection is configured so that stripes span independent failure domains (drive, server, enclosure, rack) and tolerate the declared number of concurrent failures, with rebuild completing before a further failure is likely.

Requirement and evidence

The storage engineering authority shall document the protection scheme per tier (for example k+m), the failure domains across which stripes are placed, the number of concurrent domain failures tolerated, and expected rebuild time at current capacity; shall verify placement against physical topology; and shall demonstrate rebuild of a failed component within the declared time.

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, RECOVERY.

MCF-STO-016 Immutable Recovery Copy

Claim resilienceAssurance level AL5Tier CP-5Evidence floor S5Critical to CG-10Supports CG-15

Objective. Ensure at least one copy of recovery-critical data (latest good checkpoints, model artefacts, key datasets, storage and platform configuration) is immutable for its retention period and held in a separate administrative and fault domain, so that ransomware, privileged-account compromise or operator error cannot destroy every copy.

Requirement and evidence

The storage service owner shall maintain an immutable recovery copy of declared recovery-critical data with retention locks that cannot be shortened by administrators of the primary system, in a separate administrative domain with separate credentials, and shall demonstrate restore from it within the declared time.

STO-05 Checkpoint and recovery services

MCF-STO-017 Checkpoint Durability

Claim effectivenessAssurance level AL5Tier CP-5Evidence floor S4Critical to CG-08Supports CG-10

Objective. Ensure each checkpoint is complete, consistent across all shards and ranks, durably committed and verifiable before it is marked good and before older checkpoints are deleted.

Requirement and evidence

The AI platform operator shall mark a checkpoint good only after all shards are written, flushed to durable storage, checksummed and manifest-recorded; shall never delete the previous good checkpoint until the new one is verified; and shall retain the declared number of good checkpoints. The storage service owner shall ensure the checkpoint tier honours flush semantics.

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

MCF-STO-018 Restart Readiness

Claim resilienceAssurance level AL5Tier CP-5Evidence floor S5Critical to CG-10

Objective. Ensure a training or fine-tuning job can be restarted from its latest good checkpoint on available capacity (including a different set of nodes or a reduced node count where the framework supports re-sharding) within the declared restart time objective.

Requirement and evidence

The AI platform operator shall maintain restart procedures and automation for production job classes, shall verify that checkpoints can be loaded on a different node set, shall measure time from failure to resumed training, and shall exercise restart at a defined interval including after a storage or facility event.

MCF-STO-019 Storage Recovery Sequencing

Claim resilienceAssurance level AL5Tier CP-5Evidence floor S5Supports CG-10, CG-09

Objective. Ensure that after a site, power or cooling event, storage services are brought back in a defined order (power and cooling verified, network and time, identity, metadata services, data servers, consistency checks, client mounts, then job readmission) so that recovery does not corrupt data or stall on hidden dependencies.

Requirement and evidence

The storage service owner shall maintain a storage recovery sequence with prerequisites, hold points and verification checks for each step, aligned with facility (THM/POW) and compute (CMP) recovery, and shall exercise it at a defined interval.

Evidence required: E1 Documentary and declarative; E2 Configuration and technical state; E3 Operational and observational; E4 Validation and test. Optional: E5, E6. Operating states: RECOVERY, FAILED, SHUTDOWN.

MCF-STO-020 Recovery Validation

Claim resilienceAssurance level AL5Tier CP-5Evidence floor S5Critical to CG-10

Objective. Demonstrate by periodic restore tests that every protected data class can be restored from each protection mechanism (snapshot, replica, immutable copy) to a usable, integrity-verified state within the declared recovery time, and that restored checkpoints actually resume training.

Requirement and evidence

The storage service owner shall run restore tests at a defined interval for each protected data class and protection mechanism, shall verify integrity of restored data by checksum, and, for checkpoints, the AI platform operator shall resume a training job from the restored checkpoint and confirm loss and step continuity.

STO-06 Storage monitoring and lifecycle

MCF-STO-021 Storage Telemetry

Claim operationAssurance level AL4Tier CP-3Evidence floor S4Supports CG-08

Objective. Collect storage telemetry (throughput, IOPS, latency percentiles, metadata latency, capacity, rebuild state, client errors, replication lag) with completeness monitoring and time synchronisation, to detect degradation and support incident analysis.

Requirement and evidence

The storage service owner shall collect telemetry from all in-scope storage systems and a representative sample of clients at the declared interval, shall monitor collection completeness, shall time-synchronise with compute and facility telemetry, and shall alert on thresholds.

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

MCF-STO-022 Capacity Forecasting

Claim operationAssurance level AL4Tier CP-3Evidence floor S4Supports CG-08

Objective. Forecast storage capacity and performance demand from planned training runs, dataset growth, checkpoint retention and model registry growth, against procurement lead times, so that expansion arrives before headroom thresholds are reached.

Requirement and evidence

The storage service owner shall forecast capacity and throughput demand over a horizon at least as long as procurement and deployment lead time, using the AI platform's planned workloads, and shall trigger expansion when the forecast crosses headroom thresholds within the lead time.

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

MCF-STO-023 Media Health

Claim operationAssurance level AL4Tier CP-3Evidence floor S4Supports CG-08

Objective. Monitor drive and media health (SMART/NVMe health logs, wear level, media errors, annualised failure rate by model and lot) and replace degrading media proactively before redundancy is consumed.

Requirement and evidence

The storage service owner shall collect media health indicators, shall define proactive replacement thresholds, shall track failure rates by model and lot, and shall replace media before failure where thresholds are crossed.

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

MCF-STO-024 Secure Sanitisation

Claim implementationAssurance level AL3Tier CP-2Evidence floor S3

Objective. Ensure storage media and systems leaving service, RMA or tenant reassignment are sanitised to a recognised standard with verification, so that training data, model weights and credentials cannot be recovered.

Requirement and evidence

The storage service owner shall sanitise media by clear, purge or destroy methods appropriate to media type and data classification under a recognised sanitisation standard, shall verify sanitisation, shall issue per-device certificates, and shall keep custody until sanitisation or destruction is complete, including for media sent for RMA.

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

Source: controls.csv, evidence-profiles.csv and gate-mappings.csv.