In Part 2 we said the model leads and the code follows. That raises the obvious question: what is this model, and who works on it? Start with the problem everyone feels right now. AI generates code faster than anyone can read it. Teams struggle to keep up with reviewing it, let alone understanding it.
That's the wrong place to fight. In Part 2 I said nobody will be reviewing code anymore. Then what do we review? The design. Design comes first. If you get the design right, you sidestep most of the review problem, because you review the design, not the code.
But abstraction doesn't mean leaving out the business details. That's where it used to go wrong. Our diagrams stayed at the high level: a context diagram, some components, a few call chains. The details lived in code and in prose. That no longer works.
The design has to go up, into business design: how the business actually runs its processes. And it has to go down, into detailed design: what an entity may do and when, and how an algorithm decides. Abstract enough to review. Complete enough to build from.
The model is not a diagram habit. It is a set of artefacts, each with one job. The main ones:
On the technical side, each system interaction gets a call chain: which component calls which.
None of this is new. We know about state machines, and we don't use them. We put a status flag on a database row instead, and another column next to it when the flag isn't enough. We know a flowchart can model an algorithm, and we choose to code it right away. We move straight to code instead of thinking and modelling.
So don't iterate towards the model. Start with it. Use the spec, if you have one, to come up with the model, and then let the model be the truth.
Domain knowledge stops being context. It becomes the input format.
Take one small requirement from the Master Builder Clinic, our hands-on course in business design and modelling: a customer creates an account. It starts as a business process. Onboard customer, in BPMN: the customer requests an account, verifies the email, logs in, and optionally records preferences. Two lanes, customer and system, so who does what is on the page and not in someone's head.
The first system step is refined into a system interaction, still in business words: validate the email; if it's valid, create a pending account, store it and send the event; if not, return a validation error. Next to the diagram sits a table of steps, inputs and outputs, and a list of open questions. One of them: what happens when email validation fails? The process has no error path yet. That gap is recorded in the model, visible to everyone, instead of in one person's memory.
The model doesn't only hold what we decided. It holds what we haven't decided yet. Then the first technical view: the call chain. Which component calls which, in what order. The manager validates the email, creates the pending account, asks the access layer to store it, and publishes the event. That lines up one to one with the code. The first line of the method is the email check; the next is the if-statement.
The call chain is the design, not the architecture style. Map the same steps onto a domain-driven design and the manager becomes an application service, the email check a value object, the pending account an aggregate, and the access layer a repository. Same steps, same inputs, same error path. Only the target changes.
And underneath, all of it is one graph. Every process, interaction, call chain and method is a node; every link between them is an edge. For one product, that is 1,401 nodes and 1,768 edges, not drawn by hand but extracted from the diagrams and pages themselves. Change the requirement and you change the first box. Everything downstream is connected to it, so you can see what the change touches before you touch it.
Remember the F-16 from Part 1, taken apart and scanned to rebuild a model nobody kept. This is the alternative, in software, on a product that exists.
The views are the human interface. People think in pictures: a process, an interaction, a call chain, a state machine. Business people can read the process. Architects can read the call chain. Nobody reads the raw graph.
The AI reads the graph. Ask it "if we change this interaction, what does it touch?" and it walks a handful of edges: the process, the interaction, the call chain, the manager, the access component, the state machine. Exact, and cheap. Hand it a four-hundred-page spec instead and it reads all of it, guesses the links, and gets some of them wrong.
We tested that. We gave an LLM the spec of a calculation engine, the component that holds one piece of business logic, and asked for a flowchart of its logic. It came back with something that made no sense: an endpoint in the middle of the flow, edges dangling. Then we gave it the code that had been generated from the same spec, with the same prompt. That flowchart made complete sense. I could take it to a domain expert and ask: is this what the software should do? We saw the same with a state machine.
Even a very capable model misread the spec. The code worked because it is precise. A flowchart is just as precise, and a domain expert can read it. So why keep the spec as the artefact? Keep the flowchart, and build from that.
Once the model is a graph, every architect's question becomes a query. Pick any element and look at its neighbourhood: which component owns it, which business interaction it realises, which code implements it, which rules hang on it, and which questions are still open.
Blast radius, ownership, coverage, open questions: one query against one graph. Not a meeting. Not an archaeology exercise. And some checks move forward in time. Does this step have the customer id it needs at this point in the flow? It doesn't, so the model flags it, before anyone writes code. We have always found those problems in the code. Now we can find them in the design.
This is what it means for the model to be the source of truth: you can ask it questions, and it answers.
That model needs a place to live, and that place is not a coding harness. It is a design surface: one place where the architect manages business design, system design and detailed design. Every view is drawn from the model, and every edit goes back into it. The architect works in pictures; the model stays consistent underneath.
Under the views sits a shared language. The Semantic Model is the schema: the types (business goal, actor, rule, process, system interaction; component, call, contract) and how they may relate. Each project's design is written in that language, as its own System Model. And when the system runs, its measurements point back to the design. They read it; they never change it.
We're not alone in building this. Several teams in our community are working on their own version of the tool. The agent frameworks will keep improving without us; everybody is tuning the flow. Almost nobody is working on the model. Either we're missing something, or there's a very big opportunity here.
Is there evidence? At the last two Master Builder Clinics, we modelled first: business processes, system interactions, contracts, entities. Then we gave the models to an AI and said: don't build it yet, just do a try run and tell us what you understand. It read the BPMN, followed the process to the system interaction, and knew what to validate and what to answer.
After three and a half days there was a working application. Twice, with two different rooms. And nobody in the room wrote code. That was the first stake in the ground in Part 2. Modelling did not cost us time. The models were the work. And twice matters more than fast: one run is a lucky team, two is a process.
What exists today is the model, and it is real. The deterministic compiler from Part 2 is the work ahead.
Your CEO is asking what to do with AI, and is scrolling the same feeds you are. Don't be silent. Be the adult in the room.
That is what we teach in the Master Builder Clinic: business design and modelling, from the process down to the detail, so the code can follow.
The tools change every week. The model doesn't.
