The Highest-Crime ZIP Code in Cincinnati Has Almost Nobody Living In It

We built a crime-data-by-ZIP-code MCP server, pointed it at Cincinnati, and asked it for the worst ZIP code in the city. It answered 45267. That ZIP code is a hospital. It is the postal designation for the University of Cincinnati academic medical campus, and essentially nobody lives there. The index had not found the most dangerous place in Cincinnati. It had found a division problem.

This is the failure mode we want to write about, because it is not a bug in the sense of a typo. Every step of the arithmetic is correct. The incident counts are real. The population figure is the official one. The rate is what you get when you divide the first by the second. The result is still nonsense, and no amount of care inside the calculation would have caught it, because the error is in the assumption underneath the calculation: that a ZIP code is a place where people live.

A ZIP code is not a place

A ZIP code is a set of mail delivery routes. It is an operational artifact of the Postal Service, maintained for the convenience of carriers, and it has no legal existence as a geography. It has no boundary in the sense a county has a boundary. It is a label attached to addresses, and the shape you see on a map is something a vendor drew by connecting those addresses.

The Census Bureau does not tabulate ZIP codes. It tabulates ZIP Code Tabulation Areas, which are built by taking each census block and assigning it to whichever ZIP code appears most often among the addresses inside it. There are roughly forty-one thousand USPS ZIP codes and roughly thirty-three thousand ZCTAs, and the gap is where our problem lives. The Census Bureau is explicit about this in its own documentation for ZCTAs: a ZCTA may not exist for every ZIP code, ZIP codes covering primarily nonresidential or post office box addresses may have no corresponding ZCTA at all, and a ZCTA may represent a single institutional or corporate delivery point address.

That last clause is worth reading twice. The Census Bureau is telling you, in its methodology notes, that some of the rows in your ZIP-level population table describe one building. Not a neighborhood containing a building. The building.

Why a hospital is the worst possible case

A hospital ZIP code fails in three directions at once, and the three failures compound rather than cancel.

The denominator collapses. Resident population is a nighttime measure. The census asks where you usually sleep. Patients are enumerated at their home addresses; staff are enumerated at theirs. An academic medical center with thousands of employees, an emergency department running around the clock, and a steady flow of visitors can post a resident count in the low hundreds or lower. Divide anything at all by that and the quotient is enormous. The smaller the denominator gets, the more violently a single incident moves the rate — which is the same disease we wrote about in Three Burglaries Is Not a Trend, except that here the denominator is not merely small. It is measuring the wrong quantity.

The numerator inflates. Hospitals attract recorded crime independent of how dangerous they are. Emergency departments are where assault victims arrive, where overdoses are logged, where psychiatric holds happen, where property gets taken from waiting rooms and unattended bags. More consequentially, police records frequently locate an incident at the place it was reported rather than the place it occurred. A stabbing that happened four miles away and arrived by ambulance can end up geocoded to the emergency room door. This is the same class of artifact that makes a police headquarters the highest-crime address in many cities, and we walked through the mechanics in the geocoding problem. The academic medical campus adds one more wrinkle: universities operate their own sworn police departments, so the reporting agency changes across the ZIP boundary too.

The smoothing cannot tell the difference. The standard defense against small denominators is to add a prior — a floor under the population, or a Bayesian shrinkage that pulls unreliable rates back toward a reference mean. Both are correct tools for the problem they solve. Neither solves this one. A floor of, say, five hundred residents turns an absurd rate into a merely implausible one and lets it stay at the top of the ranking. Shrinkage pulls the estimate toward the mean in proportion to its uncertainty, but the estimate is not uncertain in the statistical sense. There are plenty of incidents. The count is well measured. It is being divided by the wrong number, confidently.

Noise is not bias

This is the distinction we got wrong for a day, and it is the one worth taking away from the whole episode.

Small-count noise is a variance problem. A block with three burglaries has a rate you cannot trust in either direction, and shrinkage is the right response: borrow strength from neighboring areas, widen the interval, refuse to rank. That machinery works because the errors are random and centered on the truth.

A hospital ZIP code is a bias problem. The error is not random and it does not average out. Run more years of data through it and the estimate gets tighter around a number that is wrong. Every smoothing method in the literature assumes you have handed it a valid exposure measure and are worried about how much of it you have. Hand it an invalid one and it will faithfully reduce the noise around a false answer.

Reaching for smoothing when the problem is bias is the most common mistake in this corner of the field, and it is seductive because the output looks better. The extreme values come down. The map stops screaming. Nothing has been fixed.

Approach one: exclude, and say so

The cheapest correct answer is to refuse. Set an exposure floor — a minimum resident population, or better, a minimum count of residential delivery points — and for any ZIP code below it, do not return a rate at all.

The important detail is what “do not return a rate” means at the interface. It does not mean returning zero, which reads as safe. It does not mean returning the raw count, which reads as a rate to anyone who is not paying attention. It means returning a typed, structured refusal: a null score, a reason code such as insufficient_residential_exposure, the incident count as a separate field, and the score of the surrounding area as context.

The cost is coverage holes, and they are not evenly distributed. Central business districts, airports, campuses, ports, and industrial tracts are exactly the places a commercial user is most likely to ask about. An index that goes quiet on downtown is a hard product to sell. But quiet is better than wrong, and this is the approach we would ship first while building the others, because it can be implemented in an afternoon and it cannot produce a false accusation about a real place.

Approach two: fix the denominator

The intellectually honest fix is to stop using resident population and start estimating how many people are actually present. That argument is the whole subject of the companion piece on ambient population — Manhattan losing eight hundred thousand daytime people while its crime rates were computed against residents — so we will not re-argue it here. What that piece treats as a general property of the fraction, a hospital ZIP code turns into a divide-by-zero.

Two sources do most of the work at ZIP granularity specifically. The first is the Census Bureau's LEHD LODES series, specifically the Workplace Area Characteristics files, which give job counts by census block. A hospital ZIP code with a handful of residents has thousands of jobs, and those jobs are a direct measure of how many people are standing in it on a Tuesday afternoon. LODES is free, national, updated annually, and aggregates cleanly to any geography you can express in blocks.

The second is the HUD USPS address file, which publishes quarterly counts of residential and business addresses by ZIP code. It is the cleanest available signal for the question “is this ZIP code a place where people live?” A hospital ZIP code has a business address count in the single or double digits and a residential count at or near zero. That is a classifier, not an inference, and it is available for every ZIP code in the country including the ones with no ZCTA.

The combined exposure measure we would build looks roughly like this: take resident population, subtract the residents who commute out, add the workers who commute in, and add a visitor term scaled to establishment type. Weight the non-resident terms below one, because a worker present eight hours is not equivalent to a resident present twenty-four. The exact weight is a judgment call and should be published rather than buried — as should the fact that the resulting number is an estimate with its own error, which is now inside your denominator.

Two honest caveats. Daytime population fixes the hospital's denominator but does nothing about its inflated numerator, so a medical campus will still read high, just less absurdly. And every ambient population estimate degrades at exactly the small geographies where you need it most.

Approach three: infer population from crime — and why it is a detector, not a fix

The idea has real appeal. If we know roughly what crime rates look like nationally from FBI data, and we know what the adjacent ZIP codes look like, we could invert the relationship: take the observed incident count, divide by a plausible regional rate, and back out the population the crime implies. Where the census fails us, let the crime tell us how many people are there.

It does not work as a denominator, and it is worth being precise about why. If population is inferred from crime, and the rate is then computed as crime divided by that inferred population, the two crime terms cancel. Every ZIP code you apply it to returns approximately the reference rate you assumed. You have not estimated anything. You have built an elaborate machine for printing the regional average, and it will be most confident exactly where you know the least.

But turn it around and it becomes genuinely useful. Compute the implied population and compare it to the census figure. Do not use it. Just look at the ratio. When a ZIP code's crime volume implies forty times more people than the census counts, that ratio is not telling you the population — it is telling you the denominator is broken. It is a diagnostic, and a good one, because it fires on the whole family of problems at once: unique ZIP codes, report-location artifacts, boundary mismatches, stale population vintages, ZIP codes that were split or retired. We would run it as a nightly check over every ZIP code in the index and route the outliers to a different scoring path.

There is a non-circular version of the same instinct, and it is the one to build. Infer population from signals that are correlated with population but independent of crime: residential delivery points, employment counts, building footprints, parcel records, utility connections, school enrollment. Those give you an estimate you can then check against crime without the estimate having been made of crime. The inference is the same shape. The inputs are what make it legitimate.

The rest of the zoo

Once you have a detector, you find out the hospital was not special. Every geography with a population that does not sleep there produces the same artifact:

• Airports. Enormous throughput, near-zero residents, and their own police agency.
• Central business districts. Daytime population can exceed resident population by an order of magnitude in a downtown ZIP code.
• Stadiums, casinos, convention centers, regional malls. Same shape, plus extreme temporal concentration — the exposure exists on forty nights a year.
• Ports, rail yards, and industrial tracts. Low residents, high-value property, cargo theft.
• Universities. Partially handled by the census group-quarters rules, and partially not, with Clery-reported incidents living in a separate system entirely — which we covered in the campus crime piece.

And then the mirror image, which is easy to miss because it fails quietly in the safe direction. Prisons. The census counts incarcerated people at the facility under its usual-residence rule, so a rural ZIP code with a state penitentiary can carry several thousand residents who cannot generate or experience street crime as the public understands it. The denominator is inflated, the rate is suppressed, and the ZIP code reads as unusually safe. Nobody files a complaint about that one, which is precisely why it stays in the index.

What we would actually ship

The five pieces, in the order they run:

1. Classify every ZIP code before scoring it. Residential, mixed, commercial, institutional, PO-box-only, or no-ZCTA, derived from the HUD USPS residential and business address counts plus LODES jobs. This is a cheap lookup table and it is the single highest-value thing on the list.
2. Choose the denominator from the class. Resident population for residential ZIP codes. Weighted daytime population for commercial and institutional ones. No denominator at all for PO-box-only and no-ZCTA rows.
3. Shrink toward local neighbors, not the national mean. Empirical Bayes handles the genuine small-count noise, but the reference has to be the adjacent ZIP codes. A medical campus in a rough part of a city should not be pulled toward suburban Ohio.
4. Run the implied-population ratio as a guardrail. Nightly, over everything, with a threshold that trips into manual review rather than into a silent adjustment.
5. Never rank a suppressed ZIP code.Leaderboards are where these artifacts do their damage. A wrong number in a detail view is a wrong number. The same wrong number at the top of a “most dangerous ZIP codes” list is a headline about a hospital.

Why the MCP raises the stakes

This artifact has existed in ZIP-level crime products for as long as they have existed. What is new is who is reading the output.

A person looking at a map sees 45267, notices it is a small blob over a hospital, and discounts it. A language model calling a tool does not. It receives a number with a field name, and the field name says the number is a crime score, and it will write a fluent, confident, well-organized paragraph about how dangerous that ZIP code is. It has no map. It has no local knowledge. It has the schema, and the schema is the only place you get to tell it the truth.

So the schema does the work. Return zip_type, return denominator_method, return confidence, and when the honest answer is that this ZIP code cannot support a rate, return that as a value rather than as a caveat in a description string. Make the refusal a first-class field. The division we argued for in AI in law enforcement applies exactly here: deterministic code owns the arithmetic and the suppression rules, the model owns the language, a human owns the decision.

The FBI has been making a version of this argument since long before anyone built an MCP server. Its caution against ranking says the Bureau does not publish crime statistics in ranked form, because rankings strip out every variable that would let a reader interpret them. A tool that returns a sortable score to an agent is a ranking machine by construction. That does not mean the tool should not exist. It means the constraints have to live inside it, because there is no longer a person between the number and the sentence.

The thing the index got right

It is worth noting what actually happened here. The system did not fail silently. It produced an answer so obviously wrong that it was caught in the first serious query anyone ran against it. That is the good version of this problem. The bad version is a ZIP code that is wrong by a factor of three instead of a factor of forty, ranked eleventh instead of first, sitting in an index for two years while somebody prices insurance off it.

Which is the real argument for the guardrail. Not to catch the hospital — the hospital catches itself. To catch the ones that look fine.

Somewhere in that ZIP code there is an emergency room where the ambulances pull in, and the arithmetic counted every one of them, and divided by nobody.