Document AI for permit and land-use applications

The backlog starts at the counter

A planning department's backlog rarely starts with the hard decisions. It starts with the first hour of every application: opening the files, working out which document is which, typing parcel numbers and lot areas into the permitting system, checking that the required attachments are there and deciding which reviewer gets it. That hour is clerical, it is repeated for every submission, and it is the part of the job document AI does well. The decisions that follow are not, and a well-built system keeps a hard line between the two.

This piece is for the planning director, the permit center manager or the IT lead who has been asked whether AI can help with intake. It covers where it helps, how the system should be built, what staff review, how to measure errors on your own files, how public records rules apply and how to run a pilot that gives you a real answer in about three months.

Five places it earns its keep

Intake classification. A typical submission arrives as a stack of PDFs, or one large PDF, with an application form, a site plan, elevations, a title report, a drainage letter, photographs and an owner authorization. Sorting and labeling those documents is the first task, and the most reliably automated.

Field extraction. Application forms carry the values staff type into the permitting system: applicant, owner, parcel number, address, zoning district, project description, lot area, proposed floor area. Site plans carry more in their title blocks and data tables: setbacks, height, lot coverage, parking counts. Extraction pulls those values and shows staff where each came from.

Attachment checks. Comparing the documents present against the submittal list for the application type tells staff, in minutes, what appears to be missing. A full completeness review goes further, mapping each code requirement to evidence; at intake, a list of what looks absent is enough to stop an obviously short submission before it enters the queue.

Routing. Once the application type, location and scope are known, routing rules send it to the right reviewers: engineering when grading is shown, the historic commission staff when the parcel is in a district, the fire marshal when occupancy changes.

Draft summaries for staff reports. A first-draft project description and a table of key figures, each with a citation to the page it came from, give the planner a starting point for the staff report. The planner writes the analysis and the recommendation.

What to automate, and how far

Not every task should be automated to the same degree. The table sets out a reasonable expectation for each, before measurement on your own documents tells you more.

Task	Expected automation	Who reviews	Why
Classifying documents in a submission	High	Intake staff confirm the labels at a glance	Document types look different and errors are obvious and cheap to fix
Extracting fields from typed application forms	High to medium	Intake staff confirm each value against its highlighted source	Forms are structured, but handwriting, scans and old versions of the form add variation
Reading site plan title blocks and data tables	Medium	The assigned planner	Layouts vary by preparer, and sheets are large, dense and sometimes rotated
Reading dimensions from the drawing itself	Low, assist only	The assigned planner, against the drawing	Dimension strings overlap linework, and scale matters; the software points, the planner reads
Routing to reviewers	High, rules based	Intake supervisor reviews exceptions	Once the inputs are confirmed, routing is a rule, not a judgment
Draft project summary for the staff report	Draft only	The planner rewrites and owns it	A summary must be accurate and complete, and the planner is accountable for every word
Compliance findings, conditions and recommendations	None	Not applicable	These are decisions by staff, a hearing body or the council, and they stay that way

The architecture, layer by layer

A permit document pipeline is a set of separate stages, each with a job you can test on its own. Collapsing them into one call to a language model makes the system impossible to debug and impossible to trust.

• Ingestion. Accept PDFs and images from the portal, record a hash of each original file, split multi-document files and keep the original untouched as the record of what was filed.
• OCR. Produce text with coordinates for every word on every page, at a resolution high enough for small type on large sheets. Born-digital PDFs skip this and use their embedded text.
• Layout. A layout model identifies regions: title blocks, tables, legends, general notes, signature blocks, stamps and the drawing area, so later stages read the right part of the page.
• Extraction with citations. A language model reads the relevant regions and returns each value with its page, its region and the exact text it came from. A value without a citation is treated as not found.
• Rules. Deterministic checks catch what the model should not be trusted with: a parcel number in the wrong format, a lot area that does not match the assessor's record, a height above any plausible value.
• Review and audit. A side-by-side screen shows each value next to its highlighted source. Every confirmation, correction and rejection is logged with who did it and when.

The citation requirement is the part that makes the system usable. A reviewer who can click a value and see the highlighted region on the page confirms it in seconds. A reviewer handed a bare value has to find it in a sixty-page submission, which takes longer than typing it. Enforce the citation mechanically: check that the quoted text actually appears in the cited region, and downgrade any value that fails to "needs review."

Site plans are not forms

Application forms are the easy case. Site plans are where most of the effort goes. They are large-format sheets with small type, scaled drawings, text running in several directions, revision clouds, handwritten redlines, engineer's stamps over text and linework running through dimension strings. Every civil engineer and architect lays out a title block differently.

Treat them differently from forms. Render each sheet at high resolution and tile it, so small type survives OCR. Read title blocks and site data tables first; they carry most of the values a planner needs in a structured layout. Use the drawing area only to point a reviewer at a dimension, never to compute one. A setback measured off a scanned drawing with a scale bar is an estimate, and an estimate has no place in a zoning determination.

The best improvement is often outside the software. Publish a standard site data table, with the fields your zoning code requires, and ask applicants to include it on the cover sheet. It costs applicants nothing, helps your staff whether or not you automate, and turns the hardest extraction problem into an easy one.

People confirm every value that matters

Confidence scores are useful for ordering a reviewer's work. They are not a reason to skip review of a value that feeds a decision. A model can be confidently wrong, and the wrong values that cause trouble are the plausible ones: a lot area from the existing conditions table instead of the proposed one, an owner name from an old deed in the title report.

Sort fields into two groups. Values that feed a determination, a fee, a notice or a staff report are confirmed by a person, every time, against the highlighted source. Values used only for routing or search can be sampled: a staff member reviews a set share of them each week, and the share goes up if errors appear.

Watch the reviewer's workload, not just the model's output. If confirming twenty extracted values takes as long as typing them, the system has moved work rather than removed it. Measure staff minutes per intake before and after; that is the number the department actually cares about.

Measure errors on your own documents

A vendor's accuracy figure was measured on someone else's documents. Your applications come from your preparers, on your forms, in your scan quality, and the only measurement that predicts performance in your permit center is one taken on your own files.

Build a test set from past applications: a few hundred documents across your main application types, several years of form versions, good and bad scans, and the preparers who submit most often. Have two staff members record the correct value for each field independently, and settle disagreements with a supervisor. That labeled set is a department asset; keep it, and add to it every time the forms change.

Then measure each field separately and count three outcomes: correct, missing and wrong. They are not equal. A missing value costs a reviewer a few seconds. A wrong value presented with confidence is the expensive error, because it can survive review and reach a notice or a report. Report results by field and by document type, set a threshold for each field before you look at the results, and do not let a single overall percentage stand in for the table.

The line the software never crosses

Land-use decisions carry legal weight. Applicants have rights to notice, to a decision on the record and often to appeal. Many decisions are made by a hearing body on a record that has to stand up to review. None of that is compatible with software making determinations.

Write the line into policy before the pilot starts. The software reads, sorts and drafts. A person on staff decides, and the record shows which is which. In practice: the software does not determine completeness, compliance or approval. It does not set conditions. It does not send anything to an applicant. Draft summaries are labeled as drafts and are rewritten by the planner, who signs the staff report. Every value in a determination has been confirmed by a named staff member, and the audit log shows who confirmed it.

This line protects more than the applicant. It protects the department when a decision is challenged, because the record shows that people made every determination on evidence they checked. And it keeps staff in the position the public expects: accountable for the work.

Public records and retention

What the system produces may be a public record under your state's law: extracted data, draft summaries, review logs, perhaps model inputs and outputs. Ask your city attorney or clerk early, and set retention to match your schedules. The original submission remains the record of what the applicant filed, so store it unaltered, with its hash.

Keep the configuration with the record: which model version, which prompts and which rules processed each application. When a decision is questioned two years later, you should be able to show exactly what the software produced and what staff did with it.

Applications also carry personal information: phone numbers, email addresses, signatures, sometimes financial details. If you post applications online, redact them first, and use the extraction step to find those fields for a person to confirm. In the vendor contract, state that the department owns all data and outputs, that applicant documents are not used to train models without written permission and that everything can be exported in usable formats at the end of the contract.

A pilot that answers the question in twelve weeks

Pick one application type with steady volume and a clear submittal list, such as a residential addition or a sign permit. Agree on the measures before starting: staff minutes per intake, error counts by field and type, and whether reviewers trust the output enough to use it.

Shadow mode is the step departments are tempted to skip, and it is the one that finds the problems the test set missed: the preparer who submits everything as one file, the new version of the form nobody included, the scanner at the counter that produces faint images. Keep stopping on the table as a real option. A pilot that cannot end in "no" is a procurement, not a pilot.

What it costs and who runs it

Processing cost per page is usually the smallest line. The larger costs are staff time to label the test set and review output during the pilot, integration with the permitting system so confirmed values land in the right fields without retyping, and the ongoing work of maintaining the configuration as forms, codes and submittal lists change.

Name an owner inside the department, not just in IT: someone who knows the application types, approves changes to the extraction and rules, and watches the error reports. Budget for re-measurement each time a form changes or the model is updated, and write that obligation into the vendor contract along with the data ownership and export terms.

Frequently asked questions