From Portal to Intelligence: The Digital-Permitting Maturity Curve

Executive summary

Digital permitting programmes are often described as done once submission moves online. That is stage two of five, and it is the stage at which the reviewer’s work is least changed.

This maturity curve describes five stages, the capability each adds, the governance each requires, and the metrics that become available. It is deliberately unglamorous about the later stages: they demand configuration discipline and oversight design, not just procurement.

Why a maturity view helps

Maturity models are useful when they prevent skipped steps. A department that has not documented its local requirements cannot configure rules, because there is nothing stable to configure. A department without stage timestamps cannot demonstrate improvement, because there is no baseline.

The federal challenge statement on deterministic, AI-assisted compliance checking implies the same sequence: structured inputs and defined requirements come before automated evaluation [1], and responsible-AI guidance expects oversight design to be in place before deployment [2].

The five stages

The transitions that actually cost effort

Stage 2 to 3 is a documentation exercise disguised as a technology step: local requirements, checklists per permit type and deficiency taxonomies have to be written down and agreed. Most of the effort is internal and most of the value arrives immediately.

Stage 4 to 5 is a governance exercise. Rules must carry jurisdiction, edition and validity; findings must carry evidence; coverage must be stated; reviewer authority and override paths must be designed and recorded. Skipping this produces a system that appears to check compliance without being able to defend a single finding.

Implications for authorities having jurisdiction

Assess honestly, then pick the next stage rather than the final one. A department at stage 2 gains more from a well-configured completeness gate than from a rules pilot it cannot validate.

Publish the target stage and the current stage. It manages expectations internally and externally, and it makes the programme legible to council between funding decisions.

Implications for applicants and vendors

Applicants experience stage 3 as clearer requirements and fewer surprise rejections; stage 4 as accurate status and faster resubmission; stage 5 as findings that cite a requirement and a location. Each is a distinct service change worth communicating separately.

Vendors should map their proposals to a stage. A proposal that assumes stage 5 in a stage-2 department is proposing that the municipality do the intermediate work invisibly, at its own cost.

Risks, limitations and safeguards

• Maturity stages describe capability, not quality; a poorly configured stage-5 deployment is worse than a disciplined stage 3.
• Skipping stage 3 leaves rules configured against undocumented assumptions.
• Metrics introduced at stage 4 can be gamed; pair timeliness with rework and quality measures.
• Stage 5 requires ongoing rule maintenance as editions change; unmaintained rules become wrong rules.
• Small jurisdictions may rationally stop at stage 3 or 4; that is a legitimate end state, not a failure.

PermitAssure perspective

PermitAssure is designed to be useful at stage 3 and to grow with the department: structured intake and completeness checking first, then revision intelligence and coordination, then configured deterministic evaluation with evidence-linked findings. Each stage is independently valuable, and each carries its own configuration and validation work.