BUILD CONTEXT Working demo / pilot tool to accompany our proposal to the City of Detroit, Office of Contracting and Procurement (OCP) on behalf of the Elections department, for RFP 548227 "Scalable Voter Education Platform". The objective is a personalized, scalable voter education platform that makes civic information clear, accessible, and personally relevant, particularly for residents who are underserved or disengaged by traditional political content. Unlike traditional election portals that focus on candidate directories, the solution centers the user experience around public policy issues (housing, education, public safety) and connects those issues to relevant legislative actions, elected officials, and active candidates, translating complex municipal and state data into plain-language summaries. The demo URL will be shown to Detroit OCP and Elections evaluators. Real working screens with realistic seeded data. Proposal is due 2026-07-13; the build sprint runs 2026-07-06 to 2026-07-27. Data integrity and full source traceability are paramount to public trust and are explicitly scored. THE SOFTWARE WE'RE BUILDING Core capabilities: 1. Location-based personalization - accept a user ZIP code (with a path to expand to full address routing) to identify their specific local, state, and federal jurisdictions. Dynamically surface current officeholders (incumbents) and active candidates for upcoming election cycles based on that location. Uses the City base-units geocoder standard (mocked for demo). 2. Issue-centered architecture - users select specific civic issues of interest (housing, education, public safety). The system aggregates all jurisdictional data, candidate positions, and relevant public records around the selected issues, and provides plain-language explanations of how each issue functions at the local level and its direct community impact. 3. Leader and candidate profiles - standardized profiles for every surfaced official and candidate, including office title and jurisdictional boundaries, issue-specific position summaries, a clear explanation of how the system determined the candidate's position, and direct clickable hyperlinks to the supporting public source documents. 4. Data integrity and auditing - ingestion from official government and legislative APIs or verified data repositories, fully traceable and auditable information pathways, and a user interface that explicitly shows voters what information a summary is based on and why it is appearing on their screen ("why am I seeing this" plus source links). 5. City data standards and interoperability - machine-readable data access via an ODBC-compatible reporting database and/or an API returning JSON, CSV, or XML. Full documentation of APIs (field names, objects) and the database schema. Ability for the City to programmatically update data via API. Field-level metadata stored and displayed in the UI when appropriate. Data governance so the City can centralize, port, and reuse the data. Confidentiality, integrity, and availability controls, and adherence to applicable compliance standards (NIST, ISO, PII). 6. Admin content management - City and Elections staff curate issues, sources, and jurisdictions, and review and approve AI-generated summaries (human-in-the-loop) before they are shown to the public. 7. Public transparency dashboard - shows data provenance, source freshness, and coverage by jurisdiction so the public and the City can trust the pipeline. User roles: - Resident / voter (public, no login) - enters ZIP, selects issues, browses officials, candidates, and positions with sources. - Content admin (City / Elections staff) - curates issues and sources, reviews and approves AI summaries. - Data steward - manages source connectors, data quality, and provenance. - Auditor - read-only across the audit log and provenance. - System admin - user management and configuration. Integrations: - Official government and legislative data APIs (bill/legislative data, election and candidate data) - mocked for demo, structured like real feeds. - City base-units geocoder and Base Units Database (mocked for demo). - ODBC-compatible reporting database export. - AI / LLM for plain-language summarization with inline source citation (with a written explanation of how the AI functions, per RFP Section 5.7). - Email / SMS optional for civic reminders. Technical baseline: - Web app, responsive, accessibility-first (public-facing, serving underserved residents; WCAG 2.1 AA). - AuthN: public browse without login; staff SSO with role-based authZ. - Data: PostgreSQL. API-first REST/JSON, OpenAPI-documented, plus an ODBC-compatible reporting view. - Retrieval-augmented pipeline: ingest official sources, retrieve, and generate plain-language summaries with inline source citations and provenance metadata. - Audit log: every summary generation logged with its sources, model, and timestamp; append-only and queryable. - Field-level metadata storage and display. - Hosted: a single dev URL styled as a Detroit-Voter-Education portal. - Compliance posture: SOC 2 Type II (assume held), plus NIST / PII handling and confidentiality, integrity, availability controls. Demo storyline the build must support: 1. A Detroit resident enters ZIP 48226 and selects "Housing" and "Public Safety" as their issues. 2. The platform surfaces their local, state, and federal jurisdictions plus current officeholders and active candidates for the upcoming cycle. 3. For "Housing," it shows plain-language summaries of relevant legislative actions and each candidate's position, each with a "why this is shown" explanation and clickable links to the source documents. 4. The resident opens a candidate profile: office and boundaries, issue-specific positions, how each position was determined, and source links. 5. The resident clicks a source link and lands on the underlying public record. 6. A content admin logs in, reviews a newly AI-generated summary, sees its source citations and provenance, and approves it. 7. A data steward views the transparency dashboard: source freshness, coverage by jurisdiction, and the audit trail. 8. An auditor opens the audit log: every summary shows its sources, model, and timestamp. Build-out priorities for the sprint: - Working UI for storyline steps 1-8 (real screens, real data flow). - Seeded realistic data: the City of Detroit plus a few jurisdictions, 8-12 officials and candidates, 3-4 issues, and plain-language summaries with realistic source citations. - ZIP-to-jurisdiction routing working for a set of Detroit ZIP codes. - Issue-centered browse plus candidate and official profiles with clickable sources. - Data-integrity and provenance UI ("why am I seeing this" plus source links). - Admin summary-review (human-in-the-loop) flow. - Transparency and audit dashboards with charts. - REST API plus OpenAPI documentation and a JSON data export that satisfies the City data standards. - Deployed to a public URL that the proposal can deep-link into. Out-of-scope for the sprint: - Real government and legislative API integrations (mock with realistic sample data). - Real City base-units geocoder (mock the ZIP-to-jurisdiction map). - Real staff SSO (mock the staff login). - Full statewide or national jurisdiction coverage (demo a Detroit subset). - Real SOC 2 audit artifacts (assume the posture; not executed in this sprint).