Lehman's law of continuing change¶

The empirical software-evolution law that an E-type system — one embedded in a moving real-world environment — must be continually adapted or it progressively becomes less satisfactory, because its fitness is relational (the gap between what the code does and what the world now requires) and that gap widens monotonically while the code stands still.

Core Idea¶

Lehman's first law — the law of continuing change, introduced by Meir Lehman in 1974 and restated in the 1996 eight-law formulation — is the empirical observation that an E-type software system must be continually adapted or it progressively becomes less satisfactory to its users. An E-type system is one that models or is embedded in a portion of the real world; its operational fitness is therefore not an intrinsic property of the code but a relational property: the gap between what the code does and what the environment now requires. The environment does not stand still — regulations change, hardware platforms evolve, peer systems the software integrates with are updated, user expectations shift — so a system whose code is held constant experiences a monotonically widening mismatch between its behavior and its context. The code does not rot in any physical sense; the mismatch grows because the world around the system moves while the system does not. Satisfactory operation therefore requires sustained investment in adaptation: not just fixing defects but updating the system's model of the world it serves. Lehman and Belady's longitudinal evidence came from the OS/360 release history; the decay dynamic is also visible in cases where adaptation was not sustained — a 1996 Java applet runs the same code it always did but cannot be loaded by any modern browser; the US Internal Revenue Service's Individual Master File, written in COBOL in the 1960s, requires continuous patching not because bugs accumulate but because tax law, payment rails, and integration partners keep moving and each year of non-adaptation accumulates a larger fit deficit. The first law establishes the baseline requirement against which the fifth law (conservation of familiarity) sets the rate constraint: change is compulsory, but the per-release increment must stay within the team-and-user community's absorptive capacity.

Structural Signature¶

Sig role-phrases:

the E-type system — software whose operation is interwoven with a portion of the real world, so its fitness is relational, not intrinsic
the relational-fitness metric — the gap between what the code does and what its environment now requires, distinct from whether the code still does what it did yesterday
the drifting environment — the moving regime (regulations, platforms, integration partners, runtimes, user expectations) the system is embedded in
the held-constant code — frozen software whose intrinsic correctness is unchanged while the world around it moves
the monotone fit-decay — operational satisfaction falling as a decreasing function of time-since-last-adaptation, scaled by environmental volatility
the excluded flat branch — the "no change, no risk" trajectory the law forbids: zero intrinsic change still yields negative relational change
the maintenance reset — the compulsory adaptation that updates the system's model of the world and resets the fit deficit, the increment's rate deferred to the fifth law

What It Is Not¶

Not bit-rot. The code does not physically degrade and its intrinsic correctness is unchanged — frozen software still does exactly what it did yesterday. What degrades is relational fitness: the gap between what the code does and what its now-moved environment requires. The decay is in the world's drift away from the code, not in the code itself.
Not the claim that bugs accumulate. A system can be flawless against its original specification and still be failing its users. The first law concerns fit to a shifting environment, not latent defects; diagnosing the decline as creeping bugs sends the engineer hunting inside the code for a cause that lives outside it — in changed regulations, retired platforms, updated integration partners.
Not "no changes shipped means no risk." This is the exact trajectory the law forbids: zero intrinsic change still yields negative relational change, so freezing a system to "reduce risk" guarantees the fit deficit grows. The comforting flat branch is provably excluded, not a safe option.
Not a prescription about how fast to change. The first law fixes only the direction — adaptation is compulsory — and is silent on the size of each increment. The rate constraint belongs to the companion fifth law (conservation of familiarity); extracting a release-sizing rule from "adapt or decay" alone overreads it.
Not a law of all software. It governs E-type systems — those interwoven with and continually responding to a real-world environment. A self-contained program against a fixed, closed specification, with no moving environment to lose fit to, can run unchanged indefinitely without becoming less satisfactory; the law makes no claim about it.

Scope of Application¶

Continuing change lives within software engineering — the empirical-software-evolution and software-maintenance subfields where E-type systems are operated over long lifetimes — and its reach is bounded there; the fit-decay dynamic recurs in statutes, policies, and curricula, but those are co-instances carried by institutional_lag and temporal_decay_and_degradation, not the named law transferring.

Empirical software evolution — the home turf, where the law is the first of the eight Lehman laws; Belady and Lehman's OS/360 longitudinal data established it and FOSS replications (Godfrey and Tu, Israeli and Feitelson on Linux) confirmed it.
Software maintenance and budgeting — reclassifies baseline maintenance from a discretionary, defect-driven cost into a non-negotiable line item, since a frozen system's relational fitness decays monotonically with environmental drift.
Legacy-system management — diagnoses the decline of an untouched deployed system as environmental drift rather than bit-rot or latent bugs; the IRS Individual Master File is patched continuously not because COBOL rots but because tax law, payment rails, and integration partners keep moving.
Software-lifecycle and risk planning — exposes "ship no changes, incur no risk" as the provably-excluded branch, so a stable legacy system's risk is assessed by time-since-last-adaptation scaled by environmental volatility, not by code stability.
Software preservation and obsolescence analysis — frames why unchanged artifacts lose usability as their runtime environment moves, the 1996 Java applet that runs identical bytecode but loads in no modern browser being the clean relational-failure case.

Clarity¶

The law's central clarification is that an E-type system's fitness is relational, not intrinsic — and naming that splits apart two things a maintenance budget routinely fuses. Intrinsic correctness (does the code do what it did yesterday?) is unchanged in frozen software; relational fitness (does what it does still match what its environment now requires?) degrades monotonically, because the environment moves while the code does not. Without the law, "we shipped no changes" reads as "we incurred no risk," and decay that is really environmental drift gets misdiagnosed as bit-rot or latent bugs. With it, the engineer sees that a system can be flawless against its original spec and still be failing its users, and that the cause is outside the code — in shifted regulations, evolved platforms, updated integration partners — not inside it.

This reframes maintenance from a discretionary, defect-driven activity into a non-negotiable obligation, and sharpens the question a manager asks about a stable legacy system from "is it still working?" to "how far has its environment drifted since we last adapted it, and how volatile is that environment?" The sharper formulation makes operational satisfaction legible as a decreasing function of time-since-last-adaptation, scaled by environmental volatility — so a system in a fast-moving regulatory or integration context accrues a fit deficit far faster than one in a quiet niche, and "freeze it to reduce risk" is exposed as the move that guarantees the deficit grows. The law sets only the direction — change is compulsory — and deliberately leaves the rate to its companion fifth law; together they frame maintenance as mandatory in fact but bounded in increment.

Manages Complexity¶

The forces that degrade a deployed E-type system's standing are heterogeneous and individually intricate: a regulation is amended, a hardware platform is retired, an integration partner ships a breaking change, a browser drops a runtime, user expectations shift. To forecast a frozen system's prospects an engineer would otherwise have to track each of those drift sources on its own clock and aggregate their effects. The first law collapses that heterogeneity by reconceiving fitness as a single relational quantity — the gap between what the code does and what its environment now requires — and asserting one regularity over it: with the code held constant that gap only widens, so operational satisfaction is a monotonically decreasing function of time-since-last-adaptation, scaled by the volatility of the environment. The many drift sources need not be enumerated; they collapse into the one rate at which the world is moving away from the unchanging system. The analyst tracks two things — how long since the last adaptation, how volatile the surrounding regime — and reads the fit deficit off their product, rather than re-deriving the decay from the specific regulations, platforms, and partners in play.

Because the law fixes the sign of that function, the branch structure it supplies is the elimination of an entire false branch. "We shipped no changes, so we incurred no risk" is exactly the trajectory the law rules out: zero intrinsic change still yields negative relational change, so the no-change-no-risk reading is not a benign option but the one that guarantees the deficit grows. The analyst thus reads off, without case analysis, that a flawless system can be failing its users and that the cause lies outside the code — distinguishing environmental drift from bit-rot or latent bugs at a glance, and exposing "freeze it to reduce risk" as the move that maximizes the very deficit it means to avoid. The compression is deliberately partial: the first law sets only the direction, that change is compulsory, and hands the rate constraint to the fifth law, so the analyst reads "adapt or decay" here and "but only as fast as the community can absorb" there. A multi-source, per-system forecasting problem reduces to one monotone curve in time-since-adaptation, with the comforting flat branch provably excluded.

Abstract Reasoning¶

The law of continuing change licenses reasoning moves built on one reconception — an E-type system's fitness is relational (the gap between what the code does and what its environment now requires), not intrinsic (whether the code still does what it did yesterday).

Fit-deficit forecasting (predictive): The characteristic move treats operational satisfaction as a monotonically decreasing function of time-since-last-adaptation, scaled by environmental volatility, and reads a frozen system's prospects off that product. Given how long a system has gone unadapted and how fast its surrounding regime moves, the engineer predicts the size of its fit deficit without enumerating the individual drift sources — regulations, platforms, integration partners, runtimes collapse into the single rate at which the world is moving away from the unchanging code. The reasoning runs FROM (time-frozen × environmental volatility) TO an accrued fitness gap, so a system in a fast-moving regulatory or integration context is predicted to decay far faster than one in a quiet niche even with identical code.

Drift-versus-bitrot diagnosis (diagnostic): Confronted with a deployed system that has grown less satisfactory while its code is untouched, the move is to locate the cause outside the code — in shifted regulations, evolved platforms, updated integration partners — rather than inside it as latent bugs or "bit-rot." The law lets the engineer reason FROM the surface signature (degrading fitness, zero code change) TO the diagnosis of environmental drift, because intrinsic correctness is unchanged in frozen software while relational fitness is not. The 1996 Java applet that runs the same bytecode but loads in no modern browser is the clean case: the failure is entirely relational, so chasing it as a code defect would be misdirected.

False-branch elimination (boundary-drawing): The law fixes the sign of the fitness function, and the most consequential move is what that rules out: "we shipped no changes, so we incurred no risk" is the exact trajectory the law forbids. Zero intrinsic change still yields negative relational change, so the no-change-no-risk reading is not a benign option but the one that guarantees the deficit grows. The reasoning runs FROM a proposal to freeze a system "to reduce risk" TO the conclusion that freezing maximizes the very fit deficit it means to avoid — exposing the comforting flat branch as provably excluded rather than available.

Maintenance-as-obligation reframing (interventionist): Because change is compulsory in direction, the move reclassifies baseline maintenance from a discretionary, defect-driven activity into a non-negotiable line item — and specifies what the intervention must do: not merely fix defects but update the system's model of the world it serves. The reasoning runs FROM the relational-fitness premise TO the budgeting decision that sustained adaptation is mandatory, and the manager's question shifts from "is it still working?" to "how far has its environment drifted since we last adapted it, and how volatile is that environment?" The IRS Individual Master File — patched continuously not because COBOL rots but because tax law, payment rails, and partners keep moving — is the move applied: each year of non-adaptation accrues a larger deficit that the intervention exists to reset.

Direction-without-rate scoping (boundary-drawing): A characteristic discipline is recognizing what this law does not settle. It fixes only that change is compulsory (the direction); it makes no claim about how large each adaptation should be. The move hands the rate question to the companion fifth law (conservation of familiarity) — so the engineer reads "adapt or decay" here and "but only as fast as the producer-and-consumer community can absorb" there. Reasoning that tries to extract a release-sizing prescription from the first law alone overreads it; the boundary between compulsory-direction and bounded-increment is drawn deliberately across the two laws.

Knowledge Transfer¶

Within software engineering the law transfers as a working mechanism across every E-type system, and the transfer is literal because the precondition — software whose operation is interwoven with a moving real-world environment, so that fitness is relational rather than intrinsic — is precisely what makes a system E-type. The fit-deficit forecast, the drift-versus-bitrot diagnosis, and the maintenance-as-obligation reframing move without translation from the OS/360 longitudinal data on which Belady and Lehman first established the law, through the FOSS replications (Linux among them), to the decay cases where adaptation lapsed: the 1996 Java applet that runs the same bytecode but loads in no modern browser, and the IRS Individual Master File patched continuously not because COBOL rots but because tax law, payment rails, and integration partners keep moving. What carries across these substrates is the relational-fitness reconception, the monotone-decay-in-time-since-adaptation curve scaled by environmental volatility, and the provably-excluded "no change, no risk" branch; the vocabulary travels because the referent — a deployed system losing fit to a drifting environment — is the same in each case.

This is the most prime-shaped member of the Lehman cluster, so the cross-domain situation is best described as a shared abstract mechanism that genuinely recurs across substrates as co-instances — carried by the parent primes rather than by Lehman's first law as named, rather than as mere analogy. The underlying dynamic — the fit between a system and its embedding environment drifts as the environment changes, even when the system is held constant, so that standing still is itself a form of decay — really does recur across domains, and the recurrence is mechanistic, not decorative: a statute or treaty whose text is frozen loses fit as the conditions it governs evolve; an organizational policy unrevised drifts out of alignment with the practice it regulates; a curriculum unchanged falls behind the field it teaches. But these are co-instances of the more general patterns the law instantiates — institutional_lag (the same fit-drift dynamic for formal rules and institutions), coevolution (the upstream mechanism: the environment moves, so the system must move too), temporal_decay_and_degradation (fitness as a decreasing function of time, here driven by environmental drift rather than physical wear), and maintenance (the corrective intervention that resets the fit) — and it is those primes, not Lehman's first, that carry the lesson cross-domain. Notably the cross-substrate generalization is not only available from the parents but arguably named better by institutional_lag and temporal_decay_and_degradation, which state the dynamic without the software framing. The home-bound cargo is exactly that software framing: the E-type designation, the "code held constant," the per-release granularity, the specific drift sources (runtimes, platforms, integration partners), and the hand-off of the rate constraint to the companion fifth law. So the honest instruction is that when the structural lesson is wanted in another field, it should be drawn from institutional_lag, coevolution, and temporal_decay_and_degradation, which transfer as mechanism; "Lehman's law of continuing change," as named, is the canonical software case of that broader fit-decay pattern, and keeping it as a domain example preserves the case without claiming the cross-substrate reach for the named law. (See Structural Core vs. Domain Accent.)

Examples¶

Canonical¶

The defining evidence is Belady and Lehman's longitudinal study of IBM's OS/360 operating system, the work that produced the law in 1974. Tracking the system release by release, they found that OS/360 did not settle into a stable, finished state; each release had to keep adapting to a moving world of new hardware, new peripherals, and new user demands, and a system that was not so adapted grew progressively less satisfactory to its users. The observation was not that defects piled up but that the fit between the system and the environment it served kept eroding whenever adaptation lagged. This is why Lehman classed OS/360 as an E-type system — one whose operation is interwoven with a real-world context — and made continuing change the first of his eight software-evolution laws, later replicated on open-source systems including the Linux kernel.

Mapped back: OS/360 is the E-type system; the operating environment of evolving hardware and user needs is the drifting environment. What Belady and Lehman measured decaying was the relational-fitness metric — fit to that environment — not intrinsic correctness of the held-constant code, and their release-over-release erosion is the monotone fit-decay. The finding that releases must keep adapting is the exclusion of the excluded flat branch.

Applied / In Practice¶

The U.S. Internal Revenue Service's Individual Master File illustrates the law in a decades-long production setting. First written in assembly and COBOL in the early 1960s, the IMF is the authoritative record of individual taxpayer accounts, and it has required continuous patching ever since — not because the old code physically rots, but because tax law is rewritten every year, payment rails modernize, and the partner systems the IMF integrates with keep changing. Each filing season that the system went un-adapted would open a larger gap between what the code does and what the current tax code and financial infrastructure require. The IRS has treated maintenance not as an optional, defect-driven expense but as a compulsory annual obligation, precisely because freezing the system would guarantee a widening fit deficit rather than stability.

Mapped back: The IMF is the E-type system; annually revised tax law and evolving payment infrastructure are the drifting environment. The COBOL/assembly base is the held-constant code whose intrinsic behavior is unchanged, while the relational-fitness metric degrades each year of non-adaptation — the monotone fit-decay. The IRS's yearly patching is the maintenance reset, treating adaptation as compulsory rather than accepting the excluded flat branch.

Structural Tensions¶

T1: Frozen code as stability versus frozen code as guaranteed decay (the held-constant code cuts both ways). Freezing a deployed system is not simply a mistake — holding the code constant preserves intrinsic correctness exactly: no regression, no newly introduced defects, no retraining, the system does today what it did yesterday. That stability is a real good, and it is precisely why "freeze it to reduce risk" feels prudent. But the same freeze that eliminates regression risk maximizes relational risk: zero intrinsic change still yields negative relational change, so the fit deficit against a drifting environment grows monotonically beneath the untouched code. The two risks trade directly against each other — the stability that suppresses one guarantees the other — and no freeze can buy both. The comforting move and the harmful move are one move, scored against intrinsic correctness on one side and relational fitness on the other. Diagnostic: is the freeze being defended against regression risk, which it genuinely reduces, while ignoring the relational deficit it silently guarantees?

T2: Compulsory change versus bounded increment (the first law is unsafe without the fifth). The first law fixes only direction — adaptation is compulsory — and read alone it licenses "change as much and as fast as the deficit demands." But maximal adaptation collides with the companion fifth law, conservation of familiarity: each release must stay within the producer-and-consumer community's absorptive capacity. So the two laws pull opposite ways — the first drives change up to close the fit gap, the fifth caps the per-release increment lest the change itself destabilize the team and users. Over-adapt and you exceed absorptive capacity; under-adapt and the deficit accrues. Neither law is safe alone: the first without the fifth overreads into reckless churn, the fifth without the first rationalizes the fatal freeze. Diagnostic: is the proposed release sized to close the fit deficit, or to stay within what the community can absorb — and which constraint is currently binding?

T3: Maintenance-as-obligation versus maintenance's invisibility (the successful reset leaves nothing to show). The law reclassifies adaptation from discretionary defect-fixing into a non-negotiable obligation. But that obligation is structurally under-rewarded: a maintenance reset that updates the system's model of the world produces no visible new feature — it prevents a loss that, done well, never manifests. The better the adaptation, the smaller the fit deficit ever grows, and the less there is to point to; the work's success erases its own evidence. That invisibility is exactly what makes the budget line vulnerable — "it still works, why spend?" — which is the no-change-no-risk reading the law forbids, now dressed as fiscal prudence. The tension: the obligation is real and continuous, yet its payoff is a non-event, so the activity most needed is the one most easily cut. Diagnostic: is maintenance being justified by the deficit it prevents, an invisible non-event, or expected to show a visible deliverable it structurally cannot produce?

T4: E-type versus S-type (the classification that licenses or forbids a freeze). The law's entire force — standing still is decay — holds only for E-type systems, those interwoven with a moving environment. A genuinely self-contained program against a fixed, closed specification is S-type: with no environment to lose fit to, it can run unchanged indefinitely without becoming less satisfactory. The boundary cuts both ways and is the load-bearing judgment. Misclassify an E-type system as S-type — "it's just a batch calculator" — and you license a fatal freeze on something whose environment is quietly drifting; misclassify an S-type as E-type and you burn adaptation budget resetting a fit that was never decaying. The trouble is that E-type-ness is not always legible from the code: a program looks closed until an integration partner, a regulation, or a runtime it depended on turns out to move. Diagnostic: does this system model or integrate with any portion of a moving real world, or is its specification genuinely closed and fixed?

T5: Drift outside the code versus defect inside it (the diagnosis misfires both ways). The law's diagnostic move — a system degrading while its code is untouched means look outside, to environmental drift, not inside for latent bugs — is powerful precisely because it redirects effort away from a fruitless code hunt. But the heuristic can overfire. Real deployed systems also carry genuine latent defects that surface only when inputs or load shift, so a decline that presents as drift can in fact be a dormant bug newly triggered. Reflexively attributing every degradation to environmental drift risks leaving a real defect unpatched; reflexively hunting bugs wastes effort on a purely relational failure like the 1996 applet that runs identical bytecode but loads in no modern browser. "The cause is outside the code" is the right default and a real trap — drift and latent-defect-meets-new-environment share the signature of degrading fit over untouched code. Diagnostic: is the code doing exactly what it always did against unchanged inputs (drift), or has an environmental shift newly exercised a path the code never correctly handled (latent defect)?

T6: The single decay rate versus the specific drift source (compression buys the forecast, costs the prioritization). The law's compression is its power: it collapses regulations, platforms, integration partners, and runtimes into one quantity — time-since-adaptation scaled by environmental volatility — so the fit deficit can be forecast without enumerating each drift source. But the same collapse that makes the forecast tractable discards exactly the information an adaptation must act on. Knowing the deficit is growing at some rate does not tell you which regulation will bite next quarter, which partner's breaking change lands first, or which retired runtime severs the system — and a maintenance reset has to target a specific one. The aggregate rate answers "how urgent is adaptation?" but is silent on "adapt what, first?", so the manager who trusts the collapsed forecast still has to re-open the drift-source detail the law let him ignore in order to sequence the work. Diagnostic: is the forecast being used to decide whether to adapt, where the aggregate rate suffices, or what to adapt first, where the specific drift source must be re-identified?

T7: Autonomy versus reduction (Lehman's first law, or the domain instance of its parents). "Lehman's law of continuing change" is a canonically named, empirically established software-evolution law with its own furniture — the E-type designation, code-held-constant, per-release granularity, the OS/360 data, the hand-off of the rate constraint to the fifth law. Yet the cross-substrate reach belongs not to the named law but to the parents it instantiates: institutional_lag (frozen rules losing fit as conditions evolve), coevolution (the environment moves, so the system must), temporal_decay_and_degradation (fitness as a decreasing function of time), and maintenance (the corrective reset). A frozen statute, an unrevised policy, and an unchanged curriculum decay the same way — but there is no "E-type system" or "release" in a statute, only institutional lag made concrete; indeed the parents arguably name the dynamic better, without the software framing. Diagnostic: resolve toward the parents (institutional_lag, temporal_decay_and_degradation, coevolution) when carrying the fit-decay lesson to another field; toward Lehman's first law when diagnosing a deployed software system's decline in situ.

Structural–Framed Character¶

Lehman's law of continuing change sits at mixed on the structural–framed spectrum, and is the most structural of the Lehman cluster — because its core dynamic (relational fitness decaying as the environment drifts while the system stands still) is genuinely substrate-neutral and recurs across substrates as co-instances, not analogies. The named law is software-bound, which holds it at mixed, but its structural core reaches further than its conservation-law siblings.

Evaluative weight is nil-to-low and points structural. The law is a descriptive regularity — adapt or grow less satisfactory — that grades nothing; even "less satisfactory" names a relational fact (fit to a moving environment), not a verdict on anyone.

Human-practice-bound is where this entry separates from its siblings. The named law is software-practice-bound (E-type systems, code, releases), but the underlying dynamic is not: "standing still is decay" because fitness is relational to a drifting environment is exactly the coevolutionary / Red-Queen pattern that runs observer-free in nature — an organism whose form is frozen loses fitness as its competitors and environment evolve — and recurs in institutions (frozen statutes losing fit). So the core mechanism needs no human practice at all; only the software instantiation does. This is a stronger structural core than conservation-of-familiarity's cognitive bound or conservation-of-organizational-stability's organizational loop, both of which are intrinsically human-community-bound.

Institutional origin is mixed: the named law is Lehman's first, first read off OS/360 — a discipline-born construct — while the fit-decay/coevolution dynamic it points at is a general pattern of nature and institutions, not an invention. Vocab-travels is likewise split: "E-type," "code held constant," "per-release" are software-bound, while the abstract dynamic is well-carried (the entry says better carried) by institutional_lag and temporal_decay_and_degradation. Import-vs-recognize is the decisive structural signal: the entry flags this as the strongest co-instance case in the cluster, where a frozen statute, an unrevised policy, and an unchanged curriculum decay by the same mechanism recognized, not by metaphor imported — the profile of a near-prime dressed in software clothing.

The portable structural skeleton is relational-fitness decay under environmental drift — the fit between a system and its embedding environment falls monotonically as the environment moves while the system is held constant, resettable only by adaptation — carried by coevolution (the upstream driver: the environment moves, so the system must), temporal_decay_and_degradation and institutional_lag (the fit-drift as a decreasing function of time), and maintenance (the corrective reset). As the entry establishes, that skeleton is what continuing change instantiates in a software register, not what makes "Lehman's first law" itself travel: the cross-domain reach belongs to those parents — which name the dynamic without the software framing — while the domain-accented cargo (E-type designation, code-held-constant, per-release granularity, the drift sources of runtimes and platforms, the rate hand-off to the fifth law) stays home. Its character: a substrate-neutral, evaluatively neutral fit-decay/coevolution mechanism (recognized, not analogized, across code, institutions, and nature) wearing software-evolution vocabulary and a named-law identity — structural at its core but pinned by that software cargo to mixed, the most prime-shaped member of the Lehman family.

Structural Core vs. Domain Accent¶

This is the section that decides why continuing change is a domain-specific abstraction and not a prime — and it is a close call, because this is the most prime-shaped member of the Lehman cluster, its core mechanism recognized (not analogized) across code, institutions, and nature.

What is skeletal (could lift toward a cross-domain prime). Strip the software away and a thin, genuinely portable structure survives: the fit between a system and its embedding environment is a relational quantity that falls monotonically as the environment drifts while the system is held constant, so standing still is itself a form of decay, resettable only by adaptation. The portable pieces are abstract: fitness as relational rather than intrinsic, a monotone fit-decay as a function of time-since-adaptation scaled by environmental volatility, the provably-excluded "no change, no risk" flat branch, and a corrective reset. That skeleton is substrate-neutral, and — crucially — it is recognized, not analogized, across substrates the software domain never touches: a frozen statute losing fit as the conditions it governs evolve, an unrevised policy drifting from the practice it regulates, an unchanged curriculum falling behind its field, and, observer-free in nature, a frozen organism losing fitness as competitors coevolve (the Red-Queen pattern). Those are co-instances of the same mechanism, which is why the catalogue carries the lesson as parent primes — coevolution (the upstream driver: the environment moves, so the system must), temporal_decay_and_degradation and institutional_lag (fit as a decreasing function of time), and maintenance (the corrective reset). But this is the core the law shares, not what makes it Lehman's first law.

What is domain-bound. What the named law adds on top of the bare mechanism is software-evolution furniture that does not survive extraction. The system is an E-type system, and the frozen thing is code held constant whose intrinsic correctness is unchanged. The decay is measured at per-release granularity, and the drift sources are software-specific — retired hardware platforms, dropped runtimes, updated integration partners, rewritten regulations the code models. The evidence is the OS/360 release history, the 1996 Java applet that runs identical bytecode in no modern browser, and the IRS Individual Master File patched each filing season. And the law's identity is positional — the first of eight Lehman laws, fixing only the direction (change is compulsory) and explicitly handing the rate constraint to the companion fifth law (conservation of familiarity). The decisive test: remove the code, the release, and the E-type designation and it is no longer continuing change but the bare relational-fit-decay mechanism — which is exactly what a frozen statute or a coevolving organism is, a co-instance of the parents with none of the software apparatus.

Why this does not clear the prime bar. A prime's vocabulary travels and its transfer is recognition of the same mechanism, not analogy — and here the mechanism genuinely does travel by recognition, which is what makes the case close. But the reasoning still lands the named law below the bar, because the recognized traveller is not Lehman's first law as named; it is the substrate-neutral fit-decay/coevolution pattern the law instantiates. Within software the law travels intact as literal mechanism — the relational-fitness reconception, the monotone-decay curve, the excluded flat branch, the maintenance-as-obligation reframe — recurring as recognition across every E-type system (OS/360, Linux, the Java applet, the IMF), because the precondition (software interwoven with a moving environment) is what makes a system E-type. But these are variants of one substrate. Beyond software the co-instances (statutes, policies, curricula, organisms) exhibit the mechanism without the code/release/E-type cargo — and are, the entry notes, arguably named better by institutional_lag and temporal_decay_and_degradation, which state the dynamic without the software framing. So the cross-substrate reach is carried by the parents — coevolution, temporal_decay_and_degradation, institutional_lag, and maintenance — of which Lehman's first law is the canonical software case. The cross-domain reach belongs to those umbrella primes; "continuing change," as named, adds the E-type designation, the code-held-constant, the per-release granularity, the runtime-and-platform drift sources, and the rate hand-off to the fifth law as software-engineering baggage that stays home — leaving it the most prime-shaped member of its family, but still a domain-specific instantiation rather than the prime itself.

Relationships to Other Abstractions¶

Current abstraction Lehman's law of continuing change Domain-specific

Parents (1) — more general patterns this builds on

Lehman's law of continuing change is a decomposition of Calibrated Rule versus Moving World Prime

Lehman's first law is the E-type-software application of a frozen mapping losing fit with a non-stationary world.

Hierarchy paths (2) — routes to 2 parentless roots

Lehman's law of continuing change → Calibrated Rule versus Moving World → Temporal Decay and Degradation → Entropy (Thermodynamic Sense)

Show alternative path (1)

Not to Be Confused With¶

Bit-rot / software rot. The popular notion that unused code physically degrades over time. The first law's decay is relational, not physical: frozen code does exactly what it always did — intrinsic correctness is unchanged — and what erodes is fit to a moved environment. Tell: is the code claimed to have changed or degraded on disk (bit-rot, a misconception), or is it unchanged while the world around it moved (continuing change)? The decay is in the world's drift, not the bits.
Technical debt. The accumulated cost of internal shortcuts, deferred cleanup, and expedient design choices that make future change harder — a property of the code's own structure. Continuing change is about external fit loss to a drifting environment, independent of internal quality: a clean, debt-free system still decays if its world moves. Tell: is the problem inside the code (accumulated shortcuts raising change cost — technical debt), or outside it (environment drifting away from unchanged code — continuing change)?
Lehman's second law (increasing complexity). The sibling law that a system's internal complexity increases as it evolves unless deliberate work reduces it — a claim about entropy accumulating inside the system as it is changed. The first law is about external fit decaying when the system is not changed. They are near-opposites in locus: one about the cost of changing, the other about the cost of not. Tell: is the concern internal structure degrading through evolution (second law), or external fitness degrading through stasis (first law)?
Lehman's fifth law (conservation of familiarity). The companion law the first is deliberately paired with. The first fixes only the direction — adaptation is compulsory; the fifth fixes the rate — each increment must stay within the community's absorptive capacity. Reading a release-sizing rule out of the first law alone overreads it. Tell: is the claim that change is mandatory (first law), or that its per-release size is bounded (fifth law)? Direction versus rate.
The parent primes it instantiates (coevolution / Red Queen, institutional lag, temporal decay, maintenance). The substrate-neutral skeleton — relational fitness falls monotonically as the environment drifts while the system is held constant, resettable only by adaptation — that continuing change instantiates for software. A frozen statute, an unrevised policy, and a coevolving organism decay by the same recognized mechanism, arguably named better by these parents. Tell: strip away code, releases, and the E-type designation and what remains is bare fit-decay-under-drift, carried by the parents (which state it without software framing), not Lehman's first law. (Treated fully in an earlier section.)

Neighborhood in Abstraction Space¶

Lehman's law of continuing change sits in a crowded region of the domain-specific corpus (7^th percentile for distinctiveness): several abstractions share nearly its structure, so a description that fits it tends to fit its neighbors too.

Family — Software Evolution & Entropy (7 abstractions)

Nearest neighbors

Lehman's law of increasing complexity — 0.91
Lehman's law of declining quality — 0.90
Lehman's law of continuing growth — 0.89
Lehman's law of conservation of organizational stability — 0.88
Lehman's law of conservation of familiarity — 0.87

Computed from structural-signature embeddings · 2026-07-12