The argument
Retire Inherited Wack Without Breaking Everything
Inherited architecture becomes safely changeable when the team assigns a current decision owner, observes real dependencies, states the expected behavior, designs a bounded experiment, prepares rollback, and records a new keep-change-remove decision.
The field pattern
A permissive network rule has survived several migrations. The original ticket is gone. Flow logs show occasional traffic, but the source names are inconsistent and nobody recognizes the destination service. Operations will not approve removal without impact evidence; security will not approve indefinite retention without a rationale. Both positions are reasonable, and neither produces a decision.
Why it matters
Immediate removal may create unacceptable operational risk. Indefinite preservation creates security, scope, and evidence cost of its own. The productive path is staged learning: observe, identify, constrain, test, and decide.
The key transition is from inherited rationale to current evidence. A modern decision can still be to retain the configuration, but it should name the present owner, dependency, boundary, monitoring, review date, and reason—not simply preserve the absence of knowledge.
Questions that expose the Wack
- Who owns the current risk decision even if no one owns the original implementation?
- What traffic, identity, process, job, or control may depend on this behavior?
- What is the smallest safe experiment that would increase confidence without creating uncontrolled impact?
- What evidence and date will trigger a keep, narrow, replace, or remove decision?