New York City’s 311 open-data update describes two separate changes: renamed visible column labels and a split between historical and more recent records. A researcher can adjust one and still miss the other. The city’s explanation is useful when an old tutorial no longer matches the dataset a reader sees.

The city’s published changes

The NYC OpenData update, checked on 3 October 2026, says the visible labels Complaint Type and Descriptor became Problem and Problem Detail. It says the backend names used for API access remain unchanged.

The same note describes a split into 2010–2019 historical records and 2020-to-present records, with the latter keeping the former web address. This article reads the update; it has not queried either dataset or tested an API request.

A label change is not a new observation

A revised column heading can make an interface easier to understand without changing the underlying observation being analysed. Do not treat the new wording as proof that the city began collecting an entirely new kind of record.

For a technical workflow, identify both the visible heading and the actual field used by the query. Copying a display label into a script without checking the technical schema may create a problem unrelated to the substantive data. Current documentation should resolve that mapping.

A saved address may now cover a shorter period

The city’s note says the more recent dataset retained the existing address. That matters for an old bookmark or tutorial: the address alone may not communicate the historical coverage a reader expects. Check the dataset’s period before interpreting an apparent disappearance of older records.

A question spanning the split needs a deliberate historical-source plan. This article does not supply combined totals or guarantee that two exports can be joined without further checks. Record identifiers, field definitions and the chosen time boundaries must be examined in any actual analysis.

Extra detail still belongs to a request

The update identifies additional contextual fields and describes Additional Details as a subset of Problem and Problem Detail. A more detailed description should not be treated as an independent event merely because it appears in another column.

Likewise, a request count is not automatically a count of unique people or proven underlying incidents. We give no neighbourhood ranking, agency-performance score or conclusion that a reported condition was verified. Those would require a separate methodology and actual data work.

A reproducible starting note

Record the dataset title, period, field mapping and date consulted before building a comparison. This keeps interface changes separate from changes in coverage. The city’s update supplies the reason to review those choices; it does not supply the results of a data analysis that this publication has not performed.

Related regional guides are in our Local Services archive.