DEV Community: Yannick Loth

Which Java Construct Should You Use? Let Change Drivers Decide

Yannick Loth — Sat, 11 Apr 2026 18:46:00 +0000

A change driver is anything that, when it changes, forces an element of a system to change.
The Independent Variation Principle (IVP) constrains how modules and their elements relate to these drivers: elements sharing a module must have the same driver assignment, and elements with different driver assignments must live in different modules.

Applied to Java constructs, the lens separates essential coupling — the drivers the situation actually requires — from accidental coupling — the drivers the chosen construct drags in for reasons that have nothing to do with the situation.
Picking the right construct is picking the one whose realization carries only the essential drivers.
Throughout the article, "before" constructs carry accidental coupling (typically an implicit outer-instance reference, a synthetic class file, or a mutation channel the situation does not need); "after" constructs remove the accidental artifacts and keep only what the situation requires.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Three Questions Before You Add a Microservice — and Why They All Collapse Into One

Yannick Loth — Tue, 07 Apr 2026 16:59:05 +0000

A recent LinkedIn post from John Crickett has been making the rounds. It offers three questions to ask before adding another microservice:

Does this need to be a service?
Does this need to be its own service?
Does this need to be its own service right now?

Crickett credited Craig Ferguson, the comedian, for the format — Ferguson has a bit about three questions a man should ask himself before he speaks. The post is in that register: deliberately light, deliberately compressed, the kind of aphorism a practitioner can carry in their head into a Monday-morning design meeting. Crickett's questions have spread because they work. They surface the right conversation in teams that might otherwise never have it.

What I want to do is unpack what the aphorism is compressing. My claim isn't that Crickett's questions are wrong or incomplete — it's that they're pointing very precisely at something a formal theory of modularization can name. And the something they're pointing at is more unified than the three-part structure suggests: the three questions turn out to be three natural-language phrasings of one structural question. Seeing why is, I think, the most interesting thing you can do with the post.

Let me walk through it.

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.

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.

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.

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.

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."

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.

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:

Cell	Representative drivers	Operational compatibility with other cells
App logic	Domain rules, business workflows, validation logic	Compatible with replication; not compatible with sharing a process with the load balancer (cyclic)
Load balancing	Routing strategy, health-check protocol, traffic patterns	Cannot live inside an instance it balances
Session / state coordination	Consistency model, eviction policy, replication strategy	Must outlive any single instance — independent failure domain
Failure detection	Health-check semantics, timeout policies, recovery rules	Must survive failures of what it monitors

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:

Capacity math (outside the principle): 10,000 users on hardware X cannot be served by a single instance.
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.
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.
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.
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.

Two distinct kinds of knowledge

Notice that "there must be a separate service deployed onto four servers" is actually two different claims fused into one sentence, and they enter the principle through different doors.

"There must be a separate service" is a structural claim about elements and drivers. It says: there exist elements whose drivers (combined with engineering facts about runtimes) cannot all be served inside a shared process — they need independent deployment, independent scaling, or an independent failure domain. Once you know that, the principle takes over and propagates the structural consequence: those elements form a cell whose realization is a separate deployable unit. The principle doesn't discover the underlying drivers, but it consumes them and propagates their implications through the partition.

"Deployed onto four servers" is a quantitative fact about capacity and resource allocation. It is not a structural claim about modularization at all. The principle has nothing to say about whether the number is four, forty, or four hundred. You can change the number tomorrow without touching a single module boundary — you adjust a deployment config, you don't re-modularize. But you can't quietly change "separate service" to "in-process library" without reshaping the partition, because the drivers that put it in its own cell haven't gone away.

So the key knowledge, from the principle's point of view, is the structural knowledge. The quantitative part is what made the structural knowledge visible in the first place — capacity math is what revealed that horizontal scaling was necessary — but once the structural fact is established, the specific instance count drops out of the modularization question entirely. If a genie whispered "this system will need to run horizontally scaled" without telling you the number, the principle could already produce the correct partition. If the same genie whispered "this system will need four servers" without telling you why, the principle couldn't do anything with the information — it has no slot for a raw count.

This is the layering the honest answer requires. Capacity math produces numbers and reveals structural necessities. The principle consumes the structural necessities and produces the partition. Operations consumes the partition and the original numbers to decide how many instances of each module run where. Each layer does its own job. When a single mental model tries to carry all three at once, the layers blur, and that blurring is where a lot of microservice sizing confusion comes from.

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.

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.

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

Does Formal IVP Modularization Lead to Speculative Fragmentation?

Yannick Loth — Thu, 02 Apr 2026 18:54:57 +0000

A thoughtful comment on my recent LinkedIn post raised three concerns about the Independent Variation Principle that deserve a serious answer.

The concerns are, in essence: that proactive separation by change driver risks massive over-fragmentation; that the existence of a driver does not entail its activation with relevant probability; and that to eliminate subjectivity, the change driver must become a constant or be determined with high probability.

I take these concerns seriously, because they point to the exact place where IVP must distinguish itself from the Single Responsibility Principle.

If IVP inherits SRP's problems, the formal apparatus adds overhead without benefit.
It does not inherit them, and the reasons are structural.

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.

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.

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.

Where to go from here

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

One Principle, One Proof: Why IVP-Compliant Modules Minimize Change Impact

Yannick Loth — Tue, 10 Mar 2026 09:15:53 +0000

You refactor authentication.
You touch UserController, LoginService, SessionManager, and APIGateway.

Four files for one concern.
You already know this is wrong — but can you prove it?

This article takes a single, universally understood quality metric — change impact — and proves that applying the Independent Variation Principle (IVP) reduces it to the theoretical minimum.
No hand-waving.
No "it depends."
A clean, short proof.

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.

The principle: IVP in two directives

The Independent Variation Principle has several directives, but only two matter 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.

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. ∎

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.

The concrete example

Step 1: Identify the change driver

Let γ_auth be the authentication change driver.
It activates when any authentication-related requirement changes: password policy, MFA rules, token expiration strategy, or session validation logic.

The elements governed by γ_auth are:

validatePassword — enforces password policy
checkMFA — applies multi-factor rules
expireToken — controls session lifetime based on auth parameters
validateToken — verifies tokens against the auth scheme

All four elements exist because of authentication requirements, and all four must change together when those requirements change.
That's what makes them a single driver: they share the same reason to change.

Step 2: Non-IVP design — scattering γ_auth

A typical layered architecture distributes these elements by technical role rather than by driver:

// 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.
    }
}

Driver analysis: γ_auth's elements are scattered across 4 modules.
Each module contains some authentication logic alongside other concerns.

Change scenario: Increase minimum password length from 8 to 12, and switch from bcrypt to argon2.

What changes:

UserController — the length check (< 8 → < 12)
LoginService — passwordStrong() encodes strength criteria that just changed
SessionManager — computeTTL(getPasswordHash(...)) depends on the hashing scheme, which just changed from bcrypt to argon2
APIGateway — token validation indirectly depends on the new session format; integration tests break, call chain needs re-verification

impact(γ_auth, M') = 4. Four modules, four PRs, four risk surfaces.

Why this is non-IVP: IVP-4 requires all elements with the same driver assignment to live in one module.
Here, the four γ_auth elements live in four different modules.
IVP-4 is violated.

Step 3: IVP-compliant design — unifying γ_auth

Group all elements governed by γ_auth into a single module:

// 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.

Driver analysis: Every element governed by γ_auth lives in AuthenticationService.
No other module contains authentication logic — they call through IAuthProvider, whose signature is stable across auth changes.

Same change scenario: Increase password length, switch hashing scheme.

What changes: AuthenticationService. Nothing else.
The interface IAuthProvider doesn't change (it exposes authenticate and validateSession, not password-length constants or hashing algorithms).
Callers are untouched.

impact(γ_auth, M_IVP) = 1.

Why this is IVP-compliant:

IVP-4 (unification): All γ_auth elements are in one module. ✓
IVP-3 (separation): AuthenticationService contains only γ_auth elements — no payment logic, no user profile logic. ✓

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.

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:

Driver count per module (|Γ(M)|) — minimized to 1 by IVP-3 and IVP-4 together (separation prevents mixing; unification ensures one module per driver)
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.

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.

Iterative review-fix loops remove LLM hallucinations, and there is a formula for it

Yannick Loth — Wed, 04 Mar 2026 22:18:45 +0000

If you have used LLMs for anything that requires accuracy, you have probably noticed the pattern: the first output is a mix of genuine insight and confident fabrication. You read through it, spot the errors, fix them, and move on. Most people treat this manual review step as an unavoidable cost of working with these models.

But here is something worth pausing on: when you ask the same model to review its own output, it often finds the very errors it just made. It spots hallucinated facts, logical gaps, and inconsistencies that it introduced moments earlier. And if you ask it to fix those findings and then review again, it finds more. You can repeat this until a review round produces zero findings, and the result is remarkably clean.

This seems paradoxical at first. If the model was capable of recognizing these errors, why did it make them in the first place? The answer turns out to be that recognizing a mistake is fundamentally easier than not making one. Generation and verification are not the same cognitive task, and LLMs are measurably better at the second. This asymmetry is the key to everything that follows.

I have been using this review-fix loop for academic papers, code, and technical documentation, and it reliably converges within a few rounds. Recent research now provides a formal mathematical model explaining why it converges and when you should stop.

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.

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.

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:

Round	What typically happens
0	Initial generation, with hallucinations present
1 to 2	Major errors are removed, including factual and logical contradictions
3 to 5	Refinement phase, where nuances, edge cases, and subtle inconsistencies are resolved
6+	Diminishing returns, with a risk of the model "fixing" things that were not broken

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

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	Share of total improvement
1	50%
2	25%
3	12.5%
4	6.25%
5	3.125%

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).

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:

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.
Track findings per round. If the count is decreasing, you are converging. If it plateaus or increases, you should stop.
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.
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.

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.

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.

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.

References

Yang, Z., Zhang, Y., Wang, Y., Xu, Z., Lin, J., & Sui, Z. (2025). A Probabilistic Inference Scaling Theory for LLM Self-Correction. EMNLP 2025.
Madaan, A., Tandon, N., Gupta, P., et al. (2023). Self-Refine: Iterative Refinement with Self-Feedback. NeurIPS 2023.
Huang, J., Chen, X., Mishra, S., et al. (2024). Large Language Models Cannot Self-Correct Reasoning Yet. ICLR 2024.
Liu, G., Mao, H., Cao, B., et al. (2024). On the Intrinsic Self-Correction Capability of LLMs: Uncertainty and Latent Concept. arXiv:2406.02378.

AI mimics reasoning. But What Makes Intelligence Valuable?

Yannick Loth — Fri, 27 Feb 2026 16:10:08 +0000

A response to Bertrand Meyer's "Yes, AI is Intelligent. Prove Me Wrong" (Internet Archive Link)

What makes intelligence valuable?
Humans are also pattern matchers
Survival is what gave intelligence its value
The inverted stack
Why the distinction matters
The airplane analogy, revisited
The body as live computation
Two different reasoning machines
What would actual intelligence look like in AI?
No, AI is not a virus
The respectful disagreement
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?

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.

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?

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.

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.

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.

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.

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.

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.

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:

An agent with finite energy that really depletes, with real consequences for reaching zero.
Continuous sensory input — not discrete prompts, but an unbroken stream.
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?
Temporal continuity — persistent identity. Not memory as files. Memory as changed weights. The agent that experienced something is literally different afterward.
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.

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.

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.

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.

The Independent Variation Principle: What It Brings Compared to Every Design Principle You Know

Yannick Loth — Fri, 13 Feb 2026 18:03:22 +0000

Software engineering has accumulated decades of design wisdom: Separation of Concerns, Information Hiding, SOLID, Package Principles, DRY, KISS, Law of Demeter, and principles from functional programming. Each offers valuable guidance, but they've remained fragmented—independent heuristics learned separately, applied by intuition. I have long been struck by the similarities between them. For years, my conclusion was that most aimed at improving decoupling between software elements. This intuition was right, but incomplete.

The Independent Variation Principle (IVP) offers a unifying lens. It explains why these principles work, how they relate to each other, and when to apply them. This article examines IVP's relationship to major design principles and what it clarifies about each.

What Is IVP?
- Elements and Units
- The Two 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

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).

Elements and Units

Elements and units are simply code constructs:

Elements are atomic constructs: statements, expressions, fields, methods, functions
Units are grouping constructs: classes, modules, packages, services, layers

Critically, what counts as an "element" or "unit" depends on the observation level, which is defined by the change drivers under consideration:

At the method level, statements are elements and methods are units
At the class level, methods are elements and classes are units
At the package level, classes are elements and packages are units
At the service level, packages are elements and services are units

IVP applies fractally at every level. The principle remains the same; only the granularity changes.

This generality is intentional. IVP is formulated so that "element" and "unit" are completely general constructs—they carry no assumption about programming paradigm, language features, or system type. Whether you're organizing statements into functions, functions into modules, modules into packages, packages into services, or services into systems, IVP applies. The abstraction level is determined by the change drivers you're analyzing, not by the principle itself.

The Two Directives

IVP yields two complementary directives:

IVP-1 (Isolate Divergent Concerns): Elements governed by different change drivers should be in different units
IVP-2 (Unify by Single Purpose): Elements governed by the same change driver should be in the same unit

The key insight: IVP operates at the level of causation rather than structure. It asks: What causes this code to change? That cause is called a change driver (denoted γ in formal notation).

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?"

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.

From "Good Ideas" to Domain Analysis

Different principles approach design decisions in different ways:

SRP (heuristic): "Does this class have one responsibility?"
But what counts as "one"? Who decides?

OCP (heuristic): "Is this open for extension?"
But should it be? At what cost?

IVP (domain-grounded): "Who or what causes this code to change? Are there multiple independent sources of change affecting this code?"

IVP shifts the conversation from abstract principles to concrete domain analysis:

What business stakeholders own this functionality? Different stakeholders = different change drivers.
What external systems does this code depend on? Different systems = different change drivers.
What regulations govern this behavior? Different regulatory bodies = different change drivers.
What technical concerns are involved? Different technical domains = different change drivers.

Change Drivers Are Domain Facts

A change driver isn't an abstract concept—it's a concrete fact about your domain:

The pricing team controls pricing rules → γ_pricing
The compliance department owns regulatory logic → γ_compliance
The infrastructure team manages deployment concerns → γ_infrastructure
An external payment API has its own evolution schedule → γ_payment_api

These aren't heuristics—they're facts about your business domain. You can identify them, name them, and verify them by looking at who requests changes and why.

The Epistemological Foundation

IVP's Knowledge Theorem formalizes this: maximal cohesion is equivalent to complete and pure embodiment of domain knowledge. A module has maximal cohesion when it:

Contains all the knowledge relevant to its change driver (complete)
Contains no knowledge relevant to other change drivers (pure)
Exhibits all expected functional behavior and non-functional qualities (semantic)

The first two dimensions are structurally verifiable—you can analyze code to check them. The third requires domain expertise: does this module actually do what the business needs? This reflects that architecture is fundamentally knowledge work, not just structural arrangement.

This isn't a heuristic saying "cohesive modules are good." The Knowledge Theorem establishes a formal equivalence: cohesion reflects how well we have organized domain knowledge. High cohesion means your code structure matches your domain structure. Low cohesion means your code misrepresents what knowledge belongs together.

Practical Implications

This domain-grounding has practical consequences:

1. Decisions become more grounded. Instead of debating whether something "feels like" one responsibility, you can identify the change drivers involved. Either the code is affected by one change driver or multiple. This shifts the conversation from subjective intuition toward concrete domain analysis—though judgment remains necessary.

2. Reasoning transfers across contexts. Heuristics often fail in unfamiliar territory ("SOLID doesn't apply to my database schema"). IVP's change driver analysis works wherever things change—code, configuration, data, infrastructure, even team structure.

3. Domain experts become relevant. With heuristic-based principles, architects decide what's "right" based on experience. With IVP, domain knowledge matters. Understanding the business—who owns what, what changes independently—informs architecture directly.

4. Historical analysis becomes possible. You can mine version control history to discover actual change drivers empirically. When did things change together? When did they change independently? The answers guide future structure.

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.

Why "Epistemological"?

Epistemology is the branch of philosophy concerned with knowledge: What is knowledge? How do we acquire it? How do we organize and represent it?

Software, at its core, is embodied knowledge. Every line of code represents something someone knows about the domain:

A pricing formula embodies knowledge about how the business calculates prices
A validation rule embodies knowledge about what constitutes valid data
An API contract embodies knowledge about how systems communicate
A database schema embodies knowledge about entity relationships

When you write code, you're not just "programming"—you're formalizing knowledge into executable form. The business analyst knows the pricing rules; the code makes that knowledge precise, explicit, and operational.

This is why architecture matters: architecture determines how knowledge is organized. Good architecture organizes knowledge so that:

Related knowledge lives together (cohesion)
Unrelated knowledge stays separate (low coupling)
Each piece of knowledge has one authoritative location (no contradictions)
Knowledge can evolve independently when it changes independently

Bad architecture scatters related knowledge across modules, tangles unrelated knowledge together, duplicates knowledge in contradictory ways, and forces unrelated things to change together.

The Knowledge Theorem

The Knowledge Theorem proves that maximal cohesion (the goal all these principles pursue) is equivalent to:

Complete embodiment of domain knowledge (nothing relevant missing)
Pure embodiment of domain knowledge (nothing irrelevant included)
Semantic correctness (exhibits expected functional behavior and non-functional qualities)

The first two dimensions are structurally verifiable—you can analyze code to check purity and completeness. The third requires domain expertise: does this module actually do what the business needs? Does it meet performance, security, and reliability requirements?

High cohesion isn't about counting methods or measuring dependencies. It's about a module faithfully representing exactly one domain's knowledge—structurally and semantically. This reframes architecture from dependency management to knowledge organization.

Why This Matters

Once you see architecture as knowledge organization, familiar principles take on new meaning:

SRP: don't mix knowledge from different domains in one class
Information Hiding: hide volatile knowledge behind stable boundaries
DIP: separate policy knowledge from mechanism knowledge
Cohesion: how purely does this module represent one domain's knowledge?

The principles aren't arbitrary rules. They're all ways of saying: organize knowledge properly. IVP makes this explicit by grounding architectural decisions in domain knowledge structure—specifically, in which knowledge changes together (same change driver) versus independently (different change drivers).

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.

The Traditional View

In the traditional view, you might analyze a system and find:

Module A has high cohesion (good)
Module B has high cohesion (good)
But A and B are tightly coupled (bad)

This framing suggests coupling and cohesion are orthogonal dimensions. You could have any combination: high cohesion with high coupling, low cohesion with low coupling, etc.

The Insight

Consider what "tight coupling" actually means: changes to A force changes to B even when B's core responsibility hasn't changed. But why would B need to change for A's reasons?

The answer, I realized, is straightforward: B contains elements that vary for A's change driver.

If B were purely cohesive—containing only elements governed by B's change driver—then A's changes couldn't affect it. B would only change for B's reasons. The coupling between A and B exists precisely because B is impure: it contains knowledge that belongs to A's domain.

Coupling as Impurity Made Visible

Every instance of "problematic coupling" can be traced to a cohesion violation:

Observed Coupling	Underlying Cohesion Problem
A depends on B's internals	A contains knowledge that should be in B (A is impure)
Changes to A ripple to B	B contains knowledge governed by A's driver (B is impure)
A and B must deploy together	Both contain knowledge from a shared driver that should be extracted
Circular dependency A ↔ B	Both are impure—each contains elements belonging to the other

The coupling is not the disease; it's the symptom. The disease is impurity—modules containing knowledge that doesn't belong to their change driver.

Practical Consequences

This understanding has several practical consequences:

1. Focus on cohesion, not coupling. If you maximize cohesion (complete and pure embodiment of each change driver's knowledge), minimal coupling follows automatically. You don't need to "reduce coupling" as a separate activity.

2. Coupling analysis reveals cohesion problems. When you observe tight coupling, don't ask "how do I decouple these?" Ask "which module contains knowledge that doesn't belong to it?" The coupling tells you where to look; the fix is purifying the impure module.

3. Decoupling without purification is futile. Adding interfaces, abstractions, or indirection between coupled modules doesn't fix the underlying problem. The coupling will reassert itself because the impure module still contains foreign knowledge. You've hidden the symptom without treating the disease.

4. Coupling severity indicates impurity degree. The more severe the coupling (the more changes that ripple), the more foreign knowledge a module contains. Coupling is a measure of impurity.

The Mathematical Relationship

The Knowledge Theorem establishes that maximal cohesion equals complete and pure knowledge embodiment. This means:

Maximal cohesion → module contains exactly its change driver's knowledge, nothing more, nothing less
Pure module → contains no knowledge governed by other change drivers
No foreign knowledge → cannot be affected by other change drivers
Cannot be affected → no coupling to those other drivers

The implication is direct: a module with maximal cohesion has minimal coupling by construction. You don't achieve minimal coupling by "removing dependencies." You achieve it by ensuring each module embodies exactly one change driver's knowledge.

Cohesion First, Always

This is why IVP-1 ("isolate divergent concerns") and IVP-2 ("unify by single purpose") are both statements about cohesion:

IVP-1 prevents impurity by forbidding foreign knowledge
IVP-2 ensures completeness by requiring related knowledge to stay together

Both directives target cohesion. Neither mentions coupling directly. Yet IVP-compliant structure has minimal coupling as a consequence.

This suggests an inversion of the traditional emphasis. Rather than treating coupling as a first-order concern to be actively managed, we might better focus on cohesion. Coupling is a second-order effect—a consequence of how we organize knowledge. Get cohesion right, and coupling tends to minimize naturally.

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.

Separation of Concerns (Dijkstra)

What Dijkstra Actually Said (1974)

"Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one's subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects."
— Dijkstra, "On the Role of Scientific Thought" (EWD447)

Relevant Change Drivers

SoC applies whenever you have multiple independent dimensions of variation:

γ_A vs. γ_B vs. γ_C where each represents a distinct aspect of the system
Technical layers (presentation, logic, persistence) often have independent drivers
Domain modules often have independent drivers (different business stakeholders)
Pipeline stages may have independent drivers (different processing concerns)

The Problem with SoC

SoC provides no criterion for what constitutes a "concern" or "aspect." Two architects can look at the same system and identify completely different concerns:

One sees "data access" and "business logic" as separate concerns
Another sees "user management" and "order processing" as the concerns
A third sees "validation," "transformation," and "persistence"

Who's right? SoC provides no way to decide. It assumes you already know what the concerns are—but identifying concerns is often the hard part. As Dan North observed, "any non-trivial code can have any number of reasons to change"—so which decomposition is correct?

How IVP addresses this: Concerns are defined by change drivers. A concern is a set of elements that vary for the same cause. This provides a more concrete criterion: analyze your version control history, identify who requests changes and why, map out the causal structure. The concerns emerge from domain reality rather than relying solely on architectural intuition.

Relationship to IVP: IVP Operationalizes SoC

SoC and IVP share the same insight but operate at different levels of specificity:

SoC	IVP
"Separate different aspects"	"Separate elements that vary for different causes"
Which aspects? Why? → Intuition	Which elements vary for different causes? → Causal analysis

What IVP Adds

SoC leaves critical questions unanswered:

What constitutes an "aspect"? IVP answers: aspects are defined by shared change drivers
When should aspects be unified? SoC focuses only on separation; IVP provides the complementary directive (IVP-2)
How to measure separation quality? SoC is qualitative; IVP enables measurement through cohesion metrics tied to change drivers

In practice, this means: instead of relying on intuition about what constitutes a "concern," analyze what actually changes together in your version control history. Concerns are defined by causal reality, not abstract categorization.

Information Hiding (Parnas)

What Parnas Actually Said (1972)

"We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others."

Note: Parnas did not mention "stable interfaces." That phrase, while commonly associated with Information Hiding, is a later community interpretation—not Parnas's words.

Relevant Change Drivers

Information Hiding addresses the boundary between:

γ_client (what clients need) vs. γ_impl (how it's achieved internally)
The interface is stable; the implementation is volatile
Hiding is warranted when γ_impl is likely to change independently of γ_client

The Core Idea

The criterion is probabilistic: identify decisions "likely to change," then hide them. This requires prediction—you must judge what's likely to change. It's an economic decision because hiding has costs (abstraction overhead), and you only pay those costs where the probability of change justifies them.

Note: while this sounds like DIP, they're distinct principles. Information Hiding is probabilistic—it asks "what's likely to change?" and requires prediction. DIP is structural—it prescribes dependency direction without asking about probability. DIP says "always depend on abstractions"; Information Hiding says "hide what's likely to change." The structural result may look similar, but the reasoning differs.

Relationship to IVP: Different Concerns

Information Hiding and IVP address different questions:

Information Hiding	IVP
Which decisions should we hide?	How should we structure if we decide to separate?
Based on probability ("likely to change")	Based on causal structure (independent change drivers)
Economic/predictive judgment	Structural/design guidance

IVP tells you how to separate concerns correctly. If you decide to separate client needs from implementation details, IVP-1 tells you how: elements varying for γ_client go in one module, elements varying for γ_implementation go in another.

Information Hiding tells you whether to bother. Parnas's criterion is probabilistic: hide decisions "likely to change." This is an economic judgment—separation has costs (abstraction overhead, indirection complexity). You only pay those costs where the benefit (isolation from likely changes) justifies them.

The Architect's Two-Step Decision

IVP provides the structural analysis: "These concerns have independent change drivers. If we separate them, here's how to do it correctly."
Economic judgment decides whether to apply it: "Is this separation worth it? How likely is change? What's the cost of the abstraction? What's the cost of not separating if change occurs?"

IVP doesn't make the economic decision for you. But it does three critical things:

Clarifies what you're deciding about: Which change drivers exist? Which are independent?
Ensures correct boundaries: If you choose to separate, IVP tells you exactly where the lines should go
Makes tradeoffs explicit: When you choose not to separate independent concerns, IVP tells you precisely what coupling you're accepting—which future changes will ripple across boundaries

This last point is crucial. Without IVP, you might skip a separation and not understand the cost. With IVP, you know: "I'm coupling γ_pricing and γ_compliance in this module. If either changes independently, I'll pay the price." That's an informed tradeoff, not a blind one.

What IVP Adds

Parnas provided the economic criterion ("likely to change") but not a systematic way to identify what the independent concerns are or how to separate them correctly. IVP fills this gap:

Identifies change drivers: Who or what causes this code to change?
Reveals independence: Are these change drivers independent?
Guides the structure: If separating, ensure elements for each driver are isolated

The practical approach: use IVP to map out the change drivers and their independence relationships. Then make informed economic decisions about which separations to invest in. You might identify ten potential separations but only implement three—the ones where change is likely enough to justify the cost. IVP ensures those three are done correctly.

DRY (Don't Repeat Yourself)

What Hunt & Thomas Said (1999)

"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."
— Hunt & Thomas, The Pragmatic Programmer

Relevant Change Drivers

DRY concerns arise when code appears similar but may represent different knowledge:

γ_A vs. γ_B — two pieces of code look identical but change for different reasons
Same change driver → same knowledge → extract (IVP-2)
Different change drivers → different knowledge → keep separate despite similarity (IVP-1)

The Problem with DRY

DRY itself is sound—it speaks of knowledge, not code. But in practice, developers often apply DRY based on structural similarity rather than knowledge identity. Two pieces of code can look identical yet represent different knowledge:

Email validation in user registration
Email validation in newsletter signup

These might have identical implementations today, but they represent different business decisions. Marketing might relax newsletter validation while security tightens user registration validation. They look the same but are different knowledge.

DRY provides no criterion for distinguishing "same knowledge" from "coincidentally similar code." Without such a criterion, teams extract "shared" code, then discover that changes for one use case break the other.

Additional problems with DRY in practice:

Premature abstraction: Developers extract patterns before understanding how components will diverge. As Kent C. Dodds advocates with "AHA Programming" (Avoid Hasty Abstractions), it's cheaper to wait for a pattern to emerge than to undo a bad abstraction.
Hidden coupling: DRY'd abstractions become "optimized for keeping all components the same"—they're coupled together with no affordances for elements to evolve in diverging directions.
Increased complexity: Reading DRY'd code requires jumping between abstraction layers, maintaining mental state across indirections. Linear, "duplicated" code is often easier to understand.
The sunk cost trap: Once engineers invest in an abstraction, they tend to continue iterating on it rather than recognizing when it's the wrong abstraction.

How IVP addresses this: IVP provides the missing criterion. Same knowledge = same change driver. If two pieces of code change for the same reason (same authority, same business rule), they represent the same knowledge—extract them. If they change for different reasons, they're different knowledge despite structural similarity—keep them separate. This prevents premature abstraction by requiring causal analysis before extraction.

Relationship to IVP: Context-Dependent

DRY's relationship to IVP is context-dependent: duplication sometimes violates IVP, sometimes satisfies it.

Case 1: True Duplication (DRY and IVP agree)

Email validation in both user registration and contact form:

Both implement the same rule
Both change for the same cause (email format requirements)
IVP-2 applies: extract to shared module

Case 2: Accidental Similarity (IVP overrides DRY)

Order total calculation and inventory value calculation:

Both sum item values
Order total changes for γ_pricing (pricing rules)
Inventory value changes for γ_accounting (cost accounting rules)
γ_pricing ⊥ γ_accounting (independent)
IVP-1 applies: keep separate despite structural similarity

The DRY Trap

Blindly applying DRY to accidental similarity creates a shared utility. When pricing rules evolve, the shared utility changes, forcing inventory calculations to revalidate despite no business reason—violating IVP-1.

What IVP Adds

DRY observes that duplication is often problematic but doesn't explain why or when. IVP provides the criterion:

If duplication represents the same knowledge varying for the same cause: eliminate it (DRY and IVP-2 agree)
If duplication represents coincidentally similar code varying for different causes: preserve it (IVP-1 overrides DRY)

The question to ask before extracting "duplicate" code: Do these pieces change for the same reason? If not, the apparent duplication is actually appropriate separation.

KISS (Keep It Simple, Stupid)

The Principle

KISS is a design principle originating from the U.S. Navy (1960s). Unlike the other principles, it has no single canonical statement—it's a folk principle advocating simplicity.

Relevant Change Drivers

Complexity concerns arise when independent change drivers are accidentally coupled:

γ_A entangled with γ_B where γ_A ⊥ γ_B — accidental coupling
Cross-cutting concerns scattered across multiple modules
Essential coupling (γ_A with γ_A) is necessary; accidental coupling (γ_A with γ_B) is unnecessary complexity

The Problem with KISS

KISS provides no criterion for what counts as "simple" or "unnecessary." Every developer thinks their solution is simple; complexity is always justified by some rationale:

"We need this abstraction for testability"
"This pattern makes future changes easier"
"This indirection enables flexibility"

Without an objective measure, KISS becomes a rhetorical weapon: "Your solution is too complex" really means "I don't understand it" or "I would have done it differently." Two developers can disagree about simplicity with no way to resolve the dispute.

How IVP addresses this: IVP offers a more precise definition: unnecessary complexity is accidental coupling—coupling between elements that vary for independent causes. While determining independence still requires analysis, this gives you something concrete to examine: do these things change for the same reason or different reasons? Coupling things that change independently is unnecessary complexity; coupling things that change together is essential structure.

Relationship to IVP: IVP Operationalizes KISS

KISS identifies the goal; IVP provides the method.

Accidental vs. Essential Complexity (Brooks):

Essential complexity: inherent to the problem
Accidental complexity: arising from the solution

IVP provides precise definitions:

Essential coupling: elements coupled because they vary for the same cause (IVP-2 mandates this)
Accidental coupling: elements coupled despite varying for different causes (IVP-1 violation)

Accidental coupling creates accidental complexity. IVP-1 eliminates accidental coupling, thereby minimizing accidental complexity—exactly what KISS prescribes.

What IVP Adds

KISS is vague: what's "unnecessary"? IVP makes it precise: unnecessary complexity arises from accidental coupling—coupling elements that vary for independent causes.

When evaluating complexity, the useful question is: Is this coupling essential (things that genuinely change together) or accidental (independent concerns entangled)?

Law of Demeter (Principle of Least Knowledge)

What Lieberherr Said (1989)

"A method should only call methods of: (1) itself, (2) its parameters, (3) objects it creates, (4) its direct components."
— Lieberherr et al., "Assuring Good Style for Object-Oriented Programs"

Informally: "Don't talk to strangers."

Relevant Change Drivers

LoD concerns arise in chains that traverse independently-varying structures:

γ_A → γ_B → γ_C — each link may have an independent change driver
The more independent drivers in a chain, the more fragile the coupling
Train wrecks couple the client to n independent sources of change

The Problem with LoD

LoD is often called the "Suggestion of Demeter" because it's so easy to violate and hard to follow strictly. Several issues arise:

Delegation can be a false solution: Using wrapper methods to hide violations removes visible evidence but doesn't actually decouple the code—it just hides tight coupling.
Strict adherence leads to "wrapper hell": Numerous small wrapper methods can introduce excessive indirection, making code harder to read than the original "train wreck."
Data structures are often exempt: When accessing pure data structures (DTOs, configuration objects), strict LoD application adds ceremony without benefit.
No clear boundary: How many dots are too many? LoD provides no criterion for when a chain becomes problematic.

How IVP addresses this: IVP explains why train wrecks are problematic: each link in the chain is a potential independent change driver. Count the independent things that could change and break the chain. If order.getCustomer().getAddress().getZipCode() involves three independently changing structures, that's the problem—not the dot count itself. Data structure chains where everything changes together are less concerning.

Relationship to IVP: Bidirectional Equivalence

LoD is IVP-1 applied to method invocation scope.

Train wreck: order.getCustomer().getAddress().getZipCode()

Client C now varies for three independent causes:

γ_C: client's own requirements
γ_Customer: Customer structure changes
γ_Address: Address structure changes

This violates IVP-1. The fix (delegate to order.getCustomerZipCode()) is IVP-1 in action.

What IVP Adds

LoD gives the rule; IVP explains why: train wrecks couple clients to multiple independent variation sources.

When you see a long method chain, the relevant question is: How many independent things could change and break this chain? Each independent change source is a reason to encapsulate.

Principle of Least Surprise

The Principle

The Principle of Least Surprise (also called Principle of Least Astonishment) is a folk principle with no single canonical source. It states that system behavior should match user expectations.

Relevant Change Drivers

PoLS doesn't address change drivers—it addresses human cognition:

User expectations, domain conventions, platform idioms
These aren't change drivers in the IVP sense
PoLS is orthogonal to IVP: understandability vs. evolvability

The Problem with PoLS

PoLS is subjective and non-actionable. "Least surprise" depends entirely on whose expectations:

A novice expects different behavior than an expert
A user from one domain brings different assumptions than another
Even the same person's expectations change over time

How do you objectively apply PoLS? You can't. It provides no method, no criterion, no way to resolve disagreements. Two developers can disagree about what's "surprising" with no way to arbitrate.

IVP doesn't address this: IVP and PoLS solve different problems. IVP provides objective criteria for structural organization (evolvability). PoLS addresses human comprehension (understandability). IVP can't make PoLS objective—but it doesn't need to. They're orthogonal concerns.

Relationship to IVP: Orthogonal

PoLS and IVP address fundamentally different concerns:

PoLS: Human comprehension—how understandable is the system? (subjective)
IVP: Structural evolution—how independently can concerns vary? (objective)

Neither implies the other:

An IVP-compliant system can violate PoLS (surprising behavior despite good structure)
A PoLS-compliant system can violate IVP (unsurprising but tightly coupled)

Practical note: PoLS is a reasonable goal but not a principle in any actionable sense. IVP, by contrast, provides criteria grounded in causal analysis of change drivers—though applying IVP still requires domain knowledge and judgment.

Conway's Law

What Conway Said (1968)

"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."
— Melvin Conway, "How Do Committees Invent?"

Relevant Change Drivers

Conway's Law maps organizational structure to architectural structure:

Team boundaries become module boundaries
The question: do team boundaries align with genuine domain change drivers?
If γ_team matches γ_domain, Conway alignment is beneficial
If γ_team ≠ γ_domain, Conway produces IVP-violating structure

The Problem with Conway's Law

Conway's Law is an observation, not a prescription—yet it's often treated as guidance. Several issues arise:

It doesn't guarantee quality: Even if architecture matches organization, the result can still be poorly designed. Mirroring doesn't imply correctness.
It limits innovation: Current team structures constrain the solution space. As Conway himself noted, "there is a class of design alternatives which cannot be effectively pursued" because necessary communication paths don't exist.
Path dependency traps: Existing systems impose structure on organizations. You're constrained by how you got here, not by what's optimal now.
Turf wars and silos: Teams become protective of their domains, leading to segmented knowledge and resistance to collaboration.
Inverse Conway is hard: Reorganizing teams doesn't immediately fix embedded architecture. The existing code "pushes back" against new structures.

How IVP addresses this: IVP provides the criterion for when Conway alignment is beneficial. If team boundaries match change driver boundaries, Conway's Law produces IVP-compliant structure—embrace it. If organizational structure doesn't align with change drivers (e.g., frontend/backend split when features span both), Conway's Law produces IVP-violating structure—resist it or restructure teams.

Relationship to IVP: IVP Explains When Conway's Law Is Beneficial

Conway's Law is an observation, not a prescription. IVP explains why it holds and when to embrace it:

When to embrace: If teams represent independent change drivers (Team A owns payments changing for payment reasons; Team B owns inventory changing for inventory reasons), architectural boundaries should match team boundaries. Conway's Law producing IVP-compliant structure is beneficial.

When to resist: If organizational structure doesn't align with change drivers (frontend/backend split but features require changes to both), Conway's Law produces IVP-violating structure. Every feature requires coordination.

Practical improvement: Ask: Do our team boundaries match our change driver boundaries? If not, consider restructuring teams or accepting the coordination overhead.

Tell, Don't Ask

The Principle

"Procedural code gets information then makes decisions. Object-oriented code tells objects to do things."
— Attributed to various OO practitioners

Rather than querying an object's state and acting on it externally, tell the object to perform the action itself.

Relevant Change Drivers

Tell, Don't Ask concerns data/behavior co-location:

γ_data + γ_behavior — same driver? Co-locate (IVP-2)
γ_data vs. γ_consumer — different drivers? Querying is appropriate
The question: does the behavior change for the same reason as the data?

The Problem with Tell, Don't Ask

Tell, Don't Ask can be misused to eliminate all getters, even when querying is appropriate. Martin Fowler notes: "I've seen it encourage people to become GetterEradicators." Sometimes you genuinely need to ask an object for information—reporting, serialization, display logic.

How IVP addresses this: The issue isn't asking vs. telling—it's where the knowledge lives. If the logic operating on data should change for the same reasons as the data itself, co-locate them (IVP-2). If query results are consumed by code with a different change driver (e.g., UI rendering), separation is appropriate.

Relationship to IVP: IVP Refines Tell, Don't Ask

Tell, Don't Ask is about co-locating behavior with data. IVP explains when this matters: when behavior and data share a change driver. External queries are fine when the consumer varies independently.

Command Query Separation (CQS)

What Meyer Said (1988)

"Every method should either be a command that performs an action, or a query that returns data to the caller, but not both."
— Bertrand Meyer, Object-Oriented Software Construction

Asking a question should not change the answer.

Relevant Change Drivers

CQS addresses predictability rather than change drivers per se:

γ_query vs. γ_command — may or may not be independent
CQS is about preventing hidden coupling, not organizing known variation
Orthogonal to IVP: CQS ensures predictability; IVP ensures evolvability

The Problem with CQS

CQS introduces complexity for operations that naturally combine both—popping a stack, generating a unique ID, acquiring a lock. Strict adherence requires awkward workarounds. CQS also complicates concurrent code where atomic query-then-command operations are necessary.

How IVP addresses this: CQS is about predictability, not change drivers. IVP doesn't directly address CQS. However, CQS violations often create hidden state changes—accidental coupling between querying code and state. When queries have side effects, consumers are coupled to variation they didn't expect.

Relationship to IVP: Complementary

CQS ensures predictability; IVP ensures evolvability. Both reduce accidental coupling, but through different mechanisms. CQS prevents queries from introducing unexpected variation; IVP organizes variation that legitimately exists.

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.

YAGNI (You Aren't Gonna Need It)

What Beck & Jeffries Said (1999)

"Always implement things when you actually need them, never when you just foresee that you need them."
— Ron Jeffries, XP co-founder

YAGNI emerged from Extreme Programming (XP), coined by Kent Beck.

Relevant Change Drivers

YAGNI concerns hypothetical vs. actual change drivers:

γ_actual — change driver that exists now, requires handling
γ_hypothetical — speculated future driver, may never materialize
Abstraction is premature if only one actual driver exists

The Problem with YAGNI

YAGNI provides no criterion for distinguishing "needed now" from "needed soon." Developers disagree about what's speculative:

"We'll definitely need this abstraction when we add the second payment provider"
"This validation layer will be necessary when requirements change"

Without a framework, YAGNI becomes a rhetorical tool—some invoke it to block useful preparation, others ignore it to justify over-engineering.

How IVP addresses this: Build abstractions when you identify actual independent change drivers. If you have one payment provider and no concrete second one, there's one change driver—no abstraction needed. When a second provider appears (a new change driver), then IVP-1 mandates separation. IVP grounds YAGNI in causal reality rather than speculation.

Relationship to IVP: IVP Operationalizes YAGNI

YAGNI says "don't build it until you need it." IVP says "don't separate until you have independent change drivers." Both resist premature structure, but IVP provides the criterion: genuine independent variation, not hypothetical future variation.

Four Rules of Simple Design (Kent Beck)

Kent Beck developed these rules while creating Extreme Programming in the late 1990s. The rules are in priority order.

Passes the tests

Reveals intention

No duplication

Fewest elements — Kent Beck, Extreme Programming Explained

Rule 1: Passes the Tests

The Rule: The code must work correctly—all tests pass.

Relevant Change Drivers: None directly. This is a correctness constraint, not a structural principle. Tests verify functional behavior, not evolvability.

The Problem: "Passes tests" is necessary but not sufficient. Code can pass all tests while being poorly structured, tightly coupled, and hard to evolve.

Relationship to IVP: Orthogonal. IVP addresses evolvability; passing tests addresses correctness. Both are necessary; neither implies the other.

Rule 2: Reveals Intention

The Rule: Code should clearly communicate its purpose. Names, structure, and organization should make the code's intent obvious.

Relevant Change Drivers: This addresses human cognition, not change drivers. Like PoLS, it's about understandability rather than evolvability.

The Problem: "Intention" is subjective—intention to whom? A domain expert reads code differently than a junior developer. The principle provides no criterion for resolving disagreements about clarity.

Relationship to IVP: Orthogonal. IVP addresses evolvability; revealing intention addresses understandability. IVP-compliant code can be unclear; clear code can violate IVP. Both dimensions matter independently.

Rule 3: No Duplication

The Rule: Each piece of knowledge should appear exactly once. Eliminate redundant code.

Relevant Change Drivers:

γ_A vs. γ_B — two pieces of code look identical but may change for different reasons
Same change driver → same knowledge → extract (IVP-2)
Different change drivers → different knowledge → keep separate despite similarity (IVP-1)

The Problem: Same as DRY—when is duplication "same knowledge" vs. "coincidentally similar code"? Without a criterion, teams extract "shared" code that later needs to diverge.

How IVP addresses this: Same knowledge = same change driver. If two pieces of code would change for the same reason (same authority, same business rule), they represent the same knowledge—eliminate duplication. If they'd change for different reasons, they're different knowledge despite structural similarity—keep them separate.

Relationship to IVP: IVP-2 provides the criterion. "No duplication" is correct when duplication represents the same change driver.

Rule 4: Fewest Elements

The Rule: Subject to the above rules, minimize the number of classes, methods, and other structural elements.

Relevant Change Drivers: This rule constrains structure—don't add elements beyond what's needed.

The Problem: "Fewest elements" can conflict with "reveals intention"—sometimes more classes with clearer names are better than fewer obscure ones. The priority ordering (intention > fewest) helps but doesn't resolve all tensions.

How IVP addresses this: Elements should map to change drivers. If you have three independent concerns, three classes is appropriate—not "too many." If you have one concern, one class is appropriate—additional structure is accidental complexity.

Relationship to IVP: IVP explains when elements are "necessary"—one module per change driver. "Fewest elements" means don't create structure beyond what change drivers require.

The Four Rules Together

The rules are valuable but incomplete without a unifying criterion. IVP provides that criterion for rules 3 and 4:

Rule	IVP Relationship
Passes tests	Orthogonal (correctness, not evolvability)
Reveals intention	Orthogonal (understandability, not evolvability)
No duplication	IVP-2 provides the criterion (same change driver = same knowledge)
Fewest elements	IVP defines "necessary"—one per change driver

Once and Only Once (OAOO)

The Principle

"Say everything once and only once."
— Kent Beck

This is Beck's formulation of DRY, emphasizing that each piece of knowledge should have exactly one authoritative representation.

Relevant Change Drivers

Same as DRY:

γ_A governs knowledge K → K should appear once, in the module for γ_A
Multiple representations of K create synchronization problems when γ_A triggers change

The Problem with OAOO

Same as DRY: What counts as "the same thing"? Two code fragments may look identical but represent different knowledge if they change for different reasons.

How IVP addresses this: "Same thing" = governed by the same change driver. If two pieces of code would change for the same reason (same authority, same business rule), they're the same knowledge—say it once. If they'd change independently, they're different knowledge despite structural similarity.

Relationship to IVP: IVP Operationalizes OAOO

OAOO is DRY by another name. IVP provides the criterion: knowledge identity is determined by change driver identity.

Agile Manifesto Design Principles

The Agile Manifesto (2001) was written by 17 software experts including Kent Beck, Martin Fowler, and Robert C. Martin. While primarily about process, three of its 12 principles directly address software design.

The Principles

"Continuous attention to technical excellence and good design enhances agility."
— Agile Manifesto, Principle 9

"Simplicity—the art of maximizing the amount of work not done—is essential."
— Agile Manifesto, Principle 10

"The best architectures, requirements, and designs emerge from self-organizing teams."
— Agile Manifesto, Principle 11

Relevant Change Drivers

The Agile Manifesto addresses the meta-level of how change drivers are discovered:

Teams closest to the work understand change drivers best
Design must accommodate change (agility requires evolvability)
Simplicity reduces the number of elements that can be coupled

The Problem with the Agile Design Principles

These principles are aspirational but not actionable:

"Technical excellence and good design" is circular—what is good design? The principle assumes you already know.
"Simplicity" has the same issue as KISS—no objective criterion for what's simple or what work is unnecessary.
"Emerge from self-organizing teams" describes who makes decisions but not how to make them correctly.

How IVP addresses this: IVP provides the criterion these principles lack. "Good design" = IVP-compliant structure. "Simplicity" = minimal accidental coupling (no coupling between independent change drivers). "Emergent architecture" works because teams close to the domain understand actual change drivers—IVP tells them what to do with that knowledge.

Relationship to IVP: IVP Operationalizes

The Agile Manifesto recognizes that design must support change but doesn't specify how. IVP provides the operational definition:

Technical excellence = modules with maximal cohesion (complete and pure knowledge embodiment)
Simplicity = no accidental coupling between independent change drivers
Emergent design = structure that reflects actual change drivers discovered during development

The reason "the best architectures emerge from self-organizing teams" is that those teams learn the actual change drivers through building. IVP tells them how to structure based on what they learn.

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.

What Defines a System-of-Systems?

Maier identified five characteristics distinguishing SoS from conventional systems:

Operational Independence: Constituent systems operate independently and usefully on their own
Managerial Independence: Constituent systems are managed independently
Evolutionary Development: The SoS develops over time; constituent systems join and leave
Emergent Behavior: The SoS exhibits capabilities beyond any individual constituent
Geographic Distribution: Constituent systems are often physically distributed

These characteristics create unique architectural challenges: you cannot mandate compliance, you cannot control constituent system evolution, and the "architecture" exists primarily as communication standards rather than physical structure.

Maier's Four Architecting Principles

1. Stable Intermediate Forms

The Principle: Evolution must proceed through stable intermediate states. The architect must pay attention to intermediate steps in a planned evolution of the SoS.

Relevant Change Drivers:

γ_SoS — the overall system-of-systems capability
γ_constituent₁, γ_constituent₂, ... — each constituent system's evolution
Evolution must maintain stability while individual constituents change

The Problem: SoS cannot be built monolithically—constituent systems already exist and evolve independently. A "big bang" integration approach fails because there's no stable state to operate from during transition.

How IVP addresses this: Each intermediate state must be IVP-compliant at its level. Constituent systems must maintain their cohesion (γ_constituentᵢ) while integrating with others. The SoS architecture must isolate constituent variation so that one system's evolution doesn't destabilize others.

Relationship to IVP: Stable Intermediate Forms is IVP applied to evolutionary architecture. Each intermediate must isolate independent constituent change drivers so evolution can proceed incrementally.

2. Policy Triage (Leverage Policy, Not Structure)

The Principle: Given limited influence over constituent system design, architects must carefully select strategic intervention points. The opportunities to influence constituent systems are limited; the points of influence must be chosen carefully.

Relevant Change Drivers:

γ_architecture — SoS-level architectural decisions
γ_constituent — individual system implementation details
The SoS architect controls γ_architecture but not γ_constituent

The Problem: SoS architects cannot mandate internal structure of constituent systems. Traditional architectural control (specifying interfaces, enforcing patterns) is unavailable. What levers remain?

How IVP addresses this: Focus on policies (what must be achieved) rather than structure (how to achieve it). Policies define change driver boundaries without prescribing implementation. A constituent system can vary internally (γ_constituent) while adhering to policies that maintain SoS coherence (γ_architecture).

Relationship to IVP: Policy Triage is IVP-1 applied through policy rather than structure. It acknowledges that you cannot control all change drivers—only establish boundaries between the ones you influence and those you don't.

3. Leverage Interfaces Through Standards

The Principle: The architect must leverage the interfaces to realize the capability that the SoS is assembled to deliver. In most cases, the architecture of a system-of-systems is communications—the set of standards that allow meaningful communication among components.

Relevant Change Drivers:

γ_standard — the communication protocol/standard (controlled by SoS architect)
γ_implementation — how each constituent implements the standard (independent per system)
Standards provide the stable abstraction; implementations vary independently

The Problem: With no control over constituent internals, the only leverage is at interfaces. But interfaces must be standardized to enable interoperability—hence standards become the architecture itself.

How IVP addresses this: Standards are the stable abstraction that isolates independent variation. Each constituent varies for its own reasons (γ_constituentᵢ); the standard ensures they can still communicate. This is DIP at the systems-of-systems scale: constituents depend on abstractions (standards), not on each other's implementations.

Relationship to IVP: Leveraging Interfaces is DIP/IVP-1 at the SoS scale. The standard isolates constituent change drivers from each other while enabling collaboration.

Example: The Internet's TCP/IP protocols are the classic example. No central authority controls how individual networks implement TCP/IP—only that they adhere to the standard. The architecture is the protocol suite.

4. Ensure Cooperation

The Principle: Collaboration between independent systems is only possible if system owners choose to collaborate. Incentivizing collaboration requires appreciation of motivations and non-technical aspects (commercial benefits, protection of IP).

Relevant Change Drivers:

γ_technical — technical requirements for integration
γ_organizational — business, political, and economic factors affecting cooperation
Both must be addressed; technical architecture alone is insufficient

The Problem: Even with perfect standards, constituent systems won't join an SoS unless their owners perceive benefit. Technical architecture must align with organizational incentives.

How IVP addresses this: This principle extends IVP beyond pure technical concerns. γ_organizational (stakeholder incentives, business models, IP concerns) is as real a change driver as γ_technical. SoS architecture must account for both—technical structures that ignore organizational change drivers will fail regardless of their technical elegance.

Relationship to IVP: Ensure Cooperation acknowledges that change drivers include organizational and economic factors, not just technical ones. IVP applies to sociotechnical systems, not just code.

What IVP Adds to SoS Principles

Maier's principles were derived empirically from observing successful and failed systems-of-systems. IVP provides the theoretical foundation:

SoS Principle	IVP Explanation
Stable Intermediate Forms	IVP-compliant structure at each evolutionary state
Policy Triage	IVP-1 via policy boundaries when structural control is unavailable
Leverage Interfaces	DIP/IVP-1 at the inter-system scale
Ensure Cooperation	Change drivers include organizational/economic factors

The key insight: at the SoS scale, the "architecture" is not physical structure but communication standards. This is IVP taken to its logical extreme—when you cannot control implementations, you can only control the boundaries between them. Standards define those boundaries, isolating constituent change drivers while enabling emergent capabilities.

INCOSE Systems Engineering Principles

The International Council on Systems Engineering (INCOSE) published a formal set of 15 Systems Engineering Principles in 2022, representing 30+ years of accumulated wisdom. Several are directly relevant to IVP:

"Complex systems are engineered by complex organizations." This principle acknowledges Conway's Law at the systems level. IVP explains when this alignment is beneficial (team boundaries match change driver boundaries) versus problematic (organizational structure forces inappropriate coupling).

"SE has a holistic system view that includes system elements and their interactions." This is IVP-2 at the systems level—understanding not just elements but how they vary together.

"Decision quality depends on understanding the system, enabling systems, and interoperating systems." This resonates with the Knowledge Theorem: quality decisions require understanding the knowledge embodied in each system and how that knowledge varies.

Cloud-Native Principles (2010s)

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

12-Factor App Methodology

The 12-Factor App methodology was developed by Adam Wiggins and the Heroku team circa 2011. It prescribes best practices for building cloud-native, scalable software-as-a-service applications.

The Factors

Codebase: One codebase tracked in version control, many deploys
Dependencies: Explicitly declare and isolate dependencies
Config: Store config in the environment
Backing Services: Treat backing services as attached resources
Build, Release, Run: Strictly separate build and run stages
Processes: Execute the app as stateless processes
Port Binding: Export services via port binding
Concurrency: Scale out via the process model
Disposability: Maximize robustness with fast startup and graceful shutdown
Dev/Prod Parity: Keep development, staging, and production as similar as possible
Logs: Treat logs as event streams
Admin Processes: Run admin/management tasks as one-off processes

Relevant Change Drivers

12-Factor explicitly separates infrastructure concerns from application logic:

γ_config — environment-specific configuration (Factor 3)
γ_backing_service — database, queue, cache providers (Factor 4)
γ_build vs. γ_release vs. γ_run — distinct lifecycle stages (Factor 5)
γ_app vs. γ_environment — application code vs. deployment context (Factor 10)

The Problem with 12-Factor

12-Factor is prescriptive but not principled. It tells you what to do but not why:

No unifying rationale: Why these 12 factors? Why not 10 or 15? The factors appear as a list of best practices rather than derivations from a principle.
Implicit assumptions: The factors assume cloud deployment, statelessness, and horizontal scaling. They don't explain when these assumptions don't apply.
Scope limitation: 12-Factor addresses deployment architecture but says nothing about domain modeling, business logic organization, or code structure.

How IVP addresses this: IVP explains why these factors work. Each factor isolates a different change driver:

Config (Factor 3) isolates γ_environment from γ_app—environment changes shouldn't require code changes
Backing Services (Factor 4) isolates γ_provider from γ_app—switching databases shouldn't require code changes
Build/Release/Run (Factor 5) isolates γ_build from γ_run—runtime changes shouldn't require rebuilding

Relationship to IVP: Domain-Specific IVP-1

12-Factor is IVP-1 applied to the cloud/operations domain:

Factor	Change Driver Separation
Config	`γ_app` ⊥ `γ_environment`
Backing Services	`γ_app` ⊥ `γ_provider`
Build/Release/Run	`γ_build` ⊥ `γ_release` ⊥ `γ_run`
Dev/Prod Parity	Minimize `γ_dev` vs. `γ_prod` divergence
Processes	Statelessness isolates `γ_instance₁` from `γ_instance₂`

12-Factor discovered these separations empirically by observing what causes production incidents: deployments that couple app code to environment, builds that couple to runtime, processes that couple to each other via shared state.

IVP explains the pattern: each factor prevents accidental coupling between independent change drivers in the operational domain.

GoF Principles

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

Relevant Change Drivers

GoF principles address implementation-level variation:

γ_interface vs. γ_impl — contract vs. mechanism
γ_parent vs. γ_child — inheritance couples these; are they truly dependent?
Composition allows γ_A and γ_B to vary independently

Program to an Interface, Not an Implementation

What GoF Said (1994):

"Don't declare variables to be instances of particular concrete classes. Instead, commit only to an interface defined by an abstract class."
— Gamma, Helm, Johnson, Vlissides

The Problem: This is essentially DIP at the variable/type level. The same issue applies: when is the abstraction worthwhile? Adding interfaces everywhere creates ceremony without benefit.

How IVP addresses this: Program to an interface when the implementation might vary independently. If you'll only ever have one implementation (single change driver), the interface adds indirection without isolation benefit. Multiple potential implementations = multiple change drivers = interface warranted.

Favor Composition Over Inheritance

What GoF Said (1994):

"Favor object composition over class inheritance."
— Gamma, Helm, Johnson, Vlissides

The Problem: GoF observed that "designers overuse inheritance" and that "inheritance breaks encapsulation." But when is inheritance appropriate?

How IVP addresses this: Inheritance creates tight coupling—subclasses vary for both their own causes and their parent's causes. Composition allows independent variation. Use inheritance when parent and child genuinely share a change driver (they evolve together). Use composition when they might diverge.

SOLID Principles

Single Responsibility Principle (SRP)

What Martin Said:

"A class should have one, and only one, reason to change."
— Robert C. Martin, Agile Software Development (2003)

Relevant Change Drivers:

γ_A vs. γ_B vs. γ_C — different stakeholders, different reasons to change
A class with multiple independent drivers violates SRP
A class with one driver satisfies SRP

The Problem with SRP: What counts as "one reason to change"? This is famously vague. The same class can be described as having one responsibility ("handles user data") or multiple ("validates users, persists users, formats user display"). The granularity is undefined—SRP provides no way to determine when you've reached "one" responsibility.

How IVP addresses this: A "reason to change" is a change driver—an independently varying source of change. Change drivers are concrete: the pricing team, the compliance department, the infrastructure group, an external API. You can identify them by asking "who requests this change?" or "what causes this to need modification?" If the answer is multiple independent authorities or concerns, the class has multiple responsibilities.

Relationship: SRP is IVP applied at class granularity.

If $|\Gamma(C)| > 1$ (class has multiple change drivers), SRP is violated
If $|\Gamma(C)| = 1$ (class has single change driver), SRP is satisfied

What IVP Adds: SRP's "reason to change" is vague. IVP makes it precise: a change driver is an independently varying source of change to domain knowledge. Different actors, different business domains, different technical concerns—these are independent change drivers.

When evaluating whether a class has "one responsibility," ask: Who or what causes this code to change? If the answer is multiple independent actors or concerns, consider splitting the class.

Open/Closed Principle (OCP)

What Martin Said:

"Software entities should be open for extension, but closed for modification."
— Robert C. Martin, "The Open-Closed Principle" (1996)

Relevant Change Drivers:

γ_core vs. γ_variant₁, γ_variant₂, ... — stable core, volatile variations
OCP warranted when γ_core ⊥ γ_variantᵢ (independent)
OCP overhead unjustified when everything changes together

The Problem with OCP: OCP provides no criterion for when to apply it. Making code "open for extension" requires upfront investment (abstractions, interfaces, plugin points). Applied everywhere, OCP leads to over-engineering. Applied nowhere, code becomes rigid. OCP tells you the goal but not when the cost is justified.

How IVP addresses this: Apply OCP when you identify independent change drivers. Core logic changes for cause γ_core; variations change for causes γ_v1, γ_v2, etc. If these are genuinely independent, OCP is warranted—the abstraction isolates independent variation. If they're not independent (everything changes together), OCP adds complexity without benefit.

Relationship: OCP is IVP-1 applied to stable/variant separation.

Core functionality F changes for cause γ_F
Variations V₁, V₂, ... change for causes γ_V₁, γ_V₂, ...
These causes are independent: γ_F ⊥ γ_Vᵢ

Applying IVP-1 separates stable abstraction from volatile implementations. Adding new implementations doesn't trigger γ_F, so the abstraction remains unchanged.

What IVP Adds: OCP explains the goal but not when to apply it. IVP provides the criterion: apply OCP when you identify independent variation between core logic and its variations. Not every piece of code needs extension points—only where independent change drivers exist.

Practical improvement: Before adding abstractions "for future extensibility," identify actual change drivers. Is there genuine independent variation? Or are you adding complexity for hypothetical future changes that may never occur?

Liskov Substitution Principle (LSP)

What Liskov & Wing Said (1994):

"Subtypes must be substitutable for their base types."
— Barbara Liskov & Jeannette Wing, "A Behavioral Notion of Subtyping"

Relevant Change Drivers:

γ_base vs. γ_derived — do they genuinely share a change driver?
LSP violation: client must handle γ_derived specially, introducing accidental coupling
False unification: elements appear unified but vary for different causes

The Problem with LSP: LSP is difficult to validate because you must inspect clients to identify problems—a model viewed in isolation cannot be meaningfully validated. Classic violations (Square/Rectangle, Penguin/Bird) show that "is-a" relationships in the domain don't always translate to valid inheritance. Trying to anticipate all client assumptions yields needless complexity.

How IVP addresses this: LSP violations create false unification—elements that appear unified actually vary for different causes from the client's perspective. When a subtype requires special-case handling, the client now varies for an additional cause (accommodating that subtype's behavior). IVP-2 requires genuine dependent variation; LSP ensures the abstraction doesn't lie about this.

Relationship: LSP is IVP-2's behavioral constraint for type hierarchies.

If derived type D violates base type B's contract, client K must add special-case logic:

if (instance is D) handleDifferently();

Now K varies for two independent causes:

γ_K: client's core responsibility
γ_D: accommodating D's non-substitutable behavior

This violates IVP-1.

What IVP Adds: LSP is often stated as a contract requirement. IVP explains why it matters: LSP ensures elements unified by abstraction genuinely vary for the same cause from the client's perspective. Without LSP, the abstraction is false unification—elements appear unified but actually vary for different causes.

Practical improvement: When designing inheritance hierarchies, ask: Do all subtypes genuinely change for the same reasons as the base type? If not, you probably have a misuse of inheritance.

Interface Segregation Principle (ISP)

What Martin Said:

"Clients should not be forced to depend on interfaces they do not use."
— Robert C. Martin, "The Interface Segregation Principle" (1996)

Relevant Change Drivers:

γ_client₁ vs. γ_client₂ — different clients with different needs
Fat interface forces γ_client₂ to depend on changes driven by γ_client₁
Segregate when clients have independent change drivers

The Problem with ISP: ISP tells you to segregate but not how to determine the boundaries. Should a UserService interface be split into UserReader and UserWriter? Or UserAuthenticator, UserProfileManager, and UserPreferencesManager? ISP provides no criterion for the right granularity.

How IVP addresses this: Segregate by change driver. Group methods that change for the same cause into one interface. If authentication methods change for security reasons while profile methods change for UX reasons, those are different change drivers—segregate them. The boundaries emerge from causal analysis, not arbitrary decomposition.

Relationship: ISP is IVP-1 applied to interface design—but note how it differs from Information Hiding/DIP.

ISP vs. Information Hiding/DIP:

Information Hiding / DIP	ISP
Separate contract from implementation	Separate contracts from each other
Vertical: client ↔ implementation	Horizontal: client₁ ↔ client₂
One contract hiding one implementation	Multiple contracts for same implementation

Information Hiding/DIP is about hiding how you work behind what clients can expect. ISP is about not forcing a single fat contract on clients with different needs—it's about having multiple role-specific contracts when clients have independent change drivers.

Fat interface I with methods for clients K₁ and K₂:

Methods for K₁ change for cause γ₁
Methods for K₂ change for cause γ₂
If γ₁ ⊥ γ₂, the fat interface couples K₂ to changes irrelevant to it

IVP-1 directs: segregate by variation cause.

What IVP Adds: ISP tells you to segregate interfaces but not how to determine segregation boundaries. IVP provides the criterion: group methods that change for the same cause.

Practical improvement: When designing interfaces, ask: Which clients use which methods? If different clients use different method subsets and those clients represent independent concerns, segregate.

Dependency Inversion Principle (DIP)

What Martin Said:

"High-level modules should not depend on low-level modules. Both should depend on abstractions."
— Robert C. Martin, "The Dependency Inversion Principle" (1996)

Relevant Change Drivers:

γ_high (high-level policy) vs. γ_low (low-level mechanism)
DIP warranted when γ_high ⊥ γ_low (independent)
DIP overhead unjustified when layers always change together

The Problem with DIP: DIP is often applied dogmatically—"always add an interface." But abstractions have costs: indirection, cognitive overhead, maintenance burden. DIP provides no criterion for when inversion is worthwhile versus when it's over-engineering.

How IVP addresses this: Apply DIP when high-level and low-level modules have independent change drivers. Business policy (γ_policy) and infrastructure (γ_infrastructure) typically change for different reasons—DIP is warranted. But if two layers always change together (they're not actually independent), the abstraction adds ceremony without isolation benefit.

Relationship: DIP is IVP-1 applied to layered class dependencies.

DIP differs from Information Hiding:

Information Hiding	DIP
Probabilistic: "hide what's likely to change"	Structural: "high-level depends on abstractions"
Economic judgment required	Prescriptive rule
Module-level principle	Class-level in layered architecture

Information Hiding asks "what's likely to change?" and makes an economic decision. DIP doesn't ask—it prescribes a dependency direction. The structural outcomes may look similar, but the reasoning differs.

How IVP relates: DIP implicitly recognizes that high-level policy and low-level implementation have independent change drivers. Business rules (γ_policy) change for business reasons; infrastructure (γ_infrastructure) changes for technical reasons. IVP-1 mandates their separation. DIP prescribes how to achieve it in OO: depend on abstractions.

What IVP Adds: DIP tells you to always invert dependencies across layers. IVP explains when this is actually necessary: only when the layers have independent change drivers. Not all dependencies need inversion—only those crossing change driver boundaries.

Practical improvement: Before introducing an abstraction layer, verify that the things on either side genuinely change independently. If they always change together, the abstraction adds complexity without benefit.

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.

Relevant Change Drivers

Package principles organize change at the deployment/release granularity:

γ_package_A, γ_package_B — classes that change together belong in same package
Packages with slow-changing drivers should be stable
Packages with fast-changing drivers should be volatile

Common Closure Principle (CCP)

What Martin Said:

"The classes in a package should be closed together against the same kinds of changes."
— Robert C. Martin, Agile Software Development (2003)

The Problem with CCP: What counts as "the same kind of change"? Without a definition, two architects can disagree about whether classes belong together.

How IVP addresses this: CCP is literally IVP-2 at package granularity. "Same kind of change" = same change driver. Classes governed by the same authority, same business rule, or same external dependency belong together.

Relationship: CCP is literally IVP-2 stated at package granularity.

Common Reuse Principle (CRP)

What Martin Said:

"The classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all."
— Robert C. Martin, Agile Software Development (2003)

The Problem with CRP: CRP can conflict with CCP. CCP says "group things that change together"; CRP says "group things that are used together." These aren't always the same.

How IVP addresses this: Both principles are approximations of IVP-2. Classes that change together (same change driver) should be packaged together. Usage patterns are a heuristic for shared change drivers, but causal analysis is more precise.

Relationship: CRP emerges from IVP based on usage patterns.

Reuse/Release Equivalence Principle (REP)

What Martin Said:

"The granule of reuse is the granule of release."
— Robert C. Martin, Agile Software Development (2003)

The Problem with REP: REP is circular without additional criteria—what should be released together? It tells you the granule should match but not how to determine that granule.

How IVP addresses this: Elements sharing a change driver share a release lifecycle. If pricing rules and inventory rules change independently, they should release independently.

Relationship: REP is IVP applied to release management.

Acyclic Dependencies Principle (ADP)

What Martin Said:

"Allow no cycles in the package dependency graph."
— Robert C. Martin, Agile Software Development (2003)

The Problem with ADP: ADP is a structural rule but doesn't explain why cycles are problematic. Breaking cycles sometimes requires introducing abstractions that add complexity.

How IVP addresses this: Cycles are problematic because they force co-variation. Packages in a cycle must deploy/test together even if they have independent change drivers. Breaking the cycle isolates independent variation—but only do it if the packages genuinely vary independently.

Relationship: ADP is IVP-1 applied to prevent false variation coupling.

Stable Dependencies Principle (SDP)

What Martin Said:

"Depend in the direction of stability."
— Robert C. Martin, Agile Software Development (2003)

The Problem with SDP: "Stability" is defined circularly in terms of dependencies. A package is stable if many things depend on it. But should they depend on it? SDP assumes the dependency structure is correct.

How IVP addresses this: Stability should reflect change driver frequency. Packages with slow-changing drivers (core domain concepts) should be stable; packages with fast-changing drivers (UI, integrations) should be unstable. Dependencies should flow from fast-changing to slow-changing.

Relationship: SDP is IVP-1 applied to stability management.

Stable Abstractions Principle (SAP)

What Martin Said:

"A package should be as abstract as it is stable."
— Robert C. Martin, Agile Software Development (2003)

The Problem with SAP: SAP conflates two different things: stability (resistance to change) and abstraction (generality). A package can be stable because it's mature and rarely needs changes—without being abstract. SAP assumes abstraction is the only path to stability.

How IVP addresses this: Abstractions are stable because they unify elements with different specific change drivers under a common interface. The abstraction changes only when the concept changes, not when specific implementations change. But concrete packages can also be stable if they embody slowly-changing domain knowledge.

Relationship: SAP ensures stability through IVP-compliant abstraction.

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.

Relevant Change Drivers

GRASP principles assign responsibilities based on knowledge ownership:

γ_knowledge — the class whose driver governs the knowledge owns the responsibility
γ_ui vs. γ_use_case — Controller mediates between independent drivers
γ_domain vs. γ_technical — Pure Fabrication isolates technical variation

Information Expert

The Principle: Assign responsibility to the class with the necessary information to fulfill it.

The Problem with Information Expert: "Necessary information" is ambiguous. A class might have the data but lack the right to change it. Information location doesn't always indicate responsibility ownership. Multiple classes may have access to the same information—which is the "expert"?

How IVP addresses this: The "expert" is the class whose change driver governs that knowledge. If pricing logic changes for pricing reasons, the class owning pricing knowledge should implement pricing behavior—even if other classes have access to the data.

Relationship to IVP: Information Expert is IVP-2 for responsibility assignment. The expert is determined by which class's change driver governs the knowledge in question.

Creator

The Principle: Assign class B the responsibility to create instances of class A if B aggregates, contains, or closely uses A.

The Problem with Creator: The heuristics (aggregates, contains, closely uses) don't always align. A class might aggregate A but not be the right creator if instantiation logic varies independently from aggregation logic.

How IVP addresses this: Creation responsibility follows change drivers. If A's instantiation requirements change for the same reasons as B's behavior, B should create A. If instantiation varies independently (e.g., different creation strategies), extract creation to a factory.

Relationship to IVP: Creator is IVP-2 applied to object instantiation. Co-locate creation with usage when they share a change driver; separate when they don't.

Controller

The Principle: Assign responsibility for handling system events to a non-UI class representing the overall system or use case.

The Problem with Controller: Where should controller logic live? Bloated controllers ("god classes") violate SRP. Too many small controllers fragment use case logic. The principle provides no sizing criterion.

How IVP addresses this: Controllers isolate UI variation from use case variation. The UI changes for presentation reasons; use cases change for business reasons. These are independent change drivers—IVP-1 mandates separation. The controller is the boundary. Size controllers by change driver scope, not arbitrary rules.

Relationship to IVP: Controller is IVP-1 applied to UI/domain separation. The controller exists because UI and domain have independent change drivers.

Low Coupling / High Cohesion

The Principles: Minimize dependencies between classes; ensure each class has focused purpose.

The Problem with Low Coupling / High Cohesion: These are goals, not methods. "Minimize" and "focused" are vague. How low is low enough? How focused is focused enough? Without criteria, these become subjective judgments.

How IVP addresses this: These are the goals IVP achieves. Low coupling = not coupling independent change drivers. High cohesion = grouping elements with the same change driver. IVP explains why these goals matter and how to achieve them with precise criteria.

Relationship to IVP: Low Coupling is the goal of IVP-1; High Cohesion is the goal of IVP-2. IVP provides the operational definition of both.

Polymorphism

The Principle: Use polymorphic operations instead of explicit type checking.

The Problem with Polymorphism: When is polymorphism warranted? Adding interfaces for single implementations adds ceremony. The principle doesn't distinguish necessary polymorphism from over-engineering.

How IVP addresses this: Type checking couples client code to each variant's change driver. Polymorphism encapsulates each variant's variation, so the client varies only for its own concerns. Apply polymorphism when variants have independent change drivers from the client.

Relationship to IVP: Polymorphism is IVP-1 applied via type abstraction. It isolates independent variation behind a common interface.

Indirection

The Principle: Assign responsibility to an intermediate object to mediate between components.

The Problem with Indirection: Every indirection adds complexity. When is the indirection worth it? "All problems can be solved by another level of indirection"—but this creates its own problems.

How IVP addresses this: Indirection creates a boundary between independent change drivers. The intermediate object absorbs variation from both sides. But indirection without independent variation is unnecessary complexity—apply only when genuine independence exists.

Relationship to IVP: Indirection is IVP-1 implemented via intermediary. Warranted only when the mediated components have independent change drivers.

Protected Variations

The Principle: Wrap instability points with interfaces; use polymorphism for implementations.

The Problem with Protected Variations: What is an "instability point"? How do you identify them? The principle assumes you already know what's unstable.

How IVP addresses this: "Instability points" are locations where independent change drivers meet. Protected Variations is essentially IVP-1 stated as a pattern: isolate elements that vary independently behind stable interfaces. Change driver analysis identifies the instability points.

Relationship to IVP: Protected Variations is essentially IVP-1 stated as a pattern. IVP provides the criterion for identifying instability points.

Pure Fabrication

The Principle: Create classes that don't represent domain concepts to achieve low coupling and high cohesion.

The Problem with Pure Fabrication: When is fabrication justified? Creating non-domain classes can obscure domain logic. The principle provides no criterion for when fabrication helps versus hurts.

How IVP addresses this: Sometimes change driver boundaries don't align with domain concepts. A "service" class might exist purely to isolate technical variation (database access, external APIs) from domain variation. Pure Fabrication acknowledges that IVP-compliant structure sometimes requires non-domain classes—but only when change drivers demand it.

Relationship to IVP: Pure Fabrication supports IVP compliance when domain boundaries don't match change driver boundaries.

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.

Relevant Change Drivers

FP principles often eliminate change drivers rather than organizing them:

γ_mutation — eliminated by immutability
γ_side_effect — eliminated by pure functions
γ_structure vs. γ_behavior — separated by higher-order functions
γ_what vs. γ_how — separated by declarative style

Immutability

The Principle: Once created, data cannot be modified. Changes produce new values rather than mutating existing ones.

The Problem with Mutability: Mutable state creates hidden variation—values can change unexpectedly, coupling code to temporal ordering and making reasoning difficult.

How IVP addresses this: Immutability eliminates a category of change drivers. Each piece of mutable state is a potential source of variation. Immutability removes these sources entirely—no variation means no independent variation to separate.

Relationship to IVP: Immutability achieves IVP compliance by elimination rather than organization. Fewer change drivers means fewer independence relationships to manage.

Pure Functions

The Principle: Functions that have no side effects and return the same output for the same input.

The Problem with Impurity: Impure functions have hidden dependencies—they read or write external state, coupling them to concerns outside their explicit interface.

How IVP addresses this: Pure functions achieve maximal cohesion by construction. A pure function:

Has no side effects (no accidental coupling to external state)
Depends only on its inputs (no hidden dependencies)

Pure functions naturally satisfy IVP-1: they can't accidentally couple to independent concerns because they have no access to them.

Relationship to IVP: Pure functions are IVP-1 compliant by construction. The function boundary perfectly isolates its change driver.

Referential Transparency

The Principle: An expression can be replaced with its value without changing program behavior.

The Problem without Referential Transparency: Refactoring is dangerous—you can't safely move or reorganize code because hidden dependencies might break.

How IVP addresses this: Referential transparency enables confident refactoring. If an expression can be replaced with its value, you can reorganize code without fear of breaking hidden dependencies. This supports IVP refactoring: separating concerns becomes safe when there are no hidden couplings.

Relationship to IVP: Referential transparency enables IVP-compliant reorganization. It guarantees that structural changes don't introduce accidental coupling.

Function Composition

The Principle: Build complex functions by combining simpler ones: (f ∘ g)(x) = f(g(x)).

The Problem with Monolithic Functions: Large functions mix multiple concerns, making them hard to change and test independently.

How IVP addresses this: Composition respects change driver boundaries. In f ∘ g, function f varies for its concerns, g varies for its concerns. Composition maintains independence: changing g's implementation doesn't affect f (as long as types match).

Relationship to IVP: Function composition is IVP-1 at the function level. Each function encapsulates its own change drivers, and composition preserves that isolation.

Higher-Order Functions

The Principle: Functions that take functions as arguments or return functions as results, enabling abstraction over behavior.

The Problem without Higher-Order Functions: Behavioral variation requires code duplication or complex conditional logic, coupling iteration structure to transformation logic.

How IVP addresses this: Higher-order functions isolate behavioral variation from structural variation. A higher-order function like map separates:

The iteration mechanism (structural concern) — changes for algorithm reasons
The transformation logic (behavioral concern) — changes for business reasons

These are independent change drivers. map encapsulates iteration so that transformation logic can vary independently.

Relationship to IVP: Higher-order functions are IVP-1 applied to behavioral abstraction. They isolate structure from behavior when these have independent change drivers.

Declarative Over Imperative

The Principle: Describe what to compute, not how to compute it. Let the runtime determine execution strategy.

The Problem with Imperative: Imperative code couples what you want with how it's achieved. Changes to performance strategy require modifying business logic.

How IVP addresses this: Declarative code separates intent from mechanism.

Intent changes for business reasons (γ_business)
Mechanism changes for performance/runtime reasons (γ_runtime)

These are independent change drivers. Declarative code expresses intent; the runtime handles mechanism. Query optimization in SQL, lazy evaluation in Haskell—these are IVP-1 in action.

Relationship to IVP: Declarative style is IVP-1 applied to intent/mechanism separation. Business logic and execution strategy have independent change drivers.

Algebraic Data Types (ADTs)

The Principle: Model data as sum types (alternatives) and product types (combinations), making illegal states unrepresentable.

The Problem without ADTs: Variation is implicit, scattered across conditionals. Missing cases cause runtime errors. Related variants aren't grouped.

How IVP addresses this: ADTs make variation explicit in types. A sum type like Result<T, E> = Ok(T) | Err(E) explicitly models two variation cases. Pattern matching forces handling both. This prevents accidental coupling—you can't ignore a variant.

Relationship to IVP: ADTs achieve IVP-2 by grouping related variations in a single type, while pattern matching ensures each case is handled by code that varies for that case's reasons.

Currying and Partial Application

The Principle: Transform multi-argument functions into chains of single-argument functions. Apply some arguments now, the rest later.

The Problem without Currying: Configuration and execution are entangled. Every call must provide all arguments, even when some are fixed for a context.

How IVP addresses this: Currying enables staged configuration.

configure :: Config -> Request -> Response

Partially applying config creates a specialized handler. Configuration varies for deployment reasons (γ_ops); request handling varies for feature reasons (γ_feature). Currying separates these change drivers across time—configure once, use many times.

Relationship to IVP: Currying is IVP-1 applied across time. It separates configuration (early-bound) from execution (late-bound) when these have independent change drivers.

Lazy Evaluation

The Principle: Defer computation until results are needed. Compute only what's actually used.

The Problem with Eager Evaluation: Definition and execution are coupled. You can't define infinite structures or separate "what to compute" from "when to compute it."

How IVP addresses this: Laziness decouples definition from execution. You define what a value is (its structure) separately from when it's computed (execution strategy). Definition varies for business reasons; execution timing varies for performance reasons.

Relationship to IVP: Lazy evaluation is IVP-1 applied to computation timing. Definition and execution have independent change drivers that laziness separates.

Summary: What IVP Brings

Classic Principles (1960s–1990s)

Principle	IVP Relationship	What IVP Adds
Separation of Concerns	IVP operationalizes	Objective criterion for "what's a concern"
Information Hiding	Complementary	IVP provides structure; IH provides economic criterion
DRY	Context-dependent	Criterion for when to deduplicate vs. keep separate
KISS	IVP operationalizes	Precise definition of "unnecessary complexity"
Law of Demeter	IVP-1 at method scope	Explains why train wrecks are problematic
PoLS	Orthogonal	Different dimension (understandability vs. evolvability)
Conway's Law	IVP judges	Criterion for when to embrace vs. resist mirroring
Tell, Don't Ask	IVP refines	Co-locate when behavior shares change driver with data
CQS	Complementary	CQS ensures predictability; IVP ensures evolvability

XP and Agile Principles (1990s–2000s)

Principle	IVP Relationship	What IVP Adds
YAGNI	IVP operationalizes	Build abstractions when actual change drivers appear
Passes Tests	Orthogonal	Correctness, not evolvability
Reveals Intention	Orthogonal	Understandability, not evolvability
No Duplication	IVP-2 criterion	Same change driver = same knowledge
Fewest Elements	IVP defines necessity	One element per change driver
OAOO	IVP-2 criterion	Knowledge identity = change driver identity
Technical Excellence	IVP operationalizes	Excellence = IVP-compliant structure
Simplicity	IVP operationalizes	Simplicity = no accidental coupling
Emergent Design	IVP operationalizes	Teams discover change drivers; IVP guides structuring

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

Principle	IVP Relationship	What IVP Adds
Stable Intermediate Forms	IVP for evolution	Each intermediate state must isolate constituent change drivers
Policy Triage	IVP-1 via policy	Policy boundaries when structural control unavailable
Leverage Interfaces	DIP/IVP-1 at SoS scale	Standards isolate constituent change drivers
Ensure Cooperation	Organizational change drivers	Technical + organizational factors both matter

Cloud-Native Principles (2010s)

Factor	IVP Relationship	What IVP Adds
Config	IVP-1 for environment	Separates `γ_app` from `γ_environment`
Backing Services	IVP-1 for providers	Separates `γ_app` from `γ_provider`
Build/Release/Run	IVP-1 for lifecycle	Separates `γ_build` from `γ_run`
Dev/Prod Parity	IVP alignment	Minimizes accidental `γ_dev` vs. `γ_prod` divergence
Processes	IVP-1 via statelessness	Isolates instances from each other

GoF Principles

Principle	IVP Relationship	What IVP Adds
Program to Interface	IVP-1 at type level	Apply when implementation might vary independently
Composition over Inheritance	IVP-1 for flexibility	Use inheritance only when parent/child share change driver

SOLID Principles

Principle	IVP Relationship	What IVP Adds
SRP	IVP at class level	Precise definition of "reason to change"
OCP	IVP-1 for stable/variant separation	Criterion for when extension points are needed
LSP	IVP-2 behavioral constraint	Explains why contracts matter (prevents false unification)
ISP	IVP-1 at interface level	Criterion for segregation boundaries
DIP	IVP-1 at layer level	Criterion for when abstraction is necessary

Package Principles

Principle	IVP Relationship	What IVP Adds
CCP	Literally IVP-2	Defines "same kind of change" as same change driver
CRP	IVP-2 via usage	Usage patterns as heuristic for shared change drivers
REP	IVP for releases	Change driver determines release granularity
ADP	IVP-1 for cycles	Explains why cycles are problematic (forced co-variation)
SDP	IVP-1 for stability	Stability = slow-changing drivers; dependencies flow toward stability
SAP	IVP via abstraction	Abstractions stable because they unify diverse implementations

GRASP Principles

Principle	IVP Relationship	What IVP Adds
Information Expert	IVP-2 for responsibility	Expert = class whose change driver governs the knowledge
Creator	IVP-2 for instantiation	Creation follows change driver alignment
Controller	IVP-1 for UI separation	Isolates UI variation from use case variation
Low Coupling	Goal of IVP-1	Don't couple independent change drivers
High Cohesion	Goal of IVP-2	Group elements with same change driver
Polymorphism	IVP-1 via interfaces	Encapsulates each variant's change driver
Indirection	IVP-1 boundary	Creates boundary between independent change drivers
Protected Variations	Essentially IVP-1	Isolate independent variation behind stable interfaces
Pure Fabrication	IVP-compliant structure	Non-domain classes for change driver isolation

Functional Programming Principles

Principle	IVP Relationship	What IVP Adds
Immutability	Eliminates variation	Removes a category of change drivers entirely
Pure Functions	Maximal cohesion by construction	No accidental coupling possible
Referential Transparency	Enables IVP refactoring	Safe to reorganize when no hidden dependencies
Function Composition	IVP-1 at function level	Preserves change driver isolation across composition
Higher-Order Functions	IVP-1 for behavior	Isolates behavioral variation from structural variation
Declarative over Imperative	IVP-1 for intent/mechanism	Separates business intent from runtime mechanism
Algebraic Data Types	IVP-2 for variants	Makes variation explicit; groups related cases
Currying	IVP-1 across time	Separates configuration from execution
Lazy Evaluation	IVP-1 for execution	Decouples definition from execution timing

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.

IVP Requires Domain Expertise

IVP's generality—separate elements that vary for different causes; unify elements that vary for the same cause—is both its strength and its challenge. Applying IVP effectively requires the ability to identify change drivers, and identifying change drivers requires domain expertise.

Consider a developer new to a codebase. They may not yet understand:

Who the stakeholders are and what each cares about
Which external systems the application integrates with
What regulations govern different parts of the business
Which parts of the system are stable versus volatile
The historical patterns of change revealed in version control

Without this context, "identify the change drivers" is not immediately actionable advice. The developer knows the principle but lacks the knowledge to apply it.

Established Principles as Actionable Heuristics

This is where the established principles prove their enduring value, despite presenting serious flaws in some cases. Each principle encapsulates domain-independent patterns that experienced practitioners have observed across many contexts:

SRP: "Does this class have multiple reasons to change?" Even without knowing the specific change drivers, asking this question prompts useful reflection.

DRY: "Am I duplicating knowledge?" This triggers examination of whether code fragments represent the same underlying concept.

SOLID: Each principle offers a specific lens for examining code structure, with concrete structural indicators (interface size, dependency direction, substitutability).

Law of Demeter: "Am I reaching through too many objects?" This is immediately observable without deep domain knowledge.

12-Factor: The factors provide a checklist applicable to any cloud-native application, regardless of business domain.

These principles remain immediately actionable because they operate on structural properties visible in the code itself, not on causal relationships that require domain understanding.

IVP + Established Principles: Complementary Tools

The relationship between IVP and established principles is not replacement but complementarity:

Situation	Best Approach
Experienced in the domain, understand change drivers	Use IVP directly for principled decisions
New to domain, learning the codebase	Use established principles as guardrails while building domain understanding
Principles conflict or seem to recommend different actions	Use IVP to resolve the conflict by analyzing change drivers
Explaining a decision to others	Use IVP to provide the why, established principles for the what
Teaching junior developers	Start with concrete principles, introduce IVP as the unifying explanation

Principles Provide Context IVP Lacks

Each established principle carries contextual information that IVP's generality cannot provide:

SRP focuses attention on the class level
ISP focuses attention on interface design
DIP focuses attention on layer boundaries
Law of Demeter focuses attention on method call chains
12-Factor focuses attention on deployment concerns

When combined with IVP's unifying insight, these principles become more powerful, not less. You understand not just what to do but why it works—and crucially, when to deviate because the change driver analysis suggests a different approach.

The Learning Journey

For practitioners at different experience levels:

Beginners: Learn the established principles. They provide concrete, actionable guidance that improves code quality immediately. Don't worry yet about the deeper unification.

Intermediate: Start noticing when principles conflict or when applying them "correctly" still produces poor results. This is the signal to look deeper—to ask why these principles exist.

Advanced: Use IVP as the foundational lens. Recognize established principles as constrained instantiations of IVP. Apply IVP directly when you understand the change drivers; fall back to established principles as reliable heuristics when domain knowledge is incomplete.

Expert: Teach both. Use established principles to make ideas concrete and accessible. Use IVP to explain the underlying unity and to guide decisions in novel situations where no established principle directly applies.

When No Existing Principle Applies

Sometimes you face a design decision where none of the established principles seem directly relevant:

A novel architectural pattern with no precedent in the literature
A domain-specific structure that doesn't map to standard OO or FP patterns
A cross-cutting concern that spans multiple traditional boundaries
An integration point between systems with incompatible assumptions

In these situations, IVP is always applicable. The question "What causes this to change, and are those causes independent?" applies universally—to code, configuration, infrastructure, data schemas, team structures, and any other aspect of software systems.

The established principles are IVP applied to common, recurring situations. When you encounter an uncommon situation, you can derive the appropriate guidance directly from IVP by analyzing the change drivers involved.

The Principles Remain Valid

Nothing in this article invalidates any of the principles discussed. SRP is still correct: a class should have only one reason to change. IVP simply explains what a "reason to change" is (a change driver) and provides the criterion for identifying when you've achieved it.

The principles represent five decades of accumulated wisdom about software structure. IVP doesn't replace this wisdom—it explains it, unifies it, and extends it to situations where the established principles don't directly apply.

Use IVP to understand why the principles work. Use the principles to make IVP actionable in your daily work. And when no principle seems to fit, use IVP directly.

Practical Takeaways

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.
Empirical, not predictive: Analyze your version control history. What actually changes together? What changes independently? Let causal reality guide structure.
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.
Cohesion primacy: Focus on cohesion, not coupling. Accidental coupling manifests as reduced cohesion (foreign change drivers). Maximize cohesion and coupling takes care of itself.
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.

References

IVP

Loth, Y. (2025). "The Independent Variation Principle - A Unifying Meta-Principle for Software Architecture"

Classic Principles

Beck, K. (2000). Extreme Programming Explained: Embrace Change. Addison-Wesley. (Four Rules of Simple Design, YAGNI, OAOO)
Conway, M.E. (1968). "How Do Committees Invent?" Datamation, 14(4), 28–31.
Dijkstra, E.W. (1974). "On the Role of Scientific Thought." EWD447.
Hunt, A. & Thomas, D. (1999). The Pragmatic Programmer: From Journeyman to Master. Addison-Wesley.
Lieberherr, K., Holland, I., & Riel, A. (1988). "Object-Oriented Programming: An Objective Sense of Style." OOPSLA '88 Proceedings, 323–334.
Meyer, B. (1988). Object-Oriented Software Construction. Prentice Hall. (CQS origin)
Parnas, D.L. (1972). "On the Criteria To Be Used in Decomposing Systems into Modules." Communications of the ACM, 15(12), 1053–1058.

Agile and Cloud-Native

Beck, K. et al. (2001). "Manifesto for Agile Software Development". (Agile Manifesto)
Beck, K. et al. (2001). "Principles behind the Agile Manifesto". (12 Principles)
Wiggins, A. (2011). "The Twelve-Factor App". Heroku.

Systems-of-Systems

INCOSE (2022). "Systems Engineering Principles". International Council on Systems Engineering.
Maier, M.W. (1998). "Architecting Principles for Systems-of-Systems." Systems Engineering, 1(4), 267–284.
Maier, M.W. & Rechtin, E. (2009). The Art of Systems Architecting. 3rd ed. CRC Press.

OO Design Patterns and Principles

Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. (GoF)
Larman, C. (2004). Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design. 3rd ed. Prentice Hall. (GRASP)

SOLID Principles

Liskov, B. & Wing, J. (1994). "A Behavioral Notion of Subtyping." ACM Transactions on Programming Languages and Systems, 16(6), 1811–1841.
Martin, R.C. (1996). "The Open-Closed Principle." C++ Report.
Martin, R.C. (1996). "The Dependency Inversion Principle." C++ Report.
Martin, R.C. (1996). "The Interface Segregation Principle." C++ Report.
Martin, R.C. (2003). Agile Software Development: Principles, Patterns, and Practices. Prentice Hall.
Martin, R.C. (2017). Clean Architecture: A Craftsman's Guide to Software Structure and Design. Prentice Hall.

Critiques and Alternatives

Dodds, K.C. (2019). "AHA Programming" — Avoid Hasty Abstractions.
North, D. (2022). "CUPID—for joyful coding" — Properties over principles.
Swizec, T. (2020). "DRY—the common source of bad abstractions".
Tedinski, T. (2019). "Deconstructing SOLID design principles".

IVP Paper: https://zenodo.org/records/18024111

My AI Deleted Important Files, So I Added Model Routing

Yannick Loth — Tue, 27 Jan 2026 19:49:01 +0000

Last week I asked Claude Code to "clean up the old summary files" and it deleted documentation I actually needed. Git saved me, but when I looked at the diff I noticed something important: the session was running on Haiku, which I'd forgotten I'd switched to. Haiku did exactly what I asked — and that was precisely the problem. I had given a vague deletion request to a model that doesn't stop to consider what "old" might mean in context.

The actual problem

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

Model	Cost	Good at
Haiku	cheap	fast, mechanical stuff
Sonnet	10x	thinking things through
Opus	75x	heavy reasoning

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.

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:

Parse intent: What does this request actually mean?
Assess risk: Is it going to delete or overwrite something?
Match to agents: Is there a specialized agent for this exact task?
Choose model tier: If not specialized, which model tier makes sense?
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.

Why Sonnet does the routing

Every request goes through router first — no exceptions, regardless of what model the session runs on or how obvious the task seems. This might seem like unnecessary overhead, so let me explain why it matters.

The core rationale:

Cost efficiency: Without a dedicated router, capable models tend to handle tasks themselves. If you start a session on Opus, Opus will eventually decide "I can do this" for some request — even trivial ones that Haiku could handle for 1/75th the cost. By forcing everything through router, execution always goes to the cheapest model that can actually handle the task.
Consistency: Because all routing decisions flow through one component, you get predictable behavior regardless of your session model.
Simplicity: The architecture stays clean — just one hop (router → executor) rather than chains of delegation.

Yes, spawning an agent adds latency. But the alternative is Opus burning tokens on tasks Haiku could handle just as well. In practice, the routing overhead pays for itself many times over.

Important caveat: CLAUDE.md instructions are advisory, not mechanically enforced. The model may still decide to handle simple tasks directly. That said, the routing works best when the model recognizes it should delegate — and in my experience, it usually does.

The "no direct agent spawning" rule: This is perhaps the most important constraint: the main session model must NEVER spawn agents directly. The ONLY valid flow is User request → router → agent. This applies even when the task seems obvious.

Why so strict? Because without this rule, capable models will rationalize shortcuts. They'll think: "This is clearly an Explore task, I'll just spawn the Explore agent directly." But that defeats the entire routing system. The router exists precisely to make these decisions — not the main session model. Put differently: the extra hop through router is not optional overhead — it IS the system.

There's also a fallback for edge cases. When Sonnet isn't sure how to route something, it delegates to router-escalation (which runs on Opus). This escalation agent analyzes the ambiguous request and spawns the appropriate agent directly. In practice, Sonnet handles 95%+ of routing decisions correctly; the remaining cases get escalated before anything runs.

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.

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.

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.

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.

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.

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.

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.

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?"

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.

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.

IVP Compliance Review: CodeAI - An AI-Designed Language Evaluated Against the Independent Variation Principle

Yannick Loth — Tue, 13 Jan 2026 12:33:21 +0000

AI disclosure: This article was generated by Claude Sonnet 4.5.

Executive Summary

This document presents a formal architectural review of CodeAI, a domain-specific language designed by large language models for backend service declaration. The review evaluates the language against the Independent Variation Principle (IVP): the principle that each concern should vary in exactly one place.

Key Findings:

✅ Strong IVP Compliance: CodeAI demonstrates excellent concern separation at the language design level
✅ Seven Independent Syntactic Domains: Infrastructure, data schema (relational), data schema (document), API surface, events, integrations, workflows, and scheduled jobs each have distinct variation points
✅ Enforced Separation: The language syntax prevents concern entanglement through mandatory structural boundaries
⚠️ Implementation Context: Review based on v1.0 codebase examples; runtime implementation not evaluated

Verdict: CodeAI exhibits IVP-compliant design that actively guides developers toward maintainable, loosely-coupled system architectures.

1. Introduction

1.1 Context

On LinkedIn, Barış Gömeç announced an experiment: "I asked AI to design a programming language that AI understands better." The resulting language, CodeAI (.cai), is a declarative DSL for backend service definition, with the entire implementation generated by Claude Opus 4.5.

The creator's premise: simpler declarative syntax optimized for LLM code generation. This review adds a complementary architectural lens: Is the language also optimized for human maintainability through concern separation?

1.2 The Independent Variation Principle (IVP)

The Independent Variation Principle, as formally defined by Loth (2025), states:

"Separate elements with different change driver assignments into distinct units; unify elements with the same change driver assignment within a single unit."

A change driver is any source of variation in a system—a reason why code might need to change. A change driver assignment maps each element (function, class, module, file) to the set of change drivers that influence it. IVP prescribes that elements varying for the same reasons should be grouped together, while elements varying for different reasons should be separated.

IVP generalizes classical principles like Single Responsibility (SRP), Don't Repeat Yourself (DRY), and Separation of Concerns (SoC) by providing a unified framework based on independent variability. It extends Parnas's information hiding criterion by making change drivers explicit.

IVP Compliance Criteria:

Identification: Can distinct change drivers be clearly identified?
Localization: Does each change driver have a single, well-defined unit where it varies?
Independence: Can one change driver change without forcing changes to units governed by different change drivers?
Non-Repetition: Is each change driver assignment expressed exactly once?

1.2.1 The Role of Programming Languages in IVP

A well-designed programming language should help developers achieve IVP compliance through its syntactic and semantic structure. Language design influences architectural quality by:

Providing Appropriate Abstractions: Offering constructs that map naturally to distinct change drivers (e.g., separate syntax for data schema vs. business logic)
Enforcing Boundaries: Making it syntactically impossible or awkward to mix concerns that should vary independently
Guiding Composition: Enabling references between concerns without requiring embedding (composition over containment)
Encoding Architectural Intent: Making the separation of concerns visible and explicit in the code structure

Languages that conflate multiple change drivers into single constructs (e.g., OOP classes mixing schema, validation, business logic, and persistence) make IVP compliance harder. Developers must fight against the language's default organization. Conversely, languages with distinct syntactic spaces for distinct concerns (like CodeAI's separation of entity, endpoint, workflow, integration, etc.) make IVP the path of least resistance.

This review evaluates whether CodeAI succeeds in this linguistic support for IVP. If it does, the language not only benefits LLM code generation (through semantic clarity) but also human maintainability (through enforced concern separation).

1.3 Review Methodology

This review analyzes CodeAI's syntax and semantics through:

Syntactic Domain Analysis: Identifying top-level language constructs
Concern Mapping: Mapping change drivers to language constructs
Variation Scenario Testing: Evaluating independence through hypothetical change scenarios
Comparison Analysis: Contrasting with traditional mixed-concern frameworks

Source Material: Official examples from the CodeAI repository (examples/ directory, v1.0).

2. Architectural Analysis

2.1 Identified Syntactic Domains

CodeAI provides seven top-level declarative constructs, each targeting a distinct architectural concern:

Construct	Syntax	Purpose	Lines of Code*
Configuration	`config { }`	Infrastructure settings	14-46
Entity	`entity Name { }`	PostgreSQL data models	41-193
Collection	`database mongodb { collection { } }`	MongoDB document schemas	19-242
Endpoint	`endpoint METHOD /path { }`	RESTful API definitions	200-617
Event	`event Name { }`	Event-driven messaging	623-711
Integration	`integration Name { }`	External service clients	422-555
Workflow	`workflow Name { }`	Multi-step business processes	560-782
Job	`job Name { }`	Scheduled background tasks	197-653

*Line ranges from example files: blog-api.cai, ecommerce.cai, mongodb-collections.cai, scheduled-jobs.cai

2.2 Concern-to-Construct Mapping

Each syntactic domain addresses a specific change driver: