Skip to content

Refactoring

Prime #
1124
Origin domain
Computer Science & Software Engineering
Subdomain
software engineering → Computer Science & Software Engineering

Core Idea

Refactoring is the structural pattern of changing the internal structure of a system while holding its externally observable behavior fixed. The defining commitment is a behavior-equivalence invariant: whatever the system produced before the change — outputs, contractual obligations, regulatory effects, the experience it delivers to a consumer — it must produce after. What is free to change is everything internal to the boundary that defines "external behavior": the parts, their arrangement, their names, the interfaces they present to each other, and any performance characteristics that fall short of becoming externally visible.

The structural payoff is that refactoring decouples internal renovation from external transition risk. A system can be reorganized without renegotiating with downstream consumers, without re-litigating its purposes, and without disrupting whoever depends on it, because the contract those parties care about is held constant. This is what distinguishes the move from redesign (where the contract is also up for change), from replacement (where the system itself is exchanged for another), and from evolution under selection (where the contract changes in response to an environment).

A subtler structural fact governs the whole pattern: the invariant being held is whatever counts as external behavior, and that line is itself a design choice. Refactoring presupposes that some interface or contract is treated as fixed, and where that line is drawn determines what counts as a refactoring versus a breaking change. When the held interface is a public API, internal performance may drift silently and the space of permissible internal change is broad; when the interface includes timing and side effects, as in a real-time system, the permissible space narrows sharply. Naming the invariant precisely is therefore the first and most load-bearing act of any refactoring.

How would you explain it like I'm…

Tidy Inside, Same Outside

Imagine cleaning and rearranging the inside of your toy box so it's neater, but the toys you can take out and play with are exactly the same as before. Nobody playing with you notices any change — only the inside got tidier. Refactoring is fixing up the inside of something while keeping what it does on the outside exactly the same.

Rewire, Same Snacks

Refactoring means changing how something is built on the inside while keeping what it does on the outside exactly the same. Think of reorganizing the wiring and shelves inside a vending machine: you can rearrange everything inside, but it still takes the same coins and drops out the same snacks, so customers can't tell anything changed. The rule you must never break is that the outside behavior stays identical. This is different from a redesign (where you're allowed to change what it does), from replacement (where you swap the whole thing out), and from evolution (where the outside changes to fit a new environment). The whole point is to tidy and improve the insides without disturbing anyone who depends on the outside.

Behavior-Preserving Rework

Refactoring is the pattern of changing the internal structure of a system while holding its externally observable behavior fixed. The defining rule is a behavior-equivalence invariant: whatever the system produced before — outputs, obligations, the experience it delivers to a consumer — it must produce after. What's free to change is everything inside the boundary that defines 'external behavior': the parts, their arrangement, their names, the interfaces they show each other, and any performance that doesn't become externally visible. The payoff is that refactoring decouples internal renovation from external transition risk — you can reorganize the insides without renegotiating with the people who depend on the outside, because the contract they care about is held constant. This is what separates it from redesign (the contract is also up for change), replacement (the system itself is swapped out), and evolution under selection (the contract changes to fit an environment). The subtle part: the invariant being held is whatever counts as 'external behavior,' and that line is itself a design choice — naming it precisely is the first and most load-bearing act of any refactoring.

 

Refactoring is the structural pattern of changing the internal structure of a system while holding its externally observable behavior fixed. The defining commitment is a behavior-equivalence invariant: whatever the system produced before the change — outputs, contractual obligations, regulatory effects, the experience it delivers to a consumer — it must produce after. What is free to change is everything internal to the boundary that defines 'external behavior': the parts, their arrangement, their names, the interfaces they present to each other, and any performance characteristics that fall short of becoming externally visible. The structural payoff is that refactoring decouples internal renovation from external transition risk: a system can be reorganized without renegotiating with downstream consumers, without re-litigating its purposes, and without disrupting whoever depends on it, because the contract those parties care about is held constant. This distinguishes the move from redesign (where the contract is also up for change), from replacement (where the system itself is exchanged for another), and from evolution under selection (where the contract changes in response to an environment). A subtler structural fact governs the whole pattern: the invariant being held is whatever counts as external behavior, and that line is itself a design choice. Refactoring presupposes that some interface or contract is treated as fixed, and where that line is drawn determines what counts as a refactoring versus a breaking change. When the held interface is a public API, internal performance may drift silently and the space of permissible internal change is broad; when the interface includes timing and side effects, as in a real-time system, the permissible space narrows sharply. Naming the invariant precisely is therefore the first and most load-bearing act of any refactoring.

Structural Signature

the system with mutable internals — the external contract held fixed — the behavior-equivalence invariant — the verification mechanism — the small reversible step — the refactor/feature separation

A change is a refactoring when each of the following holds:

  • A system with mutable internals. There is an artifact whose parts, arrangement, names, and internal interfaces are free to change — code, statute, org chart, building interior, prose, proof.
  • An external contract held fixed. Some boundary is designated as the observable behavior that must not change — a published API, a statutory effect, a delivery commitment, a building envelope, the meaning of a text. Where this line is drawn is itself a design choice and the first load-bearing act.
  • The behavior-equivalence invariant. Whatever the system produced across that boundary before the change, it must produce after; internal change is licensed only insofar as it preserves this.
  • A verification mechanism. Some means re-checks the invariant after change — a test suite, a case-law comparison, output tracking, complete drawings — and a system supports refactoring exactly to the degree this re-check is cheap.
  • The small reversible step. Change proceeds in individually reversible increments with the invariant verified between each, rather than in a single sweeping motion.
  • The refactor/feature separation. Behavior-preserving change is kept distinct from behavior-changing change; a step that begins altering the contract is backed out and treated as a separately negotiated feature.

The components compose so that internal renovation is decoupled from external transition risk — the contract held constant, cheaply re-verified, and renovated step by step — which is precisely why the move fails in substrates lacking a cheap invariant-verification mechanism.

What It Is Not

  • Not refinement. Refactoring holds observable behavior exactly equal; refinement permits behavior to become more specified or more correct — narrowing nondeterminism, strengthening guarantees. A refinement changes what the system promises; a refactoring does not.
  • Not a feature change. A feature change alters the external contract; refactoring keeps it fixed. The two carry opposite risk and approval profiles, and "refactor, then feature" keeps them distinct.
  • Not a transformation in general. A transformation may freely change outputs; refactoring is the behavior-preserving special case, constrained by the equivalence invariant. Not every internal rewrite that changes behavior is a refactoring.
  • Not replacement. Replacement exchanges the system itself for another; refactoring renovates the internals of the same system behind a held-fixed contract.
  • Not modularity. Modularity is a structural property of an artifact's decomposition; refactoring is the behavior-preserving process that may improve modularity, not the property itself.
  • Common misclassification. Calling a change a "refactoring" while stakeholders disagree about what is being held constant — an unstated or contested invariant means the project is undisciplined change wearing refactoring's name, silently breaking a behavior someone relied on.

Broad Use

  • Software engineering (origin): the canonical case, with named operations — extract method, rename, introduce parameter object — backed by automated test suites that pin the external behavior so internal change can proceed continuously.
  • Law and statutory drafting: restating a statute with clearer structure, consolidated definitions, and de-duplicated provisions, without changing what it makes lawful or unlawful. Codification efforts are large-scale refactoring with legal effect as the held-constant invariant.
  • Organizational design: re-orgs that preserve product output and customer relationships while rearranging reporting lines, team composition, and decision authority. The contract held constant is "what we deliver, to whom."
  • Built architecture: gut renovation that preserves footprint, facade, registered use, and tenant obligations while reorganizing interior walls and mechanical systems. Adaptive reuse is architectural refactoring against an external envelope.
  • Writing and editing: structural editing that preserves what a piece says — its claims and conclusions — while restructuring how it says it. The invariant is meaning; the prose is up for change.
  • Mathematics: rewriting a proof with cleaner notation or a better lemma sequence while preserving exactly what is proven; the logical content is the invariant.
  • Engineering: retrofitting an existing system with newer components without changing its user-facing controls, ratings, or compliance certifications.

Clarity

Naming a change as refactoring forces explicit identification of two things at once: what is being held constant (the external contract, the observable behavior) and what is being changed (the internal structure). The clarification cuts in two directions — it tells the actor what they may not break, and it tells stakeholders why they need not worry.

The framing separates three kinds of change that ordinary language conflates: refactoring (internal change, no contract change), feature change (contract change), and replacement (the system itself is exchanged). Each carries a different risk, communication, and approval profile, so collapsing them obscures exactly the distinctions that determine how a change should be governed. A team that says "we refactored the billing system" makes a verifiable claim about scope that "we updated the billing system" does not.

The most productive cross-domain use is the implicit-invariant diagnostic: a project labelled refactoring whose stakeholders disagree about what is being held constant is a project with a missing contract specification. Surfacing that disagreement — making the invariant explicit before any internal change proceeds — is itself the structural intervention, and it applies identically whether the artifact is a codebase, a statute, or an org chart.

Manages Complexity

Refactoring lets a system be continuously renovated without requiring each renovation to also renegotiate its purposes with everyone downstream. The complexity it manages is coordination cost: in any system with many consumers of a contract, changing the contract is expensive, and a refactor bypasses that expense entirely. The same compression — change without contract renegotiation — appears in legal codification (no need to re-pass legislation), in re-orgs (no need to renegotiate customer contracts), and in gut renovation (no need to re-zone).

A second compression is that refactoring leans entirely on the means of verifying the invariant. In software this is the automated test suite; in law, a comparison of legal effects before and after; in writing, the round-trip check "does it still say the same thing?" The shared structural commitment is to behavior-equivalence verification, and the absence of such a means is precisely why refactoring is risky in the substrates that lack one — large untested codebases, deep re-orgs without clear delivery contracts, renovations of buildings without complete drawings. The verification mechanism is not incidental infrastructure; it is the thing that makes the invariant cheap enough to re-check after each small step, and so the thing that makes disciplined refactoring possible at all.

Abstract Reasoning

Recognizing the pattern licenses a recurring set of structural moves. The first is invariant specification: the held-constant boundary is the thing to write down, because refactoring without an explicit invariant is undisciplined change, while refactoring with one is structurally safe. The second is test-as-invariant-witness: the means of re-verifying the invariant is load-bearing infrastructure, and a system supports refactoring exactly to the degree that its invariant can be cheaply re-checked.

The third is step-size and reversibility: refactoring proceeds in small, individually reversible steps with the invariant verified between each — a discipline that transfers to staged legislative consolidation with judicial-effect testing, to incremental re-orgs with output tracking, and to phased renovation with envelope-integrity checks. The fourth is scope-creep prevention: refactoring is structurally narrow, so a change that begins producing behavior change should be backed out and treated as a separate, separately negotiated feature change. The widely transferable rhythm is "refactor, then feature": clean up first, change behavior second, never both in one indistinguishable motion. A fifth, more sobering pattern is the renovation paradox: the system that most needs refactoring is often the one in which refactoring is hardest, because the missing internal discipline is itself why the invariant cannot be cheaply re-verified. The same paradox recurs in legacy codebases, calcified bureaucracies, and heritage buildings.

Knowledge Transfer

The deepest transfers move concrete disciplines across substrates rather than mere vocabulary. The software insight that an automated test suite is the load-bearing infrastructure of refactoring transfers directly to legal codification: without a corpus of decided cases pinning what the law currently does, a codification risks silently changing legal effect, and the intervention is to build that "test suite" of cases first and check the codified version against it. The engineering insight that small reversible steps are safer than a big-bang change transfers to re-org design, where incremental moves with output tracking between each beat a single sweeping reorganization. The rhythm of separating internal renovation from external change transfers to product design (do the cleanup, then add the capability) and to policy (consolidate, then amend). The architectural insight that the held-constant envelope can be the only externally visible commitment — a heritage facade behind which everything is renovated — transfers to long-lived software APIs, where the published interface is the facade and everything behind it is free to change.

What makes these genuine transfers rather than analogies is that the structural roles map exactly. The system is the artifact whose internals change; the external contract — API, statutory effect, organizational output, building envelope, semantic meaning — is the invariant; the verification mechanism — test suite, case-law comparison, output tracking, complete drawings — re-validates it after each step; and the refactor/feature separation keeps behavior-preserving change distinct from behavior-changing change. A practitioner who has internalized the pattern in one substrate can walk into another and immediately ask the right questions: what is the invariant here, how do we re-verify it cheaply, and is this proposed change actually preserving it or quietly breaking it? Those questions, and the interventions they imply — invariant specification, test-as-witness, small-step discipline, refactor-then-feature — are what travel, with the same diagnostic force in every domain where some structure must be renovated without renegotiating its contract.

Examples

Formal/abstract

Rewriting a mathematical proof is refactoring with the logical content as the held-fixed contract — the cleanest formal instance because behavior-equivalence here is provable rather than merely tested. Suppose a textbook proof of the irrationality of \(\sqrt{2}\) is tangled: it mixes the parity argument with an unnecessary appeal to the fundamental theorem of arithmetic and repeats a divisibility lemma inline twice. The system with mutable internals is the proof text — its lemma ordering, notation, and intermediate steps; the external contract held fixed is exactly what is proven (the theorem statement) together with the axioms relied on. A refactoring extracts the repeated divisibility step as a named lemma (the analogue of "extract method"), replaces the heavyweight factorization appeal with the lighter parity argument, and renames variables for clarity. The behavior-equivalence invariant is that the conclusion and its dependence on the same axiom base are unchanged — the verification mechanism is a step-by-step re-check (or a proof assistant) confirming the rewritten chain still derives the theorem. The small reversible step discipline matters: each edit is checked to still close the proof, so a slip that accidentally strengthens the hypothesis is caught and backed out as a refactor/feature violation (that would be proving a different theorem). The intervention this licenses: clean up the argument's structure for the reader without anyone needing to re-audit what was proven, only how.

Mapped back: the proof text (mutable internals), the theorem-plus-axioms (fixed contract), the re-derivation check (verification mechanism), and the lemma extraction (a behavior-preserving step) instantiate the signature; the refactor/feature line is the boundary between rewriting a proof and proving a new claim.

Applied/industry

A statutory codification, a corporate re-org, and a heritage-building renovation are all refactorings distinguished only by where the invariant is drawn. The codification project consolidates a sprawl of amendments into a clean restatement: the mutable internals are section numbering, definitions, and cross-references; the external contract is legal effect — what remains lawful or unlawful must not change — and the prime's deepest transfer is exact here, that the verification mechanism is a corpus of decided cases pinning what the law currently does, built first and re-run against the codified text, the legal analogue of a test suite. The re-org rearranges reporting lines, team composition, and decision rights while holding "what we deliver, to whom" constant; the prime's small-reversible-step discipline (incremental moves with output tracking between each) beats a single big-bang reorganization, and a change that begins altering the product commitment is a feature, not a refactor, to be negotiated separately. The heritage renovation guts and rebuilds the interior behind a protected facade: the external envelope (footprint, facade, registered use, tenant obligations) is the only externally visible commitment, and everything behind it is free to change — the architectural mirror of a long-lived public API. All three exhibit the renovation paradox the prime names: the legacy statute, the calcified org, and the building without complete drawings are hardest to refactor precisely because the missing internal discipline is why the invariant cannot be cheaply re-verified.

Mapped back: statutory law, organizational design, and architecture are three genuine domains where the same roles operate — mutable internals, a fixed external contract (legal effect, delivery commitment, building envelope), and a verification mechanism (case corpus, output tracking, complete drawings) — and the prime's discipline (specify the invariant, verify cheaply, step small, separate refactor from feature) transfers intact beneath the software-flavoured name.

Structural Tensions

T1 — Where the Invariant Line Is Drawn (the boundary is a choice). "External behavior" is not given; designating which boundary to hold fixed is the first and most load-bearing act, and the same change is a refactoring or a breaking change depending on where the line sits. The characteristic failure mode is an unstated or contested invariant — a team "refactors" while consumers depended on a behavior the team considered internal (an undocumented timing, a side effect, an exact output format), silently breaking them. Diagnostic: ask whether all parties agree on exactly what the contract includes; if stakeholders disagree about what is being held constant, the invariant is unspecified and the project is undisciplined change wearing refactoring's name.

T2 — Observed Behavior versus Specified Contract (Hyrum's law). The held-fixed contract is the intended behavior, but consumers couple to observed behavior — every quirk, timing, and incidental output someone has come to depend on. The tension is that the true invariant is larger than the documented one. The failure mode is preserving the spec faithfully while breaking an undocumented behavior a downstream actor relied on, a "behavior-preserving" change that is not. Diagnostic: ask what consumers actually observe versus what the contract promises; if the gap is wide and consumers couple to observables, the verification mechanism must pin observed behavior, not just the specified contract.

T3 — Cheap Verification versus the Renovation Paradox (the system that most needs it can least support it). Disciplined refactoring requires cheap re-verification of the invariant after each step; the systems most in need of refactoring — legacy code, calcified bureaucracies, undocumented buildings — are precisely those lacking that mechanism, because the missing internal discipline is why the invariant cannot be cheaply checked. The failure mode is refactoring a verification-poor system anyway and silently breaking the contract, or freezing in place because every change is unverifiable. Diagnostic: ask whether the invariant can be re-checked cheaply; if not, the first move is to build the verification mechanism (characterization tests, a case corpus) before any internal change, not to refactor.

T4 — Refactor versus Feature (scope-creep is a sign error). The pattern is structurally narrow: behavior-preserving change must stay distinct from behavior-changing change, in opposite "directions" of the contract. The tension is the temptation to do both in one motion. The failure mode is a change that starts as cleanup and quietly begins altering the contract, so neither the refactor nor the feature is independently verifiable and a regression cannot be localized to one or the other. Diagnostic: ask whether any step has begun changing observable behavior; if a refactor starts producing a contract change, back it out and treat it as a separately negotiated feature — "refactor, then feature," never both indistinguishably.

T5 — Small Reversible Steps versus Big-Bang Rewrite (the temporal trade-off). Refactoring proceeds in individually reversible increments with the invariant verified between each; the alternative — a single sweeping rewrite — is faster to start but cannot localize a break and is hard to reverse once underway. The failure mode is the big-bang renovation that drifts from the invariant somewhere in the middle, with no checkpoint to revert to and no way to tell which of a thousand simultaneous changes broke the contract. Diagnostic: ask whether the change can be decomposed into steps each individually verifiable and reversible; if it can only be done all-at-once, the risk is a one-way door, and the discipline is to find a path of small behavior-preserving moves instead.

T6 — Refactoring versus Refinement (the framing boundary). Refactoring holds observable behavior exactly equal across an internal change; its nearest neighbour refinement permits behavior to become more specified or more correct — narrowing nondeterminism, strengthening guarantees — which is not behavior-preservation. The tension is at the boundary: a change that tightens a contract or resolves an ambiguity looks like cleanup but actually changes what the system promises. The failure mode is calling a refinement a refactoring, reassuring stakeholders that nothing changed when in fact the contract was strengthened (and some previously-valid input now behaves differently). Diagnostic: ask whether observable behavior is held identical or made more determinate/correct; if the latter, it is refinement, carries its own transition risk, and must not be sold as a no-change refactoring.

Structural–Framed Character

Refactoring sits at the framed midpoint of the structural–framed spectrum. The underlying relation is clean and substrate-neutral — change internal structure while holding an external contract fixed, verified between small reversible steps — and that behavior-equivalence invariant recurs across code, statute amendment, org redesign, building-interior renovation, and prose editing. But the prime is, at bottom, a design discipline, and that gives it a real frame.

The decisive diagnostic is institutional_origin at 1.0: refactoring is a named software-engineering practice, codified by Fowler, with a definite disciplinary home rather than a formal-mathematical one. Two diagnostics read 0.5. Its vocabulary travels with translation — refactor, behavior-preserving, test suite, breaking change are engineering terms that need restating in law or architecture. And it is human-practice-bound in a structural way: the move fails in substrates lacking a cheap invariant-verification mechanism, so it presupposes a practice that can re-check the contract (a test suite, a case-law comparison, complete drawings) — a dependence on a verification discipline rather than on any physical substrate, which is why it does not simply "run" in nature. The one diagnostic that stays clean is evaluative_weight at 0: behavior-preserving change is neither good nor bad in itself, merely a value-neutral relation between before and after. A strongly institutional origin, plus half-steps on traveling vocabulary and practice-boundness, against a value-neutral core, produce the 0.5 aggregate the frontmatter records — a genuine invariant wearing a software-engineering discipline's frame.

Substrate Independence

Refactoring is a strongly substrate-independent prime — composite 4 / 5 on the substrate-independence scale. The domain breadth is maximal at 5: the change-internal-structure-while-preserving-external-behavior pattern operates with the same force in software (the named origin), law and statutory codification (restating a statute without altering legal effect), organizational design (re-orgs preserving delivery while rearranging reporting), built architecture (gut renovation behind a protected envelope), writing and editing (restructuring prose while preserving meaning), mathematics (rewriting a proof while preserving what is proven), and engineering retrofits — genuinely distinct domains where the behavior-equivalence invariant is clear in each. The structural abstraction is high but not total, scored 4: the underlying relation (hold an external contract fixed, renovate internals, verify between small reversible steps) is value-neutral and medium-free, yet the prime is at bottom a design discipline whose move fails in substrates lacking a cheap invariant-verification mechanism — it presupposes a practice that can re-check the contract (a test suite, a case-law corpus, complete drawings), a dependence on a verification discipline that pure structural primitives lack, which holds the component at 4. The transfer evidence is concrete at 4: the disciplines map exactly, not analogically — the software insight that a test suite is load-bearing transfers to building a case corpus before legal codification, the small-reversible-step rule transfers to incremental re-orgs with output tracking, and the held-envelope insight transfers from heritage facades to long-lived public APIs, with the renovation paradox (the system most needing refactoring can least support it) recurring identically across legacy code, calcified bureaucracies, and undocumented buildings. The software-engineering name and its practice-bound verification dependence are what hold the composite at a strong 4 rather than 5.

  • Composite substrate independence — 4 / 5
  • Domain breadth — 5 / 5
  • Structural abstraction — 4 / 5
  • Transfer evidence — 4 / 5

Relationships to Other Primes

One-hop neighborhood: parents above, mutual partners to the right, children below.Refactoringsubsumption: TransformationTransformation

Parents (1) — more general patterns this builds on

  • Refactoring is a kind of Transformation

    The file: 'Refactoring is a transformation, but a BEHAVIOR-PRESERVING one — it is the specific member of the transformation family constrained by the equivalence invariant.' A clean specialization of transformation.

Path to root: Refactoring → Transformation

Neighborhood in Abstraction Space

Refactoring sits in a sparse region of abstraction space (83rd percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely rather than landing on a neighbor.

Family — Divergence & Controlled Evolution (6 primes)

Nearest neighbors

Computed from structural-signature embeddings · 2026-06-14

Not to Be Confused With

Refactoring must be distinguished from refinement, its nearest neighbour and the move it is most easily mistaken for, because both rewrite a system's internals while keeping its external character recognizable. The decisive difference is what happens to observable behavior. Refactoring holds the externally observable contract exactly equal — every output, timing, and effect the consumer depended on before must be identical after, with internal change licensed only insofar as it preserves this. Refinement changes the observable behavior in a constrained direction: it makes the system more specified, more correct, or more deterministic — narrowing previously-permitted nondeterminism, strengthening a guarantee, resolving an ambiguity. A refinement is therefore not behavior-preserving; some input that was previously valid now behaves differently (more tightly, more correctly), which is a contract change even if it looks like cleanup. The error is to sell a refinement as a refactoring — reassuring stakeholders that "nothing changed" when in fact the contract was strengthened and some downstream consumer relying on the old looseness will break. The diagnostic is whether observable behavior is held identical (refactoring) or made more determinate or correct (refinement); the latter carries its own transition risk and must not be presented as a no-change renovation.

A second genuine confusion is with transformation, the broad notion of mapping one form to another. Refactoring is a transformation, but a behavior-preserving one — it is the specific member of the transformation family constrained by the equivalence invariant. A general transformation is free to change outputs, lose information, or move between structures of unequal richness; refactoring forbids all of that across the held-fixed boundary. The error is to treat any internal rewrite as a refactoring merely because it is a transformation of the code, statute, or org chart — when the rewrite actually alters observable behavior, it is an ordinary (behavior-changing) transformation and inherits transition risk that refactoring's discipline was designed to avoid. Conversely, treating a genuine refactoring as "just a transformation" discards the load-bearing constraint — the invariant and its cheap re-verification — that makes the change safe to ship without renegotiating the contract. Refactoring's value is precisely the restriction that distinguishes it from free transformation.

These distinctions matter because each names a different relationship to the contract. Refactoring holds it equal; refinement tightens it; general transformation may alter it freely. A practitioner who keeps them straight asks whether observable behavior is held identical, made more determinate, or changed outright — and so avoids the two characteristic errors: selling a contract-strengthening refinement as a no-change refactoring, and treating a behavior-changing transformation as if it carried refactoring's safety guarantee.

Solution Archetypes

No catalogued solution archetypes reference this prime yet.