The four groups are not isolated. They interact, and the type of interaction depends on the group combination.
Mathematical constraints bound behavioural tendencies: Hofstadter’s Law (L7) says estimates are always wrong — but Amdahl’s Law (L1) gives you the hard upper bound on what is achievable. Even perfect estimation cannot help if the proposed architecture violates a physics constraint. Check mathematical laws first; they close the solution space before behavioural tendencies matter.
Design principles prevent behavioural failures: Conway’s Law (L10) predicts that team structure will produce a matching architecture. Gall’s Law (L11) says evolve don’t redesign. Together they describe a strategy: design teams to produce the architecture you want, then evolve it — do not attempt to build complex systems from scratch.
Statistical heuristics calibrate where to apply the others: The Pareto Principle (L15) tells you where to look first. 80% of latency typically comes from 20% of code paths. Apply Amdahl’s Law to those paths. 80% of failures typically come from 20% of components. Apply Q2 (How does it fail?) to those components.
Goodhart’s Law (L9) threatens all metrics-based applications of the others: Any time you measure compliance with a law (e.g., “our architecture review checks Amdahl”), Goodhart’s Law predicts that the measurement will be gamed. The engineering response: measure outcomes (latency, error rate) not compliance (review checkbox).