When PEU connects: aggregated helpline drop-in

When PEU connects, tenants' calls to the helpline arrive here as an aggregated CSV of address, date, and issue-category triplets. This product stores only per-batch counts and quality metrics, never tenant PII. Below is the most recent fixture run: each row's address is resolved to a canonical BBL via NYC Planning Labs GeoSearch, and rows are classified as matched / ambiguous / unmatched / rejected.

Methodology →

Latest fixture batch

Fixture batch · Jul 15, 2026, 09:23 PM

Source fixture

Details

Batch ID: fixture-2026-07-15-01

PASS

Total rows

Matched

Ambiguous

Unmatched (address)

Rejected (schema)

Matched fraction 100.0% of 15 real addresses. Thresholds: PASS ≥ 85%; WARN ≥ 75%.

Required CSV columns

Column	Type	Example
address	string	1036 Dean Street, Brooklyn, NY 11216
date	ISO date	2026-05-14
issue-category	string	heat-hot-water

Optional columns: borough_hintzip_hint

Forbidden columns

A row containing any of the following columns is rejected before matching. No tenant PII is ever stored in this product.

tenant_name
tenant_phone
tenant_email
call_content
unit_number
unit
apartment

Matching process

Normalize each row's address string (uppercase, expand common abbreviations, strip punctuation).
Resolve the normalized address to a canonical BBL via NYC Planning Labs GeoSearch:
https://geosearch.planninglabs.nyc/v2/search?text={query}
Classify each row as: matched, ambiguous, unmatched, rejected_forbidden_column. Rows with a top-feature confidence ≥ 0.80, a resolvable BBL, and a matching house-number/street-name become matched; borderline rows become ambiguous; no-resolution rows become unmatched. Rows carrying any forbidden PII column are rejected before matching.
Retry 3 times with exponential backoff on transient GeoSearch failures.

The batch table stores only aggregated counts and quality metrics. Tenant PII never enters the product and is not stored.