Completeness is a different question from approval
Before a planner can review an application on its merits, someone has to answer a narrower question: did the applicant give us everything the code requires to begin? Is the owner's authorization signed? Is the stormwater report stamped? Is there a traffic study, if this project is large enough to need one? Completeness is a question of evidence, not judgment about the project, and it is a question a language model can help answer, as long as the department builds the checklist, the model finds the evidence and a person sends the notice.
That split is the whole design. The checklist comes from the ordinance and the adopted submittal requirements, written and approved by staff. The model reads the submission and, for each requirement, points to the page that satisfies it or reports that it found nothing. A planner reviews the result, decides, and signs the letter that goes to the applicant. The model never decides whether an application is complete, and it never decides whether a project is good.
Why timing matters when a clock is running
Completeness reviews are often on a deadline set by law. California's Permit Streamlining Act, for example, gives an agency 30 days after receiving a development application to tell the applicant in writing whether it is complete, and an application not determined incomplete in that window is deemed complete. Federal rules for wireless facility siting set shot clocks where an incompleteness notice sent within a short window after submission stops or resets the clock, and a late one does not. Many states and local codes set their own windows.
Where those clocks apply, a late or vague notice has consequences. An application deemed complete by default goes to review with gaps the department now has to work around. A notice that lists three missing items, followed two weeks later by a second notice listing two more, frustrates applicants, and some statutes limit what a department may add in a later notice that it did not list in the first. Statutes like California's also require the notice to say what is missing and how to make it complete.
The value of a model here is not that it is smarter than a planner. It is that it reads every page of every submission on the day it arrives, against every requirement, so the planner starts the review with a full list of likely gaps instead of discovering them on day 25.
Build the checklist from the ordinance, not from memory
Experienced intake staff carry the submittal requirements in their heads. That knowledge is valuable and it is also the source of most inconsistency: two planners reviewing the same application often produce different lists, because each remembers a different set of conditional requirements. The first step is writing the checklist down, and it is worth doing even if you never use a model.
For each application type, list every requirement from the zoning ordinance, the subdivision regulations, the adopted submittal checklist, the application form's instructions and any state requirement. Give each requirement an ID, the code section it comes from, the condition under which it applies, a description of what counts as evidence and an example of an acceptable submission. Then have the planning manager approve it and version it. When the council amends the ordinance, the checklist gets a new version with an effective date.
Conditional requirements need the most care. "A traffic impact study is required for projects generating more than a stated number of peak-hour trips" depends on a value that may itself be in the submission. "A geotechnical report is required for lots with slopes above a set grade" depends on a value from the site plan. Write each condition so it can be evaluated from a named field, and the model can report not only whether the item is present but whether, on the applicant's own numbers, it was required.
How the model reads a submission
The pipeline is straightforward. Extract the text of every page with its coordinates, running OCR on scanned pages. Split the submission into documents and label each one. Then work through the checklist one requirement at a time. For each, retrieve the pages most likely to contain the evidence and give the model the requirement, its evidence description and those pages.
The model returns one of four statuses for each requirement: found, missing, unclear or not applicable. Every "found" comes with a page number and the exact quoted text or region that satisfies it. Every "not applicable" comes with the reason, tied to the requirement's condition and the value in the submission that makes it inapplicable. "Unclear" is a legitimate answer, used when a stamp is illegible, a signature block is present but blank or two documents disagree.
Then check the model's work mechanically. Confirm that each quoted passage actually appears on the cited page. Any "found" whose quote cannot be located is downgraded to "unclear" automatically. This single check removes the most damaging kind of error, a confident citation to evidence that does not exist.
What the output looks like
The planner sees a table, one row per requirement, with the evidence linked to the page. The rows below are illustrative, with hypothetical section numbers, for a site plan application.
| Requirement | Evidence found | Status |
|---|---|---|
| Owner's signed authorization Sec. 4.2(a) | Application form, page 3: owner signature block signed and dated | Found |
| Site plan showing setbacks to all property lines Sec. 4.2(c) | Sheet C-1, page 8: setback dimensions on north, south and east lines; west line not dimensioned | Unclear |
| Stormwater management report, stamped by a licensed engineer Sec. 4.2(f) | No document labeled as a stormwater report; drainage note on sheet C-2 only | Missing |
| Traffic impact study, if peak-hour trips exceed the threshold Sec. 4.2(h) | Application form, page 2: applicant states peak-hour trips below the threshold | Not applicable, with reason |
| Building elevations, all sides Sec. 4.2(d) | Sheets A-1 and A-2, pages 11 to 12: four elevations labeled | Found |
| Landscape plan with plant schedule Sec. 4.2(e) | Sheet L-1, page 14: plan present; plant schedule not found on any sheet | Unclear |
Two rows deserve attention. The traffic study row is "not applicable" on the applicant's own statement, which the planner should test, because an understated trip count is a common way for a required study to go missing. And the setback row is "unclear" rather than "missing," because the evidence is partly there. The table does not resolve either question. It puts each in front of the person who will.
A person sends the notice
The planner works down the table, starting with "missing" and "unclear," then checking every "not applicable" reason and spot-checking the "found" rows. For each, the planner records a decision: agree, disagree or needs more review. Where the planner disagrees with the model, they say why in a sentence. That sentence is the most useful data the system will ever collect.
Once the planner has decided, the system can draft the incompleteness notice from the confirmed items: each missing item, the code section that requires it and what the applicant needs to submit. The planner edits the draft, signs it and sends it through the department's normal channel. Nothing goes to an applicant without a named staff member having approved it. The model finds the page. The planner decides what the page means, and signs the letter that says so.
If the planner finds the application complete, the record shows that too, with the same table as the basis. Either way, the determination is the department's, made by a person, on evidence that is linked and preserved.
Test it on applications you have already decided
Before using the system on live applications, run it on past ones. Pull a set of past applications for the type you are starting with, including ones found complete on first review and ones that received incompleteness notices. The notices and the eventual complete submissions give you a reference answer for each requirement.
Treat that reference with some suspicion. Staff miss things too, and some of the model's "missing" findings will turn out to be items a past reviewer overlooked. Have a senior planner review every disagreement between the model and the historical record, and classify each one: the model was wrong, the historical review was wrong or the requirement is ambiguous. Ambiguous requirements go back to the checklist for a clearer evidence description.
Count the errors by kind. The expensive one is a requirement the model marked "found" when the item was absent, because a hurried reviewer might accept it. False alarms cost review time but not outcomes. Set the acceptance standard before you run the test, by requirement, and expect it to be strictest for items whose absence would stop review.
Guardrails
The guardrails are what make the system safe to use under a legal clock. Write them into the department's procedures and into the software's configuration, so they hold when the team is busy.
- The model answers completeness questions only, never questions about whether the project meets the code
- Every requirement comes from a staff-approved, versioned checklist with a code citation
- Every "found" carries a page and a quote, and quotes are verified against the page text automatically
- "Unclear" is always an allowed answer, and the model is instructed to use it rather than guess
- A named planner reviews every result and signs every notice; nothing is sent automatically
- The model, prompts and checklist version are pinned, and any change triggers a re-test on past applications
- Applicant documents are not used to train models without the department's written permission
- The system flags when a determination deadline is approaching for any application still awaiting review
The audit log is part of the record
When an applicant disputes a completeness determination, or a records request asks how the department reviews applications, the log is the answer. Build it to stand on its own.
For each application, record the hash of every submitted file, the date and time received, the checklist version, the model and prompt versions, every status the model returned with its citation, every reviewer decision with the reviewer's name, time and any reason given, the final determination and the notice sent. Keep the log for as long as your retention schedule requires for the application file itself, and ask your city attorney or clerk whether the model's outputs are public records under your state's law; plan on the assumption that they may be.
The log also tells you how the system is doing. Track how often planners override each requirement, which requirements produce the most "unclear" results and how long reviews take. A requirement planners override often usually has an evidence description that needs rewriting.
A rollout that respects the clock
From Checklist to Assisted Review
Shadow mode matters most where the clock is short. It shows whether the model's table arrives early enough in the review window to help, and whether planners trust it enough to use it, before any live determination depends on it.
What it costs
The model's processing cost per application is usually small. As a rough illustration, a submission of a hundred pages checked against thirty requirements, with a few retrieved pages per requirement, typically costs somewhere between cents and a few dollars at current published rates for capable models, depending on the model and the number of passes. Price it on your own submissions before relying on any estimate.
The larger costs are elsewhere. Writing and approving the checklists takes senior staff time, typically the largest single investment, and it pays off whether or not the model is ever used. Integration with the permitting system, so the table appears in the planner's normal workflow, can rival the build itself. Review time does not disappear; it shifts from searching to confirming. And the checklists need maintenance every time the council amends the code.
Weigh that against what the department spends now: planner hours per completeness review, the cost of second and third incompleteness notices, applications deemed complete by default and the applicant frustration that reaches the council. For most departments, the case rests less on hours saved than on fewer missed items and fewer late notices.
Frequently asked questions
No. It maps each requirement on a staff-approved checklist to evidence in the submission, with page citations, and flags what it cannot find. A planner reviews every item, makes the determination and signs any notice sent to the applicant.
From the ordinance, the adopted submittal requirements, the application instructions and any state requirements, written by staff with a code citation, an applicability condition and an evidence description for each item. The planning manager approves it, and it is versioned when the code changes.
Run it on past applications whose completeness outcomes are known, have a senior planner review every disagreement, and count errors by kind. The most serious error is marking a missing item as found. Then run it in shadow mode on live applications before planners rely on it.
Many states and local codes set deadlines for completeness determinations, and some treat an application as complete if no timely notice is sent. A full, early list of likely gaps helps planners send one accurate notice inside the window instead of several late ones.