opendrs: PR blast radius analyzer and risk score for safe auto-approval
A calibrated 0-1 risk score for every pull request, so AI-reviewed, low-blast-radius PRs can be
auto-approved into the merge queue while risky ones still wait for a human.
[GitHub Marketplace]
[CI]
[License: MIT]
AI agents now write and review code faster than people can read it, so human review has become
the bottleneck. Most pull requests are low risk, and a few cause most incidents. opendrs measures
each PR's blast radius and risk: what the change touches, how many files depend on it, the
history of the files it changes, author experience, missing tests and critical paths. It turns
that into a 0-1 score using signals from your own git history. A team then sets a policy.
For example, a PR that scores below 0.3 and has passed an AI review (Claude, CodeRabbit, Copilot
or any check run) is approved and sent to the merge queue or auto-merge. Riskier PRs still wait
for a human. The approach follows Meta's Diff Risk Score (DRS); opendrs is an independent,
open-source implementation that runs in any git repository, with no service to host.
Contents: Install · Quick start · How it works ·
Features · Results · CLI and MCP ·
Documentation · Limitations ·
Compared with other tools · Prior art
Install
Website and guides: error-path.github.io/opendrs.
Quick start
Score your current branch against the default branch. No configuration or API key is needed:
You get a score, a tier (green, yellow or red), the signals that drove it with their evidence,
and the policy decision. --json prints the full result, and --fail-above 0.6 makes the
command exit 1 above a threshold.
To score every pull request, add .github/workflows/opendrs.yml (or run npx @error-path/opendrs init):
This only comments and labels. Approval is off until you turn it on in .opendrs.yml on your
default branch; see how to auto-approve low-risk PRs and the
GitHub Action reference.
How it works
- Signals. Each signal provider reads the diff, the history and the import graph and emits
features: size, how spread out the change is, past fixes and reverts in the touched files,
the author's experience with them, complexity, blast radius (transitive dependents), critical
paths and missing tests. Every signal records how it was obtained (
observed, derived,
inferred or unknown) and the evidence behind it. All signals
- Model. A logistic regression turns the features into a probability. Each signal's
contribution
w·x is reported, so you can see why a PR scored what it did. Out of the box the
weights are hand-set priors; opendrs calibrate fits them to your repository.
Calibration and backtesting
- Tiers. The score maps to green, yellow or red, mirroring Meta's gates. Thresholds can be
absolute scores or percentiles of your own history.
- Policy. Ordered rules turn the score into a decision. Policy and safety rails
Where opendrs sits in your PR flow
A PR now often gets two rounds of AI review before a human looks at it. Those rounds catch local
defects: typos, missing null checks, an obvious off-by-one. By the time a human opens the PR, that
work is done, and what is left is a design and architecture judgment call made with less context
than before. opendrs is built for that moment: it tells the final human how much attention the PR
needs and names up to five architecture and history facts — a new import between modules, a broken
public contract, a file that usually changes with one the PR didn't touch — that neither the
editor nor the AI review comments showed. See the captain brief.
Features
Every setting lives in .opendrs.yml, read from the base branch so a PR cannot loosen its own gate:
configuration reference.
Results
CLI and MCP
Flags, exit codes, MCP tools and the agent skill: CLI, MCP server, Claude Code plugin and agent skill.
Documentation
Limitations
- The default weights are not fit to your code. Run
backtest before trusting them, and
calibrate when you have enough history.
- Labels are proxies for incidents, and small repositories give unstable numbers.
- The score is not a code review. It estimates the chance of an incident, not whether the
change is correct.
The full list: known limitations.
Compared with other tools
The full comparison, with how each tool scores and where it runs, is at
error-path.github.io/opendrs/alternatives.html.
Prior art and credits
- Meta's Diff Risk Score. Diff Risk Score: AI-driven risk-aware software development
(Engineering at Meta, 2025) and Abreu et al., Moving Faster and Reducing Risk: Using LLMs in
Release Deployment (2024). The feature set, the tiered gates and
the capture-at-X %-gated metric come from this work. opendrs is not affiliated with Meta.
- Meta's RADAR. Adams et al., Automating Low-Risk Code Review at Meta
(2026): the structured LLM reviewer with safe and risk categories, per-source policy (daily caps,
track record), deferred review, the landing delay and the content blocklist follow this paper.
Related Meta work behind
hotspots and reviewer assignment: Mockus et al., "Metrics Driven
Reengineering and Continuous Code Improvement at Meta" (ASE 2025); Paraspatki et al., "Code
Reviewer Recommendation for High Risk Diffs at Scale" (FSE Companion 2026); Rigby et al.,
Improving Code Reviewer Recommendation (TOSEM 2025).
- Benchmarks and peers. Keshavarz and Nagappan, ApacheJIT
(MSR 2022), the dataset
bench/apachejit/ scores; Sayedsalehi, Rigby and Mockus,
DRS-OSS (2025), the open-source LLM counterpart whose numbers
the benchmark quotes.
- Just-in-time defect prediction and SZZ. Mockus and Weiss, "Predicting risk of software
changes" (2000); Śliwerski, Zimmermann and Zeller, "When do changes induce fixes?" (2005); Kamei
et al., "A large-scale empirical study of just-in-time quality assurance" (2013). The
change-level features and the SZZ-style labelling follow this literature.
- REA (morluto/rea). opendrs adopts REA's evidence-first
method: every conclusion is marked observed, derived, inferred or unknown, and unknown is never
treated as safe. It also follows REA's layering of domain types, providers, a shared engine and
thin adapters.
License
MIT
