Named adopters: Osprey at Discord and Bluesky

9 September 2026. Bounded primary-source adoption inquiry closed after six discovery queries and four original HTML acquisitions. Read adopters-captures.json for custody and exact scopes. No new organization branch, harmful dataset, account, model inference, code execution, deployment inspection or case edit.

Finding

There are substantive, named reported production deployments, beyond partner logos. Discord provides its own dated technical account and describes a reciprocal development path. Bluesky's account is a ROOST-published case study quoting participating staff and identifying the platform's action machinery. Neither is an independent operational/outcome audit. Both locate important choices with the deploying platform rather than establishing a common policy imposed by the tool provider.

Discord: shared engine, retained internal rules

Discord Engineering's [19 February 2026 technical article](http[local research file] credited to Jared Miller and Ayu, reports that as of December 2025, Discord used open-source Osprey for approximately 400 million actions/day, across 204 action types and 2,288 rules, with 99 custom user-defined functions. These are operator-reported processing quantities, not counts of abusive users or successful takedowns.

Its System Components section says Discord distributes rules through ETCD and routes outputs to configurable sinks. Handling Sensitive Data describes Discord's own access controls, justification requirements and audit trails. Customizing Osprey for the Public expressly says Discord's full rules, functions and sinks were not supplied; internal configurations were placed behind plugin integrations. This documents a configurable engine and retained local configuration. The shared source does not expose every internal detection rule or imply that ROOST receives Discord's user data. Exact deployed commit, rule bundle and measured error rates remain unacquired. Source: adopters-discord-engineering.html; complete substantive body read, figures not inspected and examples not executed.

Clint Smith's [16 March 2026 account](http[local research file] says Osprey began as Discord's production engine, was donated and improved through ROOST, and the community version was reintegrated into Discord production. His author biography identifies him as Discord's chief legal officer; the article also identifies his ROOST board-chair role. This dual position matters to provenance: it is participant testimony from someone involved in both bodies. It supports a reported reciprocal resource flow, not independently proved performance. The article refers to the public v1 release but does not pin the exact Discord production revision. Its broad ecosystem user count and unrelated initiative references do not establish common policies, joined databases or additional named deployments. Source: adopters-discord2026.html, What Osprey Does and Results & Impact.

Bluesky: implementation reaches a platform-owned action receiver

ROOST's [4 February 2026 case study](http[local research file] by Andrew Chang, reports Osprey in Bluesky production, quoting its trust-and-safety engineering staff and department head by role. It reports over 45 million events and 100,000 enforcement actions daily. Those figures are attributed operating claims; actions are not necessarily unique accounts, bans or proven violations.

The described path is atproto event stream → Osprey with Bluesky-specific functions → Kafka output sink → effects receiver on Bluesky servers → action in Ozone. The account says analysts migrated and developed rules; its named example labels suspected t-shirt spammers. This identifies the platform's rule-writing and action integration, not ROOST approval of each decision. Setup still involved engineering, despite reduced dependence on engineers for subsequent rule changes.

Its cost savings are estimates, and the publication date is not an exact go-live date. The case links v1.0 information without proving Bluesky's deployed tag. This remains supplier-published participant evidence, not an independently observed endpoint. Source: adopters-bluesky-case.html, full substantive text read; diagrams and code images not visually verified.

Earlier state and support conditions

The [21 July 2025 official release](http[local research file] described Bluesky as planning adoption, with a quotation from Aaron Rodericks, then named as its trust-and-safety head. It also described public availability as forthcoming and Osprey as a Discord donation. The later accounts support progression from intention to reported production; July alone does not.

That release credits philanthropic funding and pro bono Perkins Coie legal services with the acquisition of Cove technology and tool launch. It does not allocate those resources to Bluesky or establish a recipient support contract. No paid support terms, service-level guarantees, adoption grant, update obligation or agreement requiring a particular policy was acquired for either selected platform. The public accounts describe collaboration and community assistance; contractual rights remain a separate question. Source: adopters-launch2025.html, Bringing Professional Tools, Early Adopters and What's Next.

What enters the map

The supportable paths are Discord's reported production use / contribution / reintegration, and a ROOST-published account of Bluesky production use, with platform-configured rules and a local action integration. Where the case already holds the organizations and Osprey, reuse them. Do not create an enforcement-authority edge from a logo, model-provider affiliation or working-group attendance.

No acquired adopter account establishes use of the CCF TVEC prompt pack, mandatory ROOST policy, a Canadian-funded deployment, Lantern signal access or a specific law-enforcement referral. Osprey adoption is not evidence of adopting every ROOST-supported model or sample policy. The most useful next record would pair a named deployment's exact configuration/policy revision with its approval process and a documented action or correction. That question remains for the next forest assessment; this lane has not pursued it.

Source custody and finite frontier

All four ordinary unauthenticated GETs returned substantive 200 HTML and were hash-checked. Full substantive article bodies were read. Related articles, linked models, external vendor offerings and screenshots were not treated as inspected sources. Raw HTML and derivative text remain separate; Discord's scoped rich-text body extracts aid reproduction of the read.

The six queries covered Bluesky's own site/docs, Discord's Osprey/ROOST accounts, Matrix's Osprey mention, and the named Bluesky case study. Matrix annual-report search excerpts described prospective 2026 use; they were not expanded into a third case or used to contradict a later current-use claim. No Bluesky-owned deployment report surfaced in these scoped queries; that is a retrieval limitation, not proof none exists. Public social reposts and irrelevant similarly named results were not treated as independent corroboration. No failed routes were retried. Acquisition stops here.