CivicParse | Devpost

analysis
analysis
compiler
description
home

Inspiration

I grew up in a community shaped by immigration, where switching between languages feels completely normal. At dinner tables, in grocery stores, and in conversations between generations, I hear Mandarin, Hindi, and dozens of other languages alongside English. But the documents that actually govern everyday life—school notices, municipal forms, registration requirements, benefit information—usually arrive in one very different kind of English: formal, cautious, and bureaucratic. Even when every individual word is understandable, a sentence like “Applications received after Friday may not be considered” leaves a much harder question unanswered: So what am I actually supposed to do?

That gap fascinated me because it reminded me that language barriers are not always about translation. A family can know what every word means and still miss whether something is a requirement, a recommendation, an exception, or a warning. Growing up around immigrant families made me notice how much important information depends on correctly interpreting these tiny linguistic distinctions. I wanted to build something that did more than simplify vocabulary. I wanted something that could expose the hidden structure underneath bureaucratic language. That became CivicParse: a compiler for bureaucracy.

What it does

CivicParse takes the kinds of documents families constantly encounter—school instructions, permit notices, renewal forms, and other administrative text—and turns them into a structure that is easier to act on. A user can paste text or import a PDF, and CivicParse identifies whether each clause is REQUIRED, PROHIBITED, PERMITTED, RECOMMENDED, or INFORMATIONAL / RISK. It also identifies who is responsible, what they need to do, deadlines, conditions, exceptions, and possible consequences.

The part that mattered most to me was not erasing the uncertainty already present in the language. If a notice says, “Applications received after Friday may not be considered,” CivicParse does not rewrite that as “You must submit by Friday” and pretend the two sentences are identical. It preserves the original warning and separately shows a practical IMPLIED REQUIREMENT, clearly labeled as inferred. Users can click Show why and see the exact words behind each interpretation, so CivicParse is not asking someone—especially someone already navigating unfamiliar institutional language—to blindly trust another black box.

How we built it

I built CivicParse around an idea from computer science: instead of treating a document like a paragraph to summarize, treat it like source code to compile. The application uses React, TypeScript, Vite, React Flow, and local PDF extraction through PDF.js. Documents stay in the browser, and the core analysis does not depend on an external language-model API, backend, or database.

Underneath the interface is a deterministic linguistic pipeline. CivicParse breaks a document into clauses and analyzes modal expressions such as must, may, may not, and should, along with actors, actions, timing, conditions, and consequences. I created a structured representation called CivicIR to store that information while preserving the exact location of every piece of evidence in the original document. That source tracking is what lets CivicParse highlight exactly why it reached a conclusion instead of generating an explanation afterward.

Challenges we ran into

One thing I learned quickly was that the bureaucratic English I wanted to make easier to understand is difficult precisely because small words carry enormous amounts of meaning. May seems simple, but “Families may submit electronically” gives permission, while “Processing may take longer” describes a possibility. May not can mean “you are prohibited from doing this” or “this might not happen.” A naive system would treat these sentences similarly even though a family reading them should react very differently.

The harder problem was deciding how much CivicParse itself was allowed to conclude. I did not want to solve confusing bureaucracy by creating a system that confidently invented rules. That became especially important when working with implied deadlines and consequences. Eventually, I separated explicit statements and inferred requirements entirely. If CivicParse concludes that Friday functions as a deadline, it must also preserve the fact that the source only said “after Friday” and show the evidence that led to the inference.

Accomplishments that we're proud of

I am proudest that CivicParse became something I could imagine being genuinely useful in the community that inspired it. Instead of producing another paragraph of simplified English, it answers more practical questions: Who has to do something? What do they have to do? By when? Is this mandatory? What happens if they do not? And when the answer is uncertain, CivicParse shows that uncertainty instead of hiding it.

I am also proud that the technical architecture reflects that goal. Every interpretation remains connected to its source, and the application can visualize relationships between actors, actions, deadlines, conditions, and consequences. To make sure I was improving the system systematically rather than only fixing whatever example happened to break, I also built a 60-case synthetic development benchmark across ten administrative domains. CivicParse passed all 60 cases on that frozen development set, including zero false-positive implied requirements, while still treating that benchmark as development evidence rather than a claim of universal accuracy.

What we learned

Building CivicParse changed how I think about language accessibility. I used to think the main challenge for immigrant families was translating difficult English into familiar words. But while building this project, I realized that translation can still leave the most important information unresolved. “May,” “should,” “unless,” and “will result in” are not difficult vocabulary, yet misunderstanding one of them can completely change what someone thinks they need to do.

It also made me appreciate how much trust matters when technology interprets language for people. Someone reading an important school or government notice should not have to choose between confusing bureaucracy and an equally opaque algorithm. CivicParse taught me that a useful language tool should be willing to expose its reasoning: this was written explicitly, this was inferred, this phrase created the deadline, and this is where the system is uncertain.

What's next for CivicParse

I would like to take CivicParse back to the kinds of communities that motivated it and test it against much messier real-world documents: school district notices, municipal forms, library policies, benefit renewals, and other information families actually receive. Real administrative language is far less controlled than a development benchmark, so the next challenge would be finding where CivicParse fails and expanding the linguistic framework around those failures.

Longer term, I would love to extend CivicParse across languages and across different kinds of institutions. For me, the project started with something I had seen throughout an immigrant community: people can understand English and still struggle to understand what an institution is actually asking of them. CivicParse is my attempt to make that invisible layer of language visible—so that understanding an important document depends a little less on already knowing how bureaucracy speaks.