feat: Add critical infrastructure adaptation for Rule 5 (greenfield)

move-fast-and-fix-things.md: 'The Critical Infrastructure Adaptation'
section in Rule 5. OT/NT environments where full greenfield is impossible.
Five-layer adapted stack: IT greenfield protects OT, OT config as code,
manual operation as fallback, compartmentalisation as partial burn,
long-cycle planned refresh. OT greenfield test with 4h/48h/2w targets.

vertical-power-utilities.md: New 'The Controlled Burn Adaptation' section.
Full treatment of when greenfield is not an option. Five-layer OT-adapted
stack. Explicit acceptance statement framework for genuinely irreplaceable
OT components (name, isolate, monitor, plan replacement). The OT greenfield
test. Reference back to Rule 5.

Co-Authored-By: Tom Kracmar <tom+claude@cat6.cz>

antifragile-consulting/core/move-fast-and-fix-things.md

@@ -129,6 +129,28 @@ This is the ultimate defender's power move. An attacker's leverage in a breach d
 
 **The controlled burn**: forests that are never burned accumulate the fuel for catastrophic fires. Organisations that are never greenfield-deployed accumulate technical debt, legacy dependencies, and accumulated compromise that makes eventual failure more severe. Planned greenfield on a 5-year cycle is the controlled burn that prevents the uncontrolled one.
 
+### The Critical Infrastructure Adaptation
+
+For organisations operating OT/NT environments — power generation, transmission, water utilities, telecoms network infrastructure — a full greenfield rebuild is often genuinely not possible. Protection relays run for 30 years. PLCs controlling turbines cannot be taken offline for a rebuild exercise. Safety systems require regulatory approval for any change. The controlled burn, taken literally, cannot be applied.
+
+The goal remains the same. The method changes.
+
+**The purpose of greenfield capability is to eliminate inherited compromise and return to a known-good operational state.** In OT environments, this is achieved through a different set of moves — but the test is identical: *"If our control systems were completely compromised and had to be restored, could we maintain critical service delivery and return to full automated operation from a verified baseline?"*
+
+**IT layer greenfield protects the OT layer.** The corporate IT environment, SCADA servers, historian, HMI workstations, and M365 tenant can almost always be made greenfield-capable even when the OT hardware cannot. When the IT layer can be rebuilt clean, an adversary who compromised it loses their persistence and pivot path without a single OT system being touched. IT greenfield is the outer defence of an OT environment that cannot be rebuilt itself.
+
+**Configuration as code for OT.** PLC logic, IED settings, protection relay configurations, SCADA databases, and DCS configurations belong in version control. The ability to restore a verified configuration to existing hardware is the OT equivalent of greenfield: the hardware stays, but the software state is erased and rebuilt from a known-good baseline. Configuration backup and integrity checking for OT systems is not optional — it is the closest available substitute for the rebuild capability that IT environments take for granted. ASTRAL for M365 is the pattern; the same discipline applied to OT configuration archives is the OT equivalent.
+
+**Manual operation capability is a form of "drop the compromised layer."** A power utility that can maintain 80% of service from manual procedures during a SCADA compromise has a fundamentally different risk profile than one that cannot. The ability to operate without the automation layer is, in effect, the ability to sacrifice the compromised layer and continue. Manual override procedures, validated quarterly, are the OT sector's equivalent of a tested greenfield playbook. If operators have not practised running manually in the past 12 months, the capability does not exist.
+
+**Compartmentalisation over total rebuild.** OT environments are often sectionable. Grid islanding, corridor isolation, plant-level segmentation, and control centre failover allow the operator to sacrifice a section while maintaining critical service elsewhere. The burn is localised rather than total — but the principle is the same: designed-in ability to contain, recover, and restore in sequence rather than all at once.
+
+**Long-cycle planned refresh.** OT systems have 20–40 year lifetimes, but those lifetimes should be planned, not accidental. A utility with a documented 20-year OT refresh programme — component-by-component replacement milestones, firmware escrow, spare parts inventory — is doing the OT equivalent of periodic greenfield: the environment is continuously re-established in controlled segments. Organisations that do not have this programme are not avoiding greenfield; they are deferring it until a crisis forces it under the worst possible conditions.
+
+**What the test looks like for OT**: *"If our SCADA and IT layers were fully compromised tonight, could we maintain critical service from manual procedures within 4 hours, rebuild the IT layer from clean baselines within 48 hours, and restore full automated operation from verified OT configuration backups within two weeks?"* If any of those answers is no, the gap is in manual procedures, IT rebuild capability, or OT configuration management — not in greenfield per se, but in the prerequisites that make any form of recovery possible.
+
+For the full OT/critical infrastructure treatment, see [Vertical: Power and Utilities](../reference/vertical-power-utilities.md).
+
 ---
 
 ## Mapping to Antifragile Pillars