The business problem
Before anyone buys, finances, or builds on a commercial property, a civil engineer produces a Site Investigation Report, or SIR. It is a due-diligence document that covers the parcel's ownership, zoning, flood risk, wetlands, soils, topography, utilities, and the local ordinances that govern what can be built there. Lenders read it. Insurers read it. Lawyers definitely read it.
Producing one today is slow, expensive, and expert-bound. An engineer spends days to weeks pulling data from a dozen disconnected sources: county parcel systems, FEMA flood maps, USDA soil surveys, wetlands inventories, municipal code libraries. Then they transcribe all of it into a Word template by hand. Every hop is a chance to mis-key a number. Quality depends on which engineer you got and how much time they had that week.
And here is the part that stung my customer: the work is pure cost. Clients pay for the engineer's judgment, not for the copy-paste that consumes most of the hours.
Why the obvious answer is wrong
The obvious answer in 2026 is "point an LLM at it". The obvious answer is wrong, and the reason it is wrong shaped the entire architecture of this project.
A due-diligence report is a liability document. A hallucinated flood zone or a wrong parcel acreage isn't an embarrassing chatbot answer. It is a professional-negligence problem with a signature on the last page. That reframes the whole job: the goal is not "an AI that writes reports", it is a system that automates the SIR end-to-end while keeping every factual value on a deterministic, auditable path.
If you take one thing from this series, take this: the parts of the report a firm could be sued over have to behave like software, not like a chatbot. The model gets to write prose. Code decides facts. Part 2 is entirely about that boundary, but you'll see it in every stage below.
What the system does
Give the pipeline a parcel query, a street address, a coordinate, an APN, a block/lot, an owner name, or a drawn area, and it returns a fully cited Word draft of the SIR for an engineer's review. Not a chat answer: the same DOCX template the firm already uses, with every value carrying its source and every gap carrying its reason.
address, APN, owner…
Regrid parcels
in parallel
deterministic
model, then checked
for engineer
The four enrichment agents that run in parallel after the Resolver:
indexed ordinance corpus
flood, soils, terrain, wetlands
parking, signage, fees…
corpus first, web fallback
Reading the pipeline left to right
Here is the same flow as a walk-through, because each box hides a decision that matters later in the series.
| Stage | Who does the work | What comes out |
|---|---|---|
| Resolver | Deterministic code over the Regrid national parcel API | Real parcel records, or a disambiguation question for a human |
| Zoning & code retrieval | Agent over an indexed municipal-ordinance corpus | Zoning designation and dimensional standards, cited to the section |
| Geospatial & environmental | Agent over federal geospatial services | Flood zone, soils, terrain, wetlands, per parcel |
| Section research | Agent over the same ordinance corpus | Report topics like parking and signage |
| Utilities & contacts | Agent, corpus first, web research as a fallback | Utility providers and contacts, labeled by provenance tier |
| Consolidation | Deterministic code, no model | One merged, frozen Site object with conflicts flagged as divergences |
| Executive summary + QA | Model writes, code checks | Narrative in which every sentence maps to a cited value |
| Render | Deterministic code | The firm's own DOCX template, filled and cited |
Notice what the model is not doing: it never resolves the parcel, never picks the jurisdiction, never merges two agents' answers, never fills a template field. Those are the places a hallucination would end up in a lender's hands, so they are plain Python behind the tools.
It ran for real on Azure
None of this is a whiteboard. The whole run was validated live, end to end, on Azure: a real Durham, NC parcel went from address to rendered report through the hosted pipeline. Resolution, disambiguation, four enrichment agents, consolidation, QA, DOCX. Then the environment was deliberately torn down, because the entire thing is reproducible from one Bicep template and a runbook. Part 3 covers that deployment.
draft_for_engineer, never a final authority. The engineer's judgment stays the product. The pipeline only removes the transcription.
What's next in Part 2
Part 2 is the heart of the design: the model narrates, code decides. We go through the four rules that make the boundary real (every value carries provenance, every gap carries a reason, multiplicity is never collapsed, conflicts become divergences) and the grounding gate that checks the model's prose against the data it summarizes.
- Part 2: The model narrates, code decides
- Part 3: Hosted agents on Azure AI Foundry, identities, the shared Site object, humans in the loop
- Part 4: The data layer, authoritative sources wrapped as guarded tools
- Part 5: Trust engineering, what changes for the business, lessons and the roadmap