Osprey – Open Source Abuse Rules Engine

TL;DR

TL;DR: Osprey is an open source rules engine for real-time event processing, originally built at Discord to detect spam and abuse — now available for any Trust and Safety team.

Source and Accuracy Notes

⚠️ This section is MANDATORY. All links must be verified from actual source, not guessed.

• Project page: roost.tools/osprey
• Source repository: github.com/roostorg/osprey — README read in full
• License: Apache-2.0 (verified via GitHub API license.spdx_id)
• HN launch thread: news.ycombinator.com/item?id=46860249
• Source last checked: 2026-06-24 (commit main branch, pushed 2026-06-23)

What Is Osprey?

Osprey is a high-performance safety rules engine for real-time event processing at scale. It was originally developed internally at Discord to combat spam, abuse, botting, and scripting, and has since been open-sourced by ROOST (Robust Open Online Safety Tools) — a non-profit backed by Discord, Bluesky, Matrix.org, and internet.dev.

The project describes itself as:

“Automate the obvious and investigate the ambiguous. High-performance safety rules engine for real-time event processing at scale.”

Osprey evaluates events using structured rule logic (written in SML — Sad Language, a domain-specific language) that is extendable via user-defined functions (UDFs). It can track state across events by labelling entities through a labels service backend (a Postgres example is provided).

Adopters include Discord, Bluesky, and Matrix.org.

Setup Workflow

Prerequisites

• Python 3.10+ (for the example plugins and UDF development)
• A data sink to receive verdicts (configurable output sinks)
• Optional: Postgres for the labels service backend

Step 1: Clone the Repository

git clone https://github.com/roostorg/osprey.git
cd osprey

Step 2: Install Development Dependencies

pip install -e ".[dev]"

Step 3: Configure Your Rule Set

Rules are written in SML and placed in the rules directory. The DEVELOPMENT.md covers the full development setup.

Step 4: Connect an Output Sink

Osprey outputs verdicts to configurable output sinks. See the example plugins for reference implementations.

Deeper Analysis

Architecture: Osprey is a library for processing actions through human-written rules and outputting verdicts and custom effects back to configurable output sinks. Events are evaluated against structured rule logic in SML, with UDFs providing extensibility.

Stateful detection: If a labels service backend is provided, Osprey can label entities across events — enabling stateful detection patterns like “this user has been flagged 3 times in the last hour.”

Trust and Safety focus: Unlike general-purpose streaming frameworks, Osprey is purpose-built for Trust and Safety workloads. The user personas doc describes the target users: incident responders, T&S engineers, and platform operators.

Language: Rules are written in SML (Sad Language). UDFs can be written in Python. This is distinct from Rego/OPA or Drools.

Practical Evaluation Checklist

• [ ] Read the README end-to-end
• [ ] Review the DEVELOPMENT.md for local setup
• [ ] Check the user research personas
• [ ] Examine example plugins in example_plugins/src/
• [ ] Evaluate rule complexity for your event volume

Security Notes

• Rules are evaluated in-process — consider sandboxing UDFs in production deployments
• Labels service (optional Postgres backend) stores entity state — secure accordingly
• Review the Discord engineering blog post on Osprey for deployment context

FAQ

Q: What is SML (Sad Language)? A: Sad Language (SML) is Osprey’s structured rule language for writing event evaluation logic. It is distinct from Rego (OPA), Drools, or Common Expression Language.

Q: Can Osprey be used for non-abuse use cases? A: Technically yes — any real-time event evaluation and verdict workflow could use it. However, it is purpose-built for Trust and Safety workloads and the documentation reflects that domain focus.

Q: How does it compare to OPA/Rego? A: OPA is a general-purpose policy engine. Osprey is purpose-built for T&S event streams with stateful entity labelling and a domain-specific rule language (SML). They serve overlapping but distinct use cases.

Q: Who maintains Osprey? A: ROOST (Robust Open Online Safety Tools) is a non-profit. The initial code was contributed by Discord, with adoption from Bluesky and Matrix.org.

Conclusion

Osprey fills a specific niche: open source, real-time, T&S-focused event processing with a rules engine and stateful entity tracking. If your platform needs to evaluate events against human-written rules at scale — and you don’t want to build from scratch — it is worth evaluating. The Apache-2.0 license means you can incorporate it into commercial platforms freely.

For context on production use at scale, see the HN discussion thread and Discord’s engineering involvement.