Wake: Civic Action Made Accessible

Homepage
Issues
Legislation Search
Legislator Dashboard

Inspiration

Engaging with the numerous laws and budgets in cities and states is overwhelming, to say the least. Especially for non-native English speakers, it's a struggle to be proactive in the policy-making process, frustrating both legislators and constituents.

Growing up around non-native parents and siblings in the government, we got to see both sides of the spectrum and knew that this was a meaningful problem to tackle, and a great application for language models.

We believe our website will help our cities and communities in the near future by providing an accessible way to participate in civic action, compelling more people to action.

What it does

At its core, Wake gives residents a simple and central way to report local issues and suggest community improvements. It then turns that input into clear, actionable insights for legislators to use with a mix of community driven interaction (upvotes and downvotes) as well as AI analysis (Gemma 4).

Not only that, our website breaks down the language barrier with Gemma 4, providing accessibility to a broad range of citizens. We know how hard it is to read through legislation documents and propose changes to local government when English isn't a first language - that's exactly why we built this project. Through full site translation and language support for features on the website (all through Gemma 4), we believe our project is accessible to all.

Through our website's "Legislation" feature, users can input a legislation document. For example, citizens curious about the spending breakdown for a city can download the proposed budget document and upload it for ingestion through our RAG pipeline. Documents get processed and chunked so that Gemma 4 can easily understand and search through them.

Then, users can ask Gemma 4 with any question, in any language. Utilizing Gemma 4's language capabilities, our backend processes the query and returns an answer, fully in the original language.

One of the biggest features of the entire platform is crowdsourcing issues through the “Issues” and “Suggestions”. The “Issues” tab allows citizens to report pressing problems in their city, such as potholes, fallen trees, broken streetlights, etc. The “Suggestions” tab allows citizens to report legislative concerns and suggestions.

Problems submitted through both of these features are reflected to all users on the platform, where they can then vote on which issues they think are most important. Furthermore, Gemma 4 is used throughout the entire pipeline by providing a severity ranking to the issue that is taken into account when ranking the most pressing issues. It also provides an LLM driven analysis of the issue and explains its reasoning.

At the end of a voting period, legislators receive the top ranked Issues, visible through their Dashboard. This dashboard includes numerous other features, like demographic reports on each feature through census data, an integrated map of voter districts and racial/social equality index information through ArcGIS, and statistics on top topics.

How we built it

Lots and lots of planning and iteration!

We started by establishing the features we wanted, then creating a highly detailed architectural document through repeated back-and-forths to ensure we had a stable foundation to work off of.

Because of the modular architecture design, we were then able to delegate relatively easily and work in parallel to finish the features we were each best at.

Tasks were divided into categories: UI/frontend, and backend tasks like data ingestion, Gemma 4 model usage, user signup and login, etc.

Challenges we ran into

In such a complex project, synchronizing environments was definitely tough. Hot reload doesn't pair too well with Docker, so we spent an embarrassing amount of time just getting our .env files and dependencies in order.

In the future, we plan to make better use of GitHub secrets to mitigate this problem. Furthermore, there was a lot of messing around with merge conflicts within the repository as we pushed our changes in a fast developing codebase. To fix this issue in the future, we definitely plan to setup branches for each of our features before developing, which would allow us to more easily merge changes without conflict.

Accomplishments that we're proud of

Definitely the complex full-stack architecture, as well as the RAG pipeline, open source database aggregation, GIS integration, and front-end UI design. We were fully unfamiliar with many of the technologies used here, and we’re extremely proud of how the design turned out despite that.

For instance, Integrating MapBox was extremely difficult and annoying to get set up, but visually seeing the interactable map become more and more like our vision was amazing.

What we learned

A whole lot about web design, government APIs, fullstack integration, and working in a quickly changing codebase!

Our whole group felt pretty confident towards their back-end development skills, but at the start the front-end was very undesirable and bland. We put a ton of effort into learning front-end development and experimenting with unfamiliar tools such as GSAP, ArcGIS, and MapBox to have an interactive and visually pleasing UI. This experience was extremely challenging, and with our group’s minimal UI design experience, we had to learn many many topics on the spot. We did a ton of research online about visually pleasant UI development, and felt incredibly inspired by an amazing UI one of our team members found online: https://oryzo.ai/. We used it as reference and wanted to encapsulate as much of it as possible into our work, most directly seen in our landing page.

None of us had any experience working in such a high-paced team environment. We ran into many conflicts because of how quickly the codebase was changing hourly, and we were regularly being pushed back because of communication issues and version-control. We were regularly hitting merge conflicts, divergent branches, and general disagreement hourly. It took us until the end of the second day to get a feel for each-other’s workflow. Over time though, we were able to gradually sync up our work and become a much more coherent and effective team. Working in this hackathon has been a blast, and we definitely left as a stronger and more collaborative team.

What's next for Wake: Civic Action Made Accessible

Talking to legislators, of course! Our family members are a great place to start, and we'll also reach out to potential users to gather feedback to improve the platform. Adoption starts and ends with the UX, after all.

We also plan to polish user experience, primarily through a more refined way to vote on issues. While the RAG works well for the time being with a small dataset of documents, we plan to use more advanced ways to refine the search to provide more accurate responses.

Currently, we only use Seattle as a proof-of-concept, but our idea is instantly scalable and usable for neighborhood or even state-sized data as well. In the future, we’re looking to scale our project even bigger by contacting local legislators and proposing our platform as a potential addition to the legislative process.

We believe our app can have genuine impact for both citizens and legislators, and our hope is to take this project beyond a prototype and into a deployed website in the near future.