A municipal agent needs current permitting, tax, and GIS data for reasoning. Which approach best integrates those heterogeneous sources?
Select an answer to reveal the explanation.
Short Explanation
Three city systems speaking three dialects need a nightly translator, not a resident with a USB stick. ETL that loads permitting, tax, and GIS extracts into the knowledge lake keeps the agent stocked.
Full Explanation
A municipal agent that reasons over current permitting, tax, and GIS data needs a disciplined integration path: nightly (or similarly scheduled) ETL that loads extracts from those systems into the knowledge lake (or curated store) the agent consumes. Heterogeneous civic sources become usable when transformed, joined, and refreshed on a governed cadence rather than ad hoc chat pastes.
Asking residents to paste raw database dumps each session shifts operational burden onto the public and yields inconsistent, unsafe inputs. Relying on weekly printouts scanned only when an auditor visits cannot support day-to-day agent reasoning. Hard-coding last year’s tax rates and ignoring GIS updates guarantees stale answers.
Exam caveat: ETL freshness must match decision risk—emergency GIS layers may need faster than nightly refresh. Operational check: after a known permitting or tax change lands in source systems, verify the lake and agent-facing store reflect it on the next successful ETL, with monitoring on job success and row-level freshness. Publish data contracts for each source system so schema drift in permitting, tax, or GIS breaks the ETL loudly. Alert when any of the three source extracts (permitting, tax, GIS) is missing from a successful nightly lake load.