From engineering reality to deployable software.

A requirement is one sentence. Answering it means reconciling three records that disagree.

An owner requirement arrives as prose — a paragraph in a design standard, a line in a specification. Satisfying it is not a reading task. It means resolving which elements the sentence actually applies to, then finding every model element, drawing sheet and schedule row that could settle the question, across a project with thousands of elements and years of edits.

The hard part is that the same fact has more than one home. A fixture's mounting height exists in the model as a parameter, on a sheet as a dimension and in a schedule as a value. Those three can disagree, and often do. A system that only retrieves faster produces three answers. A reviewer needs one, plus the reason the other two lost.

The difficulty is not limited to the number of documents. Each discipline names its objects differently, keeps evidence in a different place and hands its decision to a different reviewer. Domain modeling provides the shared vocabulary that lets those sources be connected without flattening their meaning.

The system cannot merely surface fragments faster. It has to reconcile disagreeing sources into a single determination a named person can inspect, challenge and sign.

Investigation is broad and probabilistic. Determination is narrow and governed.

Two things had to be true at once. The system needed to search a large, messy project the way a good engineer does — following a requirement into a room, into a fixture, into a schedule row, into the sheet that shows it. And it needed to produce results a firm could stand behind, which a probabilistic system cannot do on its own.

So the architecture splits on authority rather than on technology. Below the boundary, AI investigates: it searches, interprets language, explains a finding and proposes remediation. Above it, deterministic engines own every official automated result — the population, the predicate, the coverage, the contradictions and the determination — and each evaluation is recorded as a run rather than overwritten in place.

Architectural decisions this forced

• Deterministic authority for every official automated result.
• AI scoped to search, explanation and remediation guidance, visibly labelled as such.
• Evidence provenance and coverage recorded per requirement, not summarized at the end.
• Immutable evaluation runs, so “why did this pass last month?” has an answer.
• Human review kept separate from automated status, in the interface as well as the schema.
• Multi-version Revit compatibility isolated behind a thin adapter.
• Local and on-premise deployment paths, because the model may not leave the network.
• Release and installer validation treated as technical delivery, not as a packaging afterthought.

Build inside the workflow, not beside it.

Revit is a long-running desktop application with its own document lifecycle, transaction model, external event queue and threading rules. An add-in that treats the document as a database it can query from anywhere works in a demo and fails intermittently when the model is busy, a command is still active or a document changes underneath it. Host access stays behind commands, external events and small observable transactions; domain logic receives stable data instead of reaching through the host from everywhere.

The visible interface is only one part of the integration. The important boundary is between host-owned state, structured domain data, AI-assisted investigation and deterministic validation. Commands, transactions, runtime health and release controls make that boundary observable to the people who operate the system.

Fig. 02Engineering software integration surfaceCapability model

Extraction and model health

Extraction is discipline-scoped — All, Electrical, Mechanical, Plumbing and Lighting — because a check that silently walks the whole model produces findings nobody owns. Model-health checks run first, since a requirement cannot be evaluated against a model that is internally broken:

• Elements without levels
• Unconnected fixtures
• Fixtures missing circuits
• Panels without upstream sources

Investigation runs across the extracted context rather than over raw files: requirement → sheet → room → element → schedule → source. The agent assembles what a reviewer would have had to assemble by hand, and stops at the boundary.

Fig. 03Investigation pathDiagram

C# · .NET · Revit API · WPF/MVVM · Python · APIs · structured data · Docker · PowerShell · React/TypeScript · CI/CD

The host-level constraints behind these decisions — the version seam, QA against a moving model, the five failures that change the architecture and the release loop — are documented separately.

Open the Revit host reference →

The evidence model is a graph, because engineering facts are relational.

A requirement scopes a population. A drawing informs a room. A room contains an element. A schedule gives that element a value. A predicate evaluates it. A counterexample drives the finding. Keeping those relations explicit is what lets a reviewer inspect the path instead of trusting a paragraph generated at the end — and it is what keeps the result reconstructable after the model is reloaded and the original conversation is gone.

Getting the population right is most of the difficulty. Too broad and the system reports compliant elements as violations; too narrow and it silently skips real ones. Formalization makes that choice once, visibly, instead of letting a different reviewer or a different prompt reinterpret the same sentence later.

Fig. 04Evidence systemDiagram

The workbench below is a smaller, synthetic version of that traversal, built so a reader can move from the graph to the compiler and then run the fixed rule without losing the reasoning chain. Same population, same source path, same predicate, three views.