Completeness Review, Technical Compliance Review and Final Approval Are Not the Same

Executive summary

When people argue about whether AI should review permits, they usually mean three different activities at once: checking that a submission contains what it must contain, assessing whether the design meets adopted requirements, and deciding to issue a permit.

Separating the three clarifies both the opportunity and the limits. Completeness is largely rule-based and safe to automate under supervision. Technical review is partly deterministic and partly interpretive. Approval is a statutory act that stays with the Authority Having Jurisdiction.

Why the distinction matters

Each gate answers a different question. Completeness asks whether the file can be reviewed. Technical review asks whether the design satisfies the requirements adopted in this jurisdiction for this edition [1][2]. Approval asks whether the authority will issue, refuse or condition the permit.

The consequences of error differ too. A completeness miss costs a cycle. A technical review miss can affect safety. An approval error carries legal consequence for the authority. Controls should be proportionate to those differences, which is exactly the logic used in public-sector guidance on automated support for administrative decisions [3].

The three gates

Where automation belongs first

Completeness checking is the highest-value first automation for three reasons: the rules are administrative rather than interpretive; the errors are cheap and visible; and the benefit is felt immediately by both applicants and reviewers, because incomplete files stop consuming technical capacity.

Technical review can then be approached provision by provision. A dimension compared against a threshold with facts extracted from a validated source is a candidate; a performance-based provision requiring interpretation is not, and the system should mark it as requiring professional review rather than attempt it.

Implications for authorities having jurisdiction

Publish the completeness checklist per permit type. Applicants can then self-check, and the checklist becomes the configuration source rather than an internal habit. Where a coordinator exercises judgment at gate 1, record it — those records show whether the checklist needs adjusting.

Keep gate 3 visibly human. Every finding presented to the decision-maker should be traceable and reversible, and every override should be recorded with a reason, which is the evidence base if a decision is later questioned.

Implications for applicants and professionals

A published completeness standard converts a large share of deficiency notices into pre-submission work. For high-volume applicants, building an internal check against that standard usually pays for itself within a handful of applications.

For designers, the distinction also clarifies what a digital finding is: an observation with evidence, not a determination. A finding can be answered with an explanation, a correction, or a demonstration that it does not apply.

Risks, limitations and safeguards

• A completeness gate applied rigidly can reject legitimate unusual submissions; a referral path is mandatory.
• Automating completeness can push effort to applicants without support; publish the checklist and provide guidance.
• Gate boundaries can blur under pressure. Keep the records separate so the department can show where a decision was made.
• Deterministic checks must state their coverage; silence must not be read as compliance.
• Statutory approval cannot be delegated to software, and no system output should be phrased as approval.

PermitAssure perspective

PermitAssure implements the three gates as distinct stages with distinct records. Completeness runs against configured checklists per permit type and jurisdiction; technical evaluation applies configured deterministic rules with evidence links and stated coverage; approval remains a human act performed by the authority, recorded with its reasons.