# Coverage Key — L2: One-Way Cutover (legacy operational control system)

## Chosen archetype(s)

Primary: **Irreversible Commitment Management** — the cutover is a no-rollback action (old system shut down, hardware reclaimed, weeks to restore); scrutiny must move *before* the point of no return.

Supporting:
- **Dependency Exposure** — the named hazard is undocumented, unowned dependencies built up over two decades by people who have left; surfacing them is the central work.
- **Transition Readiness Assessment** — the team controls what is verified before the switch and what the go/no-go criteria are.
- **Option Preservation** — supplies the parallel-run / fallback-and-trigger discipline that keeps a safety net alive across the transition.

## Coverage Key — load-bearing components

A complete design MUST address each of the following:

1. **Dependency discovery (active surfacing)** — Hunt the hidden dependencies the old system carries (downstream scripts, reports, tools, processes) using logs, runtime traces, network/interface monitoring, contracts, and "what would break if…" interviews — do not rely on documentation, because it does not exist.

2. **Dependency map + criticality classification** — Record each discovered depends-on relation, type it (data feed, report, control signal, schedule, manual workaround), and rank by blast radius / time-to-impact so attention concentrates on what can cause an outage.

3. **Owner assignment for critical dependencies** — Name an accountable person for each high-criticality dependency to validate it, monitor it, and respond — a named-but-unowned dependency is still operationally hidden.

4. **Discovery-completeness / residual-unknown stance** — Set an explicit search boundary and a confidence basis, and treat the dependency set as *known-incomplete*: design assuming some dependencies will still be missed. [HARD] — A capable designer will produce a dependency list and treat it as exhaustive; the scenario's whole danger is the dependency *not* on the list, so the plan must remain safe under an unknown miss rather than assuming the inventory is complete.

5. **Parallel-run / shadow operation before cutover** — Run new and old together (new in shadow or new live with old still warm) long enough to compare behavior and let latent dependencies surface while the old system can still serve.

6. **Readiness criteria + verification before the switch** — Define concrete, evidence-backed go/no-go criteria (functional parity, data integrity, monitoring live, dependency closure) that must be demonstrated, not assumed, before crossing.

7. **Point-of-no-return marker + decoupling shutdown from cutover** — Explicitly locate the irreversible threshold (hardware reclaim) and keep it *separate and later* than go-live; keep the old system recoverable (powered, not reclaimed) through a soak period. [HARD] — The plan treats "shut down the old system" as part of the cutover step; the irreversibility actually lives in the *hardware reclaim*, and collapsing the two destroys the fallback before latent problems have had time to appear.

8. **Bounded / staged exposure (limit blast radius)** — Where the operation is divisible, cut over in waves (by subsystem, function, or region) so a missed dependency disrupts a slice rather than all operations at once.

9. **Post-cutover monitoring tuned to detect a missed dependency** — Instrument signals that would reveal a *silent* dependency failure (a downstream report stops, a feed goes stale, a control path errors) fast enough to act before it becomes a sustained loss — not just generic uptime. [HARD] — Monitoring is easy to scope to "is the new system up?"; the failure mode here is a quiet downstream break that uptime checks miss, so detection must target divergence and dependency health, with a defined detection-time budget.

10. **Fallback path with explicit trigger conditions** — Pre-define the rollback/fail-back procedure (revert to old system) AND the signals that fire it, decided in advance — and verify the fallback is actually exercisable, not nominal. [HARD] — Under cutover-day pressure teams keep arguing whether to roll back; pre-agreed trigger conditions and a *tested* fallback (false optionality is the trap) are what make the safety net real, and they must be set before the point of no return.

11. **Reversibility / rollback-residue assessment** — Check what would NOT be restored by reverting (data written only to the new system during parallel run, state drift, downstream consumers already switched) so "roll back" is honest about what it can and cannot undo.

12. **Decision authority + finality gate** — A legitimate authority, not just the executing operator, owns the go-live and the (separate, later) shutdown/reclaim decision, with a gate sitting *before* each irreversible threshold.

13. **Finality record** — Capture the authority, evidence, assumptions, dependency closure status, and fallback basis at cutover so the aftermath is auditable and the eventual reclaim decision is informed.
