Ask the ordinance a question. Get the passage it came from.
Setbacks, height limits, FAR, parking minimums and permitted uses live in municipal legal text, not in a table. This turns that text into two things a system can actually use: natural-language answers that carry their own citations, and structured dimensional data extracted at scale with a full audit trail.
The rules that decide a project are prose
Everything else about a parcel is a number in a database. What you are legally allowed to build on it is a chapter of municipal code with cross-references.
It reads like law
Because it is. A single answer can depend on a district, an overlay, a use table, a definitions section and an exception three chapters away.
Every city writes its own
Same concepts, different words, different structure, different numbering. Nothing transfers between municipalities.
A chatbot will guess
Ask a general-purpose model about a setback and it will answer confidently from nothing. In a regulatory context that is worse than no answer.
It does not scale by reading
Screening one site by hand is an afternoon. Screening a market is a headcount problem, and the answer goes stale when the code is amended.
Answers for people, structure for systems
These are different jobs and they are built differently — deliberately. One answers a question in context; the other turns a whole municipality into rows.
Retrieval-augmented Q&A
A question retrieves the most relevant ordinance passages first; the model is then constrained to answer from those passages alone, and the passages come back with the answer. Built for the moment someone needs to know whether a thing is allowed here.
- Full-text retrieval with BM25 ranking over RAG-sized chunks
- The response carries exactly the passages given to the model
- Retrieval miss returns a "couldn't find" answer rather than an unaided guess
- Answers exportable as JSON, CSV, Markdown or plain text
In-database AI extraction
A SQL pipeline that ingests providers, runs model inference inside the database, and writes structured rows — dimensional standards per district, permitted-use classifications, and the full prompt and raw response beside each one.
- Setbacks, height, FAR and density as typed columns per district
- Use permissions classified as permitted, conditional, prohibited, accessory or unclear
- Every prompt, raw response and parsed result retained as an audit trail
- Exports to CSV, GeoJSON or PostGIS
* Figures describe the current South Florida corpus build. The corpus is a snapshot, not a live mirror — it is produced by a separate acquisition pipeline and refreshed by rebuilding, so a recently amended ordinance is only present after the next build. Ask which municipalities and which build date apply to your markets.
Every answer arrives with its evidence
Retrieval runs first and the model is constrained to what it returned. The
sources array on the response is not a bibliography added
afterwards — it is exactly the set of passages the model was given, which is what makes
an answer checkable rather than merely plausible.
- Auditable by construction — read the answer, then read the ordinance text it was built from, in the same response.
- Refuses rather than invents — when retrieval finds nothing relevant, the endpoint says so instead of letting the model fill the gap.
- Batch questions — up to ten at a time, with export, for screening a site against a checklist rather than one query at a time.
- Direct text access too — section hierarchy, individual nodes and extracted tables are available without touching a model at all, and need no API key.
Inference where the data already is
The extraction pipeline runs model inference from inside the analytical database, so the prompt, the raw response and the parsed result land in a table beside the structured output rather than disappearing into an application log.
- Two provider tiers — ordinance-text providers for nuanced reasoning, structured data APIs for dimensional facts, ingested through the same schema.
- Cross-provider validation — where two sources describe the same district, disagreements are recorded as flags with warning or error severity rather than silently resolved.
- Reproducible by stage — setup, ingest, AI, report and validate run independently, so a rerun does not mean redoing everything.
- Assembled reports — a structured feasibility report per parcel request, exportable to CSV, GeoJSON or PostGIS for whatever consumes it next.
Four groups, and one that needs no key
The text endpoints are just a database read — no model involved, so they work without an AI provider configured at all. Everything that costs tokens is grouped where you can see it.
| Group | What it does | Needs a model? |
|---|---|---|
| Zoning | Sites, section hierarchy, ordinance search, individual nodes and the tables extracted from them | No |
| AI | Natural-language questions, batch questions, scenario decisions, zone comparison, node summaries, generated SQL | Yes |
| Analysis | Zoning standards per district, parcel upside, ranked opportunities, district statistics | No see limits |
| Predictive | Scenario value projections, property summaries, investment memos | Partly |
| Health | Liveness, plus database and model connectivity reported independently | No |
What the zoning permits, against what is built
Where structured standards exist for a district, they can be compared with what a parcel actually is — producing utilisation ratios, headroom, and value projections across a set of named development scenarios with every assumption stated.
- Four scenarios — hold as-is, renovate, resolve compliance, or redevelop to the zoning envelope.
- Assumptions are inputs, not magic — appreciation rate, construction cost per square foot, soft costs, developer margin, cap rate and rent are all yours to set, and default values are visible.
- Utilisation, not just capacity — current versus allowed FAR, density and height, with the additional floor area and units the envelope would permit.
- Grounded narrative — generated summaries and memos are written from the computed metrics rather than invented alongside them.
What this does not do
This is software that reads law and produces numbers. Being precise about where it is weakest is the only responsible way to sell it.
It is not a legal opinion
Answers are a research aid that points you at the governing text. Verify against the ordinance before anything is filed, purchased or built. The citations exist precisely so that verification is quick.
The standards table is noisy
The per-district standards behind the analysis endpoints are extracted from scraped ordinance tables by pattern matching, and known-bad values exist in the current build. Treat them as a starting point to confirm, not as authority.
Confidence is not correctness
The confidence field reports whether retrieval found context — nothing more. It is documented that way in the API itself, and no downstream logic should threshold on it.
The corpus is a snapshot
Ordinance text is captured by a separate acquisition run and refreshed by rebuilding. There is no incremental update, so an amendment appears only after the next build.
Coverage is where the corpus is
The current build is South Florida. Adding a market means running the acquisition pipeline against its code portal — routine, but it is a build step, not a configuration flag.
You bring the model
The AI endpoints need your own provider key, and several providers are supported. Text search, section hierarchy and table extraction run with no model and no key at all.
* We would rather show you this list on the way in than have you discover it in a deal. Generated SQL is gated so that only read statements execute, and the text endpoints are read-only against a snapshot — but none of that substitutes for checking a number against the ordinance that governs it.
The legal half of "what can I build here?"
The rest of the portfolio answers where a parcel is and what stands on it. This answers what the code allows.
Fed by the acquisition pipeline
The Opportunity Pipeline's text track discovers and captures municipal code into the indexed corpus this serves from. That repository acquires; this one answers. They share an artifact, not code.
Solution detail →Behind ordinance search on the map
This is what lets Land Intelligence's AI Analyst answer a zoning question about the parcel under the cursor and cite the section it came from.
Solution detail →Into feasibility and permitting
A cited answer about what a district permits is exactly what belongs in a project workspace when a permit application is being prepared and someone will later ask why.
Solution detail →Bring us a question you already know the answer to
The fastest way to judge this is to ask it something you have already researched by hand, then read the passages it cites. Tell us the municipality and we will run your questions against it — and say plainly where the corpus does not yet reach.