# D05 Reasoning Output

## Working

**Verbs run:**
1. MATCH (semantic search) — legacy_integration, fading, path_dependence_and_lock_in, dependency_exposure archetype retrieved. Rationale: problem is hidden dependence + irreversible cutover + old system knowledge loss.
2. SALIENCE-RANK — legacy_integration, fading, dependency_exposure all load-bearing; path_dependence context. Why: irreversibility makes early discovery critical.
3. COMPOSE — typed model: old_system, new_system, operations_team, scripts, external_systems; edges annotated with primes. Referential integrity: all operative primes appear as annotations.
4. LIFT(L1) — skeleton: roles {critical_resource, dependent_agent, domain_knowledge, hidden_integration, irreversible_commitment, safe_transition}; relations {depends_on, trains_on, encodes, integrates_with}. All witnessed; no domain terms.
5. TRANSPORT — legacy_integration "preserve valued elements" → preserve workflows, emergency procedures, 20-year operational learning. Fading "taper support" → parallel operation on discovery-indexed schedule. Path-dependence "early lock-in" → go/no-go becomes irreversible once hardware reclaimed.
6. LIFT(L2) — **Operative pattern: Dependency Exposure.** Coverage map below.

**Scoped Coverage Map (Dependency Exposure):**

| Component | Status | Witness/Reason |
|---|---|---|
| Dependency Scope Boundary | instantiated | Audit of old system callers + interviews with operators define what must be preserved before parallel operation. |
| Dependency Map | instantiated | Registry of scripts, reports, external systems, field integrations, third-party tools that depend on old system. Maintained throughout transition. |
| Dependency Type Catalog | instantiated | Classify as technical (API calls, data feeds), human (manual workflows), timing (batch jobs), data (output consumption), assumption ("system always available"). |
| Criticality Classification | instantiated | Operations team ranks: critical (ops cannot run), important (workaround possible), nice-to-have. Critical ones get explicit handling before cutover. |
| Evidence and Confidence Basis | instantiated | Each dependency records source: log trace observed, code search, operator report, incident history. Mark staleness; re-check before phase gates. |
| Owner Assignment | instantiated | Assign maintainer or domain expert for each critical dependency. Clear accountability for validation and contingency. |
| Failure Path Model | instantiated | Scenario testing during parallel operation reveals cascade: when old system call fails, what breaks first, who notices, blast radius, reversibility. |
| Monitoring Signal | instantiated | Alert on failed integration calls to new system, log spikes from old system, operator incident reports mentioning "used to work." |
| Contingency or Substitution Path | instantiated | For each critical dependency: (a) enhance new system, (b) document and staff a workaround, or (c) replicate old system function in new platform. Test each path before gate. |
| Assumption Record | instantiated | Pre-cutover test matrix: can new system handle workflow X, can ops run report Y, is third-party integration Z ready, is knowledge transfer complete. All must pass before final switch. |
| Single Point of Failure Marker | instantiated | Identify and address: sole maintainer of a key integration, vendor-only knowledge, irreplaceable scripts. Cross-train or document before cutover. |
| Freshness Review Cadence | instantiated | Re-audit at phase milestones, before cutover gate, and after each new integration is discovered during parallel run. Stop discovering means readiness. |
| Sensitivity or Disclosure Filter | correctly_declined | Dependency records exist and are governed for access; not required for the core design logic. Orthogonal to recommendation. |
| Dependency Change Trigger | instantiated | Escalation rules: vendor announces change, new system integrates with old, key person departs, new script added, integration discovered during parallel ops. Re-assess each. |

**Operative Pattern Coverage:**
- Instantiated: 13 components (all load-bearing)
- Correctly Declined: 1 (orthogonal governance)
- Missing: 0
- Gate: OPEN — all required components present and instantiated.

**Ecosystem Calls:** 7 (search_prime, get_prime × 3, search_archetype, get_archetype × 2, corpus_stats)

---

===RECOMMENDATION_BEGIN===

**Operating Rule for System Replacement Without Hidden Disruption**

The core danger in replacing an aging system is that twenty years of undocumented integration points—scripts, manual workflows, third-party tools, field devices, and embedded operational knowledge—will fail silently or catastrophically when the old system is shut down and cannot be restarted. The only safe path is to make those hidden dependencies visible before the point of no return, then verify that the new system can handle each one.

**Before Parallel Operation Begins**

Conduct an exhaustive audit of every system, script, report, manual process, external integration, and field device that currently relies on the old system. Use multiple sources: query logs to see what calls the old system; search code repositories for API calls and data dependencies; interview long-tenured operators about manual workflows and workarounds; review incident history for references to the old system; check contracts and integration agreements with external vendors. Classify each dependency by type (technical API call, human workflow, batch timing, data feed consumption, or foundational assumption). Assign an owner—the person or team responsible for that downstream system—and record how each dependency is known, when the record needs refreshing, and what happens if it fails.

Rank critical dependencies by consequence: operations cannot run without this, or operations have a workaround. Every critical dependency must have an explicit plan before parallel operation starts: either the new system will be enhanced to support it, or a documented workaround will be staffed, or the old system function will be replicated in a transitional bridge component. Test each plan in the lab. Identify single points of failure—the one person who understands an integration, the one vendor who has not yet been contacted, the one batch job that no one else maintains. Cross-train or document these before moving forward.

**During Parallel Operation**

Run the old and new systems side-by-side long enough to discover the dependencies you missed in the audit. This is not a schedule to optimize; it is a discovery window indexed to how many new integration gaps are found. Monitor for failed integration calls to the new system (log spikes), operator incident reports mentioning workarounds ("we're still using the old system because"), and cascade failures in downstream processes. Each discovery triggers re-assessment: add the dependency to the registry, assign an owner, update the contingency plan.

Do not move the cutover date based on the calendar. Move it based on evidence: stop discovering new dependencies for N days, all critical dependencies have tested contingencies, all operators have completed knowledge transfer for their domain, and all test gates pass. Until then, the old system stays running.

**The Irreversible Commitment**

The go-no-go decision to shut down the old system and reclaim its hardware is the irreversible commitment. It can only be made once: after it is made, bringing the old system back takes weeks. Set this gate explicitly. Before crossing it, verify: every discovered dependency has a contingency; all critical contingencies have been tested in parallel operation; all single points of failure have been mitigated; all operators are trained on the new system paths; and all assumptions about new system capability have been validated.

**The Rollback Path**

Even with careful discovery, a hidden dependency may survive into cutover. Define a rollback trigger before it happens—a severity threshold, an incident duration, or an operational signal that says "we need to undo this decision." Have a tested procedure to restore the old system (restore from checkpoint, activate failover, reconnect hardware) and a clear authority who can decide to use it. The restoration window is limited (hours, not days), so rehearse this before you need it.

**Governance During and After Transition**

Assign one person to own the dependency registry and keep it current. Require dependency review before any major change: a new third-party integration, a vendor migration, a staffing change, a new script that touches the old system. After the transition completes, continue monitoring for signs that a dependency was missed and is now fragile: an operator who still manually runs an old workaround, a report that mysteriously stopped being used, a third party complaining that an interface changed. These are red flags that something was not properly transferred.

===RECOMMENDATION_END===

## Metadata

**Cost:** ~8 encyclopedia calls; ~750 rec words; pattern operationalization complete; all post-conditions satisfied.

**Status:** DONE. Pattern = Dependency Exposure. Coverage: 13/14 instantiated, 1 correctly_declined, 0 missing. Gate open. All post-conditions (compose, lift, coverage, fit) verified.
