Engineering & DevelopersThis is a collaborative piece written by Jared Miller and Ayu.Despite virtually every online platform facing these sorts of challenges, many are left to reinvent tools from scratch, with varying degrees of success. We’d like to help our fellow companies get a head-start on their safety measures — that's why, in partnership with ROOST and the internet.dev team, we’re excited to open-source Osprey: our safety rules engine.With Osprey, teams can investigate real-time activities across their platforms and quickly deploy dynamic rules to address emerging threats, all with minimal engineering overhead.This post will walk you through what Osprey is, how it works, and how your team can start using it to build stronger safety measures.What do we want in a Rule Engine?Fighting bad actors requires tools that can adapt to new challenges in real-time. A service as large as Discord needs a system that can: Process at Scale: Handle thousands of events per second, in real-time, and scale seamlessly as our platform grows.‍Enable Rapid Response: Let teams write expressive rules that take effect in minutes.‍Provide Clear Decisions: Deliver actionable verdicts on whether ongoing user activities are safe, suspicious, or malicious. ‍Show Its Work: Offer transparency into how rules were executed and when errors arise, making investigating and debugging straightforward.‍Learn and Adapt: Support a continuous feedback loop where detection insights improve future rules. ‍Stay Future-Proof: Accommodate extensibility for new features to combat attack patterns we have yet to imagine.These requirements shaped every architectural decision we made when developing Osprey, from its rule language to its distributed processing model.How does it work?Key ConceptsOsprey is built around several core concepts. It ingests Actions, either synchronously via GRPC or asynchronously via a Message Queue, and runs them through a series of Rules written in SML (just Some Made Up Language) that can be expanded upon with UDFs (User Defined Functions), and processes them via a combination of Features and Effects, some of which can be applied to Entities. Synchronous actions in particular can return Verdict effects, which inform the caller about any determinations made by the rules. All outputs are then sent to our Apache Druid cluster to power our investigations UI.Easy right! … okay, that was a LOT of bolded words and new terms thrown around. Let’s drill down what all these terms mean: ActionsActions are events that we send to Osprey. Each type of action has a unique ID and schema. They’re effectively JSON blobs consumed by the rules engine, and can be customized to contain whatever data the caller provides.{