Methodology
How the Record counts
What we count, where the data comes from, how a release is approved, and what the numbers cannot tell you.
Principles
- Every published number comes from an approved, versioned snapshot with a named source and an as-of date.
- No findings are generated by AI. Plain-language findings in the Bulletin are produced by fixed rules in the release script, and a person reviews the release before it publishes.
- Nothing publishes automatically. An operator confirms each release; failed checks leave the last approved release in place.
- Old snapshots are never edited. Corrections are new snapshots plus a labeled Record update.
The counting unit
An event is one distinct pair of an ACRIS document and an eligible residential property (BBL). A document that affects ten eligible properties counts ten times. The reporting date is the recorded or filed date in ACRIS Master, never the date a document was signed.
Eligible properties are residential lots in PLUTO with at least one residential unit, inside the configured ZIPs. Rates are events per 1,000 eligible properties.
Geography
Neighborhoods are approximate operational ZIP groupings, not official boundaries. Each ZIP is assigned once in this MVP. The assignment file is config/neighborhoods.json, version 2026-09-29.1.
| Neighborhood | Borough | ZIPs |
|---|---|---|
| East New York | Brooklyn | 11207, 11208, 11239 |
| East Flatbush | Brooklyn | 11203, 11210 |
| Canarsie | Brooklyn | 11236 |
| Cypress Hills | Brooklyn | None. 11208 is assigned exclusively to East New York in this MVP. No separate non-overlapping ZIP is available for Cypress Hills. |
| Bushwick | Brooklyn | 11221, 11237 |
| Astoria | Queens | 11102, 11103, 11105, 11106 |
| Brownsville | Brooklyn | 11212 |
| Bedford-Stuyvesant | Brooklyn | 11216, 11233 |
| Crown Heights | Brooklyn | 11213, 11225 |
Report windows
Where a ZIP has full ACRIS history in the source, its report covers the latest complete twelve months and compares them with the monthly median of the prior four years. ZIPs whose source history starts with the citywide feed (March 2026) report fewer months, and their coverage note says so.
To compare neighborhoods fairly, use the common window: the most recent months that every configured ZIP covers in full.
How a release is approved
- Stage. Copy the source tables into a separate build database.
- Build. Compute monthly activity and run source and reconciliation checks. Any failure stops the release.
- Review. An operator reviews the candidate release and confirms publication.
- Publish. The release JSON is written with its ID and methodology version.
- Import.
npm run record:importconverts the approved release into a versioned snapshot, recording the reviewer, input file, and its SHA-256.
What the numbers cannot tell you
- Recorded activity is not a fraud, safety, or legal-risk score. A recorded document does not show that anything improper happened.
- Counts do not separate types of buyers or lenders.
- ZIP groupings approximate neighborhoods; lots near a boundary can fall on the wrong side.
- Short windows move with seasonal patterns.
Method history
The earlier ZIP Activity Pulse (as of August 31, 2026) counted distinct documents per ZIP over two consecutive twelve-month periods. Its numbers are not comparable with Bulletin events. It is kept as a historical snapshot.
Current Bulletin methodology version 2026-10-12.1, release bulletin-20261012T064343Z-32fb57e5.
Corrections
If you find an error, tell us. We publish a correction as a Record update that names what changed, and we keep the earlier snapshot available.