CommunityShield
ML-powered crime pattern explorer for Chicago. 8.5M rows, 4 XGBoost models with SHAP explanations, beat-level heatmap, and an honest methodology page about what the data can and cannot tell you.
Ethics and Methodology
This is the most important page in the project. Read it before drawing any conclusion from the model's output.
This is not predictive policing
The term predictive policing refers to systems that direct law enforcement resources to specific locations or individuals based on model output. CommunityShield does none of those things. It does not interface with any enforcement system. It does not produce risk scores for individuals. It does not recommend deployment. It does not communicate with any police department.
It's a public-facing tool that surfaces patterns in public data, with the same standing as a journalist visualizing the same dataset. The audience is residents, journalists, and researchers — not police.
If this project's outputs were used to direct enforcement, the result would be the same well-documented feedback loop that has discredited predictive policing systems across the United States: the model learns from enforcement data, so it predicts where enforcement has happened, which directs more enforcement to those locations, which generates more data that confirms the model. That loop is real and the harm is real. This project is built to be useless for that purpose by design.
What the data is
The crimes table contains reported incidents from the City of Chicago's public data portal. Each row represents:
- A 911 call, walk-in report, or officer-initiated report
- That was classified by a responding officer as a particular crime category
- And recorded in the city's incident management system
Every one of those three steps is a filter. The dataset does not contain unreported crime, misclassified crime, or crime that occurred outside the reporting infrastructure. Reported crime is not the same as crime that happened.
What the data is not
The data is not:
- A measure of how safe a neighborhood is (perceived safety, fear of crime, and reported crime are related but distinct)
- A measure of community trust in police (under-reporting in low-trust communities is well-documented)
- A measure of criminal activity (only the subset that becomes a report)
- A leading indicator of future events (it's a record of past reports)
- Free of historical bias in enforcement patterns
A beat with high reported crime might have high actual crime, or high police presence, or high community trust that surfaces incidents that would go unreported elsewhere — or all three. The model cannot distinguish between these. No model can, from this data alone.
Features deliberately excluded
The production model does not use:
- Race or ethnicity of victims or suspects, individually or aggregated by tract
- Income or wealth indicators at any geographic level
- Demographic features of any kind from census tracts or community areas
- Arrest outcomes as predictors (only as a held-out audit metric)
Experiment 5 in ml-deep-dive.md tested adding census-tract demographic features as a deliberate exercise. PR-AUC moved by less than 0.01, and feature importance showed the model could learn proxies for race even though race wasn't a direct input. Those features were stripped from the production model. Adding demographic features to a crime model is not an accuracy win worth taking, and at this scale it isn't even an accuracy win at all.
The data ceiling
Across hundreds of hyperparameter trials and feature engineering iterations, the four models plateau at PR-AUC between 0.58 and 0.65. More trees, deeper trees, more features, ensembling — none of it pushes past that ceiling.
The honest interpretation: reported crime is a noisy signal of underlying criminal activity, and the noise floor is the data ceiling. A better model can't fix the data. This finding is plotted prominently on the methodology page in the running app.
Intended use
- Residents asking what's the trend in my neighborhood over the past year?
- Journalists comparing crime distribution across beats and districts over time
- Researchers studying urban crime data with full visibility into model limitations
- Civic technologists demonstrating responsible ML on public data
Not intended for
- Directing police deployment
- Risk scoring individuals
- Real estate decisions or insurance pricing
- Any decision with material consequences to people in the represented beats
The methodology page surfaces this on the frontend so anyone using the product sees it before they see a model prediction.