The stage most systems skip
Most engineering software goes straight from "physical problem" to "production product" — a form, a database, a UI. It skips formalization and verification entirely, which works fine until the problem is ambiguous enough that two reasonable people would fill out the form differently. Complex engineering domains are exactly that ambiguous.
Physical problem
The starting point is never clean data. It's requirements written in prose, drawings that disagree with the model in small ways, schedules maintained in a spreadsheet nobody else has access to. Treating this stage as a data-cleaning problem is a category error — the fragmentation is not noise to be removed, it's the actual shape of how engineering information exists before someone does the work of organizing it.
Formal model
This is the stage that determines whether everything downstream is trustworthy. A requirement like "all exterior luminaires shall be mounted above 10 ft" becomes a population — the specific set of elements it applies to — and a predicate over that population: ∀x ∈ P, h(x) ≥ 10ft. Once a requirement is a predicate over a defined population, it's checkable. Before that, it's an opinion.
This is also where scope discipline matters most. A population definition that's too broad produces false failures; too narrow, and it silently misses real ones. Getting the population right is usually harder than evaluating the predicate once you have it.
Intelligent system
With a formal model in place, an AI agent has something concrete to investigate: trace the population through the model, the drawings and the schedules, and assemble the evidence a human reviewer would need to trust the result. This is the stage where "AI" does real work — not answering the question, but building the case.
Verified result
The predicate gets evaluated against the assembled evidence by a fixed, auditable rule — not the model's confidence score. When something fails, the counterexample is explicit: which element, what value, why it doesn't satisfy the condition. ∃x ∈ P : h(x) < 10ft is a stronger statement than "looks non-compliant," because it points at exactly what to fix.
Production product
None of the above matters if it doesn't ship inside the tool the engineer already has open. A determination that requires switching applications to see gets ignored. The last stage is not a UI wrapper around the previous four — it's the reason the previous four were worth doing.
The architecture canvas below is the general-purpose version of this: four layers, click any component for what it does and where it connects. The Engineering Intelligence case study walks the same five stages through one real system, in more depth than fits here.
The Engineering Intelligence Loop
The five stages above describe the shape of the work once. In production the same shape runs continuously: a requirement gets interpreted, formalized, checked against evidence and shipped as a decision — and what happens in the field afterward returns to improve the system, rather than disappearing once the determination is made. It's a closed loop, not a one-way pipeline.
