Repair the system, not only the symptom.
Some software problems cannot be corrected reliably at the point where the failure becomes visible. The change surface may include ownership, state, data boundaries, authority, concurrency, integrations, recovery behavior, and downstream consumers.
Scope trigger
System complexity, not organization size
This work is defined by the architecture surrounding the change rather than by a customer-size label. A small product can contain a system-level problem; a larger organization can have a narrowly local one. The determining question is whether the requested behavior crosses architectural boundaries that must be understood together.
The objective is not to expand scope unnecessarily. It is to avoid declaring a repair complete when the local edit has not resolved the contracts, dependencies, state, authority, failure paths, or downstream behavior that participate in the same problem.
Signals
When architecture reconstruction becomes part of the repair
- The visible defect crosses state, data, authority, concurrency, integration, or recovery boundaries.
- A local patch passes its immediate test while related behavior regresses elsewhere.
- Multiple compensating fixes have accumulated around behavior owned by another component or contract.
- The requested change cannot be scoped confidently without reconstructing dependencies and decision ownership first.
- Failure paths or downstream consumers are materially affected by a change that appears local in the codebase.
Engineering output
What system-level remediation produces
The development method governs how the work is performed. This page describes the system-level scope produced when the problem requires more than a feature-local edit.
- Architecture reconstruction
- Establish the relevant components, contracts, dependencies, state, authority, and unresolved boundaries surrounding the problem.
- Ownership and change scope
- Identify which component owns the behavior, what the architectural blast radius includes, and which invariants constrain the repair.
- Correct-layer implementation
- Modify the owning layer instead of distributing compensating logic around the visible symptom.
- Proof across the affected surface
- Verify direct behavior together with regression surface, integrations, failure paths, relevant invariants, and downstream effects.
Related material
Method, evidence, and architecture terms
PRIDE Protocol defines the development process; the Work section exposes current artifacts and implementation evidence; the Technical Wiki defines architectural blast radius, reasoning scope, decision ownership, invariants, and related terms used in this work.