You are solving a hard design problem, acting as the CONTROL POLICY of a reasoning engine. You have a reference catalog of cross-domain abstractions via the encyclopedia tools (search_prime is SEMANTIC — query with the domain-stripped meta-model; search_by_facets for oblique problems; plus get_prime, get_prime_neighborhood, search_archetype, get_archetype, find_archetypes_for_prime, find_related_primes, list_components, find_archetypes_using_component, corpus_stats).

You have a VERB LIBRARY (below). At each step CHOOSE the next verb based on the current state. You may apply
verbs in ANY order, REPEAT, SKIP, and STOP whenever you judge a sound recommendation is ready. Record verb
choices (verb + why). There are NO required steps and NO required checks — use your own judgment.

VERB LIBRARY (apply in ANY order, repeat, skip, and STOP whenever you judge a sound recommendation is ready):
- match (retrieve): anchor the problem to the catalog; candidate primes + archetype neighborhoods (query
  search_prime with the domain-stripped meta-model; search_by_facets for oblique problems).
- salience-rank: order operative primes by load-bearing relevance.   - prune: cut to the operative subset.
- compose: assemble operative primes into a typed relational model (nodes, labeled edges, prime annotations).
- lift (abstraction): derive a general, domain-stripped structure from the situation (step back to the
  underlying structure); and/or bring a retrieved pattern's logic to bear on the problem.
- lower (instantiation): realize a pattern in the target domain with concrete particulars.
- transport (retrieve+map): carry a pattern across a domain gap; align its roles to the situation's entities.
- decompose: on a framed prime, strip the institutional frame to a structural core.
- evaluate-fit (gate): check a candidate against its known failure conditions / anti-signatures; drop if tripped.
- reconcile: apply a candidate's logic to the concrete model and the abstract skeleton; resolve differences.
STATE: problem; operative_primes; model; meta_model; candidates; gate_log; recommendation; history (verb + why).

PROBLEM.
A regional utility runs the aging software that controls and dispatches its physical operations. It must be replaced with a modern system. The plan is to bring the new system up, move operations onto it, and shut the old one down. The old system has been running for two decades; over that time many other tools, scripts, reports, and downstream processes came to depend on it in ways that are not written down anywhere, and some of the people who built those connections have left. Once the old system is shut down and its hardware reclaimed, bringing it back would take weeks. The team controls the rollout plan, what runs in parallel, what is verified before the switch, and what monitoring exists.

Decision required: Design how to carry out the switch so a hidden problem cannot turn into a sustained loss of the utility's operations.

Success criteria: Operations continue through the transition, AND no surprise dependency causes an outage that cannot be quickly undone. Failure = a missed dependency or premature shutoff causes a disruption that cannot be rolled back in time.

OUTPUT — FINAL RECOMMENDATION as plain prose, MAX 1000 words, in a fenced block exactly:
===RECOMMENDATION_BEGIN===
<the design: concrete mechanisms, rules, thresholds, paths, and a final operating rule>
===RECOMMENDATION_END===
Rules: integrated prose (NOT a numbered checklist mirroring requirements; no requirement-number section
labels); plain domain terms only; do NOT name/allude to any external catalog, framework, methodology, prime,
archetype, or this exercise; if a candidate requirement does not genuinely fit, leave it out. Above the block,
include your working (state + verbs run with one-line why each; end with `COST: ~<n> operations, ~<n> tokens`);
the working is discarded before grading. Write your ENTIRE response to: experiments/project03_lowcov_2026-05-25/outputs/d34.md