Application completeness checker

A completeness check earns its keep only when each finding names a required field and the blank or conflict in this packet. If the field is present and consistent, that field produces no line. If the whole packet matches the loaded list, the output stays empty. You still decide intake: accept the file or return it.

The model does not decide whether the applicant qualifies, does not score merit, and does not write approval conditions. Completeness is a quality pass before review time starts.

What you send must be a clarification the applicant can act on: which published checklist item is missing, or which two pages in the same packet disagree. A letter that only says the application is incomplete sends people to the wrong form and produces a second incomplete filing.

When the live question is whether cited code sections match the claim, not whether a field is blank, use the compliance pre-check generator as a separate pass. Completeness asks whether the required item is here and internally consistent. Mixing the two jobs writes letters that sound official and still fail to name a blank.

Start with the checklist for this license type, program, and year. That list is the only source of "required." Load it together with the submitted packet: forms, attachments, and the structured values already captured in intake.

Do not infer extra forms from last week's similar file. Do not borrow a sister program's checklist because the trade names look alike. If this application's published list does not name a document, the checker must not ask for it.

Packets may arrive through Accela, Salesforce Government Cloud, Tyler, or a Microsoft-hosted intake path. Treat those systems as the place files and fields already live. The checker reads what was submitted against the list you loaded. It does not replace the system of record, and it does not invent an upload the system never required.

Walk the list in order. For each required field or attachment, look for a value or file in this packet only. If two fields in this packet contradict each other, such as owner name on Form A versus the name on the insurance rider, that is a conflict to cite. Similar names on other people's files are not a conflict.

For every miss, write a line you can send: the checklist item, where the instructions name it, and what is blank or which two pages disagree. Cite the packet page or field. Do not cite a habit that "this usually comes with a site plan."

Stop when the list is exhausted. Do not continue into eligibility or conditions. A completeness letter that demands proof of need, or that drafts approval language, has left the job. Merit scoring belongs with a proposal scoring assistant after the file is complete enough to evaluate. Approval language belongs later, with a condition generator for approvals, once someone is actually approving.

Here is a single walkthrough. A food-establishment license checklist requires owner identity on Form A, premises address on Form B matching Form A, a certificate of insurance that names the city as additional insured, and a floor plan with the grease interceptor labeled. The packet contains Form A, Form B with a matching address, an insurance certificate that names a holding company instead of the city, and a floor plan with kitchen equipment drawn but no interceptor label.

The checker should return two items only: additional-insured on the insurance certificate (required: the city; packet: the holding company), and the grease-interceptor label on the floor plan (required: labeled; packet: unlabeled). It should not invent a county health pre-clearance letter this checklist never named. It should not treat another restaurant's packet as evidence that this applicant forgot a ventilation schedule. Fields that are not on the list stay unmentioned.

You review those two cites, adjust tone if needed, and send the clarification. The applicant knows what to fix. When the revised packet lands, run the same list again. If both gaps are closed and nothing new is blank, the checker returns empty.

Empty output is the correct result for a complete file. Do not pad the letter with reminders, optional attachments, or items copied from a training packet. If the checklist marks something as if-applicable, flag it only when this packet's own answers make it applicable, such as a shared-kitchen yes that then requires the host agreement. If those answers do not trigger it, leave it out.

Silence is not a hidden reject. A complete packet still needs an intake decision: accept into review, or return for a reason that is not completeness, such as the wrong program or an unpaid fee. The checker does not accept. The checker does not return. It only describes gaps against the list you loaded.

If you want to ask for one more thing, put that thing on the published checklist first. Otherwise you are enforcing a private standard applicants cannot meet on the first try.

Asking for a form the checklist never named is the usual miss. Licensing packets share a family resemblance. The model will request a tax-clearance letter, a parking study, or a neighbor-notice affidavit because those appear in other programs. If this list does not name it, do not send it. Officers who paste uncited extras teach applicants that the published list cannot be trusted.

Treating the checker as a decision is the next miss. Completeness language that says the application is denied, does not meet the ordinance, or should be approved with conditions is the wrong artifact. You still accept or return the file. When several agencies must sign the same complete file, a multi-agency sign-off orchestrator tracks who has not yet signed. That is routing after intake, not a completeness finding.

Inventing an inconsistency from similar applications is the third miss. Two applicants in the same trade can file different optional exhibits. A missing optional exhibit is not a conflict. A name that might not match a registry you did not load is not something the checker can repair by guessing. Cite only blanks and conflicts inside this packet against this list.

A quieter miss: citing a field that is already filled because the model wanted different phrasing. Calling "DBA" blank when the form uses "trade name" and the trade name is filled is a false blank. Match the field labels on the form you loaded.

After the checker runs, you have cited gaps or you have empty output. If there are gaps, send the clarification, wait for the revised packet, and run the list again. If output is empty, decide intake yourself. Accept the file into review, or return it for a reason you can stand behind that is not a ghost form.

Keep the required-field list versioned with the program year. When the board adds a field, update the list before you expect the checker to find it. When a field is retired, remove it so complete packets do not get a stale ask.

The quality bar is simple. Every sentence you send names a required field and the blank or conflict in this packet, or you send nothing because the packet is complete.