Civic technology

Community Safety Reporting

Report broken lighting and dangerous crossings to the municipality — through a channel designed to stay trusted, abuse-resistant, and unsurveilled.

Scale
Medium
Platforms
iOS · Android · Web
Capabilities
Mobile · Consumer

The concept

A resident notices a dead streetlight, a crossing where cars never yield, a stairwell with a broken railing. Reporting it today means finding the right municipal office, the right form, and the patience for both. The concept is a thin, fast channel: photo, location, category, done in under a minute — routed to the responsible department, with a public status the reporter can follow until the hazard is fixed or formally declined.

Three screens of a hazard report: capture, categorize, and follow its municipal status.

The real product is trust

The form is a weekend of work. The product is everything that keeps the channel worth using in year two:

  • Residents stop reporting when reports vanish into a void — status visibility is core, not a nicety
  • Municipalities stop reading when the queue fills with spam, duplicates, and neighbor feuds
  • Everyone stops participating the moment the channel starts to feel like surveillance

Each failure mode needs a design answer, and the answers pull against each other. That tension is the study.

Abuse resistance

The most reliable defense is structural: categories describe infrastructure and conditions, never people. There is no field in which to report a neighbor. Free text is bounded and attached to an asset category; photos are prompted toward the hazard, not the street scene. On top of that sit conventional controls — per-account and per-location rate limits, duplicate clustering by proximity and category, and a municipal triage view that surfaces clusters instead of raw volume, so one pothole reported forty times reads as one strong signal rather than forty chores.

Anonymity versus accountability

Full anonymity invites abuse; full identity chills reporting. The working model is pseudonymity with one-time verification: an account is verified once as belonging to a real, distinct person, then reports carry only a stable pseudonym and its track record. The municipality sees reliability, not names. De-pseudonymization exists solely under a defined legal process, and the policy is published where every user can read it — a promise is only credible when its exceptions are written down.

Avoiding surveillance creep

The cheapest way to keep a privacy promise is to not hold the data. Precise capture metadata is stripped to coarse location; reporter histories are never exportable in bulk; retention windows are short and published. The system is deliberately shaped to be a poor surveillance instrument, so that no future administration can quietly repurpose it.

Deliberately no AI judgment

It is tempting to auto-score severity, filter “low-quality” reports, or rank the queue with a model. The concept declines all of it. A model quietly deciding which resident concerns deserve municipal attention is a political act wearing a technical costume. Routing and deduplication run on explicit, inspectable rules; judgment belongs to accountable humans inside the municipality. If that ever changes, it should change as a public policy decision — not a model update.

Prototype scope and open questions

A credible prototype is the resident capture flow, one category set, a plain triage queue for the receiving side, and end-to-end status updates. The questions worth answering before anything more: does visible status genuinely change whether people report a second time (the retention hypothesis); what verification threshold keeps abuse manageable without excluding renters, students, and visitors; and whether a municipality will adopt a channel it does not fully own.

Facing a similar problem for real?

This study's reasoning — discovery, architecture, evaluation — is exactly what a HummingByte engagement looks like. Bring us the real version.