AI-Powered Community Voice Intelligence for Local Government
zencity · Government · 2025 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.4 (schema v2)
Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.
Problem
Domain: Civic engagement and local-government decision support
ZenCity needed to synthesize community voices from surveys, social media, 311 requests, and other sources into trustworthy insights that local officials can use in existing workflows.
Constraints:
- Local-government data is multi-tenant and politically sensitive
- Officials need citations and cannot rely on invented civic facts
- Response latency matters for ad-hoc assistant queries
Architecture
ZenCity uses a layered civic-intelligence stack: raw surveys, social listening, news, 311, and engagement data enter a warehouse; domain-specific sentiment, topic labels, semantic search, precomputed elements, highlights, and insights progressively summarize that data; workflow brief generation and an MCP-backed assistant then let government users retrieve tenant-scoped answers with citations.
Diagram confidence: reconstructed (reconstructed from prose).
flowchart LR civic-data-warehouse["civic-data-warehouse"] sentiment-and-topic-enrichment["sentiment-and-topic-enrichment"] semantic-search["semantic-search"] elements-layer["elements-layer"] highlights-layer["highlights-layer"] insights-layer["insights-layer"] brief-generation-engine["brief-generation-engine"] mcp-api-servers["mcp-api-servers"] zencity-assistant["zencity-assistant"] civic-data-warehouse --> sentiment-and-topic-enrichment civic-data-warehouse --> semantic-search sentiment-and-topic-enrichment --> elements-layer sentiment-and-topic-enrichment --> highlights-layer elements-layer --> highlights-layer elements-layer --> insights-layer highlights-layer --> insights-layer insights-layer --> brief-generation-engine brief-generation-engine --> mcp-api-servers semantic-search --> mcp-api-servers mcp-api-servers --> zencity-assistant
Components
| Component | Role | Interacts with |
|---|---|---|
civic-data-warehouse |
Centralizes surveys, social posts, news, 311 records, post-interaction surveys, and direct resident engagements before enrichment. | sentiment-and-topic-enrichment, semantic-search |
sentiment-and-topic-enrichment |
Labels each data point with local-government-specific sentiment and shared topics that join surveys, social data, news, and 311 requests. | civic-data-warehouse, elements-layer, highlights-layer |
semantic-search |
Lets the assistant and analysis workflows search civic text semantically rather than relying only on keywords. | civic-data-warehouse, mcp-api-servers |
elements-layer |
Precomputes permutations of dashboard/API calculations so LLM workflows can access numbers without doing math on the fly. | sentiment-and-topic-enrichment, highlights-layer, insights-layer |
highlights-layer |
Uses deterministic rules to identify notable trends, such as discourse growth over a time window. | elements-layer, insights-layer |
insights-layer |
Synthesizes topic-specific raw data and highlights into concise explanations for a time period. | highlights-layer, brief-generation-engine |
brief-generation-engine |
Combines multiple topic insights into workflow-specific briefs for budget planning, crisis response, strategic planning, and department leaders. | insights-layer, mcp-api-servers |
mcp-api-servers |
Expose existing tenant-scoped dashboard APIs as tools the assistant can call through multiple negotiation turns. | semantic-search, brief-generation-engine, zencity-assistant |
zencity-assistant |
Agentic user interface that sanitizes requests, asks MCP tools for available data, retrieves breakdowns, and answers only with cited civic evidence. | mcp-api-servers |
Data flow
Resident signals are collected from surveys, social media, news, 311 records, and engagement tools. Each item is labeled with local-government sentiment and topics, then aggregated into elements, highlights, and insights. Brief workflows combine topic-specific insights into role-specific packets, while the assistant negotiates through MCP servers over existing APIs to select surveys, pull breakdowns, and cite the data it used.
Why this architecture
ZenCity split deterministic calculation and source citation from LLM synthesis because civic users need trustworthy numbers, tenant isolation, and low-latency answers. Existing APIs already enforced tenant boundaries, MCP made multi-turn data negotiation possible, and the elements layer avoids asking the LLM to calculate large cross-tabulations in real time.
Models used: LLMs · topic models · local-government sentiment model · text embedding models
Scale
- ZenCity processes close to a million social-media items per day through its sentiment model.“We bring in I think somewhere close to a million social media items a day and so every one of those gets labeled with sentiment which we've built a model that is uh specific to local government”transcript, stated
- Many public-safety surveys run monthly, while community surveys often run quarterly, creating long-running longitudinal civic data.“Many of the clients run those every quarter. Those blockwise public safety surveys, those many clients are running them monthly and so we're collecting a lot of information over a long time”transcript, implied
- The product serves local governments across the US, Canada, and the UK.“Yes. Uh mostly in the US. We also work with local government agencies in Canada and in the UK as well.”transcript, stated
Alternatives considered (roads not taken)
Letting the LLM calculate survey and dashboard metrics directly from raw data
Rejected because: The team found LLMs were not reliable enough at math, so it added precomputed elements for permutations of API calculations.
Single-shot custom middleware where the model asks once for all required data
Rejected because: MCP gave the model multiple cycles to discover surveys, request specific results, and negotiate with data APIs without custom compute in the middle.
Allowing LLMs to rewrite resident anecdotes and quotes inside reports
Rejected because: The LLM sometimes reworded or fabricated similar-sounding anecdotes, so exact quote insertion and linking became deterministic.
Patterns
tool-use-orchestration (agent-architecture)
The assistant negotiates with MCP-backed APIs over multiple turns to discover surveys, request results, and drill into demographic or geographic breakdowns.
rag-retrieval (retrieval)
The assistant answers from ZenCity's own data layers rather than from general model knowledge.
hybrid-search (retrieval)
Topic labels bridge structured civic categories while semantic search supports natural-language searches over content.
safety-policy-enforcement (trust-and-safety)
System prompts instruct the assistant not to guess and to use only MCP-exposed APIs with exact supporting data points.
llm-as-judge (evaluation)
ZenCity is building a second-model review flow for topic labels, with disputed cases routed to humans.
Tradeoffs
How to protect multi-tenant civic data while giving the agent tools.
Chose MCP servers on top of existing tenant-scoped APIs over new direct model access to shared data stores.
Rationale: The existing APIs already enforced tenant isolation and security boundaries.
Which steps should be generative.
Chose LLM-driven selection and synthesis with deterministic insertion of sensitive facts and quotes over letting the LLM freely rewrite numbers and anecdotes.
Rationale: The team found that exact data and quotes needed deterministic handling for trust.
Gotchas (what bit them)
The LLM should not rewrite evidence that must be exact.
Root cause: When given anecdotes, the model sometimes quoted verbatim, sometimes reworded, and sometimes fabricated similar-sounding text.
Resolution: ZenCity makes exact quote and source-link insertion deterministic rather than AI-generated.
In-flight evals can violate assistant latency requirements.
Root cause: A human is waiting for ad-hoc answers, so doubling response time for full verification is not acceptable.
Resolution: ZenCity performs input validation in-flight and weekly annotations for model accuracy, precision, recall, and consistency.
One-shot data retrieval limited assistant quality and latency.
Root cause: Their pre-MCP approach forced the model to ask for all needed data in one round while custom middleware gathered it.
Resolution: MCP enabled iterative model-to-data negotiation and removed custom compute from the middle of the trace.
Evaluation
ZenCity combines citation requirements, input/request validation, weekly annotations, and planned LLM-as-judge plus human review for disputed labels.
Metrics: accuracy · precision · recall · citation coverage · consistency over time
Outcomes
- ZenCity can produce workflow-specific briefs and ad-hoc answers from community data.
- The assistant correctly refuses unsupported questions rather than inventing civic facts.
The platform processes close to a million social media items per day and unifies them with surveys, news, 311 records, and resident engagements.