PermitDiff

The problem

Construction teams already have permit portals. The expensive part is the exception layer: a record is stale, another communication conflicts with it, or the procedural next step is unclear. A human then stops work, calls the office, repeats the permit identifier, writes down status and missing items, and still has to decide whether anything officially changed.

PermitDiff is not a phone bot for polling government offices. It is an exception resolver.

The judge-visible outcome

The product has three states:

1. Fresh record → no_call_needed. CALL-E is visibly not called.
2. Stale + grounded match → verified_match.
3. Stale + grounded discrepancy → discrepancy_detected, while official confirmation remains required.

The best outcome is often doing nothing. Product value begins with calls avoided.

Demo: https://permitdiff.vercel.app

How it works

PermitDiff first evaluates a deterministic no-call gate against a frozen permit-portal snapshot. Only staleness or an explicit applicant-side conflict makes one authorized CALL-E call eligible.

For an eligible exception, CALL-E asks only for factual information tied to the exact permit ID:

• current office-reported status
• known missing items
• next procedural step
• reported inspection readiness

The call is explicitly forbidden from requesting approval, acceleration, waivers, legal interpretation, payment, inspection changes, or commitments.

The returned evidence must bind to the accepted CALL-E call ID, exact destination, jurisdiction, permit ID, snapshot hash, and recipient-side transcript quotes.

Then PermitDiff computes the diff.

Phone evidence can reveal a discrepancy. It cannot acquire administrative authority. Even if a person says “issued” on the phone, PermitDiff does not rewrite the portal or declare the permit legally effective.

Product surface

Instead of a chatbot, PermitDiff is designed around an exception queue:

• GREEN — current, no action
• STALE — call eligible
• CONFLICT — evidence required
• WAITING — official confirmation

A judge can immediately see what needs attention, what does not, and why.

Technical implementation

• Published CALL-E Python SDK on the live execution path
• Deterministic freshness/conflict gate
• SHA-256 identity for the frozen portal snapshot
• Strict structured result schema
• Exact call/destination/jurisdiction/permit/snapshot binding
• Recipient-side quote grounding
• Applicant-side authorization and exact destination allowlist
• Durable SQLite reservation before dispatch
• outcome_unknown after ambiguous provider outcomes; automatic redial blocked
• Fail-closed routing for wrong permit, wrong destination, low confidence, incomplete schema, voicemail/refusal, or ungrounded evidence

PR: https://github.com/CALLE-AI/awesome-phone-call-agents/pull/199

What makes it different

A generic office caller tries to place a call successfully.

PermitDiff first asks whether a call should happen at all. Its trigger is the state of a specific frozen public record; its output is an evidence-bound diff; and downstream authority stays with the municipality or authorized human process.

Real-world validation boundary

A live pilot requires an applicant-side participant who is actually authorized for the exact permit case. The pilot should measure:

• calls avoided by the no-call gate
• calls placed
• answered / no-evidence outcomes
• discrepancies surfaced
• operator minutes displaced
• duplicate-call rate

It should not claim faster approvals or better permit outcomes without evidence.

Why it is worth building

Portals solve the normal case. PermitDiff targets the expensive exception: when the digital record and the human process no longer agree.

Built With

• call-e
• html
• javascript
• pytest
• python
• sqlite
• vercel