Skip to main content
← Proof·PUBLIC INFRASTRUCTURE·Benchmark Study

Four days of warning
before the Brooklyn blackout.

52,636 electrical complaints. One Brooklyn grid. 18 months of public 311 history. The pipeline discovered 254 patterns without a single rule written — and matched the pre-blackout cascade at 90% similarity, four days before Con Edison lost power to roughly 72,000 customers.

4 days
Advance lead signal
254
Patterns discovered
0
Rules written
90%
Match on outage-day cell
Dataset: NYC Open Data — 311 Service Requests (Socrata 76ig-c548)Source: opendata.cityofnewyork.us ↗Published: April 2026

DisclosureBenchmark study on public opendata.cityofnewyork.us data. No customer data was used. Reviewed by Drew Wasem, Founder, Coherany. Methodology available on request.

THE METHODOLOGY

We stopped reading 311 as a work queue and started reading it as a sensor network.

Everyone treats 311 as customer service — a call comes in, an agency logs it, someone dispatches a crew, the ticket closes. NYC gets about 3 million 311 complaints a year. Every call is geocoded, timestamped, and tagged with a complaint type. Read that again. It is a citywide sensor network with human nodes, pretending to be a work queue.

We pulled 52,636 Brooklyn electrical complaints from January 2018 through June 2019. Before any pattern work we standardized the vocabulary. Over 90 distinct descriptor strings in the raw data — POWER OUTAGE, NO LIGHTING, Wiring Defective/Exposed, dozens more — collapsed into 11 stable complaint families.

Then we built fingerprints. One row per grid cell per day. Brooklyn gridded at 0.01 degree resolution, roughly 1.1km by 0.85km cells. Each cell is a monitoring station. Each fingerprint captures the complaint types and intensity in that cell over the prior 48 hours — relative to that cell's own historical baseline, not a borough-wide threshold.

That per-cell baseline is the mechanism. A commercial strip in DUMBO that logs 4 electrical complaints in 48 hours is normal. A residential block in Marine Park that logs 4 in 48 hours is a cascade. Severity is always measured against what the cell typically generates, not against a number someone picked.

THE DATA

Eighteen months of Brooklyn, every call geocoded.

52,636
Electrical complaints
25,235
Discovery fingerprints
11
Complaint families
1.1km
Grid cell width

THE FINDINGS

Four days of distributed signal before the grid failed

We fed 25,235 discovery fingerprints into a pattern-discovery algorithm with no labels and no hand-written rules. Four minutes later, 254 stable patterns. Human analysts reviewed all 254, named them (Insight IDs 1545 through 1798), and approved the library. The engine then applied the approved library to July 2019.

01

Baseline 0–3 cells per day. July 17 hit 5. July 18 hit 6.

The normal July baseline is 0 to 3 cells per day at spike or cascade severity, and in the first half of the month the count never exceeded 5. Then July 17 arrived and the chart stopped looking like noise. Five cells on July 17. Six on July 18, and the cells were distributed across southern Brooklyn — not the same ones that fired the day before. A diffuse, simultaneous elevation across the grid, four days before the outage.

02

Brownsville, July 21: 90% match to a named, human-approved pattern

On outage day, zip 11212 (Brownsville / East New York) had 16 complaints in a 48-hour window, 5 confirmed power outages, and all three cascade modes active simultaneously — outages, wiring defects, signal failures. The pipeline matched it against Insight #1759 (multi-mode electrical cascade) at 90% similarity. Not a generic anomaly. A match to a specific, named, human-approved pattern seen repeatedly across 18 months of Brooklyn history.

03

Every alert is traceable to a named insight and a named approver

When the infrastructure review asks what did we know and when, the answer is a timestamped list: every cell, every day, every pattern match, every human-approved insight it matched against, every similarity score. July 18 Williamsburg Insight #1793. July 20 Bensonhurst Insight #1609. July 21 Brownsville Insight #1759 at 90%. That is not a retrospective reconstruction — it is what the architecture produces when it runs.

THE RESULT

The pattern matched a pre-blackout cell at 90% similarity, four days early.

90%
Similarity match on outage-day Brownsville cell

Full pipeline runtime from pull to approve: roughly 7 minutes. Discovery found 254 stable patterns in four minutes, 3,945 noise fingerprints that did not cluster into anything nameable, and zero rules authored by hand. Analysts named and approved the library. The engine did the rest.

The day after the outage, the cell count peaked at 17 — the aftermath of 72,000 customers calling 311 within 24 hours of losing power, confirming in the data what the grid already knew. The pattern before that spike is the one the ops manager needed to see. It was there, in public data, four days early.

“The usual AI vendor demo shows you dashboards. The interesting demo shows you the approval queue — every pattern named, every name signed, every match traceable.”

DW
Drew Wasem
Founder, Coherany

HONEST LIMITS

What this does and does not prove.

This is a retrospective validation against a known event. The pipeline did not predict the July 21 outage in real time — it demonstrated that the signal was present in public data that was already available, and that the approved pattern library would have matched it. A production deployment would require live Socrata ingestion, live classification, and a defined alert escalation path into the grid operator. What the benchmark proves is that the architecture works on a dataset anyone can pull today, and that the signal is real in data the city already publishes. The only question is how much earlier the warning can reach the people who can act on it.

This isn't really about 311 calls.

Every customer-service queue at every utility, every municipal government, every large property owner is an unlabeled sensor network pretending to be a work queue. The same four steps run on your claims, your tickets, your maintenance logs. Request the methodology or run it on your own data.

We use cookies for essential site functionality. No advertising or tracking cookies. Privacy Policy