PermitDesk for government IT

1. Overview and architecture

An application enters through the public portal or staff intake, is auto-classified by permit or license type, checked against a per-type document checklist, priced from your fee schedule, and routed to the reviewing departments. Complete applications move into department review queues; incomplete ones are held with a specific list of what is missing. Every decision is assistive: PermitDesk proposes a classification, a checklist result, a fee, and a routing, and a person confirms.

Integration is deliberately flexible: data is exchanged with your finance, GIS, and land-management systems over standard file-based transfer (SFTP + CSV/JSON) or REST APIs where they exist. PermitDesk does not require a live API from any one of your systems, because many government systems cannot expose a stable, permissioned API. Nothing in your stack is replaced.

  APPLICANTS                    JURISDICTION SYSTEMS
  public portal / staff intake  GIS/parcels · fee schedules · finance · records
        |  application + documents        |  file/API exchange
        +-------------------+-------------+
                            v
                    INTAKE + VALIDATION      capture, virus-scan, structure
                            v
              CLASSIFY + COMPLETENESS        type, per-type document checklist
                       /            \
             complete /              \ incomplete
                     v                 v
          FEE + ROUTING            HELD FOR DOCUMENTS
          calc fee, route          missing-item list -> applicant
          to departments                 |
              \                          /
               v                        v
        REVIEW QUEUES / STATUS / INSPECTIONS / AUDIT LOG

PermitDesk holds the application record and orchestrates the workflow; it hands issued permits, fees, and payment records to your systems of record and never posts into them without your controls.

2. Application intake

Channels

Applications arrive through the hosted public self-service portal or through staff intake for walk-ins, mail, and phone. Both produce the same structured application record, so downstream classification and routing behave identically regardless of channel.

Forms and document capture

Each permit or license type has a configured form and a required-document list. Uploaded documents are captured, virus-scanned, and stored against the application. Supported upload types are PDF, common image formats, and standard office documents; files are size-limited and content-type checked.

{
  "application_id": "BLD-40318",
  "type_code": "res_addition",
  "channel": "portal",
  "submitted_at": "2026-08-14T09:22:00-05:00",
  "parcel_id": "12-34-567-089",
  "applicant": { "name": "…", "email": "…", "phone": "…" },
  "documents": ["app_form.pdf", "site_plan.pdf", "contractor_license.pdf"]
}

3. Classification and completeness

Auto-classification

On submission, PermitDesk classifies the application to a permit or license type_code from the application content. The classification is a suggestion with a confidence signal: high-confidence matches route straight to the correct checklist, and ambiguous ones are queued for a staff member to confirm the type. Classification never issues or denies anything.

Completeness check

Each type_code carries a required-document and required-field checklist. The completeness engine compares what was submitted against that checklist and produces a per-item result. An application missing any required item is held, and the applicant receives a specific list of what to provide, rather than a generic rejection.

Completeness results are advisory to staff: a reviewer can waive an item or request it, and every such action is logged with the person and reason.

4. Routing, fees, and status

Cross-department routing

A complete application is routed to the departments configured for its type, in parallel. Routing rules are declarative, keyed on type_code, parcel attributes, and thresholds you set (for example, valuation over a limit adds structural review).

Fee calculation

Fees are computed from your published fee schedules the moment the type is confirmed. A schedule maps a type and its parameters (valuation, square footage, flat, or tiered) to a fee, and the calculation is shown to staff and applicants with the schedule version that produced it, so a charged fee is always traceable.

Status and notifications

Every application exposes a status (received, held, in_review, approved, issued, inspections, closed) to both staff and the applicant. Notifications fire on state changes over email, so the front counter stops fielding status calls. A plain-language status assistant answers applicant questions from the record without exposing internal notes.

Inspections

Once a permit is issued, inspection requests are scheduled against the same record, and results feed the status timeline so an application is one continuous history from intake to final sign-off.

5. Data exchange and integrations

File-based exchange

Where a system cannot expose an API, PermitDesk exchanges data over SFTP using CSV or JSON files with a control manifest: each file ships with a row count and checksum, and a file whose manifest disagrees is quarantined rather than ingested. This is the lowest common denominator every finance and records system can already produce.

<system>_<jurisdiction>_<feed>_<YYYYMMDD>_<HHMMSS>.csv
example: finance_cityx_fees_20260824_020115.csv

APIs where available

For GIS/parcel lookups and payment processing, PermitDesk uses REST APIs when your provider offers them: an address or parcel lookup ties an application to the correct property at intake, and the payment step hands off to your existing processor at checkout. API access is used when present and is never a hard requirement.

6. Security and data integrity

The controls below describe the system's design. Where language says "designed to," it reflects control intent and implementation, not a completed third-party audit or a specific certification, which is not claimed here.

Data minimization

PermitDesk collects only the data a permit or license application requires. Where a type does not need a piece of personal information, it is not requested. Uploaded documents are stored against the application and access-controlled; nothing is used for advertising or model training.

Encryption and access

• In transit: TLS for the portal and APIs; SFTP over SSH for file exchange, with PGP payload encryption available for sensitive feeds.
• At rest: data stores and backups designed to be AES-256 encrypted; keys held in a managed secrets store.
• RBAC: least-privilege roles (Applicant, Intake clerk, Department reviewer, Fee/approver, Inspector, Jurisdiction admin, Auditor). Designed to support SSO via SAML 2.0 / OIDC with MFA at your IdP. Access is scoped to a single jurisdiction; no cross-jurisdiction visibility.
• Immutable audit log: every submission, classification, completeness result, routing decision, fee calculation, human action, and status change is written to an append-only, hash-chained log. The Auditor role can read it; no role can edit or delete it through the application.

Human-in-the-loop by design

PermitDesk's AI assists intake, it does not adjudicate. Classification, completeness, fee, and routing are all proposals a person can accept, change, or override, and every override is logged. No permit or license is ever issued or denied by the system on its own.

7. Implementation and onboarding

A typical jurisdiction goes from kickoff to go-live in roughly 6 to 10 weeks, gated mainly by how quickly you can hand over fee schedules, permit-type checklists, and sample data.

• Discovery and configuration (wk 1-3). Configure permit and license types, per-type checklists, fee schedules, routing rules, and department roles.
• Integration setup (wk 2-4). Provision SFTP and/or API connections to GIS, finance, records, and payments; confirm field mappings; an end-to-end test.
• Pilot type live (wk 3-5). One permit or license type goes live end-to-end on real applications, so intake, classification, routing, and fees are proven on your data.
• Parallel and rollout (wk 5-8). Additional types are switched on; status notifications and inspections enabled; staff trained on review and override.
• Go-live (wk 8+). The public portal opens for the live types and the queue becomes the working surface.

8. IT FAQ

Do you need write access to our finance or records system?

No. PermitDesk can publish fee, payment, and issued-permit records to a file your existing import process consumes under your controls, or write through an API only where you choose to grant it. It never requires standing write credentials into a system of record.

Where is our data hosted?

A managed cloud environment with encryption at rest and logically isolated per-jurisdiction data. Single-tenant or jurisdiction-specified region deployment is available; the hosting model, region, and subprocessors are documented in the agreement.

How is the AI kept in bounds?

It classifies, checks completeness, calculates fees, and suggests routing. Each output is a proposal a staff member confirms, and every decision is logged. Approvals and denials are made by people, never by the system.

What if our fee schedule or permit types are unusual?

Expected and handled. Types, checklists, fee schedules, and routing rules are all configuration, mapped during discovery, so your local rules are accommodated without custom code.

Can we run single-tenant?

Single-tenant hosting is a standard option, and a jurisdiction-specified region is supported where policy requires it.

What happens to our data at contract end?

You receive a full export of your data (applications, documents, fee records, audit log) in a documented format. After the export is confirmed, PermitDesk securely disposes of your data on a defined schedule and records a disposal confirmation in the audit log.