Cimic | Devpost

Inspiration

As urban areas grow, the decisions we make about infrastructure, housing, transit, and zoning affect thousands of lives.

In the City of Atlanta metro region alone: • Public transit usage remains below 5% of commute modes, signaling both opportunity and imbalance. • Despite strong demand, over 15% of housing units remain vacant in some neighborhoods, while median home values have surged by 40% in the past five years. •. Nearly 35% of residents commute more than an hour to work—adding up to millions of hours lost annually.

These numbers aren’t just statistics; they reflect policy decisions made in silos, without holistic modeling. Cimic was inspired by the idea that simulating, visualizing, and exploring choices before they become law could turn what-ifs into insights and reactive systems into proactive ones.

What It Does

Cimic combines geospatial visualization, policy-driven simulation, and AI-generated civic dialogue into one integrated system. The app loads real geographic and demographic data for cities down to the neighborhood and district levels. Each neighborhood is powered by metrics such as population, income, home value, affordability, education levels, diversity, and commute habits, all pulled from city and census datasets.

Users can: • Explore the city visually: Navigate a live, data-driven map where each district is color-coded and labeled with its real-world attributes. • Inspect analytics: View a detailed sidebar with key metrics and graphs, including livability scores, income distributions, education breakdowns, and racial demographics. • Propose a policy: Enter any city-scale change; for example, “increase property taxes,” “expand public transit,” or “rezone industrial areas.” • Run the simulation: The model identifies which districts would be affected, then generates realistic events across the map based on each zone’s demographic and economic profile. • Events appear as pulsating hotspots, representing neighborhood reactions such as population shifts, affordability changes, or altered commute patterns. • Selecting a hotspot opens a panel showing quantitative outcomes (updated metrics) and qualitative insights (narrative event summaries). • Engage with constituents: Each event includes simulated residents who comment on the policy from different perspectives. Users can interact with them through short AI-powered “calls” to understand how the change affects individual lives. • Track evolving outcomes: After each simulation, the city’s dataset updates dynamically, reflecting new populations, housing rates, and livability scores. Simulations can be saved, compared, or shared with others.

How It Works

Overall, our tech stack consisted of React and Tailwind for the frontend, Rust and Azure for the backend, and Python for preprocessing and cleaning data. Below, we dive into how we accomplished specific aspects of our app.

Interactive Map

The map is extremely interactive, and it was all done with the help of GeoJSON data. We used Atlanta's open datasets for geospatial data, which was cleaned with Pandas in Python and implemented into React-Leaflet on the frontend, a lightweight map library that allowed for heavy customization.

Animations

The UI of this website was primarily built using a combination of Tailwind and Framer-Motion. Tailwind provided the base, and Framer-Motion let us create extremely smooth transitions and presence.

State Management

For state management, we used Zustand, as it kept a centralized state on the website rather than having to rely on things like useState or useContext. This made it simple to create the complex array of panels in the interface as data free-flowed everywhere.

Voice Agents

To interact with constituents in the city, we used ElevenLabs to create rich voice agents that had custom voices and previous context. The integration was through ElevenLabs' React SDK, and over 30 agents were created.

Rust Backend with Azure

The backend is built using the Rust programming language and consists of three distinct endpoints that handle different parts of the simulation process. A minimized set of GeoJSON data is sent to the /simulate route, where DeepSeek V3.1 is accessed through Azure AI Foundry.

The simulation runs in two phases. In the first phase, the LLM determines which city data is most relevant for future simulation computations. In the second phase, that selection is fed back into the LLM, which uses it as parameters for generating results. Based on the user’s prompt and the selected city zones, the LLM produces event data that is streamed to the client in real time.

Challenges We Faced

Our first major challenge was optimizing the tokens sent to the Azure LLM. Initially, we passed the entire GeoJSON dataset into the model’s context. This approach worked when the dataset was small, but as more features were added, we quickly hit API rate limits.

To address this, we split the process into two phases. In the first phase, the model generates the simulated target. In the second, it produces the full simulation using only the relevant geographic data. This approach ensures the model never processes the entire city dataset at once, greatly improving efficiency.

The second major challenge was efficiently aggregating and cleaning the GeoJSON data. Our dataset included extensive metadata from real city census sources, so we developed Python scripts to clean, reorganize, and format the data into a lightweight structure suitable for simulation.