SF311

Live SF Dashboard with all 311 records
LLM reading every conversation
Uber style instant action

Inspiration

Every day, residents help maintain their communities by reporting potholes, broken streetlights, illegal dumping, water leaks, blocked sidewalks, and other public problems. San Francisco alone receives roughly 775,000 service requests each year.

The problem is not simply collecting those reports. The harder problem begins after a report is received: someone must understand it, determine how urgent it is, identify repeated reports about the same issue, find the right department or crew, and turn that information into action.

When this process is slow, a dangerous bike-lane pothole can sit beside routine maintenance requests. Field workers may be available nearby, but the report and the worker remain disconnected. Residents have done their part, yet the city still lacks a fast way to decide what should be fixed next.

We wanted to make city maintenance feel less like a passive complaint queue and more like a coordinated response system. A well-maintained city is not only more efficient—it is safer, more accessible, and more respectful of the people who call it home.

What it does

The platform improves everything that happens after a resident contacts 311, while leaving the familiar calling and reporting process unchanged.

During a call, the system converts the conversation into structured information: the issue category, location, urgency, safety risk, and a concise summary. The same process can be applied to reports submitted through existing mobile and web channels.

Each case receives a transparent priority score based on urgency, safety risk, and the number of nearby reports describing the same type of problem. Cases appear on a live 3D city map and in a ranked operations queue, allowing dispatchers to see where attention is needed most.

The system then filters field crews by qualification and availability before recommending the closest suitable worker. That worker receives the task on a mobile view with the location, priority, case summary, and estimated travel time. When the worker accepts, the operations dashboard updates immediately and shows that the crew is en route.

For example, our demo begins with a resident reporting a large pothole in a bike lane after a cyclist was nearly hit. The platform recognizes the safety risk, places the case near the top of the queue, maps the location, identifies a nearby street-repair crew, and delivers the assignment to the worker. In the controlled demo, the handoff from the end of the call to a crew recommendation takes approximately 8.5 seconds.

The result is a complete human-supervised workflow:

Resident reports a problem as usual.
AI structures and summarizes the report.
Transparent rules prioritize the case.
Nearby reports are connected as a shared community signal.
The closest available qualified crew is recommended.
A worker accepts the task and the city sees the response status immediately.

Dispatchers remain in control. They can review the recommendation, change priority, merge repeated reports, reassign a crew, or resolve the case.

How we built it

We built the backend with Python and FastAPI. It can ingest live cases from San Francisco's open 311 dataset through the Socrata API, normalize each record, and apply structured AI labels. Pydantic validates the generated category, urgency, summary, and safety-risk fields against a strict schema.

Our priority engine is intentionally understandable. A case starts with an urgency value, receives an additional weight when a safety risk is present, and gains weight when reports of the same category occur within roughly 100 meters. This creates a 0–100 priority score and a yellow, orange, or red map state without allowing the language model to make the entire dispatch decision by itself.

The operations interface uses JavaScript, Vite, and MapLibre GL JS. It combines a 3D San Francisco map, a searchable ranked queue, case details, live call intake, crew locations, and dispatch status. A separate mobile worker interface receives the recommended assignment and sends acceptance back to the dashboard.

The demo is populated with a frozen snapshot of 396 real SF311 cases. We made the demonstration resilient by keeping the city data, crew state, and workflow local. Live transcript extraction uses Codex when available, with validated scripted values as a fallback, so a temporary network or model failure cannot break the presentation.

For a live deployment, the repository includes a DigitalOcean App Platform specification for the FastAPI service, Vite static site, and PostgreSQL database. The production ingestion path supports Anthropic Claude for structured case labeling, while SQLite provides a lightweight local fallback.

Challenges we ran into

Turning natural language into safe operational data. A resident describes a problem conversationally, but a dispatch system needs predictable fields. We constrained model output to a strict schema, validated every response, treated report text as untrusted data, and used safe fallback values instead of allowing malformed output to stop the pipeline.

Making prioritization understandable. It would have been easy to ask a language model for a mysterious score. Instead, we separated language understanding from operational scoring. Urgency, safety, and repeated reports contribute through visible rules that a dispatcher can inspect and override.

Synchronizing the dashboard and worker phone. The call transcript, case creation, map animation, crew recommendation, mobile task, and acceptance state all had to remain consistent across two screens. We built a shared backend state machine so either view can refresh and return to the correct point in the workflow.

Creating a reliable live demonstration. External APIs, model latency, and network connections are risky during a short presentation. We created a deterministic demo mode using real frozen city data and a graceful extraction fallback while preserving the live-data architecture for deployment.

Rendering a detailed city without overwhelming the browser. The original San Francisco building data was too large for a smooth presentation. We simplified approximately 145,000 building footprints into a lighter local dataset and loaded it behind a progress screen.

Balancing speed with human responsibility. Public-service decisions affect safety and access. We designed the system as human-supervised decision support rather than autonomous government. Recommendations remain reviewable, editable, and traceable.

Accomplishments that we're proud of

We completed the entire loop from resident conversation to structured case, priority score, map location, qualified-crew recommendation, mobile assignment, and worker acceptance.
The dashboard uses 396 real public 311 records rather than invented background pins.
The controlled workflow creates a case about five seconds after the call ends and recommends a crew approximately 8.5 seconds after the call ends.
Repeated reports are treated as a connected community signal instead of unrelated entries.
The scoring logic is transparent and can be overridden by a human dispatcher.
The demo supports several civic scenarios, including potholes, dark intersections, water leaks, illegal dumping, graffiti, blocked sidewalks, and accessibility hazards.
The system remains usable if an AI request or external data feed is temporarily unavailable.
We built both the city operations view and the field-worker experience, not just an analytics dashboard.

What we learned

We began by thinking that the main opportunity was faster classification. We learned that classification alone is not enough. The real value comes from closing the entire gap between a resident's report and a worker who can respond.

We also learned that responsible civic AI should explain and support a decision, not hide it. Language models are useful for understanding messy descriptions, but safety-sensitive prioritization needs visible rules, validation, human review, and careful measurement.

Working with real 311 data showed us how quickly individual reports become a city-scale operations problem. Cases arrive through different channels, categories are inconsistent, locations can be incomplete, and several residents may describe the same physical issue differently.

Finally, we learned that reliability is part of the product. A system intended for city operations must degrade gracefully, preserve the original report, and never discard a case simply because one automated component fails.

What's next

Our next step is a pilot with dispatchers and field crews in a city that already uses 311 or Open311. Rather than claiming theoretical savings, we would compare the platform with the existing process using clear operational measures: