The difference between a diagram and a contract is not fidelity — it is enforceability. A beautiful diagram nobody can violate is worth more than a perfect one nobody can check.
The quiet failure mode
Architectural erosion rarely happens in a dramatic moment. It happens one reasonable shortcut at a time, each individually defensible, none checked against the intended structure. By the time anyone notices, the cost of realignment exceeds the cost of living with the mess.
What a contract adds
A contract states the invariants the system must hold: which components may depend on which, where data may cross a boundary, what a module is allowed to know. Written this way, the architecture becomes something a machine can evaluate — continuously, on every change, without a human remembering to look.
An invariant that is not checked is an invariant that is not held.
The path from picture to program
- Name the boundaries you actually care about — not every box, just the load-bearing ones.
- Express the rules that must hold across those boundaries as constraints.
- Wire the constraints into the build so a violation fails fast, not in review.
- Let the design generate scaffolding, so the default path is the compliant path.
Compilation as a forcing function
When architecture compiles, drift becomes a build error instead of a discovery. The team stops relying on vigilance and starts relying on the tool. That is the whole game: make the correct thing the easy thing, and make the incorrect thing loud.
You do not enforce architecture with discipline. You enforce it with feedback that arrives before the mistake is expensive.