The underlying model can be thought of as the axioms. Going back to the Make example, it is trivial to think about axioms that describe the system's base abstra

The underlying model can be thought of as the axioms. Going back to the Make example, it is trivial to think about axioms that describe the system's base abstraction ("Let T be a set representing targets...."). Generally speaking, the theory backing a system gets used to prove a few things. 1. Given a set of requirements we want to make sure that our model for the system can satisfy those requirements. If you cast your model as a series of logical formulae, then you can certainly decide to frame questions of requirement satisfaction as proofs or derivations. 2. Does a given codebase implement the theory/model we postulated? This is generally a code or design review conversation, but could certainly be the subject of formal verification. 3. Given a new requirement (formula) can we handle it with the existing system? The third option feeds into another of Naur's points throughout the paper, namely that there are limits to the evolution of a theory before it must be tossed out. If you are thinking of some systems that you have maintained that have ceased to make any kind of sense (a programmer described a system we were working on as a Winchester House for this very reason), then you have reached the point where the theory is lost which is equated with program death in the paper. I do find it curious that you refer to design patterns and diagramming. In my mind, design patterns are a way to communicate implementation details to others working on the codebase. Saying a service uses dependency injection is like saying a building uses an A-frame. Useful information to be sure, but no one thinks of "use an A-frame" as an architecture in itself. Similarly, diagramming is always a method of communicating. The map is not the territory. Some methodologies (I'm looking at you, UML craze) forgot that but it this paper far predates that particular period of folly.