Publishing 311 data without exposing residents' personal information

Reference article · 7 min read

A 311 service request is a small dossier. It records who called, what they said, where they said it was happening, when, and often what they photographed. Most of that is useful for operations, routing, and performance reporting. Some of it identifies the person who called. Some of it identifies a neighbor who never contacted the city at all and has no idea they are in a municipal database. When an agency decides to publish service requests as open data, the hard part is not the pipeline. The hard part is deciding, field by field, what leaves the building.

The common failure is handling the structured fields carefully and forgetting everything else. The reporter name column gets dropped, the phone column gets dropped, and then a description field ships that reads "my tenant in unit 4B has six dogs and I already told the landlord." Redaction has to cover every surface that carries resident-entered content, not just the columns that look obviously personal.

What a service request actually contains

Before writing rules, inventory the record as it exists in the system of record, including fields your public portal never displays. A typical 311 record carries more than the schema suggests.

• Reporter identity and contact. Name, phone, email, and sometimes an account or login identifier tied to a mobile app profile.
• Free text. Description, internal notes, resolution notes, and any comment threads between the resident and staff.
• Attachments. Photos, video, documents, and voicemail audio or transcripts.
• Location. Exact latitude and longitude, full street address, unit or apartment number, and parcel identifiers.
• Derived identifiers. Device identifiers, IP addresses, app session data, and timestamps precise enough to correlate with other feeds.
• Cross-system links. Case numbers that join to code enforcement, police, or health department records.

Decide the disposition of each one: publish, generalize, or withhold. Write the decision down. A field with no documented decision will eventually be published by default.

Free text is where the leakage happens

Resident-entered text is the single largest exposure and the only part that cannot be solved with a column list. People type their own names and phone numbers into description fields. They type the name of the neighbor they are reporting, the landlord, the tenant, the apartment number, and sometimes a license plate or a medical detail.

Pattern matching catches the easy cases: phone numbers, email addresses, apartment designators, and obvious address strings. It does not catch "the guy in the blue house next to the church." Treat automated detection as a first pass that reduces volume, not as the control. Options, in rough order of safety:

1. Withhold free text entirely from the open dataset and publish structured categories instead.
2. Publish free text only after human review, with automated flagging to prioritize the queue.
3. Publish free text only for request types where resident-on-resident reporting is rare, such as pothole or streetlight requests.

Internal staff notes are a separate category and are usually a poor fit for bulk publication. They contain investigator impressions, third-party statements, and sometimes information staff assumed would stay internal.

Photos and attachments

Photos are frequently published without inspection because they feel like evidence of the pothole rather than a record about a person. In practice they contain faces, license plates, house numbers, mail, vehicle interiors, and, on interior inspection requests, the inside of someone's home. Video and voicemail carry voices and often names.

The conservative default is to exclude attachments from the open dataset and handle them through the records request process, where they can be reviewed individually. If images are published, require detection and blurring of faces, plates, and address numbers, plus stripping of EXIF metadata, which can carry GPS coordinates more precise than the address you just generalized.

Location precision and sensitive request types

Exact coordinates re-identify people even with names removed, because an address is effectively an identifier for a household. Two standard mitigations, used together:

• Block-level rounding. Publish the hundred block, block face, or a census geography rather than the address. This is predictable and explainable, which matters when residents ask what you did.
• Coordinate jittering. Offset the point randomly within a radius. Apply the offset once per record and persist it. If jitter is regenerated each time the file is republished, anyone archiving successive versions can average the noise away and recover the true point.

Sensitive request types warrant more than geographic fuzzing. Homeless encampment reports, hoarding, animal complaints, illegal occupancy, short-term rental complaints, noise disputes, and many code violations are neighbor-reported and retaliation-prone. For these, consider withholding record-level rows entirely and publishing counts by neighborhood or council district. Also watch for low-count cells: one hoarding complaint in a small geography identifies a household no matter how the coordinates are rounded. Set a minimum count threshold below which the cell is suppressed.

Who owns redaction, and where it runs

Redaction should happen in the publishing pipeline, not in the source system, so operations keep the full record and the public view is derived. Name an accountable owner, usually a data governance lead working with the records officer and counsel, and give that person authority to block a release.

Publication is effectively irreversible. Once a file is downloaded and mirrored, an unpublish request does not recall it. Start narrow, run a review period, and loosen later. Build an unpublish and reprocess path anyway, because you will find a leaked field, and you will need to regenerate historical files under the corrected rule.

Open data and public records are separate obligations

Publishing an open dataset is generally discretionary. Responding to a public records request is not. Withholding a field from the open file does not make it exempt, and publishing a field does not waive an exemption elsewhere. State public records laws differ substantially, and several states have specific provisions addressing complainant confidentiality or personal contact information; confirm your state's framework and any local ordinance with your counsel rather than relying on a general rule.

Two practical consequences. First, do not point requesters to the open dataset as your response when they asked for the record. Second, document the basis for each withheld or generalized field, distinguishing "exempt from disclosure" from "disclosable on request but not published in bulk." Those are different determinations and will be challenged differently.

How to start, and what to ask vendors

Begin with a redaction rulebook covering every field and request type, approved by counsel and the records officer, then a pilot publishing a narrow set of infrastructure request types. Expand once the review queue is stable.

When evaluating a 311 platform or an open data publishing tool, ask:

• Where does redaction execute, and can rules be changed and applied retroactively to already-generated extracts?
• Are attachments excluded by default, and is EXIF stripping automatic?
• Can jitter offsets be made deterministic and persistent per record?
• Do public APIs and embedded map widgets pass through the same redaction rules as the downloadable file, or do they read the source table directly?
• Is there an audit log showing which rule version produced each published file?
• What is the process and timeline for unpublishing and regenerating a dataset after a defect is found?

Require these in the contract rather than the demo. Also require that the vendor not republish or resell the underlying data, and that deletion obligations survive termination.

HQT works with state and local agencies on data platform and analytics work, including building and operating the publishing pipelines that sit between systems of record and public datasets.

Frequently asked questions