The Fatal Force database: every fatal police shooting since 2015, in two data versions

What the database covers, and what it deliberately does not

The scope statement is the first thing to read, and it is narrower than the name suggests.

The Post tracks only shootings with circumstances closely paralleling the killing of Michael Brown in Ferguson, Missouri in 2014, the incident that began a protest movement culminating in Black Lives Matter. Concretely, an incident in which a police officer, in the line of duty, shoots and kills a civilian.

Three categories are explicitly excluded. Deaths of people in police custody, fatal shootings by off-duty officers, and non-shooting deaths are not tracked in this data set.

The reason for the narrow framing is stated too. The 2014 killing of Michael Brown began a protest movement that culminated in the Black Lives Matter movement and an increased focus on police accountability nationwide, and the scope is drawn around that question rather than around police violence in general.

For a user, that means a query against this data set is a query about on-duty shootings, and a researcher who wants all deaths in police custody has to look elsewhere. The boundaries are defensible and the naming is not misleading, but they are boundaries, and they are drawn in a way a reader has to notice.

The database covers the decade from 2015 to 2024, and the README says that in 2024 the Post announced it would track only killings in that decade.

How the records were collected, which is the hard part

The collection method explains both the quality and the limits of the data.

The Post began tracking details about each police-involved killing in 2015, recording the race of the deceased, the circumstances of the shooting, whether the person was armed and whether the person was experiencing a mental health crisis. The method was manual: culling local news reports, collecting information from law enforcement websites and social media, and monitoring independent databases such as Fatal Encounters and the now-defunct Killed by Police project. In many cases the Post conducts additional reporting.

There is no feed, no API and no schema-driven import. Every record is a piece of reporting, and the README says the database is updated regularly as fatal shootings are reported and as facts emerge about individual cases.

That has a consequence the README is upfront about. At times there may be a lag between the date of the shooting and its inclusion in the database, because of delays in reporting and data verification. So a query run today may not include an incident from last month, and the lag is not uniform across incidents.

In 2022 the Post updated the database to standardise and publish the names of the police agencies involved in each shooting, to better measure accountability at the department level. That change is the reason the v2 schema exists, and it is the single most useful addition for anyone doing departmental analysis.

Why this database exists when the FBI already counts these shootings

The README is explicit about the gap between this record and the official ones, and it is the strongest justification for the dataset.

The FBI and the Centers for Disease Control and Prevention both log fatal shootings by police, but officials acknowledge that their data is incomplete. Since 2015 the Post has documented more than twice as many fatal shootings by police as recorded by federal officials on average annually. That gap has widened in recent years, and the README gives a specific figure, that in 2021 the FBI tracked only a third of departments' fatal shootings.

The gap is explained by the collection method rather than by any disagreement about the numbers. A federal agency receives reports through a system that requires a local agency to submit them, while a newsroom reads the local news and the police department's own website for every incident in its coverage area.

For a researcher, that difference is the whole reason to use this rather than the official series, and it is also the reason to be careful with it. A database that is more complete than the official one is still a database compiled by one organisation's reporting process, and the README's own framing, that the Post seeks to make records as comprehensive as possible, is an aspiration rather than a claim of completeness.

The interactive database at the Washington Post is linked from the README for exploration, and the data itself is what the repository publishes.

The two data versions, and why the old one is frozen

The repository holds two datasets, and the difference between them is a schema change rather than a different subject.

Version 2 includes changes to improve the data schema, increase transparency around research methodology and add data on law enforcement agencies, with the documentation and the data formatted in the v2 structure under the `v2/` directory. The details of the changes between v1 and v2 are in `v2/README.md`.

Version 1 is the older layout, kept in the `v1/` directory.

Two notes clarify the relationship, and they matter for anyone scripting against it. As of the official v2 release, the data files in `v2/` include all records since 2015, with the historic records transformed into the new data schema. And the v1 data is static as of the migration to v2 and is no longer updated. Only the v2 datasets are updated.

So there is one dataset with two shapes, and the old shape is a historical artifact. A project that starts with v1 because it is simpler to parse will find itself frozen at the migration point, with no corrections arriving, and that is the single most likely way to misuse this repository.

The repository root holds only `CODE_OF_CONDUCT.md`, the `LICENSE`, the `README.md` and the two version directories, which is consistent with a repository whose output is generated data rather than source code.

How to contribute, and why you cannot open a pull request

The contribution section sets an expectation that differs from most open source projects, and it is stated up front.

The Post welcomes assistance in making the data as complete and accurate as possible, and asks that you reach out with questions, feedback, updated information or corrections, and that you read the Code of Conduct first. The best way to contribute data is to email the feedback address, and the same address covers information about fatal police shootings between January 1, 2015 and December 31, 2024.

Then the sentence that sets the policy: pull requests are not accepted, because the data file is automatically generated from the internal database.

That is a sound reason and a good one to understand before you plan any contribution. A correction that arrives as a pull request has to be applied to a source system that is not in the repository, and the only route in is a human at the Post applying it. The repository is a mirror of a database, not a place where the data is maintained.

There is a subtle consequence for tooling. A project that treats this repository as a source of truth for a nightly build will find that a commit is a publication event rather than a change proposal, and that corrections arrive on the schedule of the newsroom rather than on the schedule of a pull request.

The licence, which is not an open source licence

The licensing line is short and has a consequence that is easy to miss.

The data is published under an Attribution-NonCommercial-ShareAlike 4.0 International CC BY-NC-SA 4.0 licence. The GitHub metadata records the repository's licence field as a custom one that GitHub cannot classify, with a pointer to the `LICENSE` file at the root, and the README's own statement is the one to go on.

Two terms matter for a technical reader. The NonCommercial term means the data cannot be used for commercial purposes, and the ShareAlike term means a derived dataset has to be published under the same licence.

So this is not an open source dataset in the sense that most open source licences imply, even though it is freely available and the project is happy for people to build on it. A commercial product that trains a model on the data, a company building a compliance or risk product on top of it, or an internal analysis at a for-profit organisation is outside what the licence grants, and a derived database inherits the same restriction.

For journalism, research and advocacy, which is who the collection method was built for, that is a workable arrangement, and it is worth noting that the terms match the purpose. For a data engineer with no such context, the licence is the first thing to read, not the last.

Where the Fatal Force database is the wrong source

The first wrong case is a commercial project. The NonCommercial term is unambiguous, and no amount of attribution cures it. If your use is inside a company that sells something, you need permission rather than the licence.

The second is a question about a category the data does not cover. Anyone asking about deaths in custody, about off-duty officers, or about non-shooting deaths, such as a restraint death, will get an incomplete answer from this data set by design. The scope is the point, but it is a scope.

The third is a real-time or exhaustive study. The README says there may be a lag between the date of a shooting and its inclusion, and the lag varies with reporting and verification. A paper published in the same year as an incident will undercount, and the undercount is not uniform across cases, since the cases that take longest to verify are the contested ones.

The fourth is a workflow that wants to push a correction. The data file is generated and pull requests are not accepted, so the loop is an email, and a change to a record waits for a person at the Post.

The fifth is a project that needs a stable schema. The v1 layout is frozen, the v2 layout is what receives updates, and the two are not interchangeable, so a project that starts on v1 will find its parsing code stranded.

For what it is, which is a documented, transparent, newsroom-maintained record of on-duty fatal shootings with the agency names attached, the dataset is hard to match, and the README's comparison with the official counts is a reasonable measure of its value.

Editorial conclusion

The Fatal Force database suits a researcher, journalist or advocate who needs a documented record of fatal police shootings with the circumstances, and who can work under a non-commercial licence, because the data carries the reporting effort of a newsroom and the schema change to v2 deliberately traded convenience for a transparent methodology. It does not suit a commercial project, since CC BY-NC-SA 4.0 forbids commercial use outright and the share-alike term propagates to derived datasets. Before using it, read `v2/README.md` for the changes from v1 and the methodology notes, plan for the schema, because the v1 layout is frozen and will not receive corrections, and email the feedback address with any correction you find, since the data file is generated and a pull request will not be merged.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. washingtonpost/data-police-shootings on GitHub