Offline AI for Civic Reporting: Kerbside Explained

What Kerbside does - and what it does not do

Kerbside is a small open-source tool that turns observations made on a walk into structured civic information. A resident records a voice memo and a GPS track on a phone. Later, an organiser processes those files on a laptop. The output can include a map, a short report, and tabular data for a portal or community group.

A walk can capture problems like a damaged footpath, a blocked drain, a road dug up for construction, or a streetlight that isn't working. It can also capture positive observations, like a tree providing shade. The broader view matters: a street audit should describe what's there, not only collect defects.

The workflow targets one specific form of friction. People can often describe what's wrong in plain speech, but turning that into something consistently located, categorized, and shareable takes time. Kerbside uses transcription plus a language model to draft a report by placing each observation along the route you walked, then producing outputs you can share.

It does not file complaints automatically. The person who walked the route reviews the findings, removes mistakes, and edits the wording before sharing anything. That boundary is a deliberate product choice, not a small interface detail. If an incorrect report goes to a city department, it wastes staff time, confuses residents, and can make people stop trusting the tool. Automatic submission might be faster, but for uncertain input, human approval is the safer fit.

The intended users include residents, resident welfare associations, students, and non-governmental organisations running walkability audits. Not everyone has to install or run the software. Residents can record walks on their phones; one organiser can process the files and share the map or report.

Open the live map from the project's real campus walk to see how findings appear. The project is available in the Kerbside GitHub repository, under the MIT license.

How the offline AI pipeline works

Kerbside takes a voice recording plus a GPS track and processes them on the user's laptop. It uses faster-whisper for speech recognition and Gemma 3 4B through Ollama to classify what was said.

The basic flow is:

1. Work out when the voice recording began.
2. Transcribe the recording into timestamped sentences with faster-whisper.
3. Match each sentence's timestamp to a location on the GPS track.
4. Ask Gemma to classify the sentences and draft findings.
5. Generate a map, report, GeoJSON, and CSV.
6. Let a person review and edit the findings before sharing.

You can run it from the command line or through a local web interface. The creator tested it on a Windows laptop with an Intel i5 processor, 16 GB of RAM, and no GPU. The local interface listens on 127.0.0.1, so the processing stays on that machine instead of sending recordings to a remote service.

What a real walk revealed

The most useful test wasn't a clean scripted demo. It was a 12-minute evening walk on a college campus, recorded on an iPhone and processed on a laptop. The first system had been tested against scripted examples; real speech behaved differently.

People don't talk like issue trackers. They narrate what they pass: greenery, the back of a shop, a tennis court, or a change of direction. On the real walk, Gemma initially generated 47 findings - about 40 of them were scenery, not actionable observations.

Adding more prompt instructions about what not to count helped only a little. The bigger improvement was to classify what each sentence was before trying to turn it into a finding. If a sentence looked like general description or chatter, the code dropped any attached issue category. The project also moved some predictable work into code. For instance, if a sentence adds details without naming a new street feature, it can be joined to the previous finding - even across chunk boundaries.

After those changes, the walk produced 11 draft findings. Six were genuine observations: construction materials, a road barricaded with tape, cut trees, and an unfinished road. Five came from speech recognition errors. For example, Whisper misheard a phrase about a volleyball court, and another named building was transcribed in a way that Gemma treated as "a chair blocking the footpath." The model's guess was plausible based on the transcript - but the transcript was wrong.

The reviewer removed the false findings, corrected wording, and moved two observations to where they were actually seen. The pattern - 47 initial outputs, then 11 drafts, then six reviewed findings - makes the division of labour clearer: AI can draft and organize, and the person who made the observation decides what's accurate.

That same walk also found a non-AI problem: the GPS tracker didn't have background location permission. When the phone locked, tracking stopped, leaving only the first and last minute of the route. The resulting report showed 143 metres walked, with most locations marked approximate. Kerbside flagged the weak location data, but it couldn't recover GPS points the phone never recorded. The project's instructions now tell users to set location access to Always before starting.

This is a useful reminder for anyone building AI-assisted products. Better model output can't compensate for missing or poor input data. A working system has to account for the phone, its permissions, file timing, model behavior, and the person reviewing the result.

Why the design choices matter

A voice recording plus a GPS track can reveal where someone lives, when they leave home, and the route they take. It also contains their voice. For a report about a pothole or a blocked drain, sending that data to an external API can be an unnecessary privacy cost.

Kerbside's local-first setup avoids that transfer: transcription and analysis happen on the laptop, and the resident chooses what reviewed findings to share. For the project's published example, the full transcript was not included in the public repository; only the six reviewed findings were shared.

Local processing isn't a magic privacy guarantee. Devices get lost, files get shared by mistake, and even a map of reviewed observations can reveal patterns. Groups still need to decide where recordings are stored, who can access them, and when they should be deleted. But by keeping raw audio and routes off a third-party service, there are fewer parties to trust by default.

There's also a practical side: operating cost and control. A residents' association might not have budget for ongoing API use, and a tool that depends on a changing free tier can become useless when the terms change. Open-weight models also let the project run without per-request cloud fees. The MIT-licensed code, the local rules, and outputs in formats like GeoJSON and CSV make it easier for community groups to inspect and adapt the system.

Of course, local models have trade-offs. They can be slower, require a laptop that's good enough to run them, and they can produce mistakes that still need review. The evaluation shows a related limitation: the scripted test sets got the categories right, but severity could still be off by one level, and details like a pole number could end up treated as chatter. The real walk also showed how speech recognition errors can survive into a confident-sounding but false interpretation.

None of that is a reason to dismiss the approach. It just clarifies where it fits. Kerbside works best as a tool for creating a reviewable first draft, not an automated authority on street conditions. The output becomes useful when a person checks the finding, the location, the wording, and the urgency before sharing it.

This same principle applies beyond civic reporting. When AI processes observations that could affect public decisions, the product needs visible uncertainty, a real human review step, and a clear account of what data leaves the device. Local models help with one part of that design; they don't remove the need to build the rest carefully.