Predictive policing systems promise to help police anticipate where crime might happen or who might become involved. The sales pitch usually arrives carrying words such as objective, efficient, intelligent, and data driven. Nothing says impartial justice quite like a vendor presentation with a glowing heat map.
The problem is that these systems do not observe crime directly. They analyze records created by police departments, emergency calls, arrests, incident reports, field interviews, surveillance systems, and other government activity. Those records reflect where officers were sent, which conduct they noticed, whom they stopped, and what they decided to document.
Then the prediction sends officers back to the same places. Officers generate more records there. Those records become new evidence for the system. The computer points proudly at the result and announces that it was correct.
This Resistance Survival Guide explains how to identify a predictive policing program, reconstruct its data pipeline, detect feedback loops, measure unequal surveillance, evaluate claimed results, and demand public accountability.
What Predictive Policing Actually Predicts
Predictive policing systems generally focus on places, people, or both. A place based system may identify blocks, zones, or time periods where a particular offense is supposedly more likely. A person based system may assign risk labels to individuals based on arrests, associations, family connections, school information, calls for service, or contact with police.
Some departments have retired the term predictive policing because it attracted criticism. The same functions may now appear under strategic decision support, precision policing, crime forecasting, risk terrain modeling, intelligence led policing, violence reduction, resource optimization, real time crime analysis, or data informed deployment.
Begin with function rather than branding. If a system uses past data to recommend where officers should go, whom they should watch, or who supposedly presents a future risk, you may be looking at predictive policing wearing a fresh little name tag.
How a Feedback Loop Develops
A feedback loop begins when police generated data is treated as a neutral measure of underlying crime.
Imagine two neighborhoods with similar levels of unreported drug activity. Police patrol one neighborhood more heavily. Therefore, officers observe more drug offenses there and make more arrests. The system interprets those arrests as evidence of greater crime. It recommends additional patrols in that neighborhood. Increased patrols produce more arrests, which strengthen the next prediction.
Researchers documented this danger in Runaway Feedback Loops in Predictive Policing. Their mathematical model showed how discovered crime data can repeatedly direct officers back to the same neighborhoods even when the underlying crime rate does not justify the concentration.
Reported crime and police discovered crime are not the same thing. A burglary reported by a resident enters the system differently from an offense discovered because an officer was already standing nearby. Mixing those categories without careful controls can transform police presence into apparent proof of criminality.
A neighborhood may not be generating more crime. It may simply be generating more police records because it received more police.
Step by Step Guide
Step One: Identify the System and Every Name It Uses
Search police budgets, city council agendas, procurement portals, grant applications, privacy reports, vendor websites, meeting minutes, inspector general reports, and local news archives.
Search for predictive policing, crime forecasting, risk assessment, strategic deployment, hotspot analysis, intelligence software, decision support, precision policing, violence interruption analytics, and real time crime center.
Record the official program name, vendor, product, contract number, department unit, start date, funding source, geographic coverage, and current status. A department may claim that one product ended while continuing the same process through another vendor or internal dashboard.
Step Two: Establish What the System Influences
Determine whether the output affects patrol routes, surveillance, stops, warrant applications, probation decisions, investigations, social services, school interventions, gang databases, or lists of people selected for police contact.
Request policies explaining whether officers must follow the recommendation and how supervisors document deviations. Ask whether a prediction creates probable cause or reasonable suspicion. It generally should not, but a risk score may still influence decisions long before anyone admits that it did.
A system that merely paints a map is different from one that sends armed officers to a person’s home. Do not let the agency describe both as harmless administrative assistance.
Step Three: Reconstruct the Data Pipeline
List every input used by the system. Possible inputs include reported offenses, arrests, citations, calls for service, field interview cards, traffic stops, probation records, school records, housing data, social media, license plate reader data, gunshot alerts, known associates, and demographic proxies.
For each input, identify who created it, why it was collected, how often it is updated, how errors are corrected, and how long it is retained.
The National Institute of Standards and Technology warns that bias can enter throughout the technology lifecycle. The model is not the only place to look. The rot may already be sitting in the spreadsheet.
Step Four: Separate Reported Crime From Police Discovered Activity
Divide the input records into incidents reported independently by residents and incidents discovered through police deployment.
Reported burglaries, robberies, and vehicle thefts may provide a different measure from drug arrests, disorder citations, pedestrian stops, or possession offenses that depend heavily on officer presence.
Calculate what percentage of the system’s data came from proactive enforcement. If the department cannot separate these categories, document that limitation. A model cannot reliably distinguish community harm from police attention when the agency pours both into the same statistical soup.
Step Five: Map Police Presence Before the Prediction
Collect patrol hours, officer assignments, stops, searches, citations, arrests, calls for service, surveillance locations, and specialized unit deployments from a period before the system began.
Map those activities by neighborhood, census tract, precinct, or reporting district. Then compare them with race, income, housing, and population data from the United States Census Bureau.
This establishes the historical enforcement pattern feeding the model. If one community already received disproportionate police attention, the system may be learning where police worked rather than where residents faced the most harm.
Step Six: Preserve Every Prediction and Deployment Record
Request each prediction, map, risk score, recommendation, officer assignment, deployment plan, supervisor approval, and system access log.
Ask for records in their original electronic format when possible. Screenshots may conceal timestamps, geographic identifiers, confidence values, and revision history.
The Brennan Center’s predictive policing research found that missing prediction records and audit logs can make independent evaluation nearly impossible. Conveniently forgetting to preserve the output is not transparency. It is an accountability trapdoor.
Step Seven: Build a Feedback Loop Table
Create one row for each geographic area and reporting period. Record the prediction score, officers deployed, patrol hours, stops, searches, arrests, reported crimes, police discovered incidents, and the following period’s score.
Now test the sequence. Did a higher score lead to more officers? Did more officers produce more enforcement records? Did those records raise the next score?
A strong correlation does not automatically prove causation. However, a repeated sequence can show that police deployment is helping manufacture the data used to justify future deployment.
Step Eight: Compare Similar Neighborhoods
Select areas with similar population, reported violent crime, property crime, commercial activity, and socioeconomic conditions.
Compare how often each area was predicted, patrolled, stopped, searched, and arrested. Then compare the percentage of stops that produced evidence, citations, or arrests.
If two similar areas receive sharply different levels of attention, investigate whether historical policing patterns, reporting practices, surveillance coverage, or demographic proxies explain the difference.
The relevant question is not whether police found something. Police usually find more violations wherever they look hardest.
Step Nine: Test Accuracy Using the Correct Denominator
Ask the agency how it defines a successful prediction. A claim that crime occurred inside a predicted zone proves little if the zone was large, the time window was long, or the event was common.
Calculate precision by asking how many predictions were followed by the specified outcome. Calculate coverage by asking how many relevant incidents occurred inside predicted areas. Record false positives, false negatives, and base rates.
Do not accept arrests as automatic proof of accuracy. An arrest is a government action, not a final finding of guilt. Compare arrests with charging decisions, dismissals, convictions, and verified incident reports whenever those records are available.
Step Ten: Examine How Officers Responded
Interview residents, public defenders, civil rights groups, journalists, and neighborhood organizations about what deployment looked like on the ground.
Review body camera records, complaints, stop reports, use of force records, and officer narratives from predicted areas. Determine whether officers performed visible patrols, conducted repeated stops, questioned young people, visited homes, photographed residents, or added names to intelligence systems.
The prediction’s impact cannot be measured solely through crime statistics. A program may produce no meaningful reduction in violence while increasing surveillance, humiliation, fear, and contact with the criminal legal system.
Step Eleven: Audit the Vendor and Contract
Obtain the contract, statement of work, technical requirements, pricing, amendments, training materials, validation studies, performance guarantees, subcontractors, data ownership terms, and termination provisions.
Search the vendor’s claims against independent evaluations. Determine whether the company tested the system using the same police data that created the alleged problem.
Do not accept trade secret language as a universal invisibility cloak. Courts, legislatures, and public agencies may balance legitimate proprietary interests against due process and public accountability. Government does not get to outsource consequential decisions and then announce that democracy violated the software license.
Step Twelve: Demand an Independent Evaluation
An evaluation should be conducted by researchers who are not paid by the vendor and who can access inputs, outputs, deployment records, demographic effects, and downstream outcomes.
Require analysis of false positives, false negatives, geographic disparities, racial impact, data quality, officer compliance, community harm, and actual public safety outcomes.
The evaluation should compare the system with a credible alternative, including ordinary deployment or no predictive tool. If the agency cannot explain what would have happened without the program, it cannot honestly claim the software caused an improvement.
Red Flags That Deserve Immediate Attention
Be cautious when an agency refuses to identify the vendor, does not preserve predictions, cannot list the inputs, measures success through arrests alone, or treats police discovered activity as neutral crime data.
Other warning signs include secret watchlists, undocumented officer discretion, school or family information used in risk scores, contracts signed without public debate, demographic impact never measured, and a program renamed after criticism without meaningful changes.
The grandest red flag is circular proof: police went there because the system predicted crime, then declared the prediction accurate because police found crime after going there.
That is not foresight. That is a statistical house cat proudly discovering the toy she placed under the sofa.
Turning the Audit Into Accountability
Present the findings as a timeline and feedback loop. Show the historical data, prediction, deployment, enforcement activity, new data, and next prediction.
Ask the city council or oversight board to require public policies, preserved audit logs, independent validation, community review, strict data limits, regular disparity testing, and automatic expiration of the program unless officials prove that it provides measurable public benefit.
Share the evidence with public defenders, civil rights organizations, affected communities, independent journalists, inspectors general, and local lawmakers.
A responsible audit does not need to prove that every algorithm is intentionally discriminatory. It needs to show whether the system measures crime, police behavior, or an inseparable mixture of both.
Closing RK Thoughts
Predictive policing systems are often marketed as objective tools that remove human bias from public safety decisions. Yet the software depends on choices made by humans: what to collect, where to patrol, which records to trust, what outcome to predict, and what counts as success.
A computer can process biased history faster. It cannot make that history neutral.
Follow the data from its creation through the prediction, deployment, police contact, and return to the database. That is where the feedback loop becomes visible.
Resistance Kitty has no objection to evidence based public safety. She merely insists that police stop calling their own footprints a weather forecast.
Sources
- Runaway Feedback Loops in Predictive Policing
- Predictive Policing Explained by the Brennan Center for Justice
- The Dangers of Unregulated Artificial Intelligence in Policing
- Electronic Frontier Foundation Predictive Policing Guide
- Upturn on Predictive Policing and Historical Data
- NIST Guidance on Identifying and Managing Bias in Artificial Intelligence
- Government Accountability Office Report on Smart City Technology
- United States Census Bureau Data
