Mechanism

Project-Level Recovery When Task-Level Fixes Are Insufficient

When every fresh session hit the same wall, I stopped blaming the session and started looking at the architecture.

43.2%
Rework rate on PRJ-03 -- the highest in the portfolio, signaling structural misalignment, not task-level drift
24
Commits in 4.2 hours for a complete controller strip-and-rebuild on PRJ-03 after Tear Down

The Problem

I had all the task-level recovery tools working. Stop, Pause, Reset restored awareness when context drifted. Stop and Recap re-established shared reality with the AI. Stop. Run It Back destroyed poisoned sessions and started clean. They worked -- at session scale. But some problems survived the reset. I would nuke the thread, open a fresh conversation, and immediately hit the same structural friction. The new session had clean context, but the project carried the problem forward in its architecture, its schema, its accumulated assumptions encoded in committed code.

That is a project-level spiral. The corruption lives in the codebase, not the conversation. Every session inherits the structural problem because the structure persists across sessions. Fresh starts keep hitting the same ceiling because the ceiling is built into the project itself.

The sunk cost trap made it worse. Weeks of commits. Thousands of lines of code. Multiple integrated features. Acknowledging that a significant portion of that work served the wrong direction meant accepting a painful write-down. The alternative -- continuing to build on the flawed structure -- felt productive because commits kept accumulating and features kept appearing. But each commit deepened the structural problem. The project advanced in the wrong direction with increasing efficiency. Between "nuclear reset of a conversation" and "keep building on a broken foundation," I had no mechanism. That gap is where projects silently accumulate structural debt -- each session clean, each commit competent, the aggregate drifting from Target because the underlying architecture is misaligned.

What Realign / Tear Down Actually Is

Realign and Tear Down are CEM's project-level recovery mechanisms. They fill the gap between session-level recovery (Stop. Run It Back) and ecosystem-level recovery (Hard Reset). Realign corrects structural drift when the architecture is sound but implementation has wandered. Tear Down destroys the flawed structure entirely and rebuilds from Foundation when the architecture itself is the problem.

The decision heuristic is straightforward: if targeted corrections resolve the drift, Realign was the right call. If targeted corrections provide temporary relief but the drift keeps recurring, the structure itself is poisoned and Tear Down is indicated.

What it provides:

  • Graduated project-level recovery -- matching the intervention to the actual scale of the problem instead of endlessly resetting sessions or overreacting with an ecosystem-level reset
  • A safe destruction path -- Tear Down is viable because Foundation catches every template, pattern, and piece of domain knowledge before the flawed structure is destroyed

What it does not provide:

  • A substitute for task-level recovery -- session drift still gets handled by Stop, Pause, Reset through Stop. Run It Back. Realign and Tear Down deploy only when the problem persists across fresh sessions
  • Permission to skip Foundation maintenance -- Tear Down is safe only when Foundation is healthy. If Sweeps have lapsed and Storage Discipline has degraded, Tear Down destroys irrecoverable work. Foundation health is a prerequisite, not a guarantee

The Assessment Decision

The critical operator judgment is binary: Realign or Tear Down? This maps to Spiral Anatomy's Stage 4 (Assess) operating at project scale. I built a signal table to make the call.

Signal Assessment Response
Specific features misaligned, architecture sound Repairable Realign
Integration patterns drifted, core solid Repairable Realign
Rework rate increasing but contained Repairable Realign
Architecture cannot accommodate Target Poisoned Tear Down
Every fix creates new problems Poisoned Tear Down
Rework rate accelerating despite corrections Poisoned Tear Down
Realign attempted and drift recurred Poisoned Tear Down
Cost of maintaining exceeds cost of rebuilding Poisoned Tear Down

Realign preserves the project's architecture, core codebase, and integrated features. It modifies direction without destroying substance. The cost is execution time spent correcting rather than advancing -- temporary velocity reduction for restored alignment.

Tear Down preserves everything in Foundation: templates, patterns, domain knowledge, configuration, integration work, and the knowledge of what did not work. It destroys the specific structural implementation that encoded the flawed decisions -- the accumulated interdependencies, the workarounds, the architecture that constrains rather than enables. The rebuild is faster than the original build because I know what to build, what to avoid, and Foundation provides reusable assets through Scaffold.

What the Data Shows

Realign and Tear Down were validated across ten software systems totaling 596,903 lines of production code shipped in four months (Oct 7, 2025 -- Feb 2, 2026). Project-level recovery events leave visible artifacts in git history -- architectural changes, rebuild patterns, and rework clustering.

PRJ-03 provides the clearest Tear Down evidence. The controller structure encoded early assumptions that no longer aligned with Target. Features built on those assumptions compounded the misalignment. The rework rate hit 43.2% -- the highest in the portfolio. Nearly half of all commits were corrections. Task-level drift produces rework in the 10-20% range; 43.2% means the architecture itself is generating friction. On January 28, 2026, I executed Tear Down: 24 commits in 4.2 hours, a complete controller strip-and-rebuild. The rebuild completed in a single session -- 4.2 hours for what had accumulated over multiple prior sessions. Foundation provided the domain knowledge, integration patterns, and structural templates.

The PRJ-01 landing page deletion on January 27, 2026, provides a second Tear Down event with stark velocity evidence. Complete deletion followed by clean-slate rebuild. Day of deletion: 8 commits. Following day: 68 commits in Burst mode. That 8.5x multiplier was not achievable within the old structure -- the constraints that limited output to 8 commits were the structure itself. Removing it released velocity that had been suppressed by accumulated architectural friction.

Rework rates across the portfolio quantify the cost difference between sound and misaligned architectures:

Project Rework Rate Interpretation
PRJ-09 3.9% Clean architecture, minimal structural drift
PRJ-08 3.8% Clean architecture, minimal structural drift
PRJ-10 3.7% Clean architecture, minimal structural drift
PRJ-04 16.1% New language (Go), learning-elevated rework
PRJ-03 43.2% Structural problems requiring Tear Down

The ten-fold difference between PRJ-03 and the PRJ-08/09/10 cluster quantifies what structural misalignment costs -- and what Realign and Tear Down are designed to resolve.

How to Apply It

1. Recognize the Persistence Signal When you deploy Stop. Run It Back multiple times and hit the same wall, stop blaming the session. The problem is not context corruption -- it is structural. Look at the architecture. Look at the schema. Look at the accumulated decisions encoded in committed code. If the friction persists across fresh sessions, you have a project-level problem that requires a project-level response.

2. Assess Honestly: Realign or Tear Down Use the signal table. If specific features have drifted but the architecture is sound, Realign -- stop execution across the project, identify what drifted, correct it, verify alignment with Target before resuming. If every fix creates new problems, if rework rates are accelerating despite corrections, if a previous Realign failed to hold -- the structure is poisoned. Accept the assessment and move to Tear Down.

3. Extract Before You Destroy Before Tear Down, extract every transferable asset into Foundation: templates, patterns, domain knowledge, integration credentials, solved problems. This is what makes Tear Down safe instead of catastrophic. The rebuild inherits everything except the flawed structure. If your Foundation is not maintained -- if Sweeps have lapsed and Storage Discipline has degraded -- fix Foundation health first. Tear Down without healthy Foundation destroys irrecoverable work.

4. Rebuild from Foundation Through Scaffold After Tear Down, use Scaffold to deploy Foundation assets into a new structural frame. Target the same objective from a clean architectural base. The rebuild will be faster than the original build because you know what to build, what to avoid, and you have reusable assets ready. PRJ-03 proved this: 4.2 hours for what had accumulated over multiple prior sessions. The knowledge was never lost -- only the constraint was removed.

References

  1. Keating, M.G. (2026). "Foundation." Stealth Labz CEM Papers. Read paper
  2. Keating, M.G. (2026). "Sweeps." Stealth Labz CEM Papers. Read paper
  3. Keating, M.G. (2026). "Scaffold." Stealth Labz CEM Papers. Read paper
  4. Keating, M.G. (2026). "Burst." Stealth Labz CEM Papers. Read paper
  5. Keating, M.G. (2026). "Target." Stealth Labz CEM Papers. Read paper
  6. Keating, M.G. (2026). "Stop, Pause, Reset." Stealth Labz CEM Papers. Read paper
  7. Keating, M.G. (2026). "Stop, Run It Back." Stealth Labz CEM Papers. Read paper
  8. Keating, M.G. (2026). "Spiral Anatomy." Stealth Labz CEM Papers. Read paper
  9. Keating, M.G. (2026). "Storage Discipline." Stealth Labz CEM Papers. Read paper
  10. Keating, M.G. (2026). "Recalibrate / Hard Reset." Stealth Labz CEM Papers. Read paper