MCF-OPS-017 Configuration Baseline
Claim implementationAssurance level AL3Tier CP-2Evidence floor S4Critical to CG-14Supports CG-02, CG-07
Objective. An authoritative, current baseline exists for the configuration of facility and AI infrastructure that matters to Required Functions, so that changes can be assessed against it, drift detected and known-good states restored.
Requirement and evidence
The configuration manager shall maintain an approved configuration baseline covering, at minimum: as-built single-line diagrams and P&IDs; protection settings and coordination study revision; BMS/EPMS/CDU setpoints, sequences of operation and PLC logic versions; UPS, ATS and PDU settings; firmware and software versions of facility and IT infrastructure; network and fabric configurations; storage and cluster-manager configuration. The baseline shall be versioned, access-controlled, reconciled to the live state at the profile interval and after each change, and backed up outside the fault domain it describes.
Evidence required: E1 Documentary and declarative; E2 Configuration and technical state. Optional: E3, E4, E5. Operating states: NORMAL, MAINTENANCE, RECOVERY.
MCF-OPS-018 Change Assessment
Claim operationAssurance level AL4Tier CP-3Evidence floor S4Critical to CG-14Supports CG-03
Objective. Every change to critical facility or AI infrastructure is classified, impact-assessed against the dependency graph, fault domains and redundancy, scheduled in coordination with workloads, and approved by people with authority across facilities and IT before implementation.
Requirement and evidence
The change manager shall operate a change process that requires, for each change to in-scope infrastructure: classification (standard, normal, emergency) with criteria; impact assessment that identifies affected Required Functions using the asset-to-function and dependency maps, redundancy and fault-domain exposure during the change, safety implications, and workload coordination (for example checkpoint or drain); a linked MOP for non-routine work; approval by a change authority with both facilities and IT representation for cross-domain changes; and conflict checking against other scheduled changes and maintenance. Emergency changes shall be retrospectively reviewed.
Evidence required: E2 Configuration and technical state; E3 Operational and observational. Optional: E4, E5, E6. Operating states: MAINTENANCE, TRANSITION, NORMAL.
MCF-OPS-019 Temporary Configuration
Claim operationAssurance level AL4Tier CP-3Evidence floor S4Supports CG-14, CG-07, CG-04
Objective. Temporary configurations (bypasses, jumpers, forced points, overrides, manual mode on automatic systems, inhibited or shelved alarms, temporary chillers or generators, load banks, temporary cabling and hoses) are approved, registered, time-limited, visible to operators and removed with verification.
Requirement and evidence
The shift lead shall record every temporary configuration of critical infrastructure in a temporary configuration register with description, reason, risk assessment, approver, expiry, compensating measures and removal verification. Temporary configurations shall be visible at the operator console where technically possible, included in handover, reviewed at each expiry, and any extension shall be re-approved. Safety-system overrides (fire, leak, gas detection, emergency power off) shall require approval at the level set in the capability profile.
Evidence required: E2 Configuration and technical state; E3 Operational and observational. Optional: E4, E5, E6. Operating states: MAINTENANCE, DEGRADED, EMERGENCY, NORMAL.
MCF-OPS-020 Rollback and Validation
Claim effectivenessAssurance level AL5Tier CP-4Evidence floor S4Critical to CG-14Supports CG-10
Objective. Each material change can be reversed to a known-good state when it fails, and its success is validated by defined post-change tests and observation before the change is closed and redundancy is declared restored.
Requirement and evidence
The change manager shall require each material change to define back-out criteria, a back-out procedure tested or rehearsed where practicable, and post-change validation (functional checks, telemetry review, alarm review, redundancy restoration check, and for IT infrastructure job or health checks) with evidence attached before closure. Failed validations shall trigger back-out or an incident, and post-implementation review shall be held for failed or backed-out changes.
Evidence required: E2 Configuration and technical state; E3 Operational and observational; E4 Validation and test. Optional: E5, E6, E7. Operating states: MAINTENANCE, TRANSITION, NORMAL.