Global reference data — jurisdictions, one current permit_rules row each, and permit_sources citations — built out from a prioritised worklist of counties within the builder's service radius. Each merged row records confidence (high/medium/low), whether it still needs phone verification, and the date it was last verified. The collection_queue tracks each county as pending, in_progress, collected, verified or needs_phone.
Also called: permit database · which counties are covered · permit research · verified permit data
- 1collection_queue holds the county worklist with centroid, nearest office, miles and priority
- 2Research for a county is written as <fips>.research.json, optionally with a <fips>.verdict.json adversarial review
- 3scripts/merge-permit-research.mjs merges each county in a transaction: upsert jurisdiction, replace its rule, insert up to 12 source URLs
- 4The verdict can override confidence and the authority phone; an untrustworthy verdict forces confidence low
- 5Anything not high-confidence is flagged needs_phone_verification, and the queue row becomes 'collected' or 'needs_phone'
- 6A partial unique index guarantees exactly one current rule per jurisdiction, so an answer can never be ambiguous
Migration 091 describes collection_queue as 'the operational worklist for the 250-mile build-out' — the module is only as good as the counties actually researched, so coverage is tracked as work rather than assumed. Grading exists because a scraped answer and a phoned-in answer are not the same thing, and the panel must be able to say which it is holding.
- Permitting rules are scattered across hundreds of county websites in different formats
- An unverified answer presented as fact becomes a wrong quote
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →