Methodology

How we collect

We collect from two publicly available City sources, both free and open to anyone. Records from each source are merged by request ID:

1. Public REST API. Returns service type, date, location, coordinates, status, and community votes. Covers DPW (Public Works), DPU (Utilities), PDR (Planning), RPD (Police), and DPR (Parks). June 2018 – present.
2. Power BI dashboard API. The same database behind the City’s Insights dashboard. Covers all departments — including DSS (Social Services), DOF (Finance), and HSD (Human Services) — and provides close dates. March 2021 – present.

When both sources have a record, the REST API provides the service categorization (service type and group) and the Power BI source provides the department and close date.

Example record

Here’s an actual request from our dataset — a pothole report with 5 community votes, submitted March 2026, resolved in 10 days:

View this request on the City’s site: DPW000228495 on rva311.com. Every Public-visibility record (about 42% of our archive) has a link like this. Private-visibility records (the remaining ~58%, mostly benefits and hardship cases) are not published individually on the City’s site, so they have no per-record URL.

Status codes

The City’s API returns integer status codes. We inferred the labels by spot-checking numerous records against the City’s website:

Department tag provenance

The City began consistently tagging each 311 record with a department around 2022; older records often arrived without a tag at all. To present a complete department breakdown without silently mislabeling records, every record in our archive is classified into one of four buckets, and the source of its department tag is recorded alongside the value itself.

Counts come from the live database. The all-time column reflects the entire archive; the last-30-days column shows recent ingestion. The ID-prefix bucket is mostly historical — the City tags new records with a department reliably enough that the prefix fallback rarely fires on recent records.

What each bucket means

• Tagged by the City directly. The City’s data feed included a department on the record. We use it as-is.
• Inferred from request type. The City left the department empty, but the request type (e.g., “Pothole on Road”) always maps to a single department in records the City did tag. We use that mapping. The lookup is derived at runtime from the tagged portion of the dataset.
• Inferred from record-ID prefix. The request type was ambiguous (it appears under more than one department in tagged records), but the record ID begins with one of six prefixes that map to a named department with at least 99.6% reliability: DPW, DSS, DOF, DPU, PDR, HSD. Other prefixes that look departmental (e.g., RPD and CS0) are deliberately excluded — they have meaningful cross-department drift in the tagged data, so using them would mislabel records.
• Could not classify. Neither the request type nor the record-ID prefix yielded a confident department. These records still appear in our archive, but we do not display a department label for them on public surfaces.

When we display a record whose department was inferred, the detail page surfaces a disclosure naming the department, the inference path, and the date the inference was applied. See any record with department_source beginning with inferred_from_ on the request detail page.

The unclassified records

803 records (0.16% of the archive). Each row below is a distinct combination of request type and record-ID prefix that neither inference path could resolve.

Limitations and variances

• Call center records excluded. The City’s system includes internal call center logs (IDs starting with “CS”). The City’s own dashboard excludes them, and so do we.
• Pre-2021 data quality. About 7% of older records have garbled category values from system maintenance windows. These are excluded from analysis.
• Close dates. 444 records from 2018–2019 are missing close dates because they predate our Power BI source. An additional 69 records are missing close dates in the City’s own data.
• District assignment. About 100,000 records — mostly from Finance and Public Works — have no coordinates in the source data, so they cannot be assigned to a council district. An additional ~4,000 Social Services records have coordinates that fall outside the City’s district boundaries.
• District boundary version. The City’s Power BI dashboard uses pre-2022 council district boundaries for its district assignments. We use the post-redistricting boundaries adopted by Ordinance 2022-132 on May 23, 2022. This causes our district counts to differ from the City’s dashboard by about 0.4% of records — primarily along the District 2 / District 3 boundary, which changed significantly in redistricting. Our boundaries are the legally current ones; the City’s dashboard has not yet been updated.
• Duplicate closures. ~4% of completed requests were closed as duplicates. We include them because excluding changes median resolution time by less than 0.2 days.

Reconciliation with the City’s PBI dashboard

The City of Richmond publishes its 311 data on a public dashboard at rva311.com. It shows monthly counts of requests opened, requests closed, and breakdowns by department and neighborhood — but no single “currently open” total. We run a nightly comparison against the City’s published data, request by request, so we can catch drift early. Here’s how the most recent comparison lines up for a settled month, looking at Public Works (DPW):

For older months, our archive matches the City’s data exactly. The most recent month or two can show a small lag — the City’s dashboard sometimes records a closure a day or two before we pick it up on the next sync, typically a sub-1% gap that closes on the following day. Settled months always come back to zero difference.

The “currently open” count isn’t something the City publishes. We add it up ourselves by counting every request the City’s system still has marked as Assigned or In Progress. About 16% of currently-open DPW requests were submitted before 2022 — we include them because the City’s system still has them flagged as open.

Definitions

Dates and timezones. All dates on this site are in Eastern Time (America/New_York), matching the City’s own dashboard.

Resolution time. Calendar days from submission to completion. Only computed for completed requests with close dates.

Service type vs. service group. Service type is the specific request (e.g., “Pothole on Road”). Service group is the category (e.g., “Roads, Alleys, Sidewalks and Ramps”).