Consequences and Application

The core theory — system tuple, change drivers, Γ-equivalence partition, and the partition theorem — has direct consequences for how software is structured, and it yields a concrete procedure for applying it.

1 Consequences

Several practical consequences follow from the core theory.

Change is contained. A module built as a Γ-equivalence class contains exactly the elements a change driver forces to change together, and nothing else. When a driver activates, the developer opens one module, changes what is inside, and nothing unrelated is disturbed.

Coupling is explained, not traded off. The partition removes the coupling that comes from misplacement: no element that changes together is split across modules, so no accidental cross-boundary dependency remains. The coupling that survives is the coupling the domain itself imposes between distinct driver classes — necessary coupling, not accidental.

Cohesion is a consequence of the partition. A module that is one Γ-equivalence class is pure (no foreign elements) and complete (no missing elements). That is maximal cohesion under the change-driver rule. Cohesion is not a separate knob to tune; it follows from grouping by the correct criterion.

Structure is read from the domain. The partition theorem says the compliant structure is determined once $\Gamma$ is known. Architecture becomes a reading of the domain’s change structure rather than a stylistic choice.

Wrong groupings are diagnosable. A module that mixes elements answering to different drivers, or that scatters one driver’s elements across several modules, violates a named condition. The theory names the violation and points at the fix: reunite the Γ-equivalence class.

2 The six-step application process

Applying IVP is an iterative design activity, not a mechanical algorithm. It follows a six-step cycle; you may revisit earlier steps as understanding deepens. The depth of analysis should be proportionate to the system’s expected lifetime and how often it changes.

1. Identify the elements. Choose the grain of artifact the analysis operates on — functions, classes, data structures, modules.
2. Identify the change drivers. Read the external conditions whose activation forces the system to change. This is discovery, not invention.
3. Map drivers to elements. Assign each element the set of change drivers that force it to change: build $\Gamma$.
4. Assess the current modularization. Compare the existing module structure to the Γ-equivalence partition. Name the violations: which modules are impure, which are incomplete.
5. Refactor toward compliance. Move elements so the structure converges to the partition.
6. Verify and iterate. Re-check the assignment and the partition as understanding deepens and as the domain changes.

3 What IVP does and does not tell you

IVP is a theory of where to place elements so that change is contained. It is precise about that and silent about several other things.

It does not tell you how to implement an element, only where it sits. It does not decide whether a system is correct — placement is not correctness. It does not optimize performance, security, or other quality attributes directly, though those can enter the analysis as change drivers. It is one criterion applied to one decision: where does each element belong.

Those limits are the subject of the theory’s formal treatment, not hidden in the small print. The premises and preconditions the theory assumes, and the gates that decide whether it applies to a system, are collected on the scope and validity conditions page.

4 Where the proofs live

The theorems — the partition theorem, the uniqueness result, the consequences derived from the axioms — are proved in the published papers: the partition and its cost-optimality in the paper on the Independent Variation Principle [1], the four conditions in the paper on cohesion and change propagation [2], the maintenance-cost minimum of the partition in the paper on change propagation and maintenance cost [3], and the purity and completeness properties in the paper on the nature of cohesion [4].

---

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

• The Independent Variation Principle — Zenodo, 2026 — doi:10.5281/zenodo.20794332
• Cohesion and Change Propagation: Four Necessary Conditions for Optimal Modularization — Zenodo, 2026 — doi:10.5281/zenodo.21362420
• Why Minimizing Change Propagation Minimizes Maintenance Cost — Zenodo, 2026 — doi:10.5281/zenodo.21362542
• On the Nature of Cohesion: Cohesion as Correctness Relative to a Partitioning Rule — Zenodo, 2026 — doi:10.5281/zenodo.21703193

All published papers

References

[1]

Y. Loth, “The independent variation principle.” Zenodo, Jun. 2026. doi: 10.5281/zenodo.20794332.

[2]

Y. Loth, “Cohesion and change propagation: Four necessary conditions for optimal modularization.” Zenodo, Jul. 2026. doi: 10.5281/zenodo.21362420.

[3]

Y. Loth, “Why minimizing change propagation minimizes maintenance cost.” Zenodo, Jul. 2026. doi: 10.5281/zenodo.21362542.

[4]

Y. Loth, “On the nature of cohesion: Cohesion as correctness relative to a partitioning rule.” Zenodo, Jul. 2026. doi: 10.5281/zenodo.21703193.