GovPilot's 90% claim needs comparable permit cohorts

Freeze the two permit cohorts before comparing them

The GovPilot page supplies a clear diligence question: what applications produced the stated change from 30 days to three? The public page does not expose a study table or cohort protocol. A review should identify the jurisdiction and department, permit families, project and property classes, submission channels, before and after windows, implementation dates, case counts, and eligibility rule. It should also state whether the reported values are means, medians, another summary, or selected examples.

Write the inclusion rule before querying either period. Use the same rule for legacy paper records and the digital population, then preserve every matching case identifier in a comparison register. Stratify material differences such as permit family, project scale, declared valuation, residential or commercial use, number of reviewing departments, initial completeness category, resubmission count, and final disposition. If the old records cannot supply a field used for the new cohort, disclose the asymmetry rather than silently filtering the easier population.

Publish the denominator and the full distribution

The arithmetic from 30 to three is a 90 percent decrease, but arithmetic does not reveal how many permits were observed or which ones disappeared from the comparison. Report all eligible cases, matched records, duplicates, missing files, unresolved identities, open cases, withdrawals, denials, expirations, transfers, and other exclusions for each period. Give every exclusion a stated rule and count. A result based only on completed or easily matched applications can overstate improvement even when the calculation itself is correct.

Show the distribution instead of one headline value. At minimum, publish the count, median, mean if used, quartiles, upper tail, range or other declared spread, and the share of cases without a final observed value under the study rule. Break out the predeclared strata rather than combining simple and complex populations into a single average. Retain the calculation code or query, source extract version, data dictionary, missing-data treatment, and correction history so an independent reviewer can reproduce the denominator and summary.

Keep implementation and attribution as separate questions

A before-and-after difference can coincide with more than software. Staffing levels, training, policy changes, intake assistance, demand, project mix, backlog clearance, fee practices, outside-agency capacity, holidays, emergencies, and changes in how legacy files were entered can all move the observed result. The comparison record should list concurrent changes, their dates, affected populations, and available evidence. If those factors cannot be separated, describe the result as an observed association rather than a measured software effect.

Generalization requires another boundary. A Bexar County customer example does not predict the result for a city with different permit families, staffing, authority structure, data quality, review dependencies, applicant population, or implementation scope. A buyer may use the example to request a comparable evaluation, not to insert a 90 percent benefit into every forecast. Code quality, accessibility, fairness, safety, housing completion, cost, revenue, and public satisfaction also require their own populations and methods; a shorter reported duration does not establish them.

Reproduce the comparison before using the benefit

A buyer test should use two frozen, de-identified cohort extracts and a written protocol. Run the same eligibility query, reconcile legacy and current identifiers, produce the inclusion and exclusion ledger, calculate the declared summaries, and sample cases from the center and tail of each distribution back to the source record. Have a reviewer who did not prepare the claim repeat the calculation. Any change to the population, method, or data should create a new version rather than rewrite the earlier result.

Civic Permit Review reviewed the registered GovPilot page on September 16, 2026. It supports the provider's description of permitting workflows and the customer-attributed 30-day-to-three-day, 90 percent example. It does not establish the underlying cohort, case count, source data, before-and-after periods, sampling, exclusions, distribution, independent validation, causal effect, reproducibility, configured customer workflow, legal decision, code compliance, or public outcome.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Civic Permit Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.