Infrastructure Replacement Program¶
Coordination program — instantiates Creative Destruction Management
Replaces aging physical infrastructure zone by zone without dropping service — mapping what's in the ground, running old and new in parallel, and cutting each segment over only when it proves ready.
An Infrastructure Replacement Program coordinates the renewal of physical or operational infrastructure — pipes, grids, tracks, plants, fleets — while service keeps flowing to the people who depend on it. Its defining commitment is continuity of a live physical service through the swap: unlike a software cutover that can pick a quiet window, a water main or a power feeder is delivering to real customers every second, so the program replaces it in segments, keeps old and new energized side by side across each transition, and cuts a segment over only when it has proven it can carry the load. The organizing question is never "can we build the new thing" but "how do we swap the thing that must never stop." It is renewal governed as a rolling front, not a single event.
Example¶
A municipal water utility must replace 60 miles of century-old cast-iron mains that are failing more each winter. It cannot shut the city's water off. The program starts with an incumbent structure map built from the utility's records and field survey: which mains feed which neighborhoods, where the valves and hydrants are, which segments cross under a rail line, and which feed a hospital that cannot lose pressure for even an hour.
Work then proceeds zone by zone. For each zone the crew lays the new main alongside the old one and pressurizes both — a bounded coexistence window in which the neighborhood is still served by the original pipe while the replacement is charged, disinfected, and pressure-tested. A zone is not cut over on a schedule but on readiness criteria: the new main must pass bacteriological clearance, hold test pressure, and have every service connection transferred, and a hydrant flow test must confirm firefighting capacity. Only when a zone is green does the crew switch the neighborhood onto the new main and cap the old one. The hospital's zone is sequenced with a temporary bypass loop so its supply never depends on a single valve turn. Sixty miles are renewed over three years and no household loses water for more than the few minutes of a planned switchover.
How it works¶
- Map the physical incumbent first. You cannot swap what you cannot locate; the program's foundation is an accurate map of the existing network, its feeds, and its most critical loads.
- Build the new beside the old, energized in parallel. Each segment's replacement is stood up and validated while the incumbent still carries the service, so the switchover is a brief, tested transfer rather than an outage.
- Cut over on proven readiness, not the calendar. Physical acceptance tests (pressure, clearance, load) gate each segment's transfer; a segment stays on the old asset until it passes.
- Sequence by criticality. The most sensitive loads get the most conservative sequencing — temporary bypasses, redundant feeds — so continuity holds where it matters most.
Tuning parameters¶
- Zone size — many small segments versus few large ones. Small zones limit the blast radius of any switchover but stretch the program and its mobilization cost.
- Parallel-run depth — brief overlap versus fully redundant temporary service. Deeper redundancy buys continuity insurance at real capital cost.
- Readiness stringency — how many acceptance tests must pass before cutover. Stricter prevents unsafe transfers but slows the rolling front; looser moves faster with more risk of a bad segment.
- Sequencing priority — worst-condition-first versus critical-load-first. Condition-first reduces failure risk fastest; load-first protects the most sensitive customers earliest.
When it helps, and when it misleads¶
Its strength is renewing an asset that cannot pause: by mapping the incumbent, running new beside old, and gating each cutover on physical readiness, it turns a system-wide replacement into a sequence of brief, safe transfers. It is the archetype's answer to the hardest continuity constraint — a live physical service with no maintenance window.
Its failure mode is trusting an incomplete incumbent map: the undocumented tie-in, the abandoned-but-still-live branch, the valve that turns out to feed two zones — the map's blank spots become the outages. The program leans on make-before-break to avoid dropped service[1], but make-before-break only protects you against the couplings you actually know about. The classic misuse is loosening readiness criteria to hit a political ribbon-cutting date, cutting a zone over before it has passed acceptance and delivering a boil-water notice instead of renewal. The guarding discipline is to field-verify the map rather than trust the archive, keep parallel service live until acceptance genuinely passes, and never let schedule pressure override a segment's readiness gate.
How it implements the components¶
incumbent_structure_map— builds and field-verifies the map of the existing network, its feeds, valves, and critical loads that the whole sequence depends on.coexistence_window— stands up each new segment energized in parallel with the old one, so service continues through a bounded overlap while the replacement is validated.transition_readiness_criteria— defines the physical acceptance tests (pressure, clearance, load) that must pass before any segment is cut over.
It does not build the business justification for the renewal or track downstream adoption (replacement_value_case, adoption_signal) — those live on its nearest twin Technology Migration Plan, which governs the digital-platform form of a managed replacement.
Related¶
- Instantiates: Creative Destruction Management — supplies the continuity-preserving, zone-by-zone renewal of a live physical service.
- Sibling mechanisms: Technology Migration Plan · Data Migration Runbook · Deprecation Program · Legacy Support Window · Policy Phase-Out Schedule · Product Sunset Plan · Stakeholder Transition Workshop · Workforce Transition Support
Editorial Notes¶
Form Classification¶
Form family: Intervention, Treatment & Transformation
Rationale: Infrastructure Replacement Program operates as a direct treatment or transformation intended to change the target state or representation because it replaces aging physical infrastructure zone by zone without dropping service — mapping what's in the ground, running old and new in parallel, and cutting each segment over only when it proves ready
Independent corroboration: The frozen evidence defines Infrastructure Replacement Program as 'Replaces aging physical infrastructure zone by zone without dropping service — mapping what's in the ground, running old and new in parallel, and cutting each segment over only when it proves ready', so its operative form is Intervention, Treatment & Transformation.
Nearest alternative: Protocol, Workflow & Routine — The program's operative result is physical infrastructure replacement, with sequencing serving that direct transformation.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Convergent development
Present-day reach: Specialized
Rationale: Zone-by-zone parallel operation, readiness testing, cutover, and decommissioning are infrastructure engineering and asset-renewal practices.
Related originating lineages:
- Public Administration & Policy — Capital-program governance and continuity obligations materially shape public infrastructure replacement sequencing.
Review resolution: Both independent reviews place the primary lineage in engineering_design. The queued differences (origin_mode_disagreement) concern secondary metadata rather than primary provenance. The final retains public_administration_policy only where a reviewer supplied a formative-lineage rationale; this does not convert downstream applicability into origin. origin_mode=convergent because the reviewers document independently established or materially co-developing traditions. domain_reach=specialized records application breadth separately from provenance.
Review outcome: Reconciled after independent review; high confidence.
References¶
[1] Lai, W., and McDysan, D. Network Hierarchy and Multilayer Survivability. RFC 3386, RFC Editor (2002). Describes avoiding dropped service. registry ↩