What did your city council actually decide?
A locally fine-tuned language model that turns city-council meeting minutes from 8 US cities into plain-English summaries of what was voted on, what was proposed, and what affects residents.
8 cities in the training data · 0 logins or paywalls to use it · ~2 min from query to audio broadcast · 2 failure modes named in the model cardThe problem
City councils decide your rent rules, your bus routes, and your property taxes, and they publish those decisions in some of the least readable documents in public life. Meeting minutes are long, procedural, and written for the record, not for residents. Almost nobody reads them. Local news, which used to do the translating, keeps shrinking.
The information is public. The access isn't. That gap felt like exactly the kind of narrow, high-value job I'd just proven a small model could do with PlainSpeak.
What I built
CivicDigest takes a city and a topic and returns a plain-English summary of what the council voted on, what was proposed, and what affects residents. It's built around a language model I fine-tuned locally with LoRA on Apple Silicon, using the same pipeline as PlainSpeak, pointed at city-council meeting minutes instead of Project Gutenberg.
The summarizer runs locally via Streamlit. On top of it I built a fuller delivery pipeline: search recent council records for the city and topic, summarize with the fine-tuned model, then turn the summary into a broadcast script with generated audio (about 2 minutes) and an AI news video with graphics and a ticker (about 30 minutes to render), emailed to the user. No account, no payment.
Why civic accountability is a fit for small local models
Three reasons, and they're practical, not ideological.
Privacy. What you look up about your local government is sensitive. A renter checking eviction ordinances, an activist tracking a police budget vote. A model that runs on your own machine means those queries never become someone's server logs.
Cost. Civic tools have no business model, which is why they usually die. A frontier-model API bill scales with every user and every query. A small fine-tuned model costs almost nothing to run, so the tool can stay free without a sponsor.
Access. The people who most need plain-language civic information are the least likely to have a paid AI subscription. A local model on modest hardware, or a free hosted demo, meets people where they are. CivicDigest works best with cities that keep public Legistar portals or well-indexed records, and I say so plainly: smaller municipalities with thin online archives produce sparse results.
The training data reality: municipal minutes are a mess, times eight
I trained on council records from eight cities: Chicago, Seattle, Denver, Phoenix, Detroit, Oakland, New York City, and San Francisco. Eight cities means eight formats. Different portals, different document structures, different clerk conventions for recording the same act of government. One city's crisp motion-and-vote entry is another city's three pages of procedural preamble.
That mess is the actual lesson of the project. PlainSpeak trained on Project Gutenberg, which is clean, edited, finished prose. CivicDigest is what happens when the same pipeline meets real institutional documents: boilerplate that has to be stripped, votes buried mid-paragraph, resolutions referenced by number instead of described. The curation step, deciding what a good (minutes → plain English) pair even looks like across eight house styles, was most of the work. The fine-tune itself was the easy part, again.
Editorial judgment, baked in
Eight years around newsrooms taught me that the credibility of a summary lives in how it handles its own errors. So CivicDigest ships with its editorial judgment written down.
Failure modes are named in the model card: dollar amounts and vote counts are called out specifically as the places the model can get numbers wrong. Not "outputs may contain inaccuracies" in gray fine print. The two exact ways it fails, up front.
Verify-against-source is the instruction, not a disclaimer. The documentation tells users to check anything that matters against the official records, and is explicit that the tool is not a substitute for official minutes or legal counsel. It also flags the mundane failure: meetings from the last 24 to 48 hours may not be indexed yet, so a "no results" answer isn't a "nothing happened" answer.
The design position: a civic tool that hides its weaknesses is worse than no tool. If CivicDigest misstates a vote count and the reader repeats it at a public comment session, I've damaged the exact trust the tool exists to build. Named failure modes turn the model from an oracle into a first draft, and a first draft that points you at the primary source is genuinely useful. An oracle that's wrong 2% of the time and doesn't say so is poison.
Outcome
A working system with a public repo (MIT license) and a live demo at civicdigest.app, built solo on the same laptop and pipeline as PlainSpeak. Together the two projects are one argument made twice: small models plus curated data plus honest documentation is a real way to ship AI, not just a paper finding.
GitHub: github.com/Brandi-Kinard/civicdigest
Live: civicdigest.app
Sister project: PlainSpeak
What I'd tell another engineer
Write the limitations section before you write the launch post. Deciding, in writing, exactly where your model fails forces you to actually find out, and it changes the product: once I'd named dollar amounts and vote counts as failure modes, "verify against official records" stopped being a disclaimer and became a feature. Users who know where to double-check trust everything else more, not less.