Product
Site plan review in hours, not weeks.
Noetic is a regulatory intelligence platform for land development. It reads a submitted site plan against the actual local code — the same code city reviewers use — and returns the issues a municipal review would catch, with citations to the specific code sections.
The product runs in hours. The City of Austin’s formal review takes 12 to 18 months across six to nine cycles of comments and resubmittals. The first cycle alone — the completeness check — runs four to six weeks. Noetic runs it in 15 to 30 minutes.
How it works
The engine has read and structured Austin’s entire regulatory corpus: 27 codes, 265 review guide files across 12 disciplines, 23 incentive programs, and 13 approval pathways. It was trained on 200,000 categorized review comments extracted from 30,000 historic City of Austin site plan PDFs. Each discipline has a review guidebook that encodes what reviewers actually look for — not a rephrasing of the code, but the operational rules that come out of years of reviews.
When a civil engineering firm uploads a site plan, the system parses the drawings and reports, runs each discipline check, and produces a list of findings with the exact code section, the location on the plan, and a citation to the underlying regulation. An engineer reviews the findings and decides what to fix before submission. Noetic does the research; the engineer keeps the judgment.
Recall against City of Austin reviewers
In independent validation with the City of Austin across 10 review disciplines, Noetic identified 129 of 156 issues the city’s own reviewers found on real submitted plans — 83% overall recall. The breakdown by department:
| Department | Matched | Recall | Notes |
|---|---|---|---|
| Drainage Engineering | 6 / 6 | 100% | Perfect match; agent caught additional details. |
| Floodplain | 12.5 / 14 | 90% | Validation 50% complete. |
| Transportation | 6 / 7 | 85% | One more complicated plan in review. |
| Energy | 22 / 26 | 85% | One more U3 plan in review. |
| Site Plan | 35 / 42 | 83% | Two misses tied to missing GIS layers — resolved. |
| Water | 5 / 6 | 83% | Validation 80% complete. |
| Environmental | 25 / 31 | 81% | Two require reviewer judgment. |
| Parks | 7 / 9 | 78% | One more recent plan in review. |
| Fire | 3 / 4 | 75% | — |
| City Arborist | 7.5 / 11 | 68% | Two misses tied to missing GIS layers. |
| Total | 129 / 156 | 83% | Across all 10 disciplines. |
These numbers are recall against the city’s own reviewers, not against a synthetic answer key. Some disciplines outperform city reviewers on specific items — Drainage caught additional issues the city missed. Disciplines where recall trails the headline number are typically constrained by missing GIS layers (GIS coverage has since been broadly expanded) or reviewer judgment that no automated system can substitute for.
What ships today
The same review engine packages into three customer-facing products. They share the underlying analysis; the format and audience differ.
- Site Plan Review — pre-submission compliance review for civil engineering firms. Run the same checks the City of Austin will run, before the plan goes in. Used today by Pape-Dawson, Dunaway, and other national civil engineering firms.
- Site Intelligence Reports — pre-acquisition regulatory analysis for developers, investors, and brokers. Surfaces the constraints, programs, and approval pathways that determine whether a site pencils.
- Regulatory Automation — AI review and triage for municipal departments. The product behind the City of Austin pilot.
What it doesn’t do
Noetic doesn’t replace a city reviewer or a civil engineer. It runs the repetitive parts of the analysis — the parts that ask the same question of every plan — and surfaces the findings for a human to review.
Noetic isn’t a permit expediter. It doesn’t shepherd plans through city hall, lobby reviewers, or call in political favors. It improves the plan before it’s submitted; the engineer and the city do the rest.
Noetic isn’t a generic AI overlay. Austin’s code is read and structured, not retrieved from a vector store with no grounding. The system points at specific code sections because it has read them.