The argument
Build an Exception Exit Plan That Can Actually Finish
A credible exit plan translates the original constraint into a current decision, identifies every dependent consumer, sets measurable exit conditions, sequences migration and testing, and names the evidence that will support closure or a deliberately renewed decision.
The field pattern
A legacy integration cannot support the preferred control design, so the team documents an exception and adds monitoring. Eighteen months later, two new services consume the same integration, the original project has closed, and each quarterly review changes only the expiration date. The exception record describes why removal was once hard but not what would make removal possible now.
Why it matters
Some constraints are legitimate and some exceptions must persist. The anti-pattern is not the existence of an exception; it is a renewal process that produces no new decision-quality information. Current dependencies, control performance, risk, and available alternatives can change even when the original constraint remains.
An exit plan should make both outcomes possible: disciplined closure when evidence supports it, or a transparent renewal that records what was learned, what remains necessary, and why the revised boundary is still accepted.
Questions that expose the Wack
- What exact constraint prevents the intended implementation today—not when the exception was first written?
- Which systems, teams, customers, or controls now depend on the excepted behavior?
- What observable condition would demonstrate that each dependency is ready to migrate or retire?
- Who owns the changes, tests, rollback decision, and final acceptance or closure?