Transparent Permit Status Without Oversimplifying the Review

Executive summary

"In review" is the least useful status a permit service can display. It is accurate, unfalsifiable and tells the applicant nothing about whether action is required.

A good status model names the stage, the current holder of the file, whether the applicant needs to act, and the expected next event. It resists two temptations: exposing internal review detail, and implying an outcome that has not been decided.

Why status design is harder than it looks

Status carries expectations. A label such as "approved pending conditions" will be read as approval, whatever the department intends. Where automated support contributes to a process, guidance on automated decision-making expects clarity about what has and has not been decided [1].

At the same time, opacity generates enquiry volume. Every unclear status becomes a phone call, and those calls consume the same staff the applicant is waiting for.

A status lifecycle

Four rules for status content

1. Name the stage and the holder. "In technical review — building" is more useful than any progress bar.
2. State whether the applicant must act, in the label itself, not in a sub-line.
3. Never state or imply an outcome before it is decided; "decision pending" is honest and unambiguous.
4. Give the next event, not a promise: "referral response expected before technical review completes".

Implications for authorities having jurisdiction

Derive status from workflow state rather than manual updates. A status that depends on someone remembering to change it will be wrong, and a wrong status is worse than a coarse one.

Where service targets are published, show elapsed time within the current stage rather than a countdown to a promise the department may not control.

Implications for applicants and professionals

Applicants should treat "awaiting your response" as the only status that requires action and organise internally around it. Where several projects are in flight, filtering by holder is more useful than sorting by date.

Risks, limitations and safeguards

• Status labels that imply outcomes create expectations that constrain the decision-maker; audit wording.
• Exposing internal review detail can create pressure on individual reviewers; name departments, not people.
• Automatically derived statuses can be misleading during exceptions; provide a plain-language note field.
• Status must not rely on colour alone; use words and icons.
• Historical status changes belong in the record, since applicants may later question timelines.

PermitAssure perspective

PermitAssure derives applicant-facing status from workflow state, names the holding department, and states whether applicant action is required. No status expresses or implies an approval outcome; the decision appears only once the authority records it.