The product's knowledge graph records what does not vary between customers, which makes it the right starting inventory, at a level above the detail generating a screen needs. Semantic engineering governs change to those invariants below the line.
The starting inventory for any of this is the product's knowledge graph. The graph records what does not vary between customers: the capabilities the software offers, the workflows it supports, the entities it holds, and on the architecture side the API contracts and data models. Customer-specific detail is deliberately excluded, because it is low aperture and does not generalise. In the terms of section 1.3, the graph is a record of the product's domain value proposition.
This is the approach of semantic engineering, which models an application as a queryable knowledge graph that constrains what agents generate (Semantic Engineering, the author's programme). The part of the graph that matters here is the domain invariants: what does not vary between customers, and so what an architecture should keep beneath the multi-tenancy line.
The invariants still change, less often and with more at stake, since every tenant depends on them. Semantic engineering governs those changes through the graph. It records the application in four linked layers, covering what it does, how it looks and behaves, how it is organised and how it is built, and gives each layer a named custodian. When an invariant needs to change, agents traverse the graph to find everything the change touches and report the impact before any code is written. Generation agents then work under the structural constraint of the graph, validation agents check the result against the graph before a merge, and the graph is updated on every merge. Dialect engineering, described in section 9 before 9.1, governs change above the line.
That exclusion is what makes the graph the right inventory, and a level above what a specification needs.
| Knowledge graph | What generating a screen requires | |
|---|---|---|
| Aperture | High. Capabilities, workflows, entities, contracts | Low. What this specific screen does, in what order, with what validation |
| Varies per customer | No, by construction | Frequently |
| Authoritative source | Derived from the code | The code itself |
| Intended consumer | Human engineers and architects | A compiler, then an agent |
In new development, the low-aperture detail lives in tickets, user stories and specification files. In an existing product it lives only in the code. So handing an agent the knowledge graph and a design system and asking it to modernise the interface leaves it inferring the low-aperture detail from the code with no check on whether the inference was right.
There are two routes out. Trust the agent to read the current code and reproduce its behaviour, screen by screen, with human review at each step, which is the horizontal route and its linear cost. Or add a second layer of governance above the graph: an artefact that lets the agent verify its own output. That artefact is the subject of the next section.