A rules engine and a console, or the whole lifecycle around them.
ROOST is a nonprofit publishing free, open-source trust and safety tools: Osprey, the real-time rules engine Discord donated, and Coop, a review console. Both are real, both self-host, and moderation teams run them today.
What ROOST is
Two components. Osprey evaluates rules on events as they arrive; Coop is where reviewers work the cases those rules open. Together they cover the two things a moderation stack does every second: decide, and put a person on what the decision could not settle.
What they do not carry is the lifecycle around a rule change, and the evidence after it. That is where we are different, row by row.
What Swiftward does differently
| Capability | ROOST | Swiftward |
|---|---|---|
| Rules a policy person edits, live | Yes | Yes |
| Reviewer queues and case management | Yes | Yes |
| Bring your own detectors, no lock-in | Yes | Yes |
| Runs on your own infrastructure | Yes | Yes |
| Versioned policy: draft, candidate, frozen, archived, rollback by naming a version | partial | Yes |
| Backtest a candidate against your recorded history, verdict by verdict | no | Yes |
| Shadow-test a change on live traffic before it enforces | no | Yes |
| A/B two policy versions on live traffic | no | Yes |
| Tamper-evident audit trail | no | Yes |
| Defend a past decision with the rule and the frozen version that made it | no | Yes |
| DSA Article 17 statement of reasons, generated from the decision | no | Yes |
| One deployment with SSO, row- and field-level access, multi-tenancy and support | no | Yes |
| The same engine also decides payments, claims and agent tool calls | no | Yes |
The first four rows are a draw, and they are the rows a moderation team touches every day. The rest is what a policy change costs you, and what you can prove afterwards.
What those rows mean on a Monday
You want to tighten a threshold. Here you write the candidate, run it over last month and read every account whose verdict flips, then put it in shadow on live traffic before it decides anything. On the open-source path you reason about the change, ship it, and watch the queue.
A user disputes a takedown eight months later. Here the decision record names the rule, the frozen version it ran on and the signals it read, hash-chained under a signed checkpoint an auditor can verify. Rule history in a repository tells you what the rules were; it does not tell you which one decided that account, or prove the record has not moved since.
Your security review starts. Here it meets one binary plus Postgres, with SSO, access control down to the row and the field, multi-tenancy and secrets already in it, and a support line to call. Two components across several services means standing all of that up and answering for it yourself.
And it is not only moderation
The same engine decides a payment, a claim and an agent's tool call, on the same records and the same review queues. A platform that moderates content and also moves money governs both from one place. Gateways for LLM, MCP, network, FIX and blockchain calls are part of the same binary.