Every theme in this library — Dallas's PE seals, Houston's HCAD validation, TNMP's approve-before-install sequence, code editions that vary by city — converges on one operational conclusion: the scarce asset in multi-jurisdiction solar isn't crews or leads, it's structured knowledge of what each jurisdiction and utility requires, kept current. Companies carry that knowledge three ways: in a veteran coordinator's head (doesn't scale, quits eventually), scattered across old emails and folklore (decays silently), or as a maintained database every job draws from. This is the how-to for door number three.
The schema
One record per authority — and "authority" means every gate a job passes, not just cities: AHJs, utilities, and even repeat-player HOA management companies. Per record:
- Identity and reach: name, type (city / county / TDU / muni / co-op), boundary notes and gotchas (ETJ behavior, annexation traps — jurisdiction determination fails at the edges).
- Codes: enforced NEC / IRC / IFC editions, local amendments, with a last-verified date on each — undated code facts are rumors.
- Submittal profile: required permits, forms, portal and credentials, fee schedule, the full document checklist (the plan-set calibration layer), stamp thresholds, ESS addendum.
- Process facts: review-clock behavior, inspection types and scheduling quirks, expiration rules, re-inspection fees.
- Sequence rules: what must precede what — the difference between Oncor's rhythm and TNMP's lives here.
- Live performance: your own medians — days-to-issue, first-pass approval, correction categories — because the published process and the experienced process diverge.
- Contacts and escalation paths: the counter phone number that answers, the DG engineer who responds, dated.
Sourcing and maintenance
Populate on first contact, ruthlessly. The first job in a new jurisdiction pays a research tax — official checklists pulled, a call to the counter, the profile drafted — so the second job pays nothing. Codify it as a "new-jurisdiction intake" task with a template (the expansion sprint is this at market scale).
Feed it from the work. Every correction, deficiency, fee surprise, and portal change is a database update, made the day it's learned — the coordinator's weekly review (the playbook) is the enforcement mechanism. A database fed by the work stays true; one maintained "when someone gets time" is folklore with a schema.
Re-verify on a clock. Perishable fields (fees, code editions, portals, program terms) get a six-month verification cycle; legal-framework fields get a legislative-session review. Every fact carries its date. The review dates on the guides in this library are exactly this discipline applied to published content — the internal database runs the same way.
Build vs. buy, honestly
Spreadsheet-era databases hit the same wall as spreadsheet-era trackers: the knowledge exists but doesn't attach to jobs, so coordinators still hand-carry it. The requirement that matters in any build-or-buy decision: profiles must flow into the work automatically — a new job resolves its address to its authorities and inherits their checklists, sequences, and clocks with zero human lookup. That inheritance is the difference between a reference document and an operating system, and it's the architectural heart of TexPTO: the database and the job tracker are one system, so knowledge captured on Tuesday's correction protects Thursday's submittal — for every coordinator, not just the one who learned it.
FAQ
How many jurisdictions before this is worth it? The honest answer is "the third one" — that's when the same question gets researched twice and the tax becomes visible.
Who owns the database? The permitting coordination function, with edit rights broad and verification responsibility named. Ownerless databases decay to folklore in two quarters.
What about third-party AHJ data services? Useful as seed and cross-check; never sufficient alone, because your live performance layer and your correction history are the parts competitors can't buy.
What's the minimum viable version? One page per authority with the submittal checklist, sequence rules, and dated code editions — plus the discipline of updating it the day anything is learned. Schema can grow; discipline can't be retrofitted.
Sources
- The per-authority facts this database holds are documented throughout this library's city and utility guides — the database is those guides, structured, dated, and joined to your own performance data.
Operations guidance. The schema flexes; the dated-fact and fed-by-the-work disciplines are the non-negotiables.