Palantir's ADS framework: making every detection alert earn its place

The failure mode is fatigue, not missing alerts

The README is unusually honest about why the framework exists. Before its development and adoption, Palantir faced major challenges with developing alerting strategies. There was a lack of rigor around the creation, development and implementation of an alert, which led to sub-optimal alerts going to production without documentation or peer-review.

Then the alerts accumulated a reputation. Over time, some of these alerts gained a reputation of being low-quality, which led to fatigue, alerting apathy, or additional engineering time and resources.

That sequence is the argument for the whole project. The problem is not that a team lacks detections, it is that a team has detections nobody can defend. Once responders stop trusting the alert channel, every new alert costs more than it delivers, and the marginal detection is worthless regardless of its quality.

Palantir's stated aim in publishing the framework is not only collaboration. The hope is that these examples spur greater sharing and collaboration, inspire detection enhancements for other defenders, and ultimately increase the operational cost for attackers.

The framework is a natural language template, and that is the mechanism. It helps frame hypothesis generation, testing and management of new alerting and detection strategies. No code is required to adopt it, and the repository contains no source code at all.

Nine sections, all required before production

The core of the project is a document with nine sections, and the README is emphatic about the requirement. Each section must be completed prior to production implementation.

The sections are Goal, Categorization, Strategy Abstract, Technical Context, Blind Spots and Assumptions, False Positives, Validation, Priority and Response.

Read as a sequence, they describe the lifecycle of a detection. Goal states what the alert is for. Categorization places it, which is what makes a set of alerts navigable rather than a pile. Strategy Abstract is a short human readable statement of the approach. Technical Context records the data sources and environment the detection depends on. Blind Spots and Assumptions, False Positives, Validation, Priority and Response then cover the parts that usually get skipped: what the alert cannot see, what will make it fire when it should not, how you know it works, how urgent it is, and what the responder should do when it triggers.

The README states the guarantee this structure buys: each section is required to successfully deploy a new ADS, and it guarantees that any given alert will have sufficient documentation, will be validated for durability, and reviewed prior to production deployment.

The word durability in that sentence is the tell. A detection that fires on a condition an attacker can trivially avoid is not a detection, it is a notification generator. Requiring a validation section is a way of forcing someone to ask whether the thing still works against someone who knows it exists.

Blind spots and false positives are mandatory fields

Two of the nine sections are the ones most alert templates leave out, and their inclusion is the sharpest part of the design.

Blind Spots and Assumptions forces the author to state what the detection cannot see and what it assumes to be true. A detection that watches process creation on one host has a blind spot in every other host. A detection that assumes the attacker will use a specific credential needs that assumption written down, because the assumption is exactly what an attacker will test.

False Positives forces the author to state what else triggers this alert. This is the section that changes behaviour on a response team. A rule that fires on every failed login produces an alert that responders learn to dismiss, and once they dismiss it, the real event goes with it. Writing down the benign causes is the cheapest available defence against that, and the README explicitly lists fatigue and alerting apathy as the outcomes the framework exists to prevent.

Validation then asks whether the detection has been tested, which pairs naturally with the false positives section. If you know what will make it fire wrongly and you have validated it, the alert is likely to be worth a responder's attention.

Priority and Response complete the set. Priority is what tells a responder how fast to move, and Response is what tells them what to do when it fires. An alert without a defined response is a notification, and notifications are the thing responders learn to ignore.

The alert itself lives in version control

There is a second idea in the README that is easy to miss and arguably more consequential than the template itself.

Each production or draft alert based on the ADS framework is stored in a durable, version-controlled and centralized location, for example a wiki, a GitHub entry, or similar. So the alert's documentation is a versioned artifact in the same kind of store as the code that implements it.

That changes what happens when the detection changes. If an alert lives in a wiki page with no history, then a rule someone edited two years ago to stop firing on a noisy host has no trace, and the next engineer to inherit it has no way to know why. With the alert in version control, the diff shows that someone changed the threshold, and the commit message can say why.

It also makes the peer review in the workflow enforceable. A pull request is a natural place to review an alert, because the reviewer sees the alert and the change to it in one view. The repository layout matches this model: `ADS-Framework.md` at the top level holds the core framework used internally at Palantir, and `ADS-Examples/` holds the worked examples.

The stated motivation for making this public is partly operational security. The README notes there are operational security considerations around publicly acknowledging and documenting internal alerts, and the repository is a public version of the framework the Incident Response team uses.

Adopting it starts with a hack week, not a rollout

The Using This Repository section gives a four step path, and the first step carries a warning worth quoting. The README recommends spinning up a lab environment before deploying any of these configurations, scripts or subscriptions to a production environment.

Then the steps. Download the repository and review the contents. Run an ADS hack week and try converting or generating several new alerts. Perform peer review of each new ADS and provide critical feedback. And start the process of converting legacy alerts into the ADS format.

The order is instructive. Nothing is asked to be deployed first. The hack week comes before the peer review because the point of the week is to find out how painful the template is when you have to fill it in for five alerts, and the peer review comes before the legacy conversion because the review is where the team learns what the framework is actually asking of them.

The final step is the one that decides whether the framework survives. Converting legacy alerts is unbounded work, since most teams have hundreds of them and no schedule to do it in. The pragmatic approach the sequence implies is to apply the framework to new alerts as they are written, and to convert the important legacy ones when they are touched for another reason.

The lab environment recommendation exists because the examples are described as deployable detection configurations. Something that was written to detect malicious or anomalous activity in one environment can be noisy, or silently ineffective, in another, and the only way to know which is to run it somewhere harmless first.

The examples, and the two frameworks they borrow from

The `ADS-Examples/` directory is where the framework stops being a template and becomes a set of worked examples, and the README describes them as human-readable alerting strategies which may be deployed to detect malicious or anomalous activity.

Two sources are credited in the Further Reading and Acknowledgements section, and both are worth knowing if you are building detection content. The first is the MITRE ATT&CK Framework, the well known matrix of adversary tactics and techniques that many detection programs map their coverage against. The second is the Red Canary Atomic Red Team Testing Framework, which provides atomic tests that emulate individual adversary behaviours.

The pairing is informative. ATT&CK gives you a taxonomy for what an adversary might do, which maps naturally onto the Categorization section and onto the Goal of an individual strategy. Atomic Red Team gives you a way to exercise a detection, which is what a Validation section has to point at. A framework that requires a Validation section is only credible if there is something concrete to validate against, and a library of atomic tests is exactly that.

The repository also states that contributions, fixes and improvements can be submitted directly as a GitHub issue or pull request, and that this is a public version of the framework the Incident Response team uses on the Palantir Medium publication.

One thing to note about the repository's shape. The top level contains only `ADS-Examples/`, `ADS-Framework.md`, `LICENSE` and `README.md`, and the repository has no GitHub releases and no detected primary language, because it is documentation rather than code.

MIT terms, and what you are really adopting

The repository is under the MIT License, with the notice carrying Copyright (c) 2017 Palantir Technologies Inc. and the full MIT permission text. MIT is permissive, so an organisation can copy the framework into its own wiki or documentation system and modify it without any obligation to publish changes back.

The 2017 copyright date is worth noticing. It tells you the framework predates the publication by several years, which is what you would expect of a template refined internally before being shared. The frame here is a template refined through internal use, and the public repository is the export of that.

What an organisation actually adopts is a practice rather than an artifact. The framework is a document, so the hard part is not copying the file, it is the organisational change of requiring nine sections before an alert can be deployed, of storing alerts in version control, and of running peer review on detection content the way it is run on code. The template makes that requirement explicit and gives reviewers shared vocabulary, which is the part that survives contact with a busy team.

The maintenance picture is simple. The last push was on 2026-10-02, the repository is not archived, and there are no GitHub releases, so there is no version history to track beyond the commit log. For a document that most teams copy once and adapt, that is the right shape, and it also means that if the framework needs to change for your organisation, you will be making that change locally.

Editorial conclusion

Adopt the ADS framework if your team is drowning in alerts that nobody can explain, because the framework's value is the mandatory sections on false positives, blind spots and validation rather than any detection logic, and it ships as prose you can copy into your own wiki. Skip it if your monitoring is already governed by a review process that covers the same ground, since the framework adds a template rather than a capability. Verify first that you can genuinely fill the False Positives and Validation sections for your existing alerts, because that is where the effort sits and where an unfilled template becomes theatre. The repository is MIT licensed with a 2017 Palantir copyright, the last push was on 2026-10-02, and the project has no GitHub releases.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. palantir/alerting-detection-strategy-framework on GitHub
4. README