Building a governed AI system for engineering verification

01 · Physical problem

Owner requirements arrive as prose — sometimes a paragraph in a design standard, sometimes a line item in a spec section. Verifying that a project satisfies them means finding every model element, drawing sheet and schedule row a requirement actually applies to, and doing it by hand, requirement by requirement, across a model with thousands of elements.

Engineering evidence is fragmented. Decisions cannot be.

That's the constraint that shapes everything downstream: whatever system gets built has to reconcile fragmented, disagreeing sources into a single defensible answer, not just surface the fragments faster.

02 · Formal model

Every requirement gets compiled into a predicate over a defined population. "All exterior luminaires shall be mounted above 10 ft" isn't evaluated as a sentence — it becomes: identify the population P (which model elements this actually applies to), then check ∀x ∈ P, h(x) ≥ 10ft against each one.

Getting the population right is most of the difficulty. Too broad, and the system flags compliant elements as violations; too narrow, and it silently skips real ones. This is also where a requirement's ambiguity has to get resolved once, explicitly, instead of being re-interpreted differently by whoever happens to be reviewing it that week.

03 · Intelligent system

With population and predicate defined, an AI investigation layer traces the chain: requirement → sheet → room → element → schedule → source. It gathers the evidence a human reviewer would need — which drawing shows this fixture, which schedule row confirms its rating, which room it's actually located in — before anything gets marked compliant or not.

The Evidence Graph is a synthetic, smaller-scale version of exactly this traversal — drag it, hover a node, click a requirement to trace its full chain.

04 · Verified result

A fixed, auditable rule — not the model's confidence — makes the actual determination. Population, coverage and contradictions are counted, not estimated:

Representative example — not client data.

The Verification Playground runs a live version of this same investigate-then-verify sequence against a synthetic 14-fixture dataset — including the formula morphing from the universal statement to this exact counterexample.

05 · Production product

None of this is useful sitting in a separate tool an engineer has to remember to open. It ships as a Revit add-in: tracker, evidence, determination, report, and human review, inside the application the engineering team already has open all day.

Where this is headed

The same architecture is extending past a single Revit add-in into a broader cross-system control layer — obligations, work, evidence and approvals treated as one connected graph instead of separate tools that don't talk to each other.