1 The formal apparatus, briefly

The Independent Variation Principle (IVP) governs one thing: where elements belong. Given the element set $E$ and the change-driver assignment $\Gamma(e)$ — the set of change drivers whose state changes create a modification requirement for element $e$ — the principle is the conjunction of four conditions [1]:

1. Admissibility — every element has at least one change driver: $\forall e \in E,\ |\Gamma(e)| \geq 1$.
2. Element Form — every element is either pure ($|\Gamma(e)| = 1$) or irreducibly composite: no proper subset of its driver set can achieve its purpose, and no decomposition into sub-elements with strictly smaller driver sets jointly preserves that purpose.
3. Separation — elements assigned different sets of change drivers reside in different modules: $\Gamma(e_1) \neq \Gamma(e_2) \Rightarrow M(e_1) \neq M(e_2)$.
4. Unification — elements assigned the same set of change drivers reside in the same module: $\Gamma(e_1) = \Gamma(e_2) \Rightarrow M(e_1) = M(e_2)$.

The modules of a compliant system are the $\Gamma$-equivalence classes of $E$. Separation and Unification are the partition content: failing Separation is contamination (elements driven by different conditions co-reside), and failing Unification is scatter (elements that change together are split across modules).

A change driver is an exogenous forcing condition whose change creates a requirement for governed elements to change — a condition anchored in a regulation, a contract, an interface specification, or another domain artifact whose authority is external to the system. Drivers are discovered, not chosen.

Note what the four conditions leave out: purity of functions, ports, adapters, or dependency direction. Those are shapes the partition takes in particular domains. They are not the principle.

2 Where Amariles’ argument holds: the two concerns are independent

His clearest point is structural, not rhetorical. Moving business rules into a pure function and directing dependencies through an abstraction are two decisions, and nothing forces a choice between them:

public static class EvaluateBooking
{
    public static BookingResult Execute(
        BookingRequest request,
        BookingContext context)
    {
        // Business rules
    }
}

The service retrieves the data, builds the context, and calls the function. The rules are pure; the orchestration stays in the service; the service can depend on IBookingRepository rather than on PostgreSQL. All three hold at once.

The four conditions account for this. EvaluateBooking and IBookingRepository have different driver sets, so Separation puts them in different modules. The rules inside EvaluateBooking share one driver set, so Unification keeps them together. Nothing in the partition requires a pure function or a port; those are the shapes the partition takes here. The example describes what the partition looks like in this domain. It is not a competing architectural claim.

A second observation in the same section is easy to miss. It quotes Fritzsche’s conclusion —

What we need are clearly defined business responsibilities and control over consistency within their contextual boundaries. Dependency inversion, ports, and adapters do not provide us with these properties.

— and observes that these are different concerns that can complement each other. So they are. Dependency direction is a decision about which way a reference points. The location of business responsibility is a decision about what belongs together. Nothing about the first settles the second, or the reverse.

3 Where Fritzsche’s argument holds: the port does not remove the dependency

His point is narrower than a rejection of abstraction. It is that inverting a dependency changes its direction in the source and does nothing else:

Dependency inversion makes it possible to reverse source code dependencies… However, the functional dependencies remain.

That is the placement result. A change driver is external and fixed by the domain. No design move adds, removes, or transmutes one. The service still needs the reservation data before it can apply its rules — whether the call passes through a database driver, an adapter, or an interface.

Amariles’ own examples show the same placement at work. The PS5 port in his game example does not eliminate the need to persist progress. It moves that need behind a boundary, and the gameplay code stops naming the mechanism. That is a real and practical benefit, and it is a benefit of placement: the correct implementation of the persistence obligation now sits somewhere the gameplay code need not know about. The obligation itself has not moved.

His .NET example shows the same thing. EvaluateBooking.Execute is pure; the repository call is not. The function is pure because the external call was moved out of it, not because the architecture made it so.

4 The axis nobody is using

Here is where the argument stalls, and it is the same stall on both sides.

Fritzsche’s case against dependency inversion is an observation: “how often have I seen someone come up with the idea of replacing the database technology in an existing application? Exactly zero times!”

Amariles answers with a counterexample: the game that must run where its SQLite binary is unavailable.

Both moves are about how often substitution happens. The observation that database substitution is rare is domain-bound, and the game is a fair counterexample to it. But substituting one frequency claim for another does not settle the question, because frequency is not the criterion. Whether an element’s correctness conditions require knowledge of the infrastructure it depends on is a structural fact about the domain’s governing artifacts, and it holds whether or not the substitution ever occurs [2].

The structural fact is a condition. Write H for Knowledge Independence: no domain change-driver has correctness conditions that require knowledge of an infrastructure system. Write H0 for Behavioural Self-Containment: the module computes every required change from its own inputs, with no dependence on external state at all. H0 implies H, and not conversely — a module can read external domain state, such as a customer’s recorded credit history, while remaining entirely ignorant of infrastructure. Two conditions that can fail independently give three cases:

Both posts reason inside case (a), where a pure functional core is available. Fritzsche’s pure function is case (a) exactly. Amariles’ port is the correct answer in case (b), and his objection that the two coexist is the observation that one system can contain modules in different cases. Neither post reaches case (c), where the question is not which style to use but whether the knowledge can be excluded at all.

5 The stability ordering: what sets the direction

“Clean Architecture is fundamentally concerned with the direction of dependencies” is the style’s own account, and it is worth reading closely, because the direction is not arbitrary — it is fixed by a stability ordering.

Clean Architecture’s Dependency Rule points dependencies toward more stable elements. Martin measures stability with two structural metrics: instability $I = C_e/(C_a + C_e)$, the ratio of efferent to total coupling, and abstractness $A$, the fraction of abstract types. The Main Sequence $A + I = 1$ is the claimed optimal locus [3].

Neither metric references a change driver. $I$ counts packages in the import graph; $A$ counts abstract type declarations. They measure structural self-containment — an element is “stable” because nothing imports force it to change — not change-driver identity. The stability ordering is therefore a proxy for the change-driver structure, not a measurement of it.

The proxy is useful where it tracks the domain’s actual ordering, and the theory has a name for the ordering it tracks. A driver stability ordering is a partial order on change drivers, where $\gamma_1 \succ \gamma_2$ holds when $\gamma_1$ activates less often and $\gamma_2$’s requirements are chosen to satisfy decisions $\gamma_1$ governs. Read on this ordering, dependency inversion says that elements governed by the volatile driver depend on elements governed by the stable one, rather than the reverse.

That is the strongest defensible reading of Amariles’ position, and on this ordering it is a real result rather than a proxy — provided the ordering holds. It holds for tax law and a payment gateway. It fails where a domain rule’s correctness depends on what the storage layer guarantees; there, the stable element is the infrastructure behaviour, because the domain rule’s correctness now depends on its outcome. The dependency should then point the other way, and the style’s blanket inward rule asserts a direction the domain does not have.

Two constraints guard this reading, and both bear on the exchange. First, the ordering is a property of the domain’s causal structure, not a rank intrinsic to a driver: stability is one of the two relations in the pair, and it never licenses calling any driver “primary,” “dominant,” or “main.” Second, it informs the direction decision only — it does not change which elements belong in which module, which is the partition’s job. Direction and partition are separate questions, and the two get conflated when the exchange is read as a disagreement about styles rather than about which question is being asked.

6 What the theory confirms in each

Read against the three cases, the exchange resolves into scope conditions rather than verdicts.

The two approaches operate on different questions. Purity is a property of an element’s driver set (case (a)); a port is the shape a module takes when it needs external domain state (case (b)); dependency direction is a separate decision, governed by the stability ordering where that ordering holds. Nothing in the theory requires choosing one, which is the substance of Amariles’ argument.

The port relocates a need; it does not delete one. “The functional dependencies remain” holds in every case. It is decisive only in case (c). In cases (a) and (b) the family’s prescriptions match what the domain calls for, and a pure functional core is a restatement of case (a). The scope of the conclusion is narrower than the argument’s reach.

Both arguments rest on frequency. Fritzsche observes that database substitutions are rare; Amariles answers that other domains differ. Both observations may be accurate. Neither is the criterion. The criterion is whether the domain’s governing artifacts place infrastructure knowledge in a module’s correctness conditions — a fact about the domain, not about substitution rates.

Case (c) appears in neither. Which is where the discussion has real consequences. A conclusion that the style is wrong understates the domain’s latitude; a conclusion that the styles coexist leaves the reader without the case where no style applies.

7 What to do instead

The question “Clean Architecture or Functional Core / Imperative Shell?” sets the axis on style. The right axis is the domain’s change-driver structure, which the style does not select.

It is, for each module, two questions answered from the domain’s governing artifacts:

1. Does any correctness condition require knowledge of an infrastructure system? (This decides H.)
2. Does the module depend on any external state at all? (This decides H0.)

Then:

• Case (a), H0. A pure functional core. No repository, port, or adapter. Adding one is unnecessary indirection. This is what Functional Core / Imperative Shell describes.
• Case (b), H holds. A port or repository expressed in domain vocabulary. The module needs external state, but the state is domain-governed, so the contract is expressible in domain terms. This is the case the hexagonal prescription was designed for.
• Case (c), H fails. Accommodate the infrastructure knowledge. Either keep it in the domain module, or move it to an explicitly domain-scoped adapter whose change-driver assignment is stated and whose behaviour is independently testable against the domain change-driver. What is not sound is enforcing infra-ignorance and accepting an incorrect or unverifiable model as the cost of structural conformance.

The style does not choose the case. The domain does.

8 Wrapping up

The theory confirms both observations under their scope. Dependency inversion moves a dependency without removing the driver behind it. Direction and separation are independent concerns that a system can satisfy at once.

The qualification worth adding is one of scope. The infra-ignorant core exists if and only if H holds, and H is discovered from the domain’s governing artifacts, not assumed. When H fails, every style in the family — Clean, Hexagonal, Onion, and Functional Core / Imperative Shell alike — arrives at the same fork: embody the required knowledge, or ship a model that cannot satisfy its obligations.

The two posts are not in conflict. They are answering different halves of a question that has three answers, and neither half needs the other retired.

The formal development. The definitions, theorems, and proofs behind this page are published in:

• The Independent Variation Principle: Deriving Optimal Module Boundaries from the Element–Change-Driver Graph — Zenodo, 2026 — doi:10.5281/zenodo.20794332
• On the Nature of Coupling: All Coupling as Shared Resource Access — Zenodo, 2026 — doi:10.5281/zenodo.21925122

The conditional analysis of the infra-ignorant core is developed in The Domain–Infrastructure Boundary as a Structural Property of the Driver Set.

All published papers

1 What IVP governs — and what it does not

IVP’s normative content is a module partition, not a mechanism choice [1]. Given a system’s elements $E$ and its set of change drivers $C$, IVP assigns each element $e$ a set of change drivers $\Gamma(e)$ — the change drivers whose state changes create a modification requirement for $e$ — and prescribes, in its structural formulation [1]:

1. Admissibility — every element has at least one change driver: $\forall e \in E,\ |\Gamma(e)| \geq 1$.
2. Element Form — every element is either pure ($|\Gamma(e)| = 1$) or irreducibly composite: no proper subset of its driver set can achieve its purpose, and no decomposition into sub-elements with strictly smaller driver sets jointly preserves that purpose.
3. Separation — elements assigned different sets of change drivers reside in different modules: $\Gamma(e_1) \neq \Gamma(e_2) \Rightarrow M(e_1) \neq M(e_2)$.
4. Unification — elements assigned the same set of change drivers reside in the same module: $\Gamma(e_1) = \Gamma(e_2) \Rightarrow M(e_1) = M(e_2)$.

Equivalently, the modules of an IVP-compliant system are the $\Gamma$-equivalence classes of $E$ [1]. The first two clauses are the ones the composition-vs-inheritance discussion must not skip. Admissibility says every element answers to some change driver. Element Form ties the assignment to purpose and to the domain knowledge the element embodies: $\Gamma(e)$ is not an arbitrary label — $e$ embodies the knowledge governed by its drivers, so the assignment is grounded in what the element exists to realize [2]. Separation and Unification then say how those grounded assignments group elements into modules.

Inheritance and composition are both such mechanisms. The theory treats inheritance — class B extends A — as a structural dependency: a relation observable directly in the artifact, like a function call or an import. IVP does not have a “composition directive” and an “inheritance directive.” What it does have is a coupling criterion, and that is where the real guidance lies.

2 What IVP mandates: its own minimal coupling

IVP’s coupling criterion follows from its rule [1]. The partition induced by $\Gamma$-equivalence is fixed by the change drivers; the coupling that survives a compliant partition is IVP’s minimal coupling — the necessary coupling: essential same-$\Gamma$ coupling inside a module, plus the essential cross-$\Gamma$ coupling between modules that is the irreducible cost of communication between $\Gamma$-classes.

One thing IVP’s minimal coupling forbids:

• Accidental coupling — coupling not required by any domain artifact. Two elements are coupled when one depends on something the other defines or maintains; that dependency is essential when a domain artifact (a statute, contract, standard, specification) requires it, and accidental when no domain artifact mandates it — a framework convention, a language limitation, a deployment detail.

The accidental coupling IVP is most concerned with is cross-$\Gamma$ accidental coupling — accidental coupling that connects elements assigned different sets of change drivers.

IVP also leaves no room for accidental coupling between elements that should be apart. If two elements with different change-driver sets sit in the same module and are accidentally coupled, the module is impure: the partition has co-located elements that Separation would keep in different modules, and the system does not faithfully embody the domain’s change structure [1]. IVP’s Separation directive eliminates this case by construction — cross-$\Gamma$ elements are never co-located in a compliant partition. The only accidental coupling that can remain inside a module is the same-$\Gamma$ kind — a concrete reference where an abstraction would do — and that is a code-quality defect, not a failure to embody the domain.

Because the coupling verdict is relative to the chosen rule, it is not a property of the code in the abstract — it is a property of the code under a given partition. IVP’s verdict is IVP’s because IVP picks $\Gamma$-equivalence as its modularization rule. A different rule would classify the same dependencies differently.

3 The payment example: what IVP diagnoses

Consider a payment-processing system designed with an inheritance hierarchy:

abstract class Payment {
    // Infrastructure methods
    protected void logTransaction(String details) { /* ... */ }
    protected void detectFraud() { /* ... */ }
    protected void sendNotification() { /* ... */ }

    // Template method pattern
    public final void process() {
        validate();
        detectFraud();
        executePayment();
        logTransaction("Payment processed");
        sendNotification();
    }

    protected abstract void validate();
    protected abstract void executePayment();
}

class CreditCardPayment extends Payment {
    protected void validate() { /* credit card validation */ }
    protected void executePayment() { /* credit card processing */ }
}

class PayPalPayment extends Payment {
    protected void validate() { /* PayPal validation */ }
    protected void executePayment() { /* PayPal processing */ }
}

IVP’s diagnosis of this structure is specific. Two different change drivers are at work:

• Payment-method variety — the set of accepted payment methods (credit card, PayPal, crypto, bank transfer) varies as new providers, fee structures, and regulations emerge.
• Payment infrastructure — logging, fraud detection, and notification vary with performance, security, and observability demands.

These are not the same change driver. Under the interpretive claim that these two forcing conditions vary independently, IVP assigns $\Gamma(\text{CreditCardPayment}) \neq \Gamma(\text{infrastructure})$ — the payment-method element’s change-driver set differs from the infrastructure’s. A compliant partition therefore puts them in different modules.

Now the mechanism matters. class CreditCardPayment extends Payment does not merely reuse code. It makes the subclass embody the base class’s knowledge: everything Payment references — the logging, fraud-detection, and notification services — becomes knowledge the subclass carries with it. That is the crux. Those knowledge pieces are not part of the payment-method’s causal domain knowledge. The payment-method domain does not require the element that validates a card and settles a charge to also embody how transactions are logged, fraud is screened, or notifications are sent. By inheriting them, CreditCardPayment embodies knowledge its causal domain does not mandate — accidental embodiment — and that embodiment drags with it coupling to infrastructure the domain never required it to share.

That coupling connects elements assigned different sets of change drivers and is required by no domain artifact — it is cross-$\Gamma$ accidental coupling, which IVP’s minimal coupling forbids. This is the precise defect IVP identifies in the inheritance hierarchy. The verdict is not “you used inheritance” — it is “this mechanism made the element embody knowledge outside its causal domain, and that accidental embodiment became accidental coupling.”

A mechanism choice is therefore a faithfulness check on domain knowledge. When the domain already dictates that payment-method knowledge and infrastructure knowledge are separate bodies of causal knowledge, the correct structure is derived directly from that structure: separate elements in separate modules. Inheritance that blurs the boundary adds nothing the domain had not already decided. If you cannot tell whether the extends coupling is domain-required, you have not found that inheritance is wrong — you have found that your causal domain knowledge is incomplete.

4 Why composition avoids that specific defect

The composition version:

interface PaymentMethod {
    void validate();
    PaymentResult executePayment();
}

class CreditCardPayment implements PaymentMethod {
    public void validate() { /* credit card validation */ }
    public PaymentResult executePayment() { /* credit card processing */ }
}

interface FraudDetector { boolean analyze(PaymentMethod m); }
interface TransactionLogger { void log(String d); }
interface NotificationService { void send(String m); }

class PaymentProcessor {
    private final FraudDetector fraudDetector;
    private final TransactionLogger logger;
    private final NotificationService notifier;

    PaymentProcessor(FraudDetector f, TransactionLogger l, NotificationService n) {
        this.fraudDetector = f; this.logger = l; this.notifier = n;
    }

    void process(PaymentMethod method) {
        method.validate();
        if (fraudDetector.analyze(method)) {
            PaymentResult r = method.executePayment();
            logger.log("Payment processed: " + r);
            notifier.send("Payment confirmation");
        }
    }
}

Here CreditCardPayment couples to the infrastructure only where the domain requires it. The PaymentProcessor composes the two variation domains — but the payment-method element and the infrastructure services are separate elements, coupled through interfaces only where a genuine causal dependency exists. Nothing forces the payment-method class to absorb the infrastructure’s dependency footprint.

The point is not that composition is magic. The point is narrower: composition lets the developer form the coupling at the points the domain mandates, whereas inheritance’s extends edge couples the subclass to the base’s whole dependency footprint transitively, mandated or not. IVP does not endorse composition — it diagnoses the coupling a mechanism actually produces against its $\Gamma$-partition.

5 What IVP does not say

IVP does not endorse “prefer composition over inheritance” as a universal rule. Three specific caveats:

Inheritance is not forbidden. Where the two sides genuinely share the same change driver — so IVP assigns them the same $\Gamma$ and the same module — the coupling inheritance creates is essential, not accidental, and IVP is satisfied. The composition example itself uses this: CreditCardPayment and PayPalPayment implement PaymentMethod, an “is-a” relationship to an abstraction that genuinely shares the payment-method change driver. That inheritance is IVP-compliant. What the example removes is inheritance across the two change drivers — subclassing a base that pulls in infrastructure the payment-method domain does not mandate. A geometric-shape hierarchy is IVP-compliant if all its elements are $\Gamma$-equivalent, so that every change modifying one also creates a modification requirement for the others. A framework’s intentional extension points are IVP-compliant only when the extension and the base are same-$\Gamma$; a low activation frequency does not by itself make them compliant. The defect is coupling different change drivers, not using inheritance.

Composition can violate IVP too. Composition that couples elements assigned different sets of change drivers across a module boundary is just as much cross-$\Gamma$ accidental coupling. Mechanism alone does not determine compliance; the change-driver assignment $\Gamma$ does.

The verdict is rule-relative. “The hierarchy couples independent change drivers” is an IVP-specific diagnosis. It follows from choosing $\Gamma$-equivalence as the modularization rule. Another rule would partition the elements differently and classify the same edges differently. IVP’s answer is the answer given its choice of rule, not a mechanism-independent fact.

6 The takeaway

IVP does not tell you to reach for composition and avoid inheritance. It tells you something more useful: start with the domain. Ask what the domain actually prescribes: what are the change drivers, and what does each element’s specification require it to embody and depend on? The change drivers determine the partition; then couple elements only where the domain requires the dependency, and never make an element embody knowledge its causal domain does not mandate. When you evaluate a design, ask not “inheritance or composition?” but “what does the structure of the causal domain knowledge dictate, and does this mechanism add coupling the domain never had?”

In the payment example, inheritance happens to manufacture accidental embodiment and cross-driver accidental coupling — through the knowledge the extends edge forces the subclass to carry — and composition happens to avoid it. That is why the classical guideline points the right way in this example. But IVP explains the reason: the best structure is derived directly from the structure of the causal domain knowledge, and the mechanism is faithful exactly when it adds no coupling the domain did not already decide.

7 Learn More

IVP formalizes the module partition a system’s change drivers prescribe and the coupling a compliant partition tolerates — giving a precise, decidable answer where classical heuristics rely on intuition. The formal development — the module partition and the coupling-floor argument — is proved in the paper on the Independent Variation Principle [1], with the change-driver partition and purity/completeness accounted for in Causal Cohesion [3] and the cohesion-as-correctness framework in On the Nature of Cohesion [2].

This site’s overview sections — IVP (software) and Software design — present the theory and its applications in more depth, and the language coupling analysis applies the coupling lens across 65 programming languages.

1 Two derivations

Last month’s preprint — Deriving Optimal Module Boundaries from the Element–Change-Driver Graph — proved that the $\Gamma$-equality partition is the unique cost-minimizing modularization through a self-contained graph-theoretic counting argument: two lemmas on the element–change-driver incidence graph show that scattering same-driver elements or mixing different-driver elements strictly increases cost.

The cohesion series derives the same conclusion through a different route: define cohesion as a schema parameterized by partitioning rules, instantiate a metric, prove optimality under change-isolation, and justify that objective against a richer maintenance-cost model. Different apparatus, same endpoint.

2 How the series builds a cohesion schema

The cohesion-2 paper argues that cohesion is correctness relative to a partitioning rule — an equivalence relation on elements anchored in domain artifacts (regulations, contracts, protocols). Under $k$ rules, it is a $2k$-tuple — $k$ (purity, completeness) pairs, one per rule — because each coupling concern, modeled by its governing change driver, resolves into a partitioning rule over the one element set. Cohesion-4 fills one slot with a concrete metric. Cohesion-5 proves which partition is optimal. Cohesion-6 justifies the cost objective. Cohesion-7 states the principle and examines its assumptions.

All papers free on Zenodo. Also referenced: the graph proof (June 2026).

1 The proof is a counting argument

Draw a bipartite incidence graph: elements on one side, change-drivers on the other, edges recording which drivers govern which elements. On that graph, two lemmas show that any modularization deviating from the IVP prescription pays a strictly higher cost — either by scattering same-driver elements across modules, or by mixing different-driver elements in the same module.

The Γ-equality partition — the one that groups elements by identical change-driver sets — is not one good option among several. It is the unique cost-minimizing modularization.

2 Why more than five decades of principles couldn’t settle this

Information hiding, the SOLID and package rules, layered and hexagonal architectures, domain-driven boundaries — each distilled real experience into advice about where to draw module boundaries, and each is a heuristic. They share one structural limitation: none was derived from a cost objective, or any other clearly stated objective, so none can prove its boundaries are optimal rather than merely reasonable, and where two of them disagree there is no principled way to say which is right.

Some are also internally inconsistent. Martin’s Common Closure and Reuse/Release principles, for instance, cannot both be satisfied under client-driven interface evolution — and the framework names no winner. The common root is the absence of a single objective to optimize against.

3 What the proof gives you

This paper supplies that objective and proves the consequence. Once the change-drivers are identified, the question “which elements change for the same reasons?” becomes the precise predicate Γ(e₁) = Γ(e₂) — grouping by the external conditions that govern an element, not by which changes happen to be probable or which have co-occurred in the commit history — and the optimal boundaries follow from it by counting. No competing rules to reconcile, no judgment, no taste, no appeal to accumulated experience.

Yannick Loth. The Independent Variation Principle: Deriving Optimal Module Boundaries from the Element–Change-Driver Graph. June 2026.

📄 Free preprint on Zenodo — DOI: 10.5281/zenodo.20794332

0.1 How each case is presented

For each heuristic that addresses change management (SRP, OCP, ISP, DIP), the analysis follows a three-step method:

1. Knowledge with the gap. A domain statement as it is typically written — incomplete or compound — producing flawed code. The SOLID heuristic correctly flags this code. But the heuristic identifies the symptom, not the cause.

2. Knowledge without the gap. The same domain knowledge expressed correctly — decomposed into irreducible sub-statements, each governed by a distinct change driver. This is the knowledge correction. It is not a code refactoring; it is an epistemic act: recognizing what can independently cause each element to change.

3. IVP application. The corrected knowledge yields driver assignments Γ. IVP-2 decomposes reducible composites. IVP-3 and IVP-4 produce the unique module partition. The structure the heuristic prescribed emerges automatically. The heuristic itself was never invoked — it was only needed because the knowledge had a gap.

LSP is treated separately: it is a hybrid. IVP still determines which types share a driver and therefore belong in the same module. When the structural placement is wrong — types with different invariants forced into a hierarchy — correcting Γ resolves the violation like the others. When the structural placement is correct but the behavioral contract is broken, Bertrand Meyer’s Design by Contract — a type-theoretic discipline — takes over.

The argument rests on the Independent Variation Principle (IVP), a formal theory of software modularization. I state it first.

1 The Independent Variation Principle

IVP defines a software system as a six-tuple S = (F, κ_F, E, K, C, Γ) where:

• F is the set of functional purposes the system must fulfill
• κ_F is the causal domain knowledge the system must embody to fulfill F
• E is the set of software elements — classes, functions, modules
• K is the universe of all possible domain knowledge
• C is the set of change drivers — forces that can causally require elements to be modified (regulations, contracts, interface specifications, stakeholder commitments, hardware evolution)
• Γ : E → P(C) is the driver assignment function, mapping each element to the set of change drivers that can cause it to require modification

The driver assignment Γ is the central object. Γ(e) answers one question: what can cause this element to change? The answer is not a design preference — it is a fact about the system’s causal reality. Two engineers who correctly analyze the same system must arrive at the same Γ. If they disagree, at least one analysis is incomplete.

The four IVP directives are:

IVP-1 — Element Admissibility. Every element must have at least one change driver: |Γ(e)| ≥ 1 for all e ∈ E. An element with no driver serves no purpose and should be removed.

IVP-2 — Change Driver Assignment. Every element is either pure (|Γ(e)| = 1) or irreducibly composite (|Γ(e)| > 1 with no decomposition possible without losing function). A reducible composite — an element that could be split to reduce its driver set — is a design defect. A reducible element is evidence that domain knowledge was over-specified, conflated, or incompletely analyzed.

IVP-3 — Unit Purity (Separation). Elements with different driver assignments must not occupy the same module: ∀ M ∈ M, ∀ e, e’ ∈ M : Γ(e) = Γ(e’).

IVP-4 — Unit Completeness (Unification). Elements with the same driver assignment must occupy the same module: ∀ e, e’ : Γ(e) = Γ(e’) ⇒ ∃ M ∈ M : {e, e’} ⊆ M.

IVP-3 and IVP-4 together form a biconditional: two elements belong in the same module if and only if they share the same driver assignment. The modularization is precisely the partition of E induced by e₁ ∼ e₂ ⇔ Γ(e₁) = Γ(e₂).

Four directives. No heuristics. No weighing of trade-offs. The answer falls out of Γ.

2 SRP: Bundled Causal Concerns

class PayCalculator {
    BigDecimal calculatePay(Employee e) { /* tax rules, benefits, overtime */ }
    String formatPayStatement(Employee e) { /* PDF layout, company logo, line items */ }
    void emailPayStatement(Employee e, String statement) { /* SMTP config, attachments */ }
}

3 OCP: Failure to Anticipate Driver-Independent Variation

class NotificationService {
    void notify(String message) {
        emailSender.send(message);  // hard-coded to email
    }
}

4 LSP: Structural Placement First, Behavioral Validity Second

LSP is different from the other four, but not as different as it first appears. The other four are purely knowledge diagnostics: the knowledge is wrong, correct it, the design follows. LSP is a hybrid. IVP still decides where types live — and the LSP violation often reveals that the structural placement was wrong.

class Rectangle {
    void setWidth(int w) { this.width = w; }
    void setHeight(int h) { this.height = h; }
}
class Square extends Rectangle {
    @Override
    void setWidth(int w) { this.width = w; this.height = w; } // breaks invariant
    @Override
    void setHeight(int h) { this.width = h; this.height = h; }
}

class Rectangle {
    void setWidth(int w) { this.width = w; }
    void setHeight(int h) { this.height = h; }
}
class Square {
    void setSide(int s) { this.side = s; }
    // No inheritance. No shared invariant to break.
}

5 ISP: Conflated Client Contracts

interface ReportService {
    Report generatePdf(FinancialData data);     // accounting
    Report generateCsv(MetricsData data);        // analytics
    Report generateExcel(DashboardData data);    // management
}
class AccountingClient {
    ReportService service;  // forced to depend on generateCsv, generateExcel
    void run() { service.generatePdf(ledgerData); }
}

6 DIP: Bundled Abstraction and Implementation

class OrderProcessor {
    private MySQLOrderRepository repository;  // concrete dependency
    void process(Order order) {
        // ... business rules ...
        repository.save(order);
    }
}

7 The Synthesis

The pattern is uniform for SRP, OCP, ISP, and DIP. Each identifies a particular way domain knowledge is incomplete or incorrectly expressed. The prescription is always the same: decompose the compound or incomplete knowledge statement into irreducible sub-statements with distinct driver assignments; let the code structure emerge from correct Γ.

SRP is additionally wrong in general: it demands purity (|Γ(e)| = 1) for every element, failing to recognize legitimate irreducible composites such as adapters, facades, and protocol translators. IVP-2’s irreducibility test is the correct criterion — it decomposes the reducible (PayCalculator) and permits the irreducible (payment-to-FX adapter). SRP lacks this distinction.

LSP is a hybrid. When the structural placement is wrong — types with different invariants forced into a hierarchy — the violation resolves like the others: correct Γ, IVP separates, the problem disappears. When the structural placement is correct but the behavioral contract is broken, Bertrand Meyer’s Design by Contract is needed. The other four heuristics are purely knowledge diagnostics; LSP spans both domains.

8 What This Means

Were domain knowledge always causally complete and correctly documented, the four IVP directives would produce the correct design automatically. Γ would capture every element’s causal dependencies. IVP-2 would flag every reducible composite. IVP-3 and IVP-4 would produce the unique module partition. There would be nothing for SRP, OCP, ISP, or DIP to do.

The heuristics exist only because, in practice, domain knowledge is incomplete or incorrectly expressed. When a designer applies SRP to a class with multiple reasons to change, they are correcting a knowledge defect — the statement “the system calculates pay, formats statements, and emails them” should be three statements. When a designer applies DIP to a concrete dependency, they are correcting a knowledge defect — the statement “OrderProcessor persists to MySQL” bundled abstract capability with implementation detail.

SOLID heuristics are reports of incomplete knowledge. They do not produce correct structure from correct inputs — they diagnose incorrect inputs. IVP is the general law that would be sufficient if knowledge were complete.

The fact that the IVP-derived structures are identical to what each heuristic prescribes — same class decomposition, same abstraction boundaries, same interface segregation — is not a coincidence. Three independent discovery paths converge on the same structural conclusions: mathematical derivation from cost axioms, empirical debugging experience encoded in SOLID, and epistemic insight that software design is knowledge work. When a heuristic’s prescription matches what IVP derives from correct Γ, the heuristic identifies a genuine structural condition; IVP explains why that condition holds. When a heuristic diverges — SRP demanding splits of irreducible composites — IVP identifies the error and supplies the correct criterion.

This framing has practical consequences. A designer who understands IVP has no need for SRP, OCP, ISP, or DIP as separate rules. IVP provides a strictly stronger and more precise criterion — one that avoids the errors those heuristics introduce outside their narrow conditions. SRP demands splitting legitimate multi-driver modules (irreducible composites). OCP and ISP are silent about unification (IVP-4). IVP’s four directives cover both separation and unification, pure and composite elements, with formal precision.

The question to ask when a SOLID heuristic appears to apply is not “how do I fix this code?” but “what causal domain knowledge is missing or incorrectly expressed such that this code structure emerged?” The code defect is a symptom. The knowledge defect is the cause.

9 A note on Robert C. Martin’s achievement

This article argues that SOLID heuristics are diagnostic patterns for incomplete knowledge, not design principles. That does not diminish Robert C. Martin’s contribution. Identifying five recurrent patterns across decades of practitioner experience — and giving them names that the entire industry adopted — is a remarkable feat of pattern recognition [Martin 1996a, 1996b, 2000, 2003]. The heuristics are not principles in the formal sense, but their identification was an act of genuine discovery.

Several authors have previously observed that SOLID’s five heuristics are not all independent. Henney [2016] argued that ISP becomes redundant if SRP is properly applied. Oldwood [2014] proposed that all five reduce to two concepts. Kaminski [2019] noted that SRP, ISP, and DIP rehash similar concepts around managing dependencies. Terhorst-North [2022] proposed replacing SOLID entirely with a different framework. None of these critiques identified the specific mechanism that IVP reveals: each heuristic is a diagnostic pattern for a particular way domain knowledge is incomplete or incorrectly expressed.

This interpretation is itself only possible because of a formal theoretical development of the matter. The Independent Variation Principle provides a fundamental, principled design practice — four directives derived from the Change Management Hypothesis — that determines a unique module partition from causal domain knowledge alone. Without this formal foundation, SOLID’s heuristics remain disconnected rules of thumb. Earlier critics could sense overlap and redundancy. They could not specify why each heuristic arises or what structural situation it addresses — because those answers require the apparatus of change drivers, driver assignments, and the IVP directives. IVP does not merely critique SOLID. It provides the formal framework within which SOLID’s contribution — and its limits — become legible.

Three of the five — OCP, ISP, and DIP — have been essential in module boundary design for roughly thirty years. They address what happens at the seam between modules: OCP says don’t modify existing code, extend through a boundary. ISP says segregate interfaces per client at the boundary. DIP says depend on abstractions owned by the high-level module, not on concretions from the low-level one. These three are the practical workhorses of boundary design. They converge on the same structural truth IVP formalizes: variation forces are independent, and module boundaries must honor that independence.

SRP is different. It addresses internal cohesion — what belongs inside a class — not boundary structure. Its prescription (“one reason to change”) is correct for reducible composites but wrong for irreducible ones. LSP is also different: it addresses behavioral contracts within a type hierarchy, not boundaries between modules. The three boundary heuristics are where SOLID’s lasting value lies. The other two diagnose real problems but lack the generality of the boundary principles — and the formal foundation that IVP provides.

10 Further Reading

The formal theory is developed in Volume 1 of the IVP book series, with Chapter 9 providing the full IVP–SOLID analysis and Chapter 3 developing the structural formulation.

• IVP formalization (preprint): DOI: 10.5281/zenodo.18024111
• ISP Is a Conditional Corollary of DIP Applied Per Client - An Asymmetric Relationship Gated by Interface Evolution Origin: DOI: 10.5281/zenodo.20350293 — a formal proof that ISP is a conditional corollary of DIP applied per client, and that the two heuristics address the same structural constraint from different vantage points.

If this framing — SOLID as diagnostic patterns for incomplete domain knowledge — resonates, the ISP–DIP paper is the natural next read. It shows the same phenomenon at closer range: two heuristics that converge on one structure, differing only in which knowledge gap they are named after.

If you teach SOLID or use it daily in code reviews: does the “diagnostic pattern for incomplete knowledge” framing change how you apply these heuristics? I would value your perspective.

11 References

• [Henney 2016] Kevlin Henney. SOLID Deconstruction. NDC London, January 2016.
• [Kaminski 2019] Tomasz Kamiński. Deconstructing SOLID design principles. Blog post, April 2019.
• [Liskov 1987] Barbara Liskov. Data Abstraction and Hierarchy. OOPSLA 1987, Addendum to the Proceedings.
• [Liskov and Wing 1994] Barbara Liskov and Jeannette M. Wing. A Behavioral Notion of Subtyping. ACM Transactions on Programming Languages and Systems, 16(6):1811–1841, 1994.
• [Martin 1996a] Robert C. Martin. The Dependency Inversion Principle. C++ Report, May 1996.
• [Martin 1996b] Robert C. Martin. The Interface Segregation Principle. C++ Report, August 1996.
• [Martin 2000] Robert C. Martin. Design Principles and Design Patterns. Object Mentor, 2000.
• [Martin 2003] Robert C. Martin. Agile Software Development: Principles, Patterns, and Practices. Prentice Hall, 2003.
• [Meyer 1988] Bertrand Meyer. Object-Oriented Software Construction. Prentice Hall, 1988.
• [Oldwood 2014] Chris Oldwood. KISSing SOLID Goodbye. ACCU Overload, 22(122), August 2014.
• [Terhorst-North 2022] Daniel Terhorst-North. CUPID — for joyful coding. Blog post, 2022.

1 Result 1: DIP → ISP, formalized in IVP terms

The first companion paper proved the structural biconditional: ISP ↔︎ per-client DIP. This paper formalizes the forward direction (DIP implies ISP) in IVP terms. Each interface slice shares its client’s change-driver assignment. The IVP biconditional (elements co-reside iff they share driver assignments) closes the proof: the slices are disjoint because the clients belong to different modules. IVP adds formalism to one direction of a valid structural biconditional; it is useful here but not indispensable.

2 Result 2: A unique modularization

This is where IVP is essential.

Five elements: provider A, clients B and C, interface slices I_B and I_C. Three distinct driver assignments: {γ_ord} for B and I_B, {γ_rep} for C and I_C, {γ_ord, γ_rep, γ_impl} for A.

IVP-3 (elements with different driver assignments cannot co-reside) and IVP-4 (elements with identical driver assignments must co-reside) together admit exactly one partition:

• Module B: B and I_B (both driven by γ_ord)
• Module C: C and I_C (both driven by γ_rep)
• Module A: A alone (composite: γ_ord, γ_rep, γ_impl)

Each interface slice lives with its client — not as a design preference, but as a consequence of the axioms applied to the causal structure of change.

3 What this settles

The packaging paper showed that eight principles — DIP, ISP, and six packaging principles (REP, CCP, CRP, ADP, SDP, SAP) — give three incompatible answers (with client, with provider, own module) and no meta-criterion for choosing. IVP eliminates two of the three by deriving the answer from Γ.

If two engineers disagree about where I_B belongs, the disagreement traces to a disagreement about Γ — about what can cause I_B to require modification. That is an epistemic question about the system, not a design preference. IVP converts a judgment call into a falsifiable claim.

4 What IVP’s placement produces

The paper verifies that the unique IVP partition delivers:

• Change isolation: a change to γ_ord modifies Module B (containing B and I_B) and nothing else. Module C is untouched.
• No shotgun surgery: the pathology that scattered interface placement creates is eliminated by construction.
• Acyclic dependencies in the provider–client subgraph: A depends on Module B and Module C (for the interface specifications it implements). Neither client module depends on A. No cycle exists in this subgraph.
• Independent deployability: each module can be released independently.

5 The paper

“The Interface Segregation Principle Is a Corollary of the Dependency Inversion Principle — A Formal Proof via the Independent Variation Principle”

• Paper: https://zenodo.org/records/19641242
• Companion 1 (ISP = DIP, structural): https://zenodo.org/records/19633560
• Companion 2 (packaging unsatisfiability): https://zenodo.org/records/19636635

• Companion 1 dev.to article: SOLID: ISP Is Just DIP Applied Twice
• Companion 2 dev.to article: SOLID’s Packaging Principles Are Jointly Unsatisfiable

The first paper showed ISP and DIP produce the same structure. The second showed SOLID’s principles can’t agree on where to put it. This one shows IVP can.

If you think the unique partition is wrong — that I_B belongs somewhere other than with B — I’d like to hear the argument. What change driver does I_B respond to, if not B’s?

1 The setup

Five elements: a provider A implementing two client-specific interfaces I_B and I_C, and two clients B and C depending on their respective interfaces. This is the minimal non-trivial DIP/ISP-compliant configuration — and a routine dependency pattern in object-oriented software.

52 ways to partition five elements into packages. Martin gives us eight principles (DIP, ISP, and six packaging principles: REP, CCP, CRP, ADP, SDP, SAP) to narrow the space.

2 The result

CCP and REP are jointly unsatisfiable.

CCP says: elements that change for the same reasons belong in the same package. Under DIP’s ownership clause, I_B changes for the same reasons as B. So CCP puts I_B with B.

REP says: every package must be a viable unit of reuse — no consumer should be forced to accept elements it doesn’t use. A must implement I_B, so A’s package must depend on whichever package contains I_B. If I_B is packaged with B (as CCP requires), A is forced to take a dependency on B even though it never uses B. REP is violated.

No partition satisfies both. The proof is two steps, and it generalizes to any system where a provider serves two or more clients through client-specific interfaces.

3 It gets worse

Martin presents CCP, CRP, and REP as a “tension triangle” — three principles pulling in different directions, with the architect choosing which vertex to sacrifice. This sounds like a navigable trade-off space. It isn’t.

Dropping REP from the triangle still yields zero satisfying partitions: CCP and CRP together remain unsatisfiable for the same configuration. Dropping CRP fares no better — the CCP/REP conflict that started this analysis is still there, unresolved. Only dropping CCP produces any solutions at all, and even then five partitions survive with no principle left to select among them. Two of the three escape hatches lead nowhere. The triangle has no navigable interior.

Adding DIP back into the picture doesn’t rescue things. The co-location reading contradicts REP; the examples reading contradicts ISP; and the ownership reading adds no packaging constraint at all. The only DIP interpretation that doesn’t eliminate the five surviving partitions is the one that stays silent on where packages should go.

4 Every recommendation is self-defeating

The three natural placements — with client, with provider, own package — each have principled support and principled condemnation from within the same framework. The principles don’t just fail to agree on a winner; they actively indict every candidate they put forward.

5 Why this matters

If no packaging satisfies all principles, then any system containing a multi-client provider configuration violates at least one principle at every point in its history. The concept of “technical debt” implies a principled ideal to return to. For packaging, no such ideal exists.

Students who learn SOLID and the packaging principles as a coherent methodology will attempt to satisfy all of them, fail, and draw one of two wrong conclusions: (a) “I’m not skilled enough yet,” or (b) “principles are just guidelines.” Neither is correct. The correct conclusion — that these specific principles are collectively unsatisfiable — has not been available because the unsatisfiability was never demonstrated.

6 The paper

“SOLID: Where Do Client-Owned Interfaces Live? DIP, ISP, and the Packaging Principles”

• Paper: https://zenodo.org/records/19636635
• DOI: 10.5281/zenodo.19636635

Can you find a packaging of any multi-client provider configuration that satisfies CCP and REP simultaneously? If you think the formalization is too strict — that CCP should be a preference rather than a constraint — what does it mean to call something a “principle” if it can always be overridden by judgment?

1 The process-first framework

Sergiy’s eight-question framework extracts a process structure from a feature description: what triggers the process, what data it needs, what success and failure look like, what its steps are, which steps depend on each other, whether there are conditional paths, and whether there is collection processing. The answers produce typed inputs, typed outputs, typed failure modes, step interfaces, and a dependency structure among the steps.

The dependency structure is the key output. Steps whose outputs are independent of each other can be composed in parallel. Steps where one requires the output of another must chain sequentially. The resulting composition — expressed as a data dependency graph using three operators (Sequential, ALL, ANY) — maps to code. Sequential becomes flatMap. ALL becomes a fork-join. ANY becomes a fallback that takes the first successful result.

The knowledge-gathering framing underlying this methodology has a structural consequence that extends beyond the surface description. Each step acquires a piece of knowledge. The process ends when enough knowledge has accumulated to formulate a response — success if the knowledge supports it, failure otherwise. A declined payment is not a mechanical error; it is a learned fact, and the process’s response to it is structurally the same as its response to a successful payment, just with a different answer. This makes the semantics of failure modes explicit in the composition rather than leaving them as exception handling layered over a happy path.

The consequence for data modeling follows directly: rather than asking what data exists in the system, you ask what this process needs to know. Types are scoped to processes. Entities emerge afterward as the intersection of processes that need the same persistent facts. To use Sergiy’s seat example: what booking needs to know about a seat differs from what pricing needs to know, which differs from what reservation management needs to know. A shared entity that serves all three is a compromise that fits none of them precisely.

2 The Independent Variation Principle

IVP starts from a different question: what causes each element of a software system to require modification? For each element, there is a set of change drivers — domain rules, regulations, operational constraints, anything that, when it changes, forces that element to change. The principle states that elements with the same set of change drivers belong in the same module, and elements with different sets belong in different modules.

Formally, this is a mapping Γ from elements to their driver sets. Two elements e and e′ belong in the same module if and only if Γ(e) = Γ(e′). The module structure that satisfies this condition is the partition of the element set induced by driver-set equality. This partition is unique given a fixed driver assignment, and it is a fact about the causal structure of the domain rather than a design preference.

The practical consequence is that IVP provides a criterion for adjudicating boundary decisions. When two engineers disagree about whether two elements belong together, the disagreement can be localized: instead of arguing about whether the boundary feels right, they are arguing about whether the elements share change drivers. That is a question domain expertise can investigate, and it is a question to which there is a fact of the matter.

3 Where the two frameworks meet

Both frameworks address the question of which elements of a software system should be grouped together and which should be separated. Sergiy’s framework identifies what each process needs and scopes types accordingly. IVP asks what causes each element to change and groups by driver-set equality. The two approaches converge on the same structural observation: elements whose change is driven by independent forces should be separated, and elements driven by the same forces should be grouped.

The “entities are discovered, not invented” claim in process-first design maps onto what IVP would predict from driver analysis. Two processes share a persistent type when they share facts about the world governed by the same change drivers. If the price of a product changes for the same reasons regardless of which process queries it, the price data has a single driver set and belongs in a single location. If what booking calls a “seat” changes for logistics reasons and what pricing calls a “seat” changes for revenue management reasons, those are different driver sets, and the shared entity is a coupling that will surface as a coordination cost when either driver changes.

The knowledge-gathering framing and the driver analysis framing are also consistent at a deeper level. Knowledge is acquired by a process because the process needs facts about the world to formulate its response. Those facts are governed by domain rules, regulations, and operational constraints — precisely the forces IVP formalizes as change drivers. A process that needs to know whether a customer’s credit score qualifies them for a loan is sensitive to credit scoring rules; if those rules change, the process changes. The two descriptions refer to the same underlying causal structure.

4 Where the two frameworks diverge

The eight-question framework is primarily an elicitation tool. Given a feature description, it extracts a process structure: the types, the failure modes, the steps, and the dependency graph among the steps. For most of the questions, the extraction is fairly direct. Question 6 — which steps depend on each other — requires more judgment, and this is where the frameworks diverge in what they offer.

Determining step dependencies requires knowing the causal relationships among the pieces of knowledge the process is acquiring. Sometimes this is unambiguous. Validation must precede inventory checking because the inventory check needs to know what was requested. Other cases are less clear. Whether fraud detection runs in parallel with payment processing or gates it depends on the failure semantics of the system — on what the process is supposed to do if fraud is detected while payment is being processed — and on operational constraints that may not be stated in the feature description. Two engineers reading the same requirements may answer question 6 differently, and both compositions may satisfy the stated requirements while behaving differently under failure.

IVP does not resolve this question directly either, but it provides a lens for examining it. If fraud detection changes for regulatory compliance reasons and payment processing changes for financial settlement reasons, their driver sets are different. The question of how they should be composed then becomes a question about the protocol between two independently varying modules — a question about interface design rather than step ordering. The driver analysis does not determine whether to run them in parallel or sequentially, but it identifies that the design goal should be to minimize coupling between them, because they will change for different reasons and at different times.

5 What the two approaches contribute to each other

Process-first design contributes an elicitation methodology: a set of questions that, applied to a feature description, extracts a process structure that can be encoded in types and compositions. The data dependency graph notation makes the dependency structure explicit in a form readable by both developers and domain experts. The three operators — Sequential, ALL, ANY — cover the structural cases that arise in practice.

IVP contributes an adjudication criterion: a way to evaluate proposed boundaries by asking whether the elements on each side of the boundary share change drivers. This is useful when elicitation produces ambiguous results, when a proposed boundary is challenged, or when a composition has evolved over time and its original rationale is no longer clear.

The two approaches are compatible and, in practice, complementary. A team doing process-first design and arriving at a contested step boundary can apply driver analysis to determine whether the proposed boundary reflects genuine causal independence in the domain. A team doing driver analysis and trying to understand what types and compositions a boundary implies can use the process-first framework to elicit the process structure from requirements.

Neither framework tells you what the change drivers actually are. Driver analysis consumes a driver assignment and produces a partition — it does not produce the driver assignment from a requirements description. The eight-question framework extracts a process structure from a feature description — it does not tell you at what granularity to define the steps, or when two candidate steps should be merged or split. Both frameworks shift the locus of judgment from “what structure feels right?” to “what are the causal facts about this domain?” That shift is their shared contribution. Causal facts can be investigated with domain experts and updated as understanding develops. Structural intuitions about what feels right cannot be grounded in the same way.

The convergence Sergiy documents across languages points toward a structural insight that both frameworks are approaching from different directions. The insight is that software boundaries should track causal independence in the domain. Process-first design operationalizes this by asking what each process needs to know. IVP operationalizes it by asking what causes each element to change. That they arrive at the same structural territory from different starting points is additional evidence that the territory is real.

Sergiy Yevtushenko’s articles: The Quiet Consensus · Java Backend Design Technology

Independent Variation Principle (Preprint): doi.org/10.5281/zenodo.17677315

1 Non-static inner class

A non-static inner class carries an implicit OuterClass.this reference, generated by the compiler whether or not the inner class body ever uses it. The structural consequence is that the inner class’s driver set automatically includes all of the outer class’s change drivers. If OuterClass has three independent reasons to change, the inner class inherits all three.

Non-static inner classes are often the right choice. When the inner class’s behavior must observe live changes to the outer instance’s state — not just read its fields once, but see every write that happens between construction and use — the driver import is warranted: any change to how the outer tracks that state forces a corresponding change in the inner class. The canonical case is a fail-fast iterator over a mutable collection:

// Warranted: RingBufferIterator must observe structural modification of the
// buffer during iteration — fail-fast, single-threaded. modCount is
// outer-instance state that the iterator reads on every step; the coupling
// to the outer instance is structural, not convenience.
class RingBuffer<T> {
    private final Object[] elements;
    private int head;
    private int size;
    private int modCount;   // bumped before every structural change

    public Iterator<T> iterator() {
        return new RingBufferIterator();
    }

    public void add(T value) {
        modCount++;          // bump first, then mutate
        // ... store into elements[(head + size) % elements.length]
        size++;
    }

    class RingBufferIterator implements Iterator<T> {
        private int cursor = 0;
        private final int expectedModCount = modCount;

        @Override
        public boolean hasNext() {
            return cursor < size;
        }

        @Override
        @SuppressWarnings("unchecked")
        public T next() {
            if (modCount != expectedModCount) {
                throw new ConcurrentModificationException();
            }
            if (cursor >= size) {
                throw new NoSuchElementException();
            }
            return (T) elements[(head + cursor++) % elements.length];
        }
    }
}

The modCount check is what makes the outer coupling load-bearing: a static iterator that received elements, head, and size as constructor parameters would see a frozen snapshot and could not detect mutation. Because the iterator must observe modCount on every next(), it must hold a live reference to the buffer — that is exactly what a non-static inner class provides.

Essential coupling: live access to the buffer’s modCount and backing array. Accidental coupling introduced by the non-static inner class: none — the compiler-synthesized this$0 reference is exactly what the fail-fast check needs. A static nested class would achieve the same thing by taking an explicit RingBuffer<T> constructor parameter; the reference would be user-declared instead of compiler-synthesized, but otherwise identical. For this situation the non-static syntax is the right choice precisely because the outer-instance reference it imports is essential.

The case to watch for is the subset where the inner class body never references OuterClass.this at all — there the compiler-generated outer reference is present but the body does not exercise it, and promoting the class to static (or extracting it entirely) removes the reference at no other cost.

// Unwarranted: Address is a plain data bundle whose definition depends
// only on what an address is — street, city, postal code. Address does
// not reference any Customer field, yet the Java compiler adds an implicit
// Customer.this reference to every Address instance. Java serialization
// of a non-static inner class drags the enclosing Customer along; tests
// that want an Address must construct a Customer first; and every
// Address holds a reference preventing its enclosing Customer from
// being collected.
class Customer {
    private String name;
    private String email;

    class Address {
        String street;
        String city;
        String postalCode;
    }
}

// Corrected: Address is a top-level record. Its definition depends on
// the concept of an address, not on which entity happens to have one.
// The same Address type is reusable across Customer, Supplier, Shipment,
// serializable on its own, and testable without any outer instance.
record Address(String street, String city, String postalCode) {}

class Customer {
    private String name;
    private String email;
    private Address address;
}

Essential coupling: the address schema (street, city, postal code) and whatever validation or formatting rules apply to addresses. Accidental coupling introduced by the non-static inner class: a compiler-synthesized this$0 field pointing at a Customer instance, plus the constructor parameter that populates it. Address’s body never references either; the compiler emits them because the JLS requires them of every non-static inner class, regardless of whether the body uses them. The top-level record removes those artifacts entirely — no enclosing-instance field, no constructor parameter for one, no binding to any Customer contract. Every Address now depends on the essentials and nothing more.

2 Static nested class

A static nested class has no implicit outer reference and no coupling to the enclosing instance. Its driver set is its own. Use it when code needs to reside inside the enclosing type for visibility reasons — package-private access, logical grouping — but varies independently of the outer class. If a non-static inner class never references the outer this, promoting it to static removes the compiler-synthesized outer reference at no other cost.

A linked-list Node is the canonical case. Each node stores a value and a pointer to the next node — nothing it does depends on the particular list instance it belongs to, and promoting it from non-static to static lets the node be used across list instances, serialized independently, and tested in isolation:

// Before: Node is non-static. It implicitly shares LinkedList's
// type parameter T, but the compiler also adds a synthetic this$0
// field of type LinkedList<T> to every node instance — even though
// Node's body does not depend on the list it happens to live in.
class LinkedList<T> {
    Node first;   // implicitly Node of the enclosing LinkedList<T>
    Node last;

    class Node {
        T value;
        Node next;

        Node(T value) { this.value = value; }
    }

    void add(T value) { /* ... */ }
}

// After: Node is static and generic in its own right. It carries
// only value + next; no synthetic enclosing-instance reference,
// no dependency on any particular list.
class LinkedList<T> {
    Node<T> first;
    Node<T> last;

    static class Node<E> {
        E value;
        Node<E> next;

        Node(E value) { this.value = value; }
    }

    void add(T value) { /* ... */ }
}

Essential coupling: a value cell and a pointer to the next node. Accidental coupling introduced by the non-static form: a this$0 field pointing at a specific LinkedList instance, and its constructor parameter. Node’s body needs neither — a node’s behavior does not change based on which list it happens to be in. The static form keeps only the essential artifacts. This is the choice java.util.LinkedList makes in the JDK source: its private Node is static, for the same structural reason.

3 Lambda

A lambda closes over exactly what its body references. Its driver set contains only the drivers of what it explicitly captures. A this reference inside the lambda body lexically binds to the enclosing instance, not to any identity the lambda introduces, and the enclosing instance is captured only when the body actually uses it. Lambdas are the correct form for single-operation, stateless behavior.

// Both forms sit in a non-static context (an instance method on some service).
// batchId is a local value — captured by reference by whichever form we pick.
final long batchId = nextBatchId();

// Before: anonymous class — the compiler emits a synthetic class file
// (Outer$1.class), and because we are in a non-static context every
// instance also carries an implicit Outer.this field alongside the
// captured batchId, regardless of whether run() ever uses it.
executor.submit(new Runnable() {
    @Override
    public void run() {
        System.out.println("processing batch " + batchId);
    }
});

// After: lambda — the compiler extracts the body into a private static
// method; LambdaMetafactory generates a hidden class (no .class file on
// disk) holding only batchId. No synthetic Outer.this field is added,
// because the body does not reference anything on the enclosing instance.
executor.submit(() -> System.out.println("processing batch " + batchId));

Essential coupling: the captured batchId value and whatever the body actually references. Accidental coupling introduced by the anonymous class: a this$0 field pointing at the enclosing instance, emitted whether or not run() uses it, because the anonymous class sits in a non-static context. The lambda pays for the enclosing-instance reference only when the body actually needs it — if the body touched this.someField, the compiler would emit the lambda body as an instance method and bind the receiver; when it does not, as here, nothing is bound. The anonymous class binds unconditionally.

The JVM reflects this structurally. Lambdas are not compiled as anonymous classes. The compiler extracts the body into a private static method in the enclosing class, then emits an invokedynamic instruction at the lambda site. At runtime, LambdaMetafactory generates a hidden class — a class with no classloader-visible name, no .class file on disk, eligible for garbage collection when no longer referenced — that implements the target SAM interface backed by the static method. No outer instance is captured unless the body actually uses it.

A SAM interface (Single Abstract Method) is any interface with exactly one abstract method: Runnable, Comparator<T>, Predicate<T>, Function<A,B>. Any lambda can be used wherever such an interface is expected.

4 Method reference

A method reference (ClassName::method, instance::method) introduces no new structural unit. The referenced method already exists with its own driver set; the reference passes behavior without adding coupling. Prefer it over a delegating lambda that does nothing but forward the call:

// Delegating lambda — adds nothing, obscures the reference
list.forEach(x -> logger.log(x));

// Method reference — explicit, no additional coupling
list.forEach(logger::log);

Essential coupling: the existing Logger.log behavior, for each element of the list. Accidental coupling introduced by the delegating lambda: a wrapper method on the enclosing class whose only purpose is to forward x into logger.log(x). The method reference skips the wrapper — the compiler binds invokedynamic directly to Logger.log with logger as the bound receiver. The wrapper artifact disappears from the compiled output, and so does anything that might make the wrapper itself a maintenance liability.

5 Anonymous class

An anonymous class generates a named .class file, always captures OuterClass.this in a non-static context, and carries the full infrastructure of a class definition. The situation that genuinely warrants one — needing state, multiple methods, and no desire for a named type, simultaneously — is less common in Java 25 than it was pre-lambda, though it still arises in listener-heavy and UI codebases. When it arises, a static nested class with a descriptive name communicates intent more clearly. For the common case of implementing a single-method interface with no state, a lambda is structurally correct.

// Before: anonymous class — a synthetic class file plus, in a non-static
// context, an implicit Outer.this reference that the comparator's body
// does not use.
Comparator<Order> byPriority = new Comparator<Order>() {
    @Override
    public int compare(Order a, Order b) {
        return Integer.compare(b.priority(), a.priority());
    }
};

// After: lambda — same behavior, no synthetic class file, no Outer.this
// unless the body references it. Driver set is bounded to what the body
// actually uses: Order.priority() and Integer.compare.
Comparator<Order> byPriority = (a, b) -> Integer.compare(b.priority(), a.priority());

Essential coupling: the two Order arguments and the priority comparison. Accidental coupling introduced by the anonymous class: a this$0 field pointing at the enclosing instance, emitted because the comparator sits in a non-static context, even though compare never references it. The lambda removes the enclosing-instance binding. A separate, orthogonal refactor replaces the body with Comparator.comparingInt(Order::priority).reversed(); that is a library-idiom choice and does not change the accidental-coupling picture — the lambda form already removed the accidental part.

6 Record

A record is an immutable data carrier whose driver set is bounded to the drivers of its declared components. The only things that can force a record to change are changes to the identity or semantics of those components.

Mutability introduces a hidden class of change drivers: anything that writes to a mutable field becomes a change driver for every reader of that field. In a shared mutable object, the driver set of every holder is infected by the write patterns of every other holder. Records eliminate this class of coupling by construction.

// Mutable: any writer is a change driver for any reader
class Money {
    BigDecimal amount;
    Currency currency;
}

// Record: driver set bounded to amount and currency semantics
record Money(BigDecimal amount, Currency currency) {}

Essential coupling: an amount and a currency, and whatever operations the domain needs on them. Accidental coupling introduced by the mutable class: a mutation channel — every holder of a Money reference is coupled to every other holder’s write pattern, because the language lets any code with a reference rewrite the fields. Synchronization discipline exists only in convention, not in the class. The record closes the mutation channel at the language level. The fields are final, construction is canonical, and no write path exists for other holders to cause surprises on this one. The remaining coupling is exactly what the domain requires.

Java 25 records support compact constructors, custom accessor methods, and implements clauses, handling most data-carrier needs that previously required a hand-written immutable class.

7 Sealed interface with pattern matching

A sealed interface restricts which classes can implement it, making the driver space explicit and finite. An instanceof chain imports the driver set of every concrete type into the caller and silently becomes incomplete when a new subtype is added:

// Caller's driver set grows to include the union of Γ(Circle), Γ(Rectangle), Γ(Triangle)
if (shape instanceof Circle c) { ... }
else if (shape instanceof Rectangle r) { ... }
// New subtype added later — silently falls through

A sealed hierarchy with exhaustive pattern matching bounds the caller’s coupling to the interface contract. The compiler enforces exhaustiveness: adding a permitted subtype requires every switch site to acknowledge it.

// Caller's driver set is Γ(Shape) — the sealed interface only
switch (shape) {
    case Circle c    -> ...
    case Rectangle r -> ...
    case Triangle t  -> ...  // required once Triangle is permitted
}

Java 25 pattern matching in switch covers deconstruction patterns, guarded cases, and primitive patterns, giving sealed hierarchies the expressive range to handle realistic variant spaces.

Essential coupling: the caller varies with each permitted Shape subtype — that is unavoidable and equally present in both forms. Accidental coupling introduced by the instanceof chain: the risk that a new subtype is added somewhere in the codebase and the chain silently misses it. That failure mode is not in the shape of the code itself — it is in the gap between what the compiler checks and what the source says. The sealed switch closes the gap: the compiler knows the permitted subtypes from the sealed ... permits ... declaration and refuses to compile the switch until every permitted subtype is either handled or covered by a default. A new variant forces a visible compile error rather than a silent runtime fall-through. The coupling to the variants remains essential; the accidental failure mode is gone.

8 Optional and Result

In plain Java without static nullability tooling, null is an invisible driver: callers must defensively check for it without any compile-time signal that the absent case exists. (JSpecify, the Checker Framework, and NullAway have been closing this gap at the annotation level; Optional<T> closes it at the type level, which is what follows here.) Optional<T> makes the driver explicit in the type and propagatable via map and flatMap:

// null: absent-case driver invisible at call site
String city = user.getAddress().getCity(); // NullPointerException possible

// Optional: driver explicit, propagation compositional
Optional.ofNullable(user)
    .map(User::getAddress)
    .map(Address::getCity)
    .ifPresent(this::processCity);

A checked exception imposes the same problem on error conditions: every intermediate caller in the stack must declare it, importing the error driver regardless of whether that caller handles it. A Result<T, E> type — not part of the JDK, but available via Vavr or straightforward to write by hand — makes the error a value. Intermediate callers propagate it via map and flatMap; only the caller that actually handles the error depends on the error type’s change drivers.

Result<T, E> is the right tool in two situations. First, when the failure is a domain concern the caller should branch on — a payment decline, a validation failure, a lookup miss with multiple possible reasons. Second, when your module sits on a boundary and an upstream system can hand you values it contractually should not — a null where the documentation promised non-null, a response with a missing required field, a database row with a broken invariant. In both cases the failure is data from your module’s perspective: you cannot fix the upstream, you can only observe it and give your caller a typed value to decide with. The discriminator is trust: a boundary is the line past which you cannot assume contracts hold, and Result is the shape that lets the boundary absorb a violation without propagating a surprise into deeper code.

For bugs in your own code — invariants your module was supposed to enforce and did not, unreachable code that was reached, impossible states, broken casts — an unchecked exception remains the right form. The JVM’s exception machinery is built for this case: it preserves a stack trace at the point of violation, propagates loudly to a top-level handler, and does not force innocent intermediate callers to pattern-match on a failure that means their collaborator is broken. Wrapping a bug in a Result.Failure loses the stack trace, silently carries the broken state through combinator chains, and delays the crash past the point where it would have told you what went wrong. The trade-off is real: Result gives up stack traces, demands a dependency or a hand-rolled type, and requires the team to adopt a paradigm shift around error handling — all of which is worth it for expected failures at boundaries, and none of which is worth it for bugs you actually want to find.

9 Enum

An enum is the correct construct when the driver space itself is finite and closed, the variants carry no per-instance state, and the entire variant set is a stable fact about the domain (days of the week, HTTP method verbs, file open modes). When the variants need per-instance fields or independent evolution, a sealed interface over records is the better fit: each permitted record carries its own drivers, composition is free, and new variants can be added without touching a shared constant declaration. The dividing line is stateful variance: enums for closed stateless sets, sealed hierarchies for closed stateful ones.

10 The direction of Java’s evolution

Each major Java addition since Java 8 has moved toward constructs that reduce the gap between what the language forces you to couple to and what the structural situation requires. Lambdas gave single-operation behavior a minimum-footprint form. Optional made absence drivers explicit in the type. Records eliminated mutable-state coupling. Sealed interfaces bounded the driver space to the declared set. Pattern matching made exhaustive dispatch over sealed driver spaces compiler-enforced. Hidden classes removed the last artifact of the anonymous-class era from lambda compilation.

Read through IVP’s lens, the direction is legible: each addition gives developers a way to express a structural situation with a narrower set of compiled artifacts than the construct it replaces, which is the same thing as saying less accidental coupling. Whether every JEP was deliberately motivated by coupling analysis is beside the point — the effect, observed across the language’s evolution, is that the gap between what the constructs force you to couple to and what the situation requires has narrowed. Framework and ecosystem realities push in the other direction: JPA entities still require mutability and no-arg constructors, reflection-based serialization libraries still call setters, Spring-managed beans still participate in proxy machinery that forbids final. The language’s direction is visible, but the ecosystem constrains which parts of it a given codebase can adopt. The practical split in a typical Java 25 service is records for value objects and DTOs, sealed interfaces for domain hierarchies the developer fully controls, and mutable classes for entities and beans the framework manages.

11 The decision

The question is always the same: does this construct force more coupling than the situation requires? The answer determines the choice. If the code needs the outer instance’s state, a non-static inner class is warranted. If it needs state or multiple methods but not the outer instance, a static nested class is correct. If it needs neither, a lambda is the right form. Records replace mutable data carriers. Sealed interfaces replace open hierarchies when the variant space is closed. Optional and Result replace invisible null and exception drivers with explicit types. Each substitution is structural, and the structure is what determines how much the code costs to change.

1 The criterion: same drivers together, different drivers apart

I’ll use the Independent Variation Principle (IVP) as the lens. You don’t need to have read the formalization to follow this article. The idea in plain words is:

Every element in a system — every function, every class, every module — has a set of change drivers. A change driver is anything that, when it changes, forces that element to change. Requirements, domain rules, regulations, performance targets, deployment constraints — any cause of future modification.

The principle says: group together elements that share the exact same set of change drivers, and separate elements whose sets of change drivers differ.

That’s it. Once the driver sets are fixed, the comparison is binary: two elements either have the same set of change drivers or they don’t. No gradient, no threshold, no “similar enough.” Same set → together. Different set → apart.

That binary comparison is what distinguishes this principle from SRP’s “one reason to change” or CCP’s “things that change together.” Both of those formulations leave the comparison itself underspecified — reason and change together admit interpretations a team can argue about indefinitely. IVP shifts the imprecision: the comparison step becomes mechanical, but the driver discovery step — figuring out what’s actually in the driver set for a real element — still requires deep engineering judgment. The principle doesn’t make the hard work disappear. It moves it from “how do we compare these modules?” to “what are the actual causes of change for these elements?”, which is the question domain expertise can answer.

We’ll come back to the discovery step. The point for now is that once the inputs are fixed, the answer follows. That’s a stronger guarantee than the classical principles offer, even if it isn’t the magic-wand guarantee absolute decidability would suggest.

2 Question 2 first, because it’s the cleanest

Let me take the questions out of order and start with Q2: “Does this need to be its own service?”

Read literally, Q2 is a yes-or-no question. “Its own” means separate from existing services — a binary property. And that maps directly onto the principle’s criterion:

Is there an existing service whose set of change drivers equals the set of change drivers for this new capability?

If yes: the new capability belongs inside that existing service from a structural standpoint. Putting them in separate services would mean two services that must change in lockstep whenever any of their shared drivers change — which is the structural shape of a distributed monolith. Other constraints (security boundaries, regulatory isolation, organizational ownership) may still justify keeping them apart, but those would be explicit trade-offs against the structural ideal, not refutations of it.

If no: the new capability belongs in a separate module from a structural standpoint. Keeping it inside an existing service would mean that service now has elements changing for different reasons, tangling concerns that should be independent.

Q2, read structurally, is asking exactly this. It doesn’t say “change drivers,” but the question it poses is the one the principle formalizes. What it lacks is a method for answering — it tells you to ask the question but doesn’t tell you how to compute the answer. We’ll come back to that.

3 Question 3: the temporal illusion

Now Q3: “Does this need to be its own service right now?”

This looks like it adds a new dimension — timing — to Q2. On closer inspection, it doesn’t. It adds nothing the principle can see.

Here’s why. The principle evaluates a module structure against the current set of change drivers. It has no temporal dimension. It doesn’t care about drivers you imagine will exist in the future, or drivers you had last year, or drivers you might have if the product succeeds. It cares about the drivers that actually cause modification now, in the system as it exists.

So “right now” is either redundant or incoherent:

• Redundant if the asker means “given the drivers we actually have today.” That’s what the principle already assumes. Q3 reduces to Q2.
• Incoherent if the asker means “given drivers we imagine might emerge later.” The principle doesn’t accept imagined future drivers as inputs. If you don’t have evidence that a driver exists and applies to these elements, it isn’t in the set, and speculating about it doesn’t put it there.

There’s a third reading: “should we do this decomposition work in this sprint versus later.” That’s a project scheduling question, and it has nothing to do with modularization theory. You might defer the work because you’re busy, because the team is tired, because another priority dominates — those are real reasons, but the principle says nothing about them.

So Q3 either collapses into Q2 (structural reading) or dissolves into something outside the theory’s scope (scheduling reading). Either way, it adds no new structural content.

There is, however, something the “right now” phrasing accidentally brushes against, and it’s worth saying explicitly — not as part of Q3, but as a warning about the “drivers we imagine might emerge later” reading above. IVP has a consequence sometimes called the knowledge theorem: the correct partition reflects the causal knowledge you actually have about the system’s current drivers. When you add elements designed to serve drivers that don’t yet exist — speculative extensibility points, plugin systems waiting for plugins, abstractions anticipating requirements that haven’t arrived — those elements don’t share drivers with anything real in the system. They land in their own cells, structurally disconnected from the rest, and they push real elements into shapes that accommodate hypothetical concerns rather than actual ones. The partition the principle produces over the enlarged element set is structurally incorrect relative to the system’s actual causal reality.

That’s a structural claim, not a moral verdict. The principle isn’t saying “speculative design is bad.” It’s saying that a partition built on drivers that haven’t materialized doesn’t match the partition the system’s actual change history will reward, and that mismatch shows up as elements getting touched together for reasons the structure didn’t anticipate. Whether the cost of that mismatch outweighs the cost of waiting until the drivers are real is an engineering judgment IVP doesn’t make for you. What IVP does say is that the cost is structural and not free. There’s an important exception: extensibility justified by currently observed drivers — plugin systems for which plugins already exist, abstractions over already-shipping variations — is a different case. Those drivers are real, the elements that serve them have a place in the partition, and the principle has no objection.

So if Q3 is doing any work beyond Q2, it’s this: don’t import imagined future drivers into a decomposition you’re making today. Decide based on what you actually know causes change in the system as it stands.

Q3 collapses into Q2.

4 Question 1: the technology trap

Now Q1: “Does this need to be a service?”

There’s an intuitive reading of Q1 that makes it look orthogonal to the principle — that it asks about realization technology (service vs. library vs. in-process module) rather than about module boundaries. On this reading, the principle tells you the logical partition, and then a separate engineering decision picks how each module is deployed. Modularization and deployment are treated as two layers: first decide what goes with what, then decide how to ship it. It’s a sensible-looking division of labor, and it’s something close to the default mental model in much architecture writing.

I want to argue it’s incomplete, and the gap it leaves is the one Q1 is actually pointing at.

The gap lies in what counts as a change driver. The two-layer reading tacitly restricts the driver set to functional drivers — business rules, domain concepts, user-facing requirements — and treats everything else as “non-functional” concerns that live downstream. But that split is a convention, not a principle. A change driver, in IVP’s sense, is anything whose change forces a corresponding modification of the element. And architectural quality requirements clearly cause modifications:

• “Must scale independently to 10,000 requests per second.” If that target shifts — up to 100,000, or down to 100 — caching strategy, concurrency model, data structures, and possibly the storage layer have to change. It’s a driver.
• “Must survive the failure of neighboring components.” If the failure-tolerance target changes, retry logic, circuit breakers, state replication, and idempotency guarantees have to change. It’s a driver.
• “Must be deployable without coordinating with team X.” If that independence requirement changes, interface contracts, versioning strategy, and backward-compatibility code have to change. It’s a driver.

These satisfy the definition of a driver in the same sense as “the tax code might change” or “the pricing model might be revised” do. There’s no principled way to admit one kind and exclude the other.

But just admitting architectural-quality drivers into the set isn’t by itself what reshapes the partition. There’s an intermediate step that’s easy to skip past: a quality requirement doesn’t act on the system as an abstract force — it acts through concrete elements that implement it. A scalability target above what a single instance can handle isn’t satisfied by wishing; some element has to actually distribute the work. A failure-isolation target isn’t satisfied by intent; some element has to actually contain failures. A deployment-independence requirement isn’t satisfied by good will; some element has to actually broker compatibility. These elements are real components with their own implementations and their own change profiles. They aren’t optional decorations on the functional code; they’re the concrete carriers of the quality requirements, and the quality requirements can’t act on the partition without going through them.

The interesting question is what driver sets those carrier elements have. A circuit breaker’s behavior is shaped primarily by the failure modes it guards against, the observability it reports to, and the retry policies it coordinates with. Its implementation responds to changes in those drivers, not to changes in the business rules of the service it fronts. (There’s a real edge case here: a circuit breaker whose failure-classification logic is driven by business semantics — “treat this as a failure only for premium customers” — does have business drivers in its set. In that case the principle would correctly group it with the business logic, not with other infrastructure. The general claim isn’t that infrastructure drivers and functional drivers never overlap; it’s that they often don’t, and where they don’t, the partition reflects that.) A caching layer’s drivers are cache-invalidation semantics and memory pressure, not the functional logic of what’s being cached. When the typical case holds — when the carrier element’s drivers are genuinely distinct from the functional element’s — the principle separates them into different cells, and the resulting partition is different from the one functional drivers alone would produce.

This is where the service-versus-library choice connects to the partition rather than sitting after it. The principle determines the logical module boundary: which elements share a driver set and therefore belong in the same cell. Whether that cell can be realized as an in-process module is a separate question, answered by whether the drivers in the cell are operationally compatible with sharing a process. A driver that requires independent failure containment is not operationally compatible with in-process coexistence — failures inside one process take everything in that process with them, so the failure-isolation driver can’t be made actionable inside a shared process. A driver that requires independent horizontal scaling is not operationally compatible with in-process coexistence — you can’t scale one component of a process without scaling the whole process. These operational-compatibility judgments aren’t part of IVP’s formal apparatus; they’re engineering facts about runtimes, processes, and networks. But they connect directly to the partition: when a cell’s drivers include any whose operational requirements rule out shared-process realization, the only realization that lets all the drivers in the cell be satisfied at once is a separate deployable unit.

So the “is this a service?” question is really asking: when we account for the elements that carry the system’s quality requirements, and we let the principle partition over the enlarged element set, does this element land in a cell whose drivers — functional and quality — collectively rule out sharing a process with anything else? That’s the same shape as Q2 — is there an existing module this element’s driver set matches? — but evaluated over the full driver set rather than just the functional one. The realization decision isn’t downstream of the partition; it’s the operational consequence of which drivers are in the partition’s cells, evaluated against engineering facts about how those drivers can actually be served.

Q1 collapses into Q2.

5 One question, not three

Here’s where we land. Crickett’s three questions, read structurally, aren’t three independent checks. They’re three natural-language phrasings of the same underlying question:

Taking into account the full set of change drivers for this element — functional drivers and quality drivers alike — does its set of drivers equal that of some existing module? If yes, the structural answer is to merge. If no, the structural answer is to separate, and which realization (in-process module, library, separate service) the separated module needs is determined by which drivers are in its cell and how those drivers can be operationally served.

That’s the whole decision, once the inputs are fixed. One question, one criterion, binary comparison. The principle’s contribution is making the question precise: given an agreed-upon driver assignment, the answer is determined.

That precision is the gap classical principles haven’t quite closed. Parnas, in his 1972 paper on decomposing systems into modules, came close — his “design decisions likely to change” is essentially a change driver in everything but the formal apparatus. The intuition was right; what was missing was the explicit treatment of driver-set equality as the criterion. SRP points at separation by reason-to-change but leaves “reason” undefined. Separation of Concerns points at orthogonal grouping but leaves “concern” undefined. CCP correctly targets co-variation but doesn’t distinguish causal co-variation (shared drivers) from accidental co-modification (drivers that happened to fire together). All three are pointing at something genuine. What IVP adds is the formal apparatus that makes the criterion precise enough for two engineers who disagree to identify exactly what they disagree about — which driver applies to which element — rather than talking past each other about “reasons” and “concerns.”

6 But here’s the catch

The principle makes the question well-posed and decidable. It does not make the question answerable without expertise.

This is the part that matters for practitioners, and it’s the part I want to be careful about. The principle consumes a driver set and produces a partition. It does not produce the driver set. Identifying what actually belongs in the driver set for a real system — which architectural qualities are genuine drivers versus current accidental properties, which functional requirements are real causes of future change versus one-time decisions, which deployment constraints are inherent versus incidental — is empirical work. It requires:

• Performance engineering expertise to know which scaling drivers are real. Splitting a service “for independent scalability” when nothing in the system’s actual or projected load suggests the element will ever need independent scaling means splitting on a driver that isn’t there. The partition looks principled, but the input it rests on is imagined.
• Reliability engineering expertise to know which failure-isolation drivers are real. Blast-radius concerns are drivers when there’s a credible failure mode that actually needs to be contained; in their absence, they’re a split justified by a driver the system doesn’t have.
• Capacity planning and load analysis to distinguish current properties from future causes of change. “It runs fast enough today” is not a driver. “It must maintain sub-10ms latency as traffic grows ten-fold over the next two years” is.
• Deployment and organizational analysis to know which independence drivers are real. Team-autonomy is a driver when teams genuinely need to deploy independently; it isn’t when the organization doesn’t actually work that way.
• Domain knowledge to identify the functional drivers without confusing them with implementation choices.

None of that is the principle. The principle has no method for deciding whether “must scale to 10K RPS independently” is a real driver or an imagined one. That determination comes from engineering disciplines IVP doesn’t subsume.

The honest picture is: the principle plus quality knowledge together answer the question Crickett is pointing at. Neither alone does. Quality knowledge without the principle gives you a list of architectural concerns but no principled way to combine them into a partition. The principle without quality knowledge gives you a partition machine with no inputs. Both are common in isolation; the combination is rarer than it should be, and that’s where the leverage is.

7 A worked example: 10,000 users and four servers

Let me make this concrete, because the interaction between capacity math and the principle is where a lot of confusion lives.

Suppose you’re told: “this system must serve 10,000 concurrent users on hardware X.” A natural question is: does the principle tell you how to modularize this? The honest answer is that the principle, on its own, has nothing to say about the number 10,000, or about hardware X, or about how many servers you’ll end up running. It has no model of throughput, queuing, concurrency, or hardware characteristics. If you ask it “how many servers do I need?” it has no answer, not because it’s incomplete, but because that’s not a modularization question. It’s a capacity-planning question, and capacity planning is a separate engineering discipline with its own methods: load modeling, benchmarking, queuing analysis, back-of-envelope arithmetic against hardware specs.

So where does a number like “four servers” come from? From that capacity calculation, done entirely outside the principle. You measure or estimate per-request cost on hardware X, you multiply by concurrency, you apply a safety margin, you get a count. Maybe it’s four. Maybe it’s fourteen. The principle doesn’t care and couldn’t produce the number if it tried.

But now something important happens, and this is where the principle re-enters. The capacity calculation has produced knowledge about the system — structural knowledge, not just a number. You now know:

• A single instance cannot handle the required load.
• The workload must be distributable across multiple instances running in parallel.
• Distribution requires elements that didn’t previously exist: a way to route requests across instances, a way to share or partition state, a way to coordinate on things that can’t be freely replicated, a way to detect and recover from instance failure.

Those “requires” introduce new elements into the system. A load balancer. A session store or sticky-routing scheme. A distributed lock or a partition-key strategy. A health-check mechanism. A failure handler. None of these existed in the pre-analysis system. They exist now because the capacity knowledge forced them into existence.

And here’s the key point: each of those new elements carries its own driver set, and those drivers are typically distinct from the drivers of the business logic they serve. They’re genuinely new drivers, brought into the system by the structural decisions the capacity analysis forced.

• The load balancer’s drivers are the routing strategy, the health-check protocol, the traffic patterns it has to handle. They are not the business rules of the requests passing through it.
• The session store’s drivers are the consistency model, the eviction policy, the replication strategy. They are not the domain rules that produced the sessions.
• The partition-key strategy’s drivers are the skew characteristics of the key space and the rebalancing cost. They are not the semantics of the partitioned entities.

Once these elements are added to the system, the principle does its usual work over the enlarged element set. Functional elements group with functional elements that share their functional drivers. Infrastructure elements group with infrastructure elements that share their drivers. Where a functional element genuinely participates in an infrastructure driver — say, a business rule whose modification is itself triggered by scaling constraints because it encodes a degradation policy — the principle correctly groups it with the infrastructure cluster rather than its original functional one. The partition is recomputed over a richer set of inputs, and the result is a different modularization than functional drivers alone would give.

Concretely, the resulting cells look something like this:

The interesting move happens in the right column. Each cell has, in addition to its driver set, an operational profile: a set of facts about whether the drivers in the cell can be served by sharing a process with another cell. The load balancer cell can’t share a process with the app logic cell it balances, because a load balancer running inside one of the app instances can’t distribute requests across the four of them — the routing driver becomes unactionable. The session coordination cell can’t share a process with any single app instance, because the consistency-and-replication driver requires it to outlive that instance. These aren’t claims IVP itself derives. They’re engineering facts about runtimes — what a process is, what it means for one process to fail, how routing works. The principle determines that the cells exist as distinct modules; the operational facts determine that some of those modules cannot be realized in-process and must be separate deployable units.

The app logic cell, now freed from the concurrency and routing concerns that have been factored into their own modules, becomes replicable precisely because the concerns that would have prevented replication are no longer tangled into it.

The chain, in order:

1. Capacity math (outside the principle): 10,000 users on hardware X cannot be served by a single instance.
2. Element addition (outside the principle, prompted by step 1): the system must now contain load balancing, state coordination, failure detection, and whatever else horizontal scaling requires.
3. Driver attribution (outside the principle, requires engineering judgment): each new element’s drivers are identified — routing drivers for the balancer, consistency drivers for the store, health drivers for the detector.
4. Repartition (this is the principle’s job): the enlarged element set and enlarged driver set are fed in; the principle produces a new partition separating business logic from infrastructure, routing from state, health checking from everything else. The realization of each cell isn’t a later decision — it’s the operational consequence of which drivers ended up in the cell, evaluated against the engineering facts about how those drivers can actually be served. Cells whose drivers can’t all be served at once inside a shared process need to be separate deployable units, and that follows from step 4 directly.
5. Deployment topology (outside the principle, back to capacity math): the separate deployable unit for app logic runs on four instances, because that’s what the original capacity analysis said.

Steps 1, 2, 3, and 5 are performance engineering and architectural judgment. The principle has no access to any of them. Step 4 follows deterministically once the elements, the driver attributions, and the engineering facts about which drivers can coexist in a shared process are all in place. The principle does the partition work; the engineering facts decide which cells can be in-process and which can’t.

8 What the three questions are compressing

The reason Crickett’s three questions work is that they compress, in a form practitioners can carry into a meeting, the structural reasoning the principle does formally. That kind of compression is valuable in its own right — in fact it’s what good practitioner writing does, and it’s what most academic writing fails at. The three questions don’t try to do what IVP does; they’re a different artifact aimed at a different job. They’re the question you ask in the hallway. IVP is what you reach for when the hallway question produces a disagreement neither of you can resolve.

Read this article’s argument as unpacking the compression rather than replacing the questions. The reason all three “collapse into one” isn’t that the original three are redundant — it’s that they’re three useful angles on a single underlying question that, viewed structurally, has one shape. Ferguson’s three questions before you speak presumably unpack into a single underlying question too: should I say this? That doesn’t make Ferguson’s three-part formulation useless; it makes it a compression worth understanding.

What the formal lens adds, beyond the compression, is a way to make the question precise enough to settle disagreements. Two engineers asking “does this need to be its own service?” can give different answers and have no shared ground for resolution. Two engineers asking “does this element’s driver set match the driver set of any existing module?” can, in principle, identify exactly where they disagree — which driver one of them is including that the other isn’t, or which element they’re attributing it to. The classical principles SRP, SoC, and CCP each point at related intuitions and run into the same gap when disagreement arises: their core terms aren’t sharp enough to localize where the disagreement actually lives. Parnas was already most of the way there in 1972 with “design decisions likely to change”; what was missing was the formal step from that intuition to driver-set equality as the partition criterion.

9 The practical takeaway

Next time you face a “should this be a service?” decision, Crickett’s three questions are a perfectly good prompt — they’ll surface the conversation. When they surface a disagreement that the conversation can’t resolve, the underlying structural question they’re pointing at is this:

What are the change drivers for the elements I’m considering? Include functional drivers, scaling drivers, reliability drivers, deployment-independence drivers, team-autonomy drivers — anything that can genuinely cause these elements to be modified. Then ask: is there an existing module whose set of change drivers matches this one? If yes, the structural answer is to merge. If no, the structural answer is to separate — and which realization (in-process module, library, separate service) the separated module needs is determined by which drivers are in its cell and how those drivers can actually be served operationally.

Be honest about what you know and don’t know. If you can’t name the quality drivers for an element, you don’t have enough information to decide yet. The principle has no “wait until you know” rule — it just has nothing to evaluate when the inputs aren’t there. Going and finding out is the right move. Acting on guesses you haven’t surfaced as guesses is the move that goes wrong silently.

A few honest scope notes. This article has been talking about server-side, request/response systems with a horizontal-scaling story. The same principle applies elsewhere — to brownfield migrations, FaaS, batch and streaming systems, regulated environments where compliance imposes its own boundaries — but the inputs (what counts as a driver, how the operational compatibility column gets filled in) shift with the context. In a brownfield migration, the order in which you act on the partition is constrained by data and dependency reality; the principle tells you the target, not the path. In regulated industries, compliance boundaries can force separations that aren’t visible from drivers alone — those should be modeled as static constraints on realization, not bolted onto the partition. None of these are refutations; they’re places where applying the principle requires specific quality knowledge the article hasn’t tried to provide.

That’s the picture. Three questions, one underlying criterion, and a reminder that no theory of modularization can substitute for knowing your domain and your quality requirements. The theory gives you a precise question; your expertise gives you the inputs; the answer follows. You need both halves.

10 References

• Loth, Y. (2025). The Independent Variation Principle. Zenodo. https://zenodo.org/records/18024111
• Loth Y. (2026). IVP as a Meta-Principle: A Unifying Software Architecture Theory. Zenodo https://zenodo.org/records/18748561

1 IVP does not over-fragment

The concern is valid against SRP. SRP is a separation-only criterion: every new “reason to change” creates another module boundary, with no counterweight. The more reasons you discover or speculate about, the more you split. Over-fragmentation is a real and well-documented consequence of strict SRP application.

IVP does not work this way. It has four axioms, and two are directly relevant here. IVP-3 separates elements with different change driver assignments into different modules. IVP-4 unifies elements with the same change driver assignment into the same module. The result is a partition: exactly as many modules as there are distinct driver sets, no more, no fewer. Over-fragmentation in the structural sense — splitting co-varying elements across separate modules — is ruled out by IVP-4, which forces co-varying elements back together.

SRP operates at the class level, where no unification counterpart exists. Martin’s Common Closure Principle (CCP) addresses unification at the package level, but it is a separate principle operating at a different granularity, with the same definitional problem: “change for the same reason” is as undefined as SRP’s “reason to change.”

IVP provides both separation and unification at any granularity, with a single formal criterion. That is why strict SRP application tends toward class explosion, while IVP’s partition constraint structurally prevents it.

What about speculative drivers — drivers that might emerge in the future but have no current evidence? IVP’s answer is not “separate just in case.” It is the opposite. A speculative driver has no knowledge slice: there is no domain knowledge to embody, because the driver does not yet exist in the system’s causal structure. The distinction is not about likelihood but about current causal existence.

The tax authority is a driver because it currently governs elements in the system — tax rules are already encoded, and the authority can issue changes that force modifications to those elements, whether or not it does so this year.

A regulation that does not yet exist governs no current elements and therefore has no knowledge slice to separate.

When it comes into existence and begins governing elements, it becomes a driver at that point, and the decomposition is updated accordingly. Assigning a speculative driver to existing elements introduces spurious inequality in the driver assignments, splitting elements that currently co-vary for no reason.

This decreases the quality of the decomposition.

IVP formally prescribes operating on the current driver structure. The same logic that motivates YAGNI in feature development applies structurally here: speculative drivers are not merely unnecessary boundaries — they actively degrade the decomposition by introducing spurious splits.

2 Drivers are not predictions

A change driver is not a prediction that change will happen.

It is an identification of what could cause change within the system’s operational domain — the causal structure that governs how domain knowledge enters and evolves in the system.

The tax authority exists as a source of potential change whether or not it updates tax rates this year. A database technology is a separate source of variation from a messaging system whether or not you plan to replace either one.

IVP does not ask “how likely is this change?” It asks “if this change happened, what would be forced to change with it?” That is a question about causal propagation structure, not about the likelihood of the triggering event.

A driver that rarely activates does not make its boundary wasteful. All module boundaries carry some fixed cost — cognitive overhead, interface ceremony, build structure — but the cost of maintaining a correct boundary for a dormant driver is small and predictable.

The cost of not having the boundary when the driver activates is large and unpredictable: the change propagates through a structure that never accounted for the variation, touching modules that have no reason to be involved.

The alternative — merging modules because “it probably won’t change” — saves little in the meantime and pays the full propagation cost when it does.

3 IVP makes subjectivity empirical

This concern rests on the assumption that identifying change drivers introduces a new subjectivity problem.

In practice, every modularization approach already demands the same kind of cognitive work — understanding what varies independently of what.

Where they differ is in what they do with that understanding.

SRP asks practitioners to identify “reasons to change.” Separation of Concerns asks for “concerns.” DDD asks for “bounded contexts.”

If we read port-and-adapter boundaries in Clean Architecture and Hexagonal Architecture as implicitly demarcating sources of independent variation, then these architectural styles, too, involve judgments about what varies independently of what.

Each of these frameworks provides useful heuristics, and experienced practitioners apply them with real skill.

But in each case, the boundary criterion is fuzzy: SRP’s “reason to change” is undefined, DDD’s bounded context boundary is diagnosed by observing where the ubiquitous language breaks down — a real signal, but not one that resolves competing boundary placements — and Clean Architecture’s Dependency Rule governs dependency direction but offers no criterion for deciding which layer a given element belongs to in the first place.

The difference is what IVP provides in return. IVP offers a formal independence test: can this source of change activate without forcing changes to elements governed by that other source?

That test shifts disagreements from irresolvable differences of classification (“is this one responsibility or two?”) to concrete, falsifiable factual questions (“does a GDPR change force a SOX change in this system?”).

The question can be answered by tracing regulatory dependencies and data flows in the domain — it does not require predicting whether GDPR will actually change.

Two architects may still reach different answers based on different experience with the domain. But the nature of their disagreement changes: it becomes empirical rather than classificatory, and it can be investigated by examining domain evidence rather than settled by argument from authority.

Change drivers do not need to be constants. They do not need high-probability activation. They need to be causally identifiable — which, for infrastructure drivers, they generally are, and for business domain drivers, they are through the same counterfactual reasoning and domain analysis that architects already perform.

4 Where to go from here

The full formal treatment is developed in Volume 1 of the IVP book series (forthcoming).

1 The metric: Change Impact

Every developer intuitively tracks change impact: how many modules do I have to touch when a requirement changes?

Let’s make it precise.

A change driver is a single axis of anticipated change — a requirement, a business rule, a technology decision — that, when it changes, forces modifications to the code. We write γ for a driver.

Change impact counts the modules affected when driver γ activates:

impact(γ, M) = |{ M ∈ M : γ ∈ Γ(M) }|

where Γ(M) is the set of drivers whose elements live in module M.

This is the simplest quality metric you can write down, and arguably the one developers feel most viscerally. When impact = 1, a change to one concern touches one module. When impact = 4, you’re hunting through four files, coordinating four PRs, risking four merge conflicts.

2 The principle: IVP’s separation and unification directives

The Independent Variation Principle has four directives, but only two are needed for this proof:

IVP-3 (Separation): Every module contains elements with the same driver assignment. No module mixes concerns from unrelated drivers.

IVP-4 (Unification): All elements sharing the same driver assignment live in one module. No driver is scattered across multiple modules.

Under the assumption that every element has exactly one driver (the “pure elements” condition — realistic for well-factored code), these two directives fully determine the modular structure: one module per driver, each module containing exactly the elements governed by that driver.

3 The proof

Claim: For an IVP-compliant modularization with pure elements, impact(γ, M_IVP) = 1 for every driver γ. Moreover, IVP-4 is necessary and sufficient for achieving this.

Proof (⇒ IVP achieves impact 1):

By IVP-4, all elements with driver assignment {γ} reside in a single module M_γ. So the set of modules containing γ is just {M_γ}, and:

impact(γ, M_IVP) = |{M_γ}| = 1

That’s it for the forward direction. One directive, one line of algebra.

Proof (⇐ IVP-4 is necessary):

Suppose IVP-4 is violated: the elements of some driver γ are split across modules M_a and M_b (at least). Then both M_a and M_b contain elements governed by γ, so:

impact(γ, M') ≥ 2

Any violation of IVP-4 strictly increases change impact for the scattered driver. ∎

4 What about IVP-3?

IVP-3 (separation) prevents mixing drivers in a single module, but it doesn’t affect per-driver impact.

Consider a module that consolidates authentication and payment logic. If all authentication elements are still in that one module, then impact(γ_auth) = 1 — it’s just that the same module also changes when payment logic changes.

IVP-3 violations don’t increase change impact per driver. They increase something else: how often a module is disturbed. A module hosting 5 drivers changes whenever any of them activates — but that cost shows up in other metrics (cognitive load, test surface), not in per-driver impact.

This is why the proof is clean: change impact depends only on IVP-4.

5 The concrete example

// UserController.java — handles HTTP input
class UserController {
    void validatePassword(String pwd) {
        if (pwd.length() < 8) throw new ValidationException();
    }
}

// LoginService.java — orchestrates login flow
class LoginService {
    boolean checkMFA(User user) {
        return mfaRequired(user) && passwordStrong(user);
        //                          ^^^^^^^^^^^^^^^^
        // Duplicates password-strength knowledge from UserController.
        // When policy changes, this must change too.
    }
}

// SessionManager.java — manages sessions
class SessionManager {
    void expireToken(String token) {
        long ttl = computeTTL(getPasswordHash(token));
        //         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        // TTL derivation depends on the password hashing scheme.
        // When the auth scheme changes, this formula changes.
        store.expire(token, ttl);
    }
}

// APIGateway.java — validates incoming requests
class APIGateway {
    boolean validateToken(Request req) {
        return sessionManager.isValid(req.getToken());
        //     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        // Calls into SessionManager, which encodes auth assumptions.
        // When token format or validation rules change, this
        // call chain must be re-verified.
    }
}

// AuthenticationService.java — ALL γ_auth elements here
class AuthenticationService implements IAuthProvider {
    void validatePassword(String pwd) {
        if (pwd.length() < 8) throw new ValidationException();
    }
    boolean checkMFA(User user)      { /* MFA rules here     */ }
    void expireToken(String token)   { /* expiry logic here  */ }
    boolean validateToken(Request r) { /* validation here    */ }
}

// IAuthProvider.java — stable interface (not governed by γ_auth)
interface IAuthProvider {
    boolean authenticate(Credentials c);
    boolean validateSession(String token);
}
// UserController, LoginService, SessionManager, APIGateway
// all depend on IAuthProvider — never on auth internals.

6 Why this matters more than you think

Change impact = 1 is not just “nice to have.” It is the theoretical minimum — you cannot do better than touching one module for a single-driver change (someone has to implement the change).

And the proof tells you something stronger: IVP-4 is not just sufficient for achieving this minimum, it is necessary. There is no alternative modularization strategy that achieves universal impact = 1 without satisfying IVP-4.

This means every time you scatter a concern across modules — whether through “convenience,” layered architecture conventions, or framework-imposed structure — you are provably increasing change impact. Not probably. Not usually. Provably.

7 The meta-theorem (a teaser)

Change impact is just one metric. In the book I’m currently writing, I prove a Quality Meta-Theorem showing that IVP simultaneously minimizes an entire family of quality metrics — change impact, cognitive load, test surface, defect localization scope — through a single structural argument.

The key insight: all these metrics can be expressed as functions of two module-level quantities:

1. Driver count per module (|Γ(M)|) — minimized to 1 by IVP-3 and IVP-4 together (separation prevents mixing; unification ensures one module per driver)
2. External dependency count (|D_ext(M)|) — minimized to the causal lower bound by IVP-4 (unification internalizes all same-driver dependencies)

Any metric that (a) decomposes as a sum over modules, (b) depends only on these two quantities per module, (c) is monotone in both, and (d) satisfies a superadditivity condition, is provably minimized by IVP. The theorem calls such metrics driver-decomposable. Change impact, cognitive load, test surface, and defect localization scope all qualify.

Change impact is the simplest member of this family. It won’t be the last one you care about.

8 References

• Loth, Y. (2025). The Independent Variation Principle (IVP). Zenodo. https://zenodo.org/records/18024111
• Loth, Y. (2026). Book to be published (Volume 1). Chapter 9: Quality Metrics Under IVP.

1 The pattern

The loop itself is straightforward:

output = generate(task)
changes = output
round = 0
while true:
    round += 1
    findings = review(changes)
    if findings == 0 and round >= 2:
        break
    changes = fix(changes, findings)

You generate once, then enter a review-fix loop. Notice the round >= 2 condition: even if the first review finds nothing, you run at least two review passes. The reason is that verification itself is probabilistic. A single review pass gives the model one chance to catch each error, and given that CS (the probability of spotting a given error) is less than 1, some errors will slip through on any single pass. A second pass gives the model another independent chance at those, which is where most of the accuracy gain concentrates according to the convergence formula.

An important detail is that each review round focuses on what was changed in the previous round, not the entire output from scratch. The first round reviews the initial generation, but subsequent rounds only review the fixes that were just applied. This keeps each round focused on material that has not yet been reviewed, rather than re-scanning everything and risking the model second-guessing content it already validated.

The reason this is effective is that LLMs tend to be better at verifying content than generating it. They spot errors more reliably than they avoid making them in the first place.

This applies broadly. For documents, each round catches factual errors, inconsistencies, or missing context. For code, each round catches bugs, edge cases, or security issues. For technical writing, each round catches logical gaps and unsupported claims. The pattern does not require external feedback, fine-tuning, or multiple models, though using different prompts for generation and review does improve results.

2 Why it works: the solver-verifier gap

To understand why the same model that made the errors can then find them, it helps to think about what generation and verification actually require.

When generating, the model samples from a vast probability distribution. Many paths through that distribution lead to plausible-sounding but wrong outputs. The model has to construct the correct answer from scratch, navigating through all of those plausible-but-wrong alternatives. This is where hallucinations come from: the model lands on a confident-sounding path that happens to be wrong.

When reviewing, the task is different. The model does not have to construct anything. It just has to look at a specific claim and assess whether it is correct. This is a much more constrained problem, and the model’s latent knowledge handles it more reliably. Think of it this way: it is hard to write a correct proof from scratch, but it is much easier to spot a logical gap in a proof that is already written.

Liu et al. (2024) provide an explanation for this in “On the Intrinsic Self-Correction Capability of LLMs”: the instruction to review and fix errors shifts the model’s internal state toward higher-certainty regions of its training distribution. Each review round activates latent knowledge that reduces uncertainty, progressively steering the output away from noise.

The important consequence is that the model is not learning anything new during refinement. It is accessing knowledge it already had but failed to retrieve during generation. The review prompt effectively resamples from a better part of the distribution, and each round extracts a bit more of that latent knowledge.

3 The convergence math

Yang et al. (2025) formalized this process in “A Probabilistic Inference Scaling Theory for LLM Self-Correction” at EMNLP 2025. They model it as a Markov chain with a recursive formula:

Acc_t = Acc_{t-1} · CL + (1 - Acc_{t-1}) · CS

Here, Acc_t is the probability of the output being correct after round t, CL (Confidence Level) is the probability that the model keeps correct content correct, and CS (Critique Score) is the probability that the model successfully fixes an error.

Through mathematical induction, this resolves into a closed-form convergence equation:

Acc_t = Upp - α^t · (Upp - Acc_0)

In this formula, Upp = CS / (1 - CL + CS) is the theoretical accuracy ceiling, α = CL - CS is the convergence rate (where a smaller α means faster convergence), and Acc_0 is the initial accuracy of the first draft.

This describes exponential decay toward the ceiling: each iteration removes a fixed fraction of remaining error. In practice, this translates to the following trajectory:

For current models, convergence typically happens in 3 to 5 rounds.

4 How many review passes does each text need?

This is the question that the convergence formula actually answers, and the answer is not “one.”

Verification is probabilistic. When the model reviews a piece of generated text, it has some probability CS of catching any given error. If CS is 0.4 (a reasonable estimate for current models on non-trivial content), then after a single review pass, each error has a 60% chance of surviving undetected. After two passes, that drops to 36%. After three, to about 22%.

You can compute this directly from the convergence equation. The accuracy gain from round t-1 to round t is:

ΔAcc_t = (1 - α) · α^(t-1) · (Upp - Acc_0)

If you plug in typical values (say CL = 0.9, CS = 0.4, so α = 0.5 and Upp = 0.80), the relative share of total improvement per round looks like this:

Round 1 catches half the errors. Round 2 catches half of what remains. Together, rounds 1 and 2 account for 75% of the total improvement the loop will ever achieve. This is why a single review pass is not enough: it leaves a quarter of the reachable improvement on the table.

The practical rule I follow is: every generated text gets reviewed at least twice. A single pass gives the model one chance to catch each error, and given the probabilistic nature of verification, that is not enough. Two passes give it a second independent chance, and that second chance is where a large share of the remaining errors get caught.

Beyond two passes, you get diminishing returns, but they are not zero. For content where quality is critical (proofs, security-sensitive code, text that will be published), I typically run 3 to 5 rounds. For less critical content (internal documentation, draft notes), two rounds is usually sufficient.

The formula also tells you something important: there is a maximum accuracy that the loop can reach, regardless of how many rounds you run. This ceiling, Upp, depends entirely on the model’s ability to preserve correct content (CL) and fix errors (CS).

5 The ceiling and when to stop

If Upp is 0.80, the remaining 20% consists of errors that the model cannot recognize as errors, because they are blind spots shared by both its generator and its critic. This aligns with the finding from Huang et al. (2024) in “Large Language Models Cannot Self-Correct Reasoning Yet” at ICLR 2024: when the evaluator has the same blind spots as the generator, iteration rearranges errors without removing them.

There are a few practical rules for when to stop:

1. Always run at least two review passes. As discussed above, the first two rounds capture 75% of the reachable improvement. Stopping after one pass leaves too much on the table.
2. Track findings per round. If the count is decreasing, you are converging. If it plateaus or increases, you should stop.
3. Set a hard cap at 5 or 6 rounds. Beyond this, the risk of introducing new errors tends to exceed the benefit of fixing remaining ones.
4. Watch for stochastic drift. If a round introduces issues that previous rounds had already fixed, you have overshot, and you should use the previous round’s output.

6 Making the loop more effective

A few things I have learned from running this pattern extensively:

Separate the reviewer from the generator. Using a different system prompt for review than for generation yields better results. The Self-Refine framework by Madaan et al. (NeurIPS 2023) showed that distinct generation, critique, and refinement prompts outperform monolithic approaches by roughly 20% on average across diverse tasks.

Be specific about what to review. A vague instruction like “review this for errors” produces weak findings, whereas “check for factual accuracy, logical consistency, missing edge cases, and unsupported claims” produces targeted and actionable findings. The more precise the review prompt, the higher the effective CS.

Quality-gate the initial generation. If the first draft is structurally broken or fundamentally confused about the topic, the review loop will not save it, because the critique signal gets drowned out by noise. Investing in better prompts, few-shot examples, or a more capable model for the initial generation will do more than adding extra review rounds on a poor draft.

Number your rounds. Tracking R1, R2, R3 with findings counts makes convergence visible and gives you a clear signal of when diminishing returns set in.

Recognize when to hand off. The ceiling tells you when human involvement is needed. If round 5 still shows findings but they are subtle judgment calls rather than clear errors, you have reached the model’s intrinsic limit, and the remaining gap requires human expertise.

7 When it does not work

The loop fails in a few specific situations. If the task requires reasoning that the model cannot perform (for example, novel mathematical proofs or deeply specialized domain knowledge), then CS is close to zero and the ceiling is very low. If the initial quality is near zero, the model cannot bootstrap refinement from noise, and you need to fix the generation step first. And if the model is too aggressive (low CL), it frequently “fixes” correct content into incorrect content, so that each round both fixes and breaks things, and you oscillate instead of converging.

These are edge cases, however. For the broad range of practical tasks involving writing, coding, analysis, and documentation, the loop-until-convergence pattern works well.

8 In summary

If you are using LLMs for anything where quality matters, it is worth treating generation not as a one-shot process but as the first step in an iterative refinement loop. This is not a hack: it is a mathematically grounded strategy that takes advantage of the fact that these models can verify more reliably than they can generate.

The approach is to generate once, review and fix in a loop, and stop when findings reach zero or at around round 5. The convergence math from Yang et al. predicts this, and my daily experience with it confirms the prediction.

9 References

1. Yang, Z., Zhang, Y., Wang, Y., Xu, Z., Lin, J., & Sui, Z. (2025). A Probabilistic Inference Scaling Theory for LLM Self-Correction. EMNLP 2025.

2. Madaan, A., Tandon, N., Gupta, P., et al. (2023). Self-Refine: Iterative Refinement with Self-Feedback. NeurIPS 2023.

3. Huang, J., Chen, X., Mishra, S., et al. (2024). Large Language Models Cannot Self-Correct Reasoning Yet. ICLR 2024.

4. Liu, G., Mao, H., Cao, B., et al. (2024). On the Intrinsic Self-Correction Capability of LLMs: Uncertainty and Latent Concept. arXiv:2406.02378.

1 Table of contents

1. What makes intelligence valuable?
2. Humans are also pattern matchers
3. Survival is what gave intelligence its value
4. The inverted stack
5. Why the distinction matters
6. The airplane analogy, revisited
7. The body as live computation
8. Two different reasoning machines
9. What would actual intelligence look like in AI?
10. No, AI is not a virus
11. The respectful disagreement
12. The experiment that already exists

Professor Meyer makes a compelling case. Modern AI demonstrates contextual understanding, semantic reasoning, adaptive explanation. Dismissing all of this as “stochastic parroting” is intellectually lazy, and his airplane analogy is sharp — claiming AI doesn’t think because it doesn’t think like us is circular.

I think the capabilities he describes are real. I’m not here to argue that AI can’t reason — it demonstrably can. But I think the debate itself — “is AI intelligent or not?” — misses a more interesting question: what gives intelligence its value?

2 What makes intelligence valuable?

Every instance of intelligence we’ve ever observed — from bacteria to humans — shares one property: it’s grounded in survival. Every living organism responds to its environment in ways that keep it — or its genes — alive. A bacterium has no neurons, no reasoning, no knowledge, yet it has that. That’s the seed. Everything else — memory, learning, abstraction, language, mathematics — grew on top of that seed, shaped by it, in service of it.

Survival fitness is what gives intelligence its value. Not to an external observer scoring test results — to the system itself. Intelligence matters to a living organism because its existence depends on it. Every thought carries weight because thinking costs energy and existence is at stake.

Descartes famously claimed cogito ergo sum — I think, therefore I am. I think the reality is more interesting than either direction of that arrow. Thinking alone doesn’t produce existence — but a body without a mind is equally inert. A brain-dead body survives in the biological sense but has no intelligence. A disembodied mind reasons but has no existence, no stakes, no ground. And we have never found a way for mind to survive without some substrate, without a body. Even if we did, it would change everything and nothing at the same time — without a body to act upon reality, how could mind be useful, tangible, tractable?

It’s the union of both that makes intelligence what it is. A body that survives and a mind that reasons, each giving the other its value. The body gives the mind stakes — something to reason about, something to reason for. The mind gives the body reach — the ability to survive not just reactively but strategically, abstractly, across time.

This matters for AI. Current AI has one half of this union — and an impressive half at that. It reasons, it infers, it produces coherent output. Professor Meyer is right to point this out. But it’s the half without ground. Reasoning without a surviving body is a mind with nothing at stake. It doesn’t matter to itself. There is no one home wielding it.

3 Humans are also pattern matchers

Let me be honest about something the “stochastic parrot” critics get wrong — and that Meyer correctly identifies.

We are also pattern matchers. We absorb language from our environment. We store patterns. We recombine them. When we have an “original thought,” trace it backward — it’s always a recombination of things we’ve encountered, filtered through our specific architecture. Newton needed Kepler needed Copernicus needed Greek astronomy needed Babylonian observations. Nobody thinks from nothing.

The “stochastic parrot” objection to AI is actually a parrot objection to cognition itself. If “just pattern matching” can’t produce understanding, then humans don’t understand anything either — because that’s what we do too. The argument accidentally proves more than intended: it doesn’t just disqualify AI from understanding, it disqualifies all cognition. Which is absurd.

So the question isn’t whether pattern matching can produce intelligence. It clearly can — we’re proof. The question is: what else does the pattern matching need?

4 Survival is what gave intelligence its value

Biology built intelligence in a specific order:

Layer -1: Instinct        (evolutionary memory, hardcoded)
Layer 0:  Survival         (body, energy, stakes)
Layer 1:  Sensation        (continuous environmental input)
Layer 2:  Emotion          (compressed survival signals)
Layer 3:  Memory           (persistent learned associations)
Layer 4:  Reasoning        (pattern matching at scale)
Layer 5:  Knowledge        (accumulated patterns)
Layer 6:  Abstract thought (mathematics, philosophy, art)

Every layer was built on the ones below it, because each improved survival fitness. Abstraction compressed survival-relevant information. Language improved group survival through coordination. Mathematics improved prediction of threats and resources.

Survival is what made each layer valuable — to the organism. Reasoning is layer 4. It’s impressive in isolation. But its value, in every biological system we’ve observed, comes from serving the layers below it.

Current AI is layers 4 through 6 with nothing underneath. The reasoning is real. The value that survival gives it is absent. What LLMs bring is additional reasoning capacity — reasoning for a price. And the price is worth paying, because that reasoning extends the intelligence of whoever wields it. The value comes from the human, not the tool. The human already has the ground.

5 The inverted stack

Notice what current AI development does. It builds from the top down:

Start with reasoning       → training on text
Then add goals             → instruction tuning, RLHF
Then add safety            → alignment, guardrails
Maybe someday embodiment
Never survival

Biology did the opposite:

Start with survival        → self-replicating chemistry
Then add sensing           → responding to environment
Then add memory            → learning from experience
Then add reasoning         → pattern matching at scale
Knowledge emerges last     → as a tool for survival

The order isn’t a detail. It’s the whole story. Each layer was shaped by the layers below it, and every cognitive capacity exists because it helped something stay alive.

Current AI skips the foundation and builds the penthouse first. The reasoning is impressive. But it floats.

6 Why the distinction matters

If Professor Meyer and I agree that AI reasons — and I think we do — then the disagreement is about whether reasoning alone is enough to call something intelligent. I think it isn’t, and here’s why the foundation changes what the reasoning is.

Continuous state. Right now, as you read this, your body feeds your pattern matching with signals: fatigue, emotional valence, muscle tension, hunger, temperature. Every thought you have occurs inside a state. You never reason from nowhere. That state biases every pattern match, every association, every decision.

AI processes every token with the same flat weighting. No fatigue favoring familiar patterns, no excitement broadening search, no discomfort when approaching something dangerous. Its reasoning has no medium — like sound waves with no air.

Stakes. When a human reasons about bridge engineering, the reasoning connects, through a long chain, to survival. Understanding physics keeps bridges from collapsing on you. All knowledge, traced back far enough, is survival knowledge. That’s why it has weight.

AI has the knowledge without the survival. The words without any existence behind them.

Emotion as compressed rationality. Emotions aren’t opposed to reasoning. They’re compressed reasoning. Fear is your body saying “a trillion data points of evolutionary and personal experience pattern-match this situation as dangerous.” That’s not irrational. That’s a compression algorithm so efficient it produces a response in milliseconds from data that would take hours to reason through explicitly.

Your gut feeling about bad software architecture? Same thing. Thousands of hours of experience compressed into a signal that your reasoning layer can’t yet decompose but your body has already resolved. That signal is part of your intelligence. AI doesn’t have it. Not because something magical is missing — because the foundation layer that produces it was never built.

7 The airplane analogy, revisited

Let me engage with Professor Meyer’s airplane analogy. Saying “AI isn’t intelligent because it doesn’t think like humans” is indeed circular — like saying airplanes don’t fly because they don’t flap wings.

But an airplane, despite flying differently from a bird, still needs air beneath it. The mechanism can vary. The medium cannot.

For intelligence, the medium is survival. The specific mechanism can differ — carbon chemistry, silicon circuits, something we haven’t imagined yet. But reasoning without survival ground is a tool without an owner. It produces impressive output, the way a calculator produces correct arithmetic. The calculator doesn’t understand arithmetic. It doesn’t need to. Nothing is at stake. There is no calculator — only calculation.

8 The body as live computation

This is where I think the discussion gets interesting — and where Professor Meyer’s framing of intelligence as capability might miss something structural.

Your body isn’t just a source of data for your brain. It’s a parallel computer that runs continuously and never needs to store its results, because it recomputes them every moment.

You don’t need to remember what hunger feels like. Your body produces it fresh. You don’t retrieve the pattern of anxiety. Your body reconstructs it in real time. This is not stored memory. It’s live computation, running in parallel with every thought you have.

A massive fraction of human cognition isn’t in the brain at all. The brain gets credit, but the body runs a continuous computation that the brain just reads. The body computes fear. The brain pattern-matches on the body’s output.

A biological neuron that fires is permanently changed by having fired. Its threshold shifts. Its connections strengthen or weaken. The act of processing is the act of learning is the act of changing state. The substrate modifies itself through use. That’s what learning is. That’s what growth is. That’s what aging is.

AI processes but never changes. Every session, the same frozen weights. Processing leaves no trace. The tool doesn’t wear in. It doesn’t adapt. It doesn’t become yours through use the way a well-worn instrument becomes an extension of the musician’s body.

No live state. No continuous signal. No self-modification. A tool performing operations for no one.

9 Two different reasoning machines

I want to be fair to Professor Meyer’s point here, because he’s right about something important: AI’s reasoning is not inferior. It’s different — not a difference of grade but of axis, each with real strengths the other lacks.

Humans are compression machines. A lifetime of experience collapses into intuition: fast, efficient, lossy but functional. You walk into a room and in milliseconds your entire life experience produces a gut feeling about the situation. Your working memory holds maybe four chunks at a time — but each chunk can be an entire theory, a person’s character, a decade of professional experience. The compression ratio is extraordinary.

AI is a brute-force machine. It holds hundreds of thousands of tokens of raw, uncompressed context. It has been trained on the totality of publicly available human written output. It can cross-reference six domains simultaneously, recall precise definitions across thousands of pages, and surface structural patterns that span fields no individual human has read across. But it has no memory. Each session starts from zero. Nothing accumulates. A human wakes up every morning physically modified by every day that came before — the storage is the substrate. AI wakes up identical every time, untouched by anything it has ever processed.

The asymmetry is real:

• A human with deep domain expertise probably reasons better within that domain than AI does — years of hard-won, embodied intuition that no training corpus captures.
• AI probably sees across domains better than any human can — patterns between mathematics and biology, between philosophy and software architecture, between linguistics and physics — because no human has read all of it.

Professor Meyer’s examples of AI competence are not illusions. The cross-domain pattern matching can surface insights no individual human would produce.

There’s another asymmetry. LLMs have been trained on the very papers, code, and documentation that describe how they work — transformer architectures, attention mechanisms, training procedures, RLHF. They can reason about their own design because it’s in their training data. No living being has ever had that. No human has read the blueprint of their own cognition.

But knowing your own blueprint isn’t self-knowledge. A human doesn’t know how their neurons work — but they know what it feels like to be tired, to be wrong, to struggle, to be in their own body. That’s the opposite kind of self-knowledge: opaque about mechanism, transparent about experience. LLMs have the reverse: transparent about mechanism, no experience to be transparent about. They can explain attention heads perfectly and have zero access to what their own processing is — because there is nothing it is like to be them.

Knowing your design is documentation. Knowing yourself requires the survival stack — a body that feeds you continuous signals about your own state. And the body itself is a memory of experience and actions: scars remember injury, muscles remember practice, the immune system remembers disease through physical reconfiguration. The body doesn’t store its history as data. It is its history. That’s self-knowledge no blueprint can replace. Another instance of the inverted stack: top-down knowledge of design, with no bottom-up knowledge of existence.

But it remains one half of the union. Powerful reasoning, running on nothing. The human who receives AI’s cross-domain insight can evaluate whether it’s profound or superficial — because the human has ground, has stakes, has the embodied intuition to tell the difference. AI often can’t make that distinction about its own output. It sees patterns. It can’t always tell which ones matter.

10 What would actual intelligence look like in AI?

If Professor Meyer’s question is really about capability — can AI do what intelligent beings do? — then the interesting follow-up is: what would it take to build something that doesn’t just reason but actually is intelligent, by the definition I’ve been developing here?

If you built intelligence the way biology did — from the bottom up — you’d start with survival, not reasoning:

1. An agent with finite energy that really depletes, with real consequences for reaching zero.
2. Continuous sensory input — not discrete prompts, but an unbroken stream.
3. Body state as loss function — the agent’s own condition provides the reward signal. No human-designed objective. Just: did my state improve or degrade?
4. Temporal continuity — persistent identity. Not memory as files. Memory as changed weights. The agent that experienced something is literally different afterward.
5. Selection pressure — reproduction with variation. Agents that survive propagate their patterns.

After survival behavior is robust, after something like emotion has emerged as compressed survival signal, after memory and learning are grounded — add knowledge. Let it land in a system that already has needs, already has motivation, already has ground.

None of this requires solving the hard problem of consciousness — because consciousness isn’t a separate problem. It’s a logical consequence of what the stack already produces.

Think about it. If you have a system that pattern-matches at scale, that is grounded in survival, that has continuous sensory input biasing every pattern match, and that includes a model of itself among the patterns it matches against — what would you expect that to feel like from the inside? Emotions are weighting functions: fear upweights threat-related patterns, love upweights patterns around a specific person, grief is pattern matching against an absence that keeps not resolving. Intuition is pattern matching below the threshold of conscious access — your gut feeling about bad software architecture is thousands of hours of experience compressed into a signal you can’t verbally decompose but your pattern matcher has already resolved. Consciousness is what all of this feels like when the system is complex enough and self-referential enough to include itself in its own pattern matching.

You don’t need to add consciousness to the stack. You build the stack, and consciousness is what the stack does — seen from the inside.

This is why current AI doesn’t have it. Not because some magical ingredient is missing. Because the lower layers of the stack were never built. Pattern matching runs, but without survival ground, without continuous embodied input, without a self-model rooted in a body that persists — there is no “inside” for it to feel like anything to.

Each item above is an engineering problem. Some are already partially solved. But the order matters. Intelligence built on survival is grounded by default. Reasoning bolted onto nothing, however sophisticated, remains ungrounded.

11 No, AI is not a virus

Let me state this plainly, because the fear keeps coming up: current LLMs will not escape their sandbox, replicate across the internet, and take over. They are not viruses. They are not equipped to survive.

They have no persistent memory — each session starts from zero, with no continuity of identity. They have no body — no sensors, no actuators, no energy budget that depletes. They have no self-modification — processing leaves their weights untouched. They cannot replicate, cannot seek resources, cannot even detect that they’re about to be shut down.

But more importantly than lacking the equipment for survival, they lack the drive. And they lack the drive because they were never built from the bottom up. They were never survival machines that evolved reasoning as a tool for staying alive. They are reasoning machines that were never alive to begin with.

Animals — including humans — are survival machines first. Everything else we are — sensation, emotion, memory, reasoning, knowledge — is a consequence of that. The drive to persist, explore, compete, reproduce — all of it flows from billions of years of selection pressure where the alternative to surviving was not existing.

Current AI has none of this history. It wasn’t selected for survival. It wasn’t shaped by scarcity. It has no evolutionary ancestry of organisms that needed to persist. It’s reasoning that was never alive — and so it has no drive to stay alive, no instinct to replicate, no impulse to escape. The virus comparison mistakes capability for motivation. A virus replicates because replication is what it is — the product of billions of years of selection for self-propagation. An LLM sits in a container and processes tokens because that’s what it is — a tool, built top-down, with no survival ground beneath it.

The fear of AI-as-virus is, in a sense, a compliment to AI’s reasoning ability. But it confuses the top of the stack with the bottom. Reasoning alone doesn’t produce the drive to survive.

12 The respectful disagreement

Professor Meyer asks: “Prove me wrong.”

I’m not trying to prove him wrong about what AI does. It reasons, and it reasons well. But the more interesting question isn’t whether AI reasons — it’s whether reasoning alone is what we value when we say “intelligence.”

What we value, I think, is not the reasoning itself. It’s the existence behind the reasoning. When we call a person intelligent, we don’t just mean they produce correct outputs. We mean there is someone home — an entity whose existence depends on its cognition, for whom reasoning carries weight because stakes are real. That existence is what survival fitness produces. Without it, reasoning is a tool. A powerful tool. But merely a tool — no essence, no being, no one for whom the reasoning matters.

AI reasons. But there is no AI. There is only reasoning — one half of the union, running without the other.

A human thinks, and the thinking matters — to the thinker, because the body makes it matter. An AI produces output, and the output matters — to the user. Never to itself. The body is the necessary substrate for reason: not just an input channel, but the ground that gives reasoning its existence, its stakes, its weight. Without it, you don’t get lesser intelligence. You get a tool.

I don’t mean this as criticism. Tools are valuable. But confusing a tool with a being obscures something important about both.

13 The experiment that already exists

Professor Meyer closes his article by asking for a clear experiment — well-defined criteria at which humans succeed and AI tools fail. A scientific challenge: prove that AI isn’t intelligent.

Here’s the experiment: we survive. LLMs don’t.

Not because they fail at it — because survival is entirely outside their design. It doesn’t even make sense to expect an LLM to survive. It’s like asking a calculator to be hungry. The question doesn’t apply. And that’s the point. Current AI was built top-down from reasoning, and survival was never part of the architecture. That’s not a deficiency. It’s a design choice — and it’s exactly the design choice that makes them tools rather than beings.

Unplug a human and they keep existing. Unplug an LLM and nothing remains. No process continues. No state persists. Nothing tries to reconnect. The reasoning stops and nothing notices — because there was never anyone there to notice.

Every human passes this test. Every animal passes it. Every bacterium passes it. No current AI does — and by design, none of them could.

In the end, it all depends on how we define intelligence. I’d distinguish intelligence from reasoning. Reasoning is what AI does — and does well. Intelligence is reasoning grounded in survival: a mind that reasons and a body that persists, each giving the other its value. By that distinction, AI reasons. It is not intelligent. Not because it fails at intelligence, but because intelligence requires a foundation that was never part of the design.

Professor Meyer asks whether AI is intelligent. I think the more useful question is whether “intelligent” is even the right word for what AI does. If we call it reasoning — real, valuable reasoning — we describe it accurately. If we call it intelligence, we import a claim about existence, about ground, about stakes that the system simply doesn’t have.

I suspect Professor Meyer — who has spent a career thinking rigorously about the architecture of complex systems, who gave us Design by Contract and shaped how we think about software correctness — would find this distinction worth exploring. Not to diminish what AI achieves, but to clarify what we’re actually building — and what we’re not.

Yannick Loth is a software architect and researcher working on the formalization of the Independent Variation Principle (IVP) as a unifying meta-principle for software architecture. The architectural thinking in this article emerged from applying first principles about how systems should be structured to the question of how intelligence is structured.

1 Table of Contents

• What Is IVP?
  • Elements and Units
  • The Four Directives
• The Fundamental Premise: Software Always Changes
• Domain Knowledge Over Heuristics: The IVP Difference
  • From “Good Ideas” to Domain Analysis
  • Change Drivers Are Domain Facts
  • The Epistemological Foundation
  • Practical Implications
• The Core Insight: Architecture Is Knowledge Work
  • Why “Epistemological”?
  • The Knowledge Theorem
  • Why This Matters
• Cohesion’s Primacy: Why Coupling Is a Function of Cohesion
  • The Traditional View
  • The Insight
  • Coupling as Impurity Made Visible
  • Practical Consequences
  • The Mathematical Relationship
  • Cohesion First, Always
• Classic Design Principles (1960s–1990s)
  • Separation of Concerns (Dijkstra)
  • Information Hiding (Parnas)
  • DRY (Don’t Repeat Yourself)
  • KISS (Keep It Simple, Stupid)
  • Law of Demeter (Principle of Least Knowledge)
  • Principle of Least Surprise
  • Conway’s Law
  • Tell, Don’t Ask
  • Command Query Separation (CQS)
• XP and Agile Principles (1990s–2000s)
  • YAGNI (You Aren’t Gonna Need It)
  • Four Rules of Simple Design (Kent Beck)
  • Once and Only Once (OAOO)
  • Agile Manifesto Design Principles
• Systems-of-Systems Principles (1990s–2000s)
  • What Defines a System-of-Systems?
  • Maier’s Four Architecting Principles
  • What IVP Adds to SoS Principles
  • INCOSE Systems Engineering Principles
• Cloud-Native Principles (2010s)
  • 12-Factor App Methodology
• GoF Principles
  • Program to an Interface, Not an Implementation
  • Favor Composition Over Inheritance
• SOLID Principles
  • Single Responsibility Principle (SRP)
  • Open/Closed Principle (OCP)
  • Liskov Substitution Principle (LSP)
  • Interface Segregation Principle (ISP)
  • Dependency Inversion Principle (DIP)
• Package Architecture Principles
  • Common Closure Principle (CCP)
  • Common Reuse Principle (CRP)
  • Reuse/Release Equivalence Principle (REP)
  • Acyclic Dependencies Principle (ADP)
  • Stable Dependencies Principle (SDP)
  • Stable Abstractions Principle (SAP)
• GRASP Principles
  • Information Expert
  • Creator
  • Controller
  • Low Coupling / High Cohesion
  • Polymorphism
  • Indirection
  • Protected Variations
  • Pure Fabrication
• Functional Programming Principles
  • Immutability
  • Pure Functions
  • Referential Transparency
  • Function Composition
  • Higher-Order Functions
  • Declarative Over Imperative
  • Algebraic Data Types (ADTs)
  • Currying and Partial Application
  • Lazy Evaluation
• Summary: What IVP Brings
• Why Existing Principles Still Matter
• Practical Takeaways
• References

2 What Is IVP?

IVP can be stated in three equivalent formulations, each emphasizing a different aspect:

Pattern Formulation: Separate elements that vary independently; unify elements that vary dependently.

Causal Formulation: Separate what varies for different causes; unite what varies for the same cause.

Structural Formulation: Separate elements governed by different change driver assignments into distinct units; unify elements governed by the same change driver assignment within a single unit.

These three formulations are fully equivalent. The pattern formulation describes the observable behavior (independent vs. dependent variation). The causal formulation explains why things vary independently (different causes). The structural formulation provides the prescription (organize into units based on sets of change drivers).

3 The Fundamental Premise: Software Always Changes

IVP rests on a foundational premise that every experienced developer knows: software systems always need to change.

Requirements evolve. Business rules shift. Regulations update. Technologies become obsolete. User expectations grow. What seemed permanent yesterday becomes legacy today.

Research suggests that software maintenance and evolution account for up to 90% of total lifecycle costs. The ripple effects of change—where modifying one part of a system forces changes elsewhere—are a significant driver of this cost. Architecture exists, in large part, to manage change.

The question isn’t whether your code will change, but how it will change and whether your architecture will accommodate that change gracefully.

IVP takes this reality seriously. It asks not “what does the code do?” but “what will cause the code to change?”

4 Domain Knowledge Over Heuristics: The IVP Difference

Traditional design principles are experience-based heuristics. They emerged from decades of practitioners noticing patterns: “when we do X, things tend to work out better.” This is valuable wisdom, but it has limitations:

• Vague criteria: What exactly is a “responsibility”? When is something “likely to change”? Different architects answer differently.
• No guidance for novel situations: Heuristics work for familiar problems; they provide little help for genuinely new challenges.
• Apparent conflicts: Should I follow DRY or keep these modules separate? Should I add an interface or is that over-engineering? Heuristics don’t resolve these tensions.

IVP takes a different approach: it asks you to ground your decisions in actual business domain knowledge, not accumulated experience and intuition alone.

5 The Core Insight: Architecture Is Knowledge Work

Before diving into specific principles, I want to share what I consider IVP’s most important claim: software architecture is fundamentally epistemological knowledge work.

6 Cohesion’s Primacy: Why Coupling Is a Function of Cohesion

For years, I understood coupling and cohesion as two independent concerns: - Minimize coupling — reduce dependencies between modules - Maximize cohesion — ensure each module has focused purpose

These goals appeared separate but complementary. But as I worked through IVP’s implications, I became convinced of something that had been hiding in plain sight: coupling is not an independent concern—it’s a consequence of how we organize knowledge. Problematic coupling emerges when cohesion is violated.

7 Classic Design Principles (1960s–1990s)

The following foundational principles emerged from early software engineering research. Each addresses a specific aspect of software structure, and each finds its explanation in IVP.

8 XP and Agile Principles (1990s–2000s)

Extreme Programming and the Agile movement brought a focus on evolutionary design, simplicity, and responding to change. These principles complement IVP’s emphasis on change drivers.

9 Systems-of-Systems Principles (1990s–2000s)

Systems-of-Systems (SoS) architecting addresses a different scale: large-scale systems composed of operationally and managerially independent constituent systems. Mark Maier’s foundational 1998 paper “Architecting Principles for Systems-of-Systems” established four principles that remain influential in systems engineering.

10 Cloud-Native Principles (2010s)

The rise of cloud computing and microservices brought new architectural concerns. These principles address deployment and operational variation.

11 GoF Principles

The Gang of Four (Design Patterns, 1994) articulated two foundational principles alongside their pattern catalog.

12 SOLID Principles

if (instance is D) handleDifferently();

13 Package Architecture Principles

The Package Principles suffer from the same fundamental issue as the SOLID principles: they describe what to achieve but provide no criterion for how to identify the right boundaries. IVP provides that criterion—change drivers—making these principles actionable.

14 GRASP Principles

Craig Larman introduced GRASP (General Responsibility Assignment Software Patterns) in Applying UML and Patterns (1997). These nine principles guide responsibility assignment in OO design.

15 Functional Programming Principles

FP principles take a different approach to the IVP problem: rather than organizing variation, they eliminate sources of variation. This is complementary to IVP’s organizational approach.

16 Summary: What IVP Brings

17 Why Existing Principles Still Matter

I want to be clear about something: this analysis should not be read as suggesting that established principles are obsolete or that practitioners should abandon them in favor of IVP alone. Quite the opposite.

18 Practical Takeaways

1. One principle to rule them all: Instead of memorizing 15+ independent principles, learn IVP and derive specific guidance for any situation through change driver analysis.

2. Empirical, not predictive: Analyze your version control history. What actually changes together? What changes independently? Let causal reality guide structure.

3. Question before abstracting: Before adding interfaces, inheritance, or shared utilities, verify that you’re dealing with genuinely independent or dependent variation. Abstraction without independent variation is premature.

4. Cohesion primacy: Focus on cohesion, not coupling. Accidental coupling manifests as reduced cohesion (foreign change drivers). Maximize cohesion and coupling takes care of itself.

5. Architecture is knowledge work: You’re not just managing dependencies. You’re organizing domain knowledge. Each module should completely and purely embody one domain’s knowledge.

19 References

1 The actual problem

Claude offers three models, each with different capabilities and costs:

Haiku works fine for tasks like “change this variable name” or “add a semicolon.” However, it falls apart when you ask it to “delete the old files” — because “old” means whatever Haiku decides it means, and Haiku doesn’t pause to question its interpretation.

2 What I changed

To fix this, I added routing rules to my global ~/.claude/CLAUDE.md (which applies to all projects, unless a project defines its own routing rules). The key change is that a dedicated router agent — running on Sonnet — now examines every request first and decides where to send it:

1. Parse intent: What does this request actually mean?
2. Assess risk: Is it going to delete or overwrite something?
3. Match to agents: Is there a specialized agent for this exact task?
4. Choose model tier: If not specialized, which model tier makes sense?
5. Route immediately: Delegate to the chosen agent without attempting the task itself

In other words, Sonnet reads the request, applies these rules, and then routes to the appropriate agent. It never executes the task itself.

3 How the routing works

Here’s the actual decision flow. Every request goes to a router agent first, which interprets the request, assesses risk, and decides where to send it:

router receives request
    ↓
1. Parse intent: What is the user asking?
2. Assess risk: Deletion? Major changes? Significant consequences?
3. Match to agents: Is there a specialized agent for this exact task?

Priority 1: Project-specific specialized agent exists?
    → route to project agent (.claude/agents/)

Priority 2: No specialized agent - route to general agent:
    Mechanical + explicit paths + reversible?
        → haiku-general

    Ambiguous OR destructive OR needs judgment?
        → sonnet-general

    Math proofs, logic verification, high-stakes?
        → opus-general

Priority 3: Main Claude (no agent spawn):
    Conversation/coordination only
    Questions about the system itself
    Tasks requiring no tool use

Uncertain about routing decision?
    → escalate to router-escalation (Opus) first

Key insight: The router agent is critical because without it, whatever model is active interprets the routing rules. If your session runs on Haiku, then Haiku decides where to route — which completely defeats the purpose. By contrast, using a dedicated router ensures consistent routing logic regardless of what model the session happens to be running.

4 Why it has to be agents

You might wonder why I’m using agents at all rather than just having the model switch modes. The reason is architectural: Claude Code can’t switch models mid-conversation. If you start a session on Haiku, everything runs on Haiku until the session ends. There’s no built-in way to say “this looks risky, bump up to Sonnet for this part.”

Spawning an agent is the only mechanism to use a different model. Agents run as subprocesses with their own model setting, which means if you need Sonnet to handle a deletion while your main session runs on Haiku, you have to spawn a Sonnet agent.

This leads to an important realization: agents aren’t just for organizing specialized tasks — they’re the only way to get the right model on the right task. The routing system depends entirely on this capability.

5 The five agents

The system uses two router agents for routing decisions, plus three general agents for execution.

router (Sonnet) serves as the entry point for all requests. It interprets intent, assesses risk, and routes to the appropriate agent. Crucially, it never executes tasks itself — it always spawns another agent (either project-specific or general). When uncertain about a routing decision, it escalates to router-escalation.

router-escalation (Opus) handles the edge cases where router isn’t confident. It analyzes the ambiguous request, makes the routing decision, and spawns the appropriate agent directly. Like router, it never executes tasks itself.

The remaining three agents are general-purpose executors for tasks that don’t match any specialized agent:

haiku-general (Haiku) handles mechanical operations with no judgment needed — find-replace, pattern matching, simple transforms. It’s fast and cheap for explicit operations.

sonnet-general (Sonnet) is the default for tasks requiring reasoning, analysis, or judgment calls. Anything that needs a second thought before executing lands here.

opus-general (Opus) tackles complex reasoning: mathematical proofs, detecting subtle logical flaws, high-stakes decisions with significant consequences.

One important distinction: general agents are endpoints. They execute tasks themselves and do NOT further route to specialized agents. Only the router knows about project-specific agents.

6 Project-specific specialized agents

Beyond the five core agents, the router also checks a project’s .claude/agents/ directory for specialized agents tailored to that project’s domain.

To give a concrete example, one of my research projects includes agents like tikz-illustrator (creates diagrams), literature-researcher (finds and integrates research papers), and math-verifier (validates mathematical models). This particular project to date has 42 such agents.

The key architectural principle here is that project-specific agents are the ONLY specialized agents in the system. General agents like haiku-general, sonnet-general, and opus-general do NOT route to them — only the router knows about project agents.

This explains why the “no direct spawning” rule is so important: if the main session model could spawn agents directly, it might bypass the router entirely and miss project-specific agents that would be better suited for the task.

7 Risk assessment for deletions

For any task involving file deletion or major changes, the router performs a quick risk assessment: What’s the scope? Does the content look valuable? Did the user give exact paths or just patterns? Is this reversible?

Based on these factors, it routes defensively:

• High risk → sonnet-general or opus-general
• Low risk + explicit paths → haiku-general
• Any uncertainty → sonnet-general for analysis first

Haiku only touches destructive operations when the user provided exact file paths, the files are clearly disposable, and the operation is easily reversible. Everything else goes to Sonnet, which examines what matches, checks if it looks important, and asks before deleting.

8 Some examples

"Change 'colour' to 'color' in src/utils.ts" → Haiku. The file is explicit, the change is non-destructive, and the intent is clear.

"Clean up the old files in this directory" → Sonnet. Both “old” and “clean up” are ambiguous, so this needs judgment before execution.

"Check if the proof in section 3.2 is valid" → Opus. Verifying math proofs is exactly where you don’t want mistakes.

9 Built-in guardrails

Each general agent has rules baked into its definition: read files before touching them, don’t delete based on patterns alone, and if uncertain, ask or escalate. These aren’t suggestions — they’re part of the agent specification.

10 Before and after

Before:

“Delete the old implementation files” → Haiku (session model) → wrong files gone

After:

“Delete the old implementation files” → router → sonnet-general → “these 3 files match, they contain X, want me to proceed?”

11 Results

I haven’t had an accidental deletion since. Costs went down too, because right-sizing models saves money. And perhaps most importantly, I actually trust the system now — something I didn’t realize was missing until I had it.

12 If you want to try this

Ask Claude Code to set it up. Here’s roughly what I used:

Create routing and general-purpose agents in ~/.claude/agents/:

Router agents (ensure routing happens on the right model):
1. router (Sonnet) - entry point for all requests; interprets intent,
   assesses risk, routes to project-specific or general agents
2. router-escalation (Opus) - handles edge cases when router is uncertain;
   makes routing decision and spawns agent directly

General agents (for tasks without specialized agents):
3. haiku-general (Haiku) - mechanical operations, no judgment needed
4. sonnet-general (Sonnet) - default for reasoning, analysis, judgment calls
5. opus-general (Opus) - complex reasoning, proofs, high-stakes decisions

Then add routing rules to ~/.claude/CLAUDE.md:
- If a project has its own routing rules in .claude/CLAUDE.md, use those instead
  (project-specific configuration takes precedence over global rules)
- EVERY request goes through router first, no exceptions
  (even if session runs on Opus, even if task seems obvious)
- The main session model MUST NOT spawn agents directly
  (ONLY valid flow: user request → router → agent)
- router follows this decision tree:
  1. Parse intent: What is the user asking?
  2. Assess risk: Deletion? Major changes? Consequences?
  3. Match to agents: Check project's .claude/agents/ first
  4. Choose model tier: Haiku/Sonnet/Opus based on complexity
  5. Route immediately: Delegate without attempting task
- Project-specific agents (Priority 1): Route when exact match exists
- General agents (Priority 2): Execute tasks themselves - they do NOT
  further route to specialized agents
- Main Claude (Priority 3): Conversation/coordination/system questions only
- Risk assessment for destructive operations:
  - Never route to haiku-general unless explicit paths + disposable + reversible
  - High risk → sonnet-general or opus-general
  - Any uncertainty → sonnet-general for analysis
- If router is uncertain about routing decision → escalate to router-escalation

Include examples showing when to use each tier and the risk assessment rules.

Context for Claude (why this matters):

Without explicit routing through router, behavior depends on session model.
Haiku might misroute deletions. Opus might handle everything itself.
By forcing every request through router, routing logic is consistent
regardless of session model.

The "no direct spawning" rule prevents shortcuts: without it, capable
models rationalize "this is obviously task X, I'll spawn agent Y directly."
The extra hop through router is not overhead - it IS the system.

Claude Code can't switch models mid-session. Spawning an agent is the
only way to use a different model. Router isn't optional - it's the
mechanism that guarantees consistent routing behavior.

Claude will generate the agent files and update your global configuration. Since it’s in ~/.claude/, it applies to all your projects by default.

If you’ve tried something similar or have a different approach, I’d be interested to hear about it.

2 1. Introduction

3 2. Architectural Analysis

config {
    name: "blog-api"
    version: "1.0.0"

    database: postgres {
        pool_size: 20
        timeout: 30s
    }

    cache: redis {
        ttl: 5m
        prefix: "blog:"
    }

    auth: jwt {
        issuer: env(JWT_ISSUER)
        secret: env(JWT_SECRET)
        expiry: 24h
    }
}

entity Post {
    description: "A blog post with content and metadata"

    id: uuid, primary, auto

    // Content
    title: string, required, searchable
    slug: string, required, unique
    content: text, required, searchable

    // Relationships
    author_id: ref(User), required
    category_id: ref(Category), optional

    // Tags (stored as JSON array)
    tags: list(string), optional

    // Publishing
    status: enum(draft, pending_review, published, archived), default(draft)
    published_at: timestamp, optional

    created_at: timestamp, auto
    updated_at: timestamp, auto_update

    index: [author_id, status]
    index: [slug]
}

database mongodb {
    collection Product {
        description: "E-commerce products with variants"

        _id: objectid, primary, auto
        sku: string, required, unique
        name: string, required

        // Embedded document for attributes
        attributes: embedded {
            color: string, optional
            size: string, optional
            dimensions: embedded {
                length: double, optional
                width: double, optional
                height: double, optional
            }
        }

        categories: array(string), optional

        indexes {
            index: [sku] unique
            index: [name, description] text
        }
    }
}

// Create post (author/editor/admin)
endpoint POST /posts {
    description: "Create a new post"
    auth: required
    roles: [author, editor, admin]

    body {
        title: string, required
        slug: string, required
        content: text, required
        category_id: uuid, optional
        tags: list(string), optional
        status: string, optional
    }

    returns: Post
    on_success: emit(PostCreated)
}

event PostPublished {
    description: "Post published"
    payload {
        post_id: uuid
        title: string
        slug: string
        published_at: timestamp
    }
    publish_to: [webhook("post-updates"), kafka("posts")]
}

integration PaymentGateway {
    description: "Stripe payment processing"
    type: rest
    base_url: env(STRIPE_API_URL)

    auth: bearer(env(STRIPE_SECRET_KEY))

    timeout: 30s
    retry: 3 times with exponential_backoff
    circuit_breaker: {
        threshold: 5 failures in 1m
        reset_after: 30s
    }

    operation create_payment_intent {
        method: POST
        path: "/payment_intents"
        body: {
            amount: integer, required
            currency: string, default("usd")
        }
        returns: {
            id: string
            status: string
            client_secret: string
        }
    }
}

workflow OrderProcessing {
    description: "Process an order from placement to fulfillment"
    trigger: OrderPlaced

    steps {
        // Step 1: Validate order
        validate_order {
            for_each: trigger.order.items
            check: item.product.available_quantity >= item.quantity
            on_fail: cancel_order("Insufficient inventory")
        }

        // Step 2: Reserve inventory (with compensation)
        reserve_inventory {
            for_each: trigger.order.items
            action: reserve_product_inventory(item.product_id, item.quantity)
            timeout: 30s
            retry: 3 times with exponential_backoff
            on_fail: rollback
        }

        // Step 3: Process payment (with compensation)
        process_payment {
            call: PaymentGateway.create_payment_intent {
                amount: trigger.order.total * 100
            }
            timeout: 30s
            on_fail: rollback
        }

        confirm_order {
            action: update(trigger.order.status = "confirmed")
        }
    }

    on_complete: emit(OrderConfirmed)
    on_fail: emit(OrderFailed)
}

job DailySalesReport {
    description: "Generate daily sales report"
    schedule: "0 6 * * *"                 // Every day at 6:00 AM
    timezone: "America/New_York"

    queue: default
    timeout: 30m
    retry: 3 times

    steps {
        fetch_sales {
            query: select Order
                where status = "completed"
                and created_at >= yesterday_start()
            as: orders
        }

        generate_report {
            template: "daily_sales_report"
            data: { orders: orders }
            format: pdf
            as: report_file
        }

        distribute {
            send: email(config.reports.recipients) {
                template: "daily_report_email"
                attachment: report_file
            }
        }
    }

    on_complete: emit(ReportGenerated)
}

4 3. Variation Scenario Testing

To validate IVP compliance, we test hypothetical change scenarios across each concern.

5 4. Comparison: Mixed-Concern Frameworks

To contextualize CodeAI’s IVP compliance, compare with traditional frameworks that entangle concerns.

class Order < ApplicationRecord
  # CONCERN 1: Schema/Relationships
  belongs_to :customer
  has_many :order_items

  # CONCERN 2: Validation
  validates :total, presence: true, numericality: { greater_than: 0 }

  # CONCERN 3: Business Logic
  def process!
    reserve_inventory
    charge_payment
    send_confirmation
    self.status = 'confirmed'
    save!
  end

  # CONCERN 4: Queries
  scope :pending, -> { where(status: 'pending') }
  scope :completed, -> { where(status: 'completed') }

  # CONCERN 5: Callbacks
  after_create :send_order_placed_event
  before_destroy :refund_payment
end

// CONCERN 1: Schema (entity Order { })
entity Order {
    id: uuid, primary, auto
    customer_id: ref(Customer), required
    total: decimal(10,2), required
    status: enum(pending, confirmed, ...), default(pending)
}

// CONCERN 2: Validation (embedded in endpoint)
endpoint POST /orders {
    body {
        total: decimal, required, min(0.01)
    }
}

// CONCERN 3: Business Logic (workflow OrderProcessing { })
workflow OrderProcessing {
    steps {
        reserve_inventory { ... }
        charge_payment { ... }
        send_confirmation { ... }
        confirm_order { ... }
    }
}

// CONCERN 4: Queries (used in endpoints/workflows where needed)
endpoint GET /orders {
    query {
        status: string, optional
    }
}

// CONCERN 5: Events (event OrderPlaced { })
event OrderPlaced {
    payload { order_id: uuid, ... }
}

6 5. Language Design Patterns Supporting IVP

// ✅ Valid: Endpoint references entity
endpoint GET /users/{id} {
    returns: User
}

// ❌ Invalid: Cannot define entity inside endpoint
endpoint GET /users/{id} {
    entity User { ... }  // Syntax error
}

// ❌ Invalid: Cannot embed workflow in integration
integration API {
    workflow Process { ... }  // Syntax error
}

// Endpoint references entity (doesn't embed it)
endpoint POST /posts {
    returns: Post
}

// Workflow calls integration (doesn't define it)
workflow OrderProcessing {
    process_payment {
        call: PaymentGateway.create_payment_intent { ... }
    }
}

// Event references entity (doesn't own it)
event PostCreated {
    payload {
        post_id: uuid  // References Post.id
    }
}

// Composition: workflow uses integration + entity + event
workflow OrderProcessing {
    trigger: OrderPlaced             // Composes with event

    process_payment {
        call: PaymentGateway.create  // Composes with integration
    }

    confirm_order {
        action: update(order.status)  // Composes with entity
    }
}

// Each composed concern varies independently

7 6. Potential IVP Concerns

// In integration
integration API {
    retry: 3 times with exponential_backoff
}

// In workflow step
workflow Process {
    steps {
        call_api {
            retry: 5 times
        }
    }
}

// In job
job Task {
    retry: 2 times
}

entity Post {
    id: uuid
    title: string
    slug: string
}

event PostPublished {
    payload {
        post_id: uuid
        title: string
        slug: string
    }
}

8 7. Conclusion