Engagement type: Iron Pine IP build Current status: In production
The Problem
When a wildfire alert service identifies a new active fire in a county, someone has to figure out — quickly — which fire agencies have jurisdiction over the affected area and need to be notified. The list is rarely simple. It includes county Office of Emergency Management, the county sheriff, federal partners (US Forest Service ranger districts, BLM field offices, sometimes BIA tribal coordinators), state fire marshals, and any number of local fire departments whose jurisdictions overlap the affected boundary.
The operational pain point is that this list does not exist anywhere in usable form. There is no commercial database that maps US fire agencies to the counties they have jurisdiction over. There is no public dataset that distinguishes "headquartered in this county" from "has jurisdictional authority over this county" — a critical distinction when a USFS ranger district headquartered in one state has authority over national forest land that crosses into three other states. Customer Success teams at fire alert service companies were doing this work manually: calling County OEMs to ask which agencies they coordinated with, then maintaining the answers in spreadsheets that went stale within months.
That manual research process was the actual cost. Every new project initiation required hours of phone calls. Every county added to a service area required the cycle to repeat. Every personnel change at a County OEM required the institutional knowledge to be rebuilt. And the spreadsheets that captured the results were per-team, per-region, per-customer — meaning the same county might be researched five different times by five different teams across the industry, with five different conclusions.
We built the Fire Agency Intelligence Platform to solve this problem once. The deeper question was whether the data could be assembled at all — whether the jurisdictional mapping that did not exist commercially could be computed from public sources.
The Approach
The Phase 1 Integration Assessment focused on the data-availability question first. If the underlying public sources could not support a complete national dataset with computed jurisdictional boundaries, the platform was not buildable regardless of how good the architecture was.
Three findings shaped the build:
The jurisdictional mapping had to be computed, not researched. No source provided "which counties does this fire agency have jurisdiction over." But two sources, taken together, made it computable. Federal land management agencies (USFS, BLM) publish boundary polygons for ranger districts and field offices through their ArcGIS portals — free, public, and updated. The US Census Bureau publishes county boundary polygons through TIGERweb. The intersection of these two datasets, computed in PostGIS, produces exactly the jurisdictional mapping that did not exist commercially. The architecture's central innovation was running this intersection at scale.
The agency discovery had to be cost-disciplined. Discovering 33,000+ fire agencies through paid search APIs alone would have cost more than the project's entire infrastructure budget. The breakthrough was recognizing that 33 states publish centralized OEM contact pages — scrapeable for zero cost. SerpAPI was reserved for the gaps. This split dropped discovery costs by an order of magnitude and made the full national build economically viable.
The data quality layer mattered more than the data quantity. A registry of 33,000 agencies with bad geocoding, inconsistent naming, and missing classification data would be worse than no registry at all. We built data quality scoring into the architecture from day one — every agency record carries a quality score that surfaces incomplete, suspicious, or stale entries for review.
The Phase 2 Integration Build ran across six working sessions. The progression was deliberate: an Idaho proving ground first (44 counties, complete national-scale workflow tested against a small, verifiable dataset), then federal agencies at zero SerpAPI cost, then national county-level OEM and sheriff coverage. The proving-ground step caught six bugs before they could waste credits at scale.
The Architecture
The platform runs on the standard Iron Pine stack — Python backend, Next.js frontend — with one architecturally critical addition: PostGIS, the spatial extension for PostgreSQL.
Data sources. Federal land management boundaries pulled from USFS and BLM ArcGIS portals (free). County boundaries from US Census TIGERweb (free). Agency discovery via primary scraping of state OEM contact pages, with SerpAPI as fallback for gaps. Geocoding via the US Census Geocoder as primary (free, handles 85–90% of US addresses) and Google Maps as fallback for the remainder.
The PostGIS jurisdictional mapping. The architectural centerpiece. Boundary polygons from USFS ranger districts and BLM field offices are loaded into PostGIS and intersected against county boundaries using ST_Intersects. The result is a set of "jurisdictional" agency-to-county links computed automatically — 2,774 of them in the current dataset, on top of 32,735 "headquartered in" links from the agency address data. Together they make 35,509 total agency-county relationships, captured in a junction table that the dashboard reads at query time.
Frontend. Next.js 15 dashboard with React Leaflet for map rendering (free, no API key required). The county detail view loads agencies in three tiers: the junction table (HQ + jurisdictional), then statewide agencies filtered by state, then USFA local fire departments matched by name. This three-tier loading handles data completeness gracefully across different data quality levels — a county with rich coverage shows everything; a county with sparser data still surfaces relevant statewide and local agencies rather than appearing empty.
Multi-tenant from day one. A projects/selections data model supports multiple downstream users with different scoping needs. RLS is enforced on every table. The architecture would support productizing the platform for additional customers without restructuring; that is a deliberate design decision rather than an immediate need.
Data quality scoring. Every agency record carries a data_quality_score computed from a structured rubric — completeness of contact information, geocoding confidence, classification specificity, source reliability. The admin dashboard surfaces low-scoring records for review.
The Outcomes
The platform now contains 33,872 fire agencies across the United States, with 96.3% OEM coverage, 97.3% sheriff coverage, and roughly 89% geocoding completion. Average data quality score across the registry is 78 of 100, with the lowest-scoring records flagged for review.
The PostGIS innovation produced 2,774 jurisdictional agency-county links computed automatically from federal boundary data — added on top of the 32,735 "headquartered in this county" links derived from agency addresses, for 35,509 total relationships. This dataset did not exist commercially before this build and would have taken thousands of hours of manual research to assemble by phone.
The total build cost was approximately $70 per month of infrastructure to operate, with a one-time SerpAPI spend of roughly 5,840 of 15,000 credits to populate the initial dataset. Geocoding costs stayed near zero by routing through the free Census Geocoder for the bulk of US addresses and reserving Google Maps for the remainder. The build duration was six working sessions over 48 hours of focused execution.
The platform is in production and reviewed by external technical stakeholders. It serves as Iron Pine IP — a reusable platform pattern that can be productized into a multi-customer SaaS, licensed as a data product, or embedded as a backend layer for partner platforms requiring authoritative fire agency intelligence.
The Lessons
Five things from this build now inform our approach to similar data-platform engagements:
Computed beats researched, when the source data exists. The most valuable IP in this build was not the agency registry — it was the jurisdictional mapping computed from federal boundary data. Whenever a "this dataset doesn't exist" claim is made, the next question should be "what would it take to compute it from sources that do exist?" PostGIS, geospatial intersection, federal open data — these are mature technologies that make formerly-manual mapping problems automatable.
Free beats paid when free is good enough. ArcGIS portals provided boundary data that would have cost tens of thousands annually as a commercial dataset. The Census Geocoder handled the bulk of US address geocoding at zero cost. OpenStreetMap rendered all the maps without an API key. The instinct to reach for paid APIs first is wrong; the instinct should be to identify what the public data layer covers, then pay only for the gaps.
Cost discipline at the discovery layer is the difference between a viable build and a budget casualty. SerpAPI at $0.01 per query sounds trivial until the project requires 100,000 queries. Splitting discovery into "primary scrape where possible, paid API for the long tail" reduced this build's discovery cost by roughly an order of magnitude. We have since built this pattern into our standard discovery architecture.
The proving-ground pattern catches bugs cheaply. Idaho's 44 counties served as the test bed for the entire national workflow. Six bugs surfaced and were fixed against a known dataset before the national build began. Without that step, the same bugs would have surfaced mid-build, after thousands of credits had been spent on broken queries. Small, known, verifiable dataset first; scale second.
Data quality scoring is not optional infrastructure. A registry with no quality signal is a registry that erodes trust the first time a user finds a stale or incomplete record. Building data quality scoring into the schema from day one — not as a future enhancement — keeps the dataset usable as it scales and surfaces problems before users find them.
Iron Pine helps mid-market companies integrate AI into how they actually operate — grounded in your data, embedded in your workflows, adopted by your people, and operated with production discipline.
Talk to us about an Integration Assessment · Try the AI Health Check