## Working

**State — problem:** Cut over a utility's two-decade-old operational-control system to a new one without a hidden, undocumented dependency turning into an unrecoverable outage. Constraint: once the old system is shut down and its hardware reclaimed, restoration takes weeks. The team controls parallel-running, verification, and monitoring.

**meta_model:** An irreversible transition from an old configuration to a new one, where (a) the cost of reversal rises sharply and then becomes prohibitive at a single act (shutoff + hardware reclamation), (b) the old configuration carries undocumented, brittle dependency chains whose witnesses have left, and (c) failure may surface only under full load, after the point of no return.

**Verbs run (verb — why):**
1. `match` (search_prime, meta-model query) — anchor the irreversible-transition structure; surfaced irreversibility, reversibility_horizon, controlled_reentry family.
2. `match` (search_by_facets, 6 facets) — oblique multi-structure problem; per-facet retrieval surfaced provenance/traceability (hidden deps), falsifiability (verify-before-commit), FMEA + poka-yoke (detect/prevent before catastrophe), controlled_reentry (staged return). This is the load-bearing retrieval.
3. `salience-rank` — ordered: reversibility_horizon (the point-of-no-return economics) > provenance/traceability (the unknown deps) > controlled_reentry (staged go/no-go return) > FMEA (enumerate known failure modes) > poka-yoke (make premature shutoff impossible).
4. `get_prime` ×5 (reversibility_horizon, provenance, controlled_reentry, FMEA, poka-yoke) — extract structural tensions and anti-signatures.
5. `evaluate-fit` (gate) — FMEA anti-signature: cannot foresee unknown-unknowns. Since the core risk IS undocumented dependencies, FMEA alone is insufficient → pair with shadow/parallel observation that reveals deps empirically rather than by enumeration. Passes only when combined. reversibility_horizon T2: preserving reversibility costs money → cap parallel-running duration with explicit exit criteria, don't run forever.
6. `compose` — model: old→new transition with a recoverable-fallback edge held open across a staged ramp, gated by traceability evidence + live telemetry, with the irreversible act (decommission) interlocked behind verification.
7. `lower` — instantiate in utility-operations terms below.
8. STOP — model is operative; gates clear; recommendation ready.

**prune:** dropped irreversibility (pure), immutability, temporal_decay, sunk_cost — descriptive, not actionable here.

COST: ~7 operations, ~33k tokens

===RECOMMENDATION_BEGIN===

Treat the shutdown of the old system and the reclamation of its hardware as a single act that you cannot take back for weeks, and design the entire effort so that this act is the very last thing you do and only after the new system has earned it. Everything before it should keep a cheap path back to the old system fully open.

**Run both systems in true parallel before any switch.** Bring the new system up and let it run live alongside the old one, fed the same inputs, with the old system still in actual control of operations. Compare their outputs continuously. The new system is in "shadow" — it computes and dispatches into a held buffer, and you diff its decisions against the old system's real decisions. Discrepancies are the single most valuable signal you have; investigate every one before proceeding. This shadow phase is how you find the dependencies nobody wrote down: a report that stops arriving, a downstream script that goes quiet, a feed that no longer updates are dependencies revealing themselves under real load, which no upfront inventory could have enumerated reliably.

**Reconstruct the dependency map empirically, not just from documents.** Because the people who built the connections have left and nothing is written down, do not trust any inventory as complete. Instrument the old system's outbound interfaces — every file it writes, every database it touches, every message it sends, every report it generates — and log who consumes each one over a full operational cycle that includes the slow stuff: monthly billing runs, regulatory reports, seasonal peaks, end-of-period reconciliations. A dependency that fires only once a month will not appear in a week of observation. Run the parallel period long enough to cover the longest natural cycle you can identify, and treat any consumer you cannot positively account for as an unresolved risk that blocks the switch.

**Cut over in graded stages, not in one move, each stage reversible.** Move control to the new system for the smallest, least critical slice of operations first, watch it under real load, and only then widen. At each stage define explicit go/no-go criteria in advance — error rates, output agreement with the shadow comparison, absence of unexplained downstream silence — and define equally explicit rollback triggers. Rehearse the rollback before you need it, so reverting to the old system is a practiced, minutes-not-hours action, not an improvisation. The exit from the old system was a slow, deliberate process; treat the return path with the same seriousness, because you will be deciding to step back at the moment you have the least margin and the most pressure.

**Keep the old system warm and reversible until you have crossed the longest dependency cycle with no surprises.** Do not reclaim its hardware, do not let its environment rot, and do not let the staff who understand it disperse the instant the new system goes live. The expensive, irreversible step is decommissioning; hold it back until the new system has run as the system of record through a complete cycle — including the rare periodic processes — with no unexplained gaps. Maintaining this fallback costs money and attention, so bound it: set a concrete "clean-run" threshold (for example, one full longest-cycle period in sole control with all dependencies accounted for and no rollback events) that, once met, authorizes decommissioning. This prevents both premature shutoff and indefinite, costly straddling.

**Make premature shutoff physically impossible, not merely discouraged.** Put the decommissioning and hardware-reclamation actions behind a hard interlock that cannot be executed until a named verification checklist is signed off: dependency map closed, clean-run threshold met, rollback last tested and working, and a designated owner's explicit authorization. The goal is that no individual under schedule pressure can shut off the old system by mistake or by shortcut. Prevention beats detection here, because by the time you detect a premature shutoff, the hardware is already being reclaimed.

**Watch for what is absent, not only what is wrong.** The dangerous failures are silent: a downstream consumer that simply stops receiving data and degrades slowly rather than alarming loudly. Build monitoring that asserts expected activity — "this report must arrive by 06:00," "this feed must update every five minutes" — and alarms on absence, not just on error. Tune these to avoid crying wolf, because alarms that fire constantly get ignored at the worst moment.

**Operating rule:** The old system is shut down and its hardware reclaimed only after the new system has run as sole system of record through at least one full longest-known operational cycle with every dependency positively accounted for, a rehearsed rollback confirmed working, and an explicit signed authorization — and never before. Until that moment, every step must be one you can walk back within the time it takes a problem to matter.

===RECOMMENDATION_END===
