Rewrite Scope Firewall¶
Control barrier — instantiates Second-System Complexity Restraint
A structural barrier that forces parity work, debt repair, architecture change, and new features into separate approval channels so none can smuggle the others in.
"While we're rebuilding it anyway" is the phrase that sinks second systems, and it works by conflation: a parity ticket quietly carries an architecture rewrite; a debt-cleanup branch grows three new features; a bug fix becomes a redesign. Rewrite Scope Firewall is the structural barrier that keeps work classes physically separate. It routes parity, technical-debt retirement, architecture change, and net-new features into distinct channels — separate branches, separate review tracks, separate approval authority — so that no class can ride in on another's justification. Its defining idea is separation of concerns applied to change itself: not a judgment about whether any item is good (that is scoring), and not a schedule of when work lands (that is staging), but a wall ensuring each piece of work travels through the channel that matches what it actually is.
Example¶
A bank is rewriting the core payments ledger its first system ran for fifteen years. The classic failure looms: an engineer opens a branch to fix a rounding bug (a parity/debt item), notices the surrounding code is ugly, refactors the module (architecture), and — since they are in there anyway — adds a new fee-calculation feature a product manager mentioned. One pull request, four unrelated risks, impossible to review or roll back cleanly.
The Rewrite Scope Firewall forbids this. Work is tagged at intake into one of four lanes — parity, debt retirement, architecture, new feature — and each lane has its own branch policy and its own approver. The rounding fix goes through the parity lane and ships. The refactor, if justified, files as a separate debt-lane item routed to the debt-retirement lane with its own review. The new fee feature must go through the feature channel — where it hits admission scoring — and cannot enter as a rider on a bug fix. The firewall also consults the constraint-function map: a debt item that removes an old constraint must name the replacement discipline before it clears the wall. The result is that every change is reviewable, attributable, and reversible on its own.
How it works¶
- Tag at intake by work class. Every unit of work is classified — parity, debt, architecture, or new feature — before it can start; unclassified work does not proceed.
- Give each class its own channel. Separate branches, review tracks, and approval authority per class, so a change cannot silently change class mid-flight.
- Retire debt in its own lane. Technical-debt work flows through a dedicated retirement lane with its own budget, rather than hitching onto feature or parity branches where it hides.
- Check constraint-function before release. A change that removes a predecessor constraint must reference the function map and name the replacement discipline, so the firewall does not let a "cleanup" quietly drop a load-bearing function.
Tuning parameters¶
- Channel count and granularity — how many lanes and how finely work is classified. More lanes give cleaner separation but add routing overhead and edge-case disputes about which lane an item belongs to.
- Wall height — how strictly cross-class bundling is forbidden (hard block versus flagged exception). A hard wall maximally prevents smuggling but can force artificial splits of genuinely coupled work.
- Approval separation — whether each lane has distinct approvers or shared ones. Distinct approvers resist conflation but cost coordination and can slow tightly related work.
- Bundling exception policy — when, if ever, two classes may share a change, and who signs off. Each allowed exception is a crack in the firewall.
When it helps, and when it misleads¶
Its strength is structural, not motivational: it does not rely on discipline to resist "while we're in here anyway" — it makes the bundling mechanically inconvenient by enforcing separation of concerns at the level of change management.[n1] Clean lanes also make the successor reviewable and reversible: a lane can be paused, audited, or rolled back without dragging unrelated work with it.
Its failure mode is bureaucratic friction: taken too far, forcing genuinely coupled changes into separate lanes creates ceremony, artificial splits, and merge pain that tempt engineers to route around the firewall entirely — at which point it protects nothing. The classic misuse is a firewall so rigid that a two-line fix requires three tickets, breeding contempt for the whole control. The guarding discipline is to keep the lanes few and the classification fast, to allow a governed, rare exception for truly inseparable work, and to measure the firewall by whether risky bundling actually stopped — not by how many tickets it generated.
How it implements the components¶
technical_debt_retirement_lane— the firewall's signature: debt gets a dedicated channel with its own budget and review, so cleanup neither hides inside feature work nor is starved by it.preserved_constraint_function_map— a change that removes an old constraint must clear the wall by naming the function's replacement, wiring the map into the change-control gate.
It does not score whether a new feature deserves admission — that is the ambition_triage_gate of Feature Admission Rubric; and it does not cap the successor's aggregate complexity, which is the complexity_and_scope_budget job of Complexity Budget Review. The firewall only governs *which channel work travels through, not whether or how much of it there is.*
Related¶
- Instantiates: Second-System Complexity Restraint — supplies the structural separation that stops one work class from smuggling in the others.
- Consumes: Constraint-Release Inventory — supplies the constraint-function map the firewall checks releases against.
- Sibling mechanisms: Architecture Decision Record with Future-Option Cost · Complexity Budget Review · Constraint-Release Inventory · Feature Admission Rubric · Parity-Then-Expansion Gate · Postlaunch Ambition-Thaw Review · Second-System Premortem · Staged Release Ladder · Successor Charter
Editorial Notes¶
Form Classification¶
Form family: Structure, Architecture & Configuration
Rationale: Rewrite Scope Firewall operates by maintains separate work channels, branches, review tracks, and approval boundaries by classified work type. That concrete deployed or enacted form is Structure, Architecture & Configuration under the frozen taxonomy.
Nearest alternative: Control, Automation & Runtime — Although Control, Automation & Runtime can support this mechanism, the frozen evidence makes its operative form the act that maintains separate work channels, branches, review tracks, and approval boundaries by classified work type; the alternative is therefore secondary rather than defining.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Separating kinds of work into distinct approval channels is an organizational portfolio-governance control.
Related originating lineages:
- Accounting & Auditing — Control segregation independently prevents one budget or approval purpose from concealing another.
- Computer Science & Software Engineering — Architecture and change-control practice materially distinguishes refactoring, repair, and feature scope.
- Systems Thinking & Cybernetics — Systems thinking, feedback control, and cybernetics supplies a parallel or contributing lineage for the mechanism's defining operation: a structural barrier that forces parity work, debt repair, architecture change, and new features into separate approval channels so none can smuggle the others in.
Review resolution: Both blind reviewers agree that organizational_management is the primary historical origin. Explicit reconciliation of alternate origin disagreement starts from reviewer_a’s mechanism-specific evidence: Separating kinds of work into distinct approval channels is an organizational portfolio-governance control. Reviewer A proposed alternates=accounting_auditing, computer_science, origin_mode=cross_disciplinary_synthesis, domain_reach=multi_domain, and encyclopedia_synthesis=true; reviewer B proposed alternates=computer_science, systems_cybernetics, origin_mode=cross_disciplinary_synthesis, domain_reach=multi_domain, and encyclopedia_synthesis=true. The final record retains every independently supported alternate from either review (accounting_auditing, computer_science, systems_cybernetics) without an arbitrary cap, selects origin_mode=cross_disciplinary_synthesis to represent the combined lineage evidence, and keeps domain_reach=multi_domain and encyclopedia_synthesis=true from the more mechanism-specific assessment. Present-day transfer is recorded as reach and is not treated as proof of historical origin.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; medium confidence.
Notes¶
[n1] Separation of concerns — Dijkstra's principle that a system is more tractable when distinct aspects are handled independently rather than tangled together. The firewall applies it to the change process itself: each class of change is a separate concern with its own channel, so reasoning, reviewing, and reverting stay clean. ↩