ClearToPermit — municipal plan check

Permit-package review for cities / AHJs — applicants upload, staff review, humans keep the stamp.
Closed-beta landing: /cleartopermit (also cleartopermit.com)

• Status — Closed beta; municipal design-partner path (elevated)
• Brand — ClearToPermit (working)
• Assistant — Clara (secondary UI, not the product home)
  • Public: convert, educate, and search (ClearToPermit / city process)
  • Signed-in: workspace-aware (packages, status, findings, search)
• Partner cities — named only in internal ops, not in public docs

(Same plan-reading technology family as Estym8 construction takeoff — different product, buyers, and assistant. Details: suite map.)

For partner review (Paul / design partners)

Read in this order (landing mirrors the story at /cleartopermit):

1. Dual-sided model
2. Canonical workflow
3. Dashboard
4. Clara
5. Multi-city access
6. City settings
7. New city onboarding
8. Learn from misses
9. Who may upload
10. MVP capabilities
11. Design-partner workflow · Golden packages · City questionnaire · Success metrics

Also: Staffing · UX · Job

---

Dual-sided model — upload, review, status

ClearToPermit is one product with two human sides on the same package:

How the loop runs (ClearToPermit assists; only two human sides — submitter and city staff):

Typical path

1. Someone uploads the package; status becomes Submitted
2. ClearToPermit runs a draft review
3. The right staff get notified of draft findings
4. Staff act — for example: send to review, return incomplete, submit deficiencies, issue, or deny
5. The applicant is notified of that staff decision

Rules that do not bend

Package status (illustrative)

Statuses are package-level and appear in the UI + audit trail. Reasons attach when denied / returned.

What the audit trail should record (in order)

1. Draft findings from ClearToPermit
2. Staff notified
3. Human actions (return, in review, findings, issued, or denied)
4. Applicant notified after staff act

Who may upload (accounts)

“Direct upload” still means a signed-in submitter tied to a jurisdiction (which city’s checklist applies) — not an anonymous public dropbox. That keeps packages private, routes the right checklist, and prevents spam uploads.

Account creation in production (recommended):

During the closed beta, gate everyone (staff + submitters):

1. Request access
2. Approval
3. Invite

Do not open public registration until a city explicitly wants public applicant self-serve.

Who is allowed to upload plans?
It depends on the jurisdiction and permit type — not one global rule:

• Many cities accept uploads from the applicant of record (owner) or their authorized agent (architect, engineer, design firm, GC expeditor).
• Some permit types effectively require a licensed design professional (architect / engineer) as the submitter or as a required party on the package.
• Cities often still want a named applicant of record even when the firm uploads the drawings.

ClearToPermit should model submitter role (owner / architect / engineer / firm / GC / staff) and let the city’s rules decide who may create a package for that permit type — not hard-code “owners only” or “architects only.” Ask each design partner who may upload for the pilot permit type.

City permit system (Accela / Tyler / etc.)

ClearToPermit speeds the review workflow; it does not replace the city’s system of record. Yes — integrate over time so status / issuance can sync or deep-link, without making ClearToPermit the permit ledger. Pilot can record permit issued inside ClearToPermit first; official write-back to Accela/Tyler is a later integration when the city wants it.

Notifications & messaging (phased)

Deep links (required when notifications / messaging ship)

Every notification about a package, status change, or finding should open the signed-in user on that package, and when relevant on the specific finding (or message thread).

• Applies to staff alerts (“package needs action”) and applicant notices (“deficiencies submitted,” “permit issued”)
• Prefer stable app URLs with package id + finding id (optional message id)
• Avoid generic inbox-only links

Submission surface (MVP): packages are uploaded from inside the signed-in app (dashboard or package page). No anonymous dropbox, email-in, or staff re-import as a first-class path. Additional channels (city-site deep link, Accela/Tyler handoff, firm API) only when a design partner needs them — and they still create a real ClearToPermit package under a jurisdiction.

---

Canonical workflow — build to this

Treat this as the product spine. New screens, roles, and settings must fit this loop — do not invent parallel intake or auto-decision paths.

1. Sign in
2. Land on the dashboard (home for every role)
3. Choose / confirm city when the user has more than one
4. Upload the package (signed-in; city rules say who may submit)
5. Status: Submitted
6. ClearToPermit draft review (completeness + citation-backed findings)
7. Notify the right staff (and applicant when relevant)
8. Humans act (approve, deny, return, edit findings, send to review, or record issued)
9. Notify the other side; update status and audit trail
10. Applicant resubmits if asked — then the loop continues until issued or denied

Build rules:

1. One home after login — every user lands on the dashboard (see below), not a blank chat or a random deep page.
2. Jurisdiction first — every package belongs to exactly one city / AHJ. Checklist, who-may-submit, notifications, and staff queues are scoped to that city.
3. Draft, then notify, then humans act — never skip notify; never auto-set Returned / Denied / Issued.
4. Role-shaped dashboard — submitters see their packages and upload; staff see their city’s queue and actions. Same product, different primary widgets.
5. City settings drive defaults — who may submit, completeness checklist, adopted codes / local restrictions, notification targets, etc. live in city settings, not hard-coded product logic.
6. Adhere while we create — if a feature doesn’t serve this workflow, park it (lead-magnet pages, SoR sync, SMS, etc. come later without changing the spine).

---

Post-login dashboard

All users land on a dashboard once logged in. That is the default home for submitters and city staff (and ClearToPermit admins).

Dashboard principles:

• Primary navigation: Dashboard · Packages · (City) Settings · Account — Clara is always available as secondary help, never the home screen.
• Empty states teach the next step (e.g. “Upload a package to [City]” or “No packages need action”).
• Notifications and deep links return the user to the package (and finding when relevant); after sign-in with no deep link, always dashboard.
• Do not make chat, settings, or a single package the post-login default.

---

Clara — public (sales) and signed-in (workspace)

Clara is ClearToPermit’s assistant. The product is still workflow-first — Clara is not the home screen. Public Clara converts and educates; signed-in Clara is extremely useful on real work.

Two modes

Search (both modes)

Clara is a search surface, not only Q&A. Users should be able to ask in natural language and get finds + links (or clear “not found”).

Search results should prefer deep links into the right package, finding, or settings section. If nothing matches, say so and suggest a narrower query or the UI filter.

Public Clara bar (sales, marketing, education)

Public Clara’s job is to turn interested visitors into closed-beta subscribers (request access → invite) while staying 100% on ClearToPermit — not Estym8 takeoffs, not generic AI chat.

She should:

• Convert — when intent is clear (city staff, A/E, GC, innovation lead), guide to Request access, Product brief, or Contact; explain closed beta (gated accounts, no charge while evaluating) without pressure or fake scarcity
• Educate on the city’s process — in plain language for cities and submitters: who uploads, completeness vs discipline review, draft then notify then humans act, status the applicant sees, resubmittal, and permit issued
• Search / find — help visitors locate the right product answer or page topic quickly (“where do I request access?”, “how does resubmittal work?”)
• Answer product questions — dual-sided model, who may submit, multi-city membership, city settings, notifications, what is / isn’t automated, Revit path (honest), Accela/Tyler (speed layer, not replacement)
• Stay on brand — ClearToPermit outcomes and trust (staff keep the stamp; never automatic approve/deny/issue). Brief mention of Estym8 only if the user asks about construction takeoffs / GC estimating, then return to ClearToPermit
• Not invent a specific city’s unpublished checklist or claim live package access

Success for public Clara = the visitor understands the workflow and knows the next step to join (request access / talk to us).

Signed-in bar (build to this)

Clara should be able to answer and search, in plain language, for things like:

• What am I working on? — packages on their dashboard / in the open city; current package when they’re on a package page
• Find a package / finding — “find the TI on Main St,” “packages in Draft ready,” “open finding about egress,” “show returned incomplete this week”
• What’s the status? — Submitted, Draft ready, In review, Returned, Findings out, Issued, Denied — and who last acted
• Why did this fail / get returned / stall? — upload errors, processing failures, completeness gaps from the draft, staff return reasons, missing required files — grounded in audit trail + findings, not guesswork
• What do these draft findings mean? — explain citation-backed comments; point to sheet / checklist item when available
• What should I do next? — resubmit, wait for staff, open a finding, check city settings (admin) — guidance only
• Who was notified / who needs to act? — when that data exists on the package
• Find in settings (city admin) — “where do we set who may submit?”, “show our NEC edition”

Context Clara must use (when available):

• Current user, role, and approved cities
• Current city filter / open jurisdiction
• Open package (and finding / message when deep-linked)
• Package status, audit trail, draft vs staff-submitted findings
• Processing / upload error records (why a run failed)
• City settings that affect the user (e.g. who may submit) — explain, don’t silently override
• Search index over the above (authorized scope only)

Hard limits (still non-negotiable)

• Clara never approves, denies, returns, issues, or otherwise changes official package outcome.
• Clara never invents violations or statuses — if data is missing, she says so and points to where to look.
• Clara only searches and sees packages and cities the user is authorized for (same membership rules as the UI).
• Staff and submitters get role-appropriate answers and search hits (staff may see draft queues; submitters don’t see other applicants’ packages).

UX

• Floating Clara (or equivalent) on signed-in surfaces — always one click away from the work.
• Prefer package-scoped answers when a package is open; otherwise dashboard / city scope.
• Treat “find / search / show me / where is” as first-class intents — return ranked results + deep links, not only prose.
• Offer short next steps and deep links into the UI (“Open findings”, “View audit”) rather than long essays.
• Public Clara must not claim she can see live packages until the user is signed in; she may still sell, educate, and search public product topics.

Success for signed-in Clara = the user rarely leaves the product to ask “what’s going on?” or dig through lists — Clara can answer and find it from their workspace.

---

Multi-city — jurisdiction membership

Yes — support multiple cities, and track which cities each person is approved for.

ClearToPermit is multi-tenant by jurisdiction (city / AHJ):

Access rules:

• A user may upload or see packages only for cities where their membership is approved (plus any package they’re explicitly a party to under that city’s rules).
• Closed beta: ClearToPermit / city admin approves city membership after request access — do not assume “signed up once = all cities.”
• If a user has one approved city, skip city picker and use it. If multiple, require an explicit city choice before upload (and default the dashboard filter to last-used or primary city).
• City staff must not see other cities’ packages or settings unless they have membership there.

This is how we keep multi-city honest without a global anonymous inbox.

---

City settings

Each city needs a Settings area (city admin / authorized staff) for defaults that shape intake and review. Product logic reads these settings; it does not hard-code one city’s rules for everyone.

MVP settings (minimum):

Codes & restrictions (city-defined)

Cities configure what “correct for us” means in Settings — not a single national default baked into the product.

Draft findings should cite against this city’s configured pack (edition + amendments + restrictions), and label confidence honestly (suggested vs proven). Staff still confirm or dismiss — settings shape the draft; they never auto-issue.

Next settings (after MVP):

• Reviewer assignment defaults (named vs unassigned queue)
• Required parties on a package (e.g. applicant of record even when firm uploads)
• Richer amendment / restriction editors and pack versioning
• Accela/Tyler or SoR deep-link / sync toggles when integration exists
• Messaging / SMS prefs
• Promotion queue for learn-from-misses candidates (see below)

Settings principles:

• Only city admin (or ClearToPermit admin acting for the city) changes jurisdiction settings.
• Changes are audited (including code pack / restriction edits).
• Submitters see the effect of settings (e.g. “You may upload as Architect for [City]”) — not the full admin console.
• Code packs are per city — one city’s amendments do not silently apply to another jurisdiction.

---

New city onboarding

Short answer: A new city cannot fully self-serve from a cold public signup today. Someone must create the jurisdiction and complete minimum setup before that city uses ClearToPermit. A live meeting is recommended for design partners / first pilots; it is not a forever requirement for every city forever.

Closed beta / design partners (now)

Until the jurisdiction exists and minimum settings are in place, submitters should not be able to upload “to” that city.

Later (scale)

Aim for assisted self-serve city onboarding, not a mandatory sales meeting for every AHJ:

1. City requests access. ClearToPermit approves and creates the jurisdiction (or the city admin finishes a guided setup wizard after invite).
2. City admin finishes Settings (codes, checklist, who may submit). ClearToPermit provides templates / defaults they can edit.
3. City admin invites staff and (if allowed) submitters.
4. Optional success call / office hours — helpful, not a hard gate.

Staff accounts stay invite-only. Full open self-serve for creating a new city tenant is a product decision for later — not closed-beta default.

What “setup” must include (minimum)

• Jurisdiction record (name, display)
• At least one city admin
• Who may submit + submitter invite policy
• Completeness checklist (even a short pilot list)
• Codes & restrictions seed (editions + known local amendments for the pilot type)
• Notification defaults (who gets draft-ready alerts)
• Pilot permit type(s) in scope

Without those, draft review and notify have nothing honest to run against.

Meeting vs async

Policy for now: ClearToPermit ops handles jurisdiction create + first invite; city finishes Settings (with our help on the first one). Do not promise “sign up and upload tomorrow” for a brand-new city with zero setup.

---

Learn from misses — human-gated

Cities will catch things the draft review missed. That should make the next package better — without silent autopilot or inventing violations.

In product (staff action):

1. Staff add a missed finding on the package (sheet / pin optional, description, optional code or checklist cite, severity).
2. Finding is stored on the audit trail as staff-origin (distinct from AI draft) and can go out with deficiencies when staff submit.
3. Staff can also dismiss or edit AI draft findings (false positives) — those signals matter too.

Learning loop (after MVP trust — human-gated):

Guardrails (non-negotiable):

• No silent learning into live city packs — a city admin (or ClearToPermit ops with city approval) reviews and promotes candidates.
• Learning is per jurisdiction by default — one city’s misses do not rewrite another city’s codes.
• Never treat approve/deny/issue outcomes as automatic “train the code checker” labels.
• Opt-in anonymized cross-city learning only with explicit contract language later.
• Still draft + notify + humans act — learning improves drafts; it never auto-returns or auto-denies.

Success: “We missed X once; after promotion, we draft X next time” — with a clear human approval step in City settings or an ops promotion queue.

---

Staffing positioning — empower reviewers, never replace them

ClearToPermit makes government reviewers more efficient and better at their jobs. It does not replace plan examiners, eliminate front-desk or discipline review roles, or take the stamp.

Sell capacity and quality for the people already doing the work, not workforce reduction.

---

UX principle — workflow with AI assist, not a chatbot

Submitters get upload + status + notify-on-change. Staff get draft findings and a clear path to take action. AI drafts and notifies; humans drive every outcome — including permit issued. The system never acts automatically. Clara explains the work; she does not change outcomes.

---

One-liner

Upload a package. ClearToPermit drafts findings and notifies the right people. Humans approve, deny, return, or issue — then the other side is notified. Staff keep the stamp. Not a bid estimate. Never automatic outcomes.

---

Job (and what it is not)

Success = time-to-human-action + deficiency quality + trust + notify-the-right-person — not “FTEs removed.”

Revit / BIM (flagship)

Commercial and institutional packages increasingly include Revit. ClearToPermit treats native .rvt / BIM import as a headline capability: model inventory, completeness against jurisdiction rules, and Revit ↔ PDF consistency over time. PDF remains required for field inspectors where the city already works that way. We do not claim full model QA until a pilot spike proves extract and a first rule pack on real packages.

---

Scale — TI through large packages

One product, scale-adaptive: fast on small tenant-improvement packages; same workflow stages on multi-building / phased sets via classify → processing order → discipline or area bundles. Prove trust on a bounded permit type first; architect for large packages from day one.

---

Who buys / who uses

Buyer = municipality (or shared-services plan-check). Users = (1) submitters who upload, get notified, and track status, and (2) city staff who act on notifications. City staff may also upload when appropriate; the default path is not “applicant submits elsewhere → staff re-imports into ClearToPermit.”

---

Shared engine, separate product

ClearToPermit reuses the same plan-set reading spine as Estym8 (folder/PDF ingest, classify, sheet intelligence, organic evidence for conflicts). It does not ship city cost estimating, and it does not reposition Estym8 as city software. Separate product surface, auth, pricing, and roadmap.

---

Competition (honest)

Municipal AI plan review is not an empty category (e.g. Archistar, CivCheck, Blitz, Govstream, Symbium, CodeComply). ClearToPermit’s wedge is messy multi-file package intelligence, citation-backed comment log, resubmittal back-check, and a serious Revit path — with humans keeping the stamp. We do not claim an empty field for “AI for cities.” Suite-wide, we claim no AI-first portfolio peer on one greenfield spine (see suite map).

---

Core capabilities

MVP (first pilot slice)

• Post-login dashboard as home for every role (submitter queue vs staff action queue)
• Multi-city membership — user approved per city; package always belongs to one city
• City settings — who may submit, checklist, codes & restrictions, notification defaults, pilot permit types
• Direct upload from the app (signed-in; jurisdiction-scoped) — multi-PDF / folder; .rvt when provided
• Status starts at Submitted
• Draft review against the city’s configured codes / checklist — notify staff only; no auto return/deny/issue
• Staff action surface: approve, deny / return (with reason), add / edit findings (including missed findings) — humans take every outcome action
• In review with reviewer name or unassigned (staff-set)
• Append-only audit trail (system draft vs human actions)
• Email + in-app notify the right party of findings / status (staff on draft ready; applicant after staff act)
• Workflow UX — not chatbot-first; signed-in Clara workspace-aware (status, findings, failures, next steps) — secondary UI, high usefulness

Next (after MVP trust)

• Resubmittal back-check (original + comments + revised)
• Stronger notification routing (role / assignee)
• Deeper codes / amendments / restrictions packs + versioning in City settings
• Human-gated learn-from-misses — promote recurring staff-added patterns into that city’s pack
• Stronger Revit object-level checks and Revit ↔ PDF consistency

Later

• SMS + in-app notification prefs
• Messaging (staff ↔ staff notes; staff ↔ applicant), with deep links to package + finding / thread
• Accela/Tyler (or city SoR) integration — sync/deep-link status & issuance; ClearToPermit remains the speed layer, not the replacement ledger
• Parcel/zoning feasibility · multi-department routing analytics

---

Where AI earns its keep

High value early: draft completeness + citation-backed findings against city-configured codes, notify the right person, package overview for staff, audit trail separating drafts from human actions.
After trust: back-check triad; richer code / restriction packs; human-gated promotion of staff-missed patterns so we don’t miss the same issue twice.
Not for AI alone (never automate): stamp authority, approve/deny/return/issue, inventing violations without evidence, silent learning into live city packs.

---

Design-partner workflow (discovery — captured)

Patterns from municipal design-partner discovery (city name private). Treat as illustrative until a partner confirms their own process.

---

Golden evaluation packages — city architect path

Design-partner ground truth: plan sets the partner city already reviewed and approved, plus the audit trail (comments / deficiency history). Optionally include rejected / incomplete front-desk examples.

Intake asks: mix of small and larger packages; electronic PDF (and .rvt if any); audit trail per package; anonymization and FOIA-safe handling; no public republish of plan sets.

---

City discovery questionnaire

Status: [ ] open · [~] partial · [x] answered. Frame as staff efficiency, not job replacement. Use with each design-partner city (do not publish the city’s name in public materials).

Must-have (locks MVP)

1. Completeness checklist — Front-desk complete vs reject list today? Can we get a copy?
2. Pilot permit type — First package type? (commercial, TI, residential, site, …)
3. 90-day win — What would make the city say this worked?
4. Who clicks — Front desk only for phase 1, or building/fire from day one?
5. System of record — Accela / Tyler / other? Export-only OK for pilot? Integration later vs in-app “permit issued” only?
6. [~] Golden packages — Approved sets + audit trail via city architect (count, TI vs large, reject samples, transfer path still open) 6b. [ ] Who may upload — For the pilot permit type: owner, A/E, design firm, GC expeditor? License required?

High value

7. Environmental — As required by project type (trigger list still open)
8. Routing — Parallel or sequential? Who consolidates comments?
9. Comment format today — Spreadsheet, portal, letter? Sample deficiency package?
10. Codes / amendments — Editions + local amendments on comments?
11. Revit in practice — How often? Who opens models?
12. PDF for field — Who publishes the inspector set?
13. Resubmittals / back-check — How are comments closed today?
14. Liability line — What must never be automated?

Nice-to-have

15. Volume — Packages/month; % rejected at front desk; cycle time
16. Procurement — Design partner / MOU / RFP timeline?
17. [~] Stakeholders next — City architect intro; permit tech, building official, fire, IT
18. Competitors already seen — Archistar / CivCheck / Blitz / Accela AI demos?

---

Success metrics

---

Risks (summary)

Draft + notify only · humans take every outcome action · never auto-approve/deny/return/issue · separate SKU so Estym8 stays estimator-focused · start with checklist + few high-value amendments · prove with design-partner packages before platform overbuild · ship PDF path first while Revit spike runs.

---

Related

• ClearToPermit beta landing
• Suite map
• ClearToIssue (A/E pre-issue QA)
• AI-first positioning

Internal execution notes (backlog IDs, naming shortlist, engineering dry-runs) live in the repo only — not on this public page.