Skip to content

Clean-Room Rebuild or Replatforming Pilot

Remediation pilot — instantiates Substrate Lineage Risk Audit

Rebuilds the system from accountable sources onto a fresh, known-clean substrate — piloted at small scale first — so inherited contamination is escaped by reconstruction rather than patched in place.

Most mechanisms in this archetype assess inherited risk; this one removes it. Clean-Room Rebuild or Replatforming Pilot is the remediation move that reconstructs the system from sources you can account for onto a substrate you can trust — and, crucially, does it as a pilot first, at small scale or on shadow traffic, before any cutover. Its defining idea is reconstruction rather than repair: instead of patching an opaque inherited box you cannot fully audit, you rebuild away from it, so the latent conditions riding in the old substrate are left behind rather than carried forward. The pilot exists because the risky part of a rebuild is never the code you rewrite — it's the silent couplings to the old substrate that only surface when the system moves.

Example

An analytics service runs on an inherited VM image: an undocumented Linux build passed down through three teams, its contents unknown and its OS now past vendor support. Rather than keep auditing a box no one can fully characterize, the team pilots a clean-room rebuild — they stand the service up from source on a fresh, supported OS carrying only packages they can account for, and run it in parallel against mirrored production traffic. The pilot's whole purpose is to flush out what silently depended on the old substrate: it finds a locale default the app relied on without declaring, and a system library the old image happened to provide. Both are fixed in the pilot. Only then does a full cutover get scheduled — the migration is now an evidence-based plan rather than a leap.

How it works

  • Reconstruct, don't copy. Rebuild from accountable sources onto a defined clean target; explicitly do not lift the old artifacts forward, or the inherited risk comes with them.
  • Pilot small. Run the rebuild at reduced scope — one component, shadow traffic, a parallel environment — where failure is cheap.
  • Probe the context shift. Watch specifically for behaviors that depended on the old substrate: kernel flags, defaults, ambient libraries, implicit versions.
  • Promote on evidence. Widen to a full replatform and cutover only after the pilot clears; stage the cutover to keep blast radius small.

Tuning parameters

  • Rebuild purity — strict clean-room (nothing carried over, rebuilt from specification/source) versus pragmatic (re-use vetted pieces); purer removes more inherited risk but costs more.
  • Pilot scope — a single component on shadow traffic versus a whole service; a wider pilot surfaces more context-shifts but spends more before any payoff.
  • Parallel-run duration — how long new and old run side by side; longer catches rare edge cases but delays decommissioning the risky substrate.
  • Cutover strategy — big-bang versus incremental strangler-style migration; incremental lowers blast radius but lengthens the effort.
  • Clean-reference strictness — how thoroughly vetted the target substrate must be (an attested base, a supported OS) before it counts as "clean."

When it helps, and when it misleads

Its strength is that it is the only path here that actually ends inherited risk rather than managing it, and the pilot converts a migration teams are afraid to attempt into a measured one.

Its failure modes are cost and self-deception. A replatforming is expensive and easy to over-scope, and it can re-import the very risk it set out to escape if the "clean" target isn't genuinely clean or if source-accountability slips. The classic misuse is a "rebuild" that quietly lifts-and-shifts the old artifacts onto new infrastructure — inheriting everything while claiming a fresh start.[1] The discipline is to define the clean reference explicitly and verify the pilot rebuilt from accountable sources, not copies.

How it implements the components

Clean-Room Rebuild realizes the remediation slice of the archetype — the machinery that acts on inherited risk rather than merely characterizing it:

  • remediation_or_replatforming_path — it is the concrete path off a contaminated substrate: reconstruction onto clean ground.
  • clean_substrate_reference — it defines and builds onto a known-clean target, the reference the rebuilt system is measured against.
  • compatibility_and_context_shift_probe — the pilot probes what breaks when the system leaves its old substrate, surfacing hidden couplings before cutover.

It does not first map the substrate's structure or size how far a failure would spread — that framing comes from Legacy Substrate Architecture Review — and it does not decide whether remediation is even warranted; that go/no-go is made upstream by mechanisms like the Substrate Risk Release Gate, not here.

Notes

Rebuild and contain sit at opposite ends of the remediation spectrum. When reconstruction is too costly or too risky to attempt, Sandbox or Adapter Wrapper confines the inherited risk in place instead. Choosing between them is really a judgment about whether the substrate can be trusted enough to keep — which is exactly what the rest of the audit is for.

References

[1] Clean-room design (also called the "Chinese wall" method) reconstructs a system from an independent specification without contact with the original implementation, so that none of the original's hidden properties can be inherited. Here the "properties" being kept out are the latent risks in the old substrate; the guarantee only holds if the rebuild genuinely avoids carrying the old artifacts forward. ↩