ROOST Project Roadmap now available: share your feedback!

[cassidyjames]

Hey ROOSTers, community members, partners, and other Internet friends! The ROOST Project Roadmap is now publicly available—and in true open source fashion, it's hosted right here on GitHub, on our Community repo:

https://github.com/roostorg/community/blob/main/roadmap.md

This roadmap is a mostly near-term look at our priorities when it comes to the tools and features we're focused on building.

We're thrilled to share it with you all, and especially to get your input and feedback! Please use this discussion to share any feedback, questions, suggestions, or comments that you might have, and we can work together to discuss them here and file any appropriate issues/pull requests against the community repo when it makes sense.

We look forward to your input! 🐣

[julietshen]

wow so much cool stuff

[joshgay]

Thank you, this is great work and a nice solid bedrock for community building.

[cassidyjames]

Thank you @joshgay!

[vinaysrao1]

@tgthorley Answering your comments here:

I think in general this strikes the balance of providing AI integrations but also ensuring non-AI based capability is available.

However - given the prevalence of AI and ML in Safety (for a decade now) and the increasingly fast adoption of Agentic AI, I wonder if ROOST should be thinking more ambitiously about the role of AI in Safety systems and howAI native capabilities might improve the eco-system.

Our desire to be backwards compatible and provide choice shouldn't limit innovation at the cutting edge.

Thank you for calling this out. We agree that AI will play an increasingly important role in the threat models we have to defend against and in the defenses we will build. This is a relatively short term roadmap and we are looking forward to working with you to build a more ambitious one.

Question in ignorance that this point sparked:
Does Osprey currently support "Sliding Window" type detections?

Yes, this will be one of the features we will put out as a fast follow to the v1 release of Osprey.

One area of exploration that I think is a critical future area for the industry is the integration and feedback in policies and enforcement
guidance so that ML detections can adapt to policy/guidance changes dynamically as well as provide feedback on them (i.e. identifying
policy gaps, outliers that don't fit in existing guidance etc). This tightening of the loop between operations and policy is something
that we should consider.

There is a plan for an ML platform coming that considers this usecase in the context of building prompted LLMs with a feedback mechanism to develop a policy wrt to a dataset with known outcomes. Two outcomes we are looking for is (a) gaps in the current policy (b) changes that will cover the gaps.

Love this and have some thoughts and experience in how we can develop this functionality. I'll see if we can provide some open source
examples. in 2026

Looking forward to hearing about your experience with this.

I'm interested to think about where the line between COOP and Osprey is in this regard. Where does Agentic review live - should it live
in the review system or should it be an extension of the detection systems or is there some new middle layer here for Agentic Review
that essentially feeds into the Human review tool where needed.

This is still in ideas and thinking stage. We had two applications in mind (1) Osprey: offline analysis for missed recall (2) Coop: agentic human assist. Agentic because models will have access to tools to query dbs, do websearch etc to map the full threat network. Given the scope and scale of the investigation, we frame it as human assist rather than automated.

I'd love to think about testing and evaluation suites in this context and how we link that back into COOP.

Yes, this would fit nicely with the eval platform and Coop integration. We will appreciate your inputs.

[marielpovolny]

Thank you for sharing this roadmap! The progress on Osprey alone, especially the feature and stability improvements you’ve delivered in just a few months, is remarkable, especially as someone who new open-source ecosystems and building. Exciting to see this tool mature so quickly into something genuinely usable across different safety workflows.

I have a question about the scope of participation within the Model Community:

The roadmap highlights resources, datasets, prompt-translation support, and model comparison events, and I’m curious whether you also envision the RMC as a place for more practitioner-oriented engagement (e.g. sharing operationally grounded failure modes or insights that emerge during real-world deployment). Or is the intent for the RMC to remain primarily focused on structured evaluation, knowledge resources, and feedback loops to model developers?

Looking forward to seeing how all of this takes shape.

[Celestine22]

Overall, this is awesome stuff. Clarifying how teams should evaluate fit and sequence adoption would make it even easier for potential users and contributors to engage early and effectively. Even a lightweight lifecycle diagram or a short “who this is for” section per project could help.

[ThisIsMissEm]

Support for text input that is markdown formatted would probably be good for applications that support rich text — you probably don't want raw HTML, and many AT Protocol applications have some degree of rich text, though their specifics vary quite a lot (there's no standard for rich text), so converting the text to markdown prior to sending to Coop would allow Coop to render something near correct without supporting custom rich text.

[gbiss]

This is a recommended roadmap item for Coop, which is based on a conversation I had with @julietshen in the coop-internal channel on Discord. It could be useful for Coop to implement "cascading" rules. By that I mean, instead of a rule attempting to match against every media item that stream through the system, the rule could instead be configured to run as follow-up, contingent on an earlier rule being triggered first.

I have the following use-case in mind. Perhaps there exists a more heavy-weight ML service that should only run if an image has first been predicated by a lighter-weight model. Media that trigger the lighter-weight rule would then be put into a queue to be evaluated against the heavy-weight service. This could help avoid filling human moderation queues with many false positives that might arise from a light-weight model, but also avoid performing heavy-weight computation on every media item that streams through the system.

[tgthorley]

Yes! This is the model our detections systems use at GitHub... high recall, low precision rules first, then higher precision (more computationally expensive) rules (including bespoke classifiers and LLMs) run to triage the detections and drive down false positives.

[cassidyjames]

Thanks @gbiss and @tgthorley! I've opened an issue on the Coop repo here: roostorg/coop#75

[julietshen]

@vinaysrao1 recently brought up the following while thinking through what's needed for our projects in the short-term in order to be ready for AI-powered safety.

We're proposing adding a Data Abstraction Layer and a Safety Decision Taxonomy to the roadmap as prerequisites for AI-powered features in both Coop and Osprey. Sharing the detailed proposal here for feedback!

Data Abstraction Layer

Any detection or agentic system is only as good as the data it has. Each org has a different data model (accounts, posts, servers, threads, channels). It is likely that raw data (front-end logs) and processed data (account trust graphs) are in tables outside Coop and Osprey. Without a shared abstraction for entity relationships and a way to reach into org-specific data, every feature we build (agentic assistants, automation agents) inherits these limitations.

Two constraints limit what Coop and Osprey can do today:

• Data model heterogeneity: Every org has different data types and different relationships between them. Coop and Osprey make minimal assumptions about this, which limits the depth of investigation, review, and AI-assisted reasoning.
• Data visibility: Both tools only see data pushed through the input event stream. Useful context like account history, reputation scores, and content/account relationships might live outside these tools.

AI assistants and agentic review outcomes depend on having full context. We propose three primitives:

1. Entity Graph Declaration

Orgs provide a schema config that declares their entity types and key fields. For example: an account has many posts, a post belongs to a thread, a thread belongs to a channel. Coop and Osprey consume this declaration generically: the review UI renders relationship context based on the graph, Osprey rules can traverse these relationships, and an agentic assistant knows what questions it can ask.

The schema ships as a spec, validator, and reference implementation for common platform shapes (AI chatbot, social media, gaming, or messaging platform).

This lets an AI assistant ask "show me other posts by this account" or "what is the moderation history of this channel." The graph considerably reduces the complexity of building AI assistants and reduces unpredictability in their results. Agents can also explore the data schema to discover new attacks.

2. Content Enrichment

Events are often just an entity ID, action type, and a payload. We need useful context for thorough analysis that includes broader signals like account age and reputation score.

Define an enrichment interface: org-implemented functions that run at event ingestion time and fetch additional context from org-internal systems. Enriched events carry richer context through the entire pipeline. Osprey and Coop rules can evaluate it, Coop's review interface can display it, and AI assistants can reason over it.

Instead of "user X posted Y," it becomes "user X (account age: 2 days, reputation: low, failed verification) posted content Y (in channel Z, with 12 flags this week)."

3. Graph Query Protocol

Define a query protocol where inter-event and inter-entity relationships are expressed. This can be used in Coop's review interface and by AI assistants. The protocol converts a natural language question like "find related entities by attribute Y" to a properly-formatted query against org-internal systems.

The protocol could use MCP as a transport layer or a simple lookup table with database table schemas and sample queries. Orgs can control who can query which tables. The protocol is a contract, not an implementation. This could get complex quickly, and the simplest approach is materialized tables and giving access to just the tables.

Safety Decision Taxonomy

Related to the Data Abstraction Layer, we're also proposing a Safety Decision Taxonomy that works across both tools. Policy enforcement for individual content is well understood. A piece of content is violating, borderline, or fine, and an action is associated with the label.
Account-level policies are less mature. Policies and decision maps for anything more complex (sequences of behaviors, correlated accounts, content patterns) are very rarely formally defined. These are the patterns we expect from AI-assisted adversarial behavior. They continuously mutate. The system we build needs to adapt.

The taxonomy is a representation framework for expressing policies across all entity scopes and all decision types. It is a shared language between humans and AI safety agents.

Dispositions

At a high level, three outcomes:

Violative: The entity or pattern matches an existing policy with a defined enforcement. This is deterministic. It becomes a rule in Osprey or Coop. How to action known
badness: auto-action or manual review.
Needs review: The entity or pattern matches a known behavior with middling confidence, or mostly matches a pattern but there are notable differences from pre-defined
enforceable outcomes. These get routed to an appropriate evaluator, like a specific queue in Coop. Also deterministic.
Needs classification: This is the heart of AI-assisted exploratory work. It is not about executing known policies but about discovering new behaviors for which a policy may be needed. Adversarial mutations and novel harm patterns should be caught here as anomalous clusters. This could trigger further AI-assisted hypothesis generation and testing, or human exploration. For new badness: detect → investigate → create policy → codify → monitor.

Entity Scopes

All of the above apply across accounts, behaviors, content entities, and their associated clusters. The cardinality of the problem space will be large. AI-assisted exploratory work will require checks to prevent combinatorial explosion.

Feedback Loop

The taxonomy is self-extending:

• Discovery: Anomaly detection and clustering-based rules identify new patterns.
  Investigation: Existing data is overlaid on new patterns (average reputation score, average account age, etc.) to understand similarity to historically bad or good behavior.
• Policy: Based on the pattern's harmfulness, create a policy.
• Codification: Convert the pattern into an Osprey or Coop rule (via a classifier if needed) under the "violative" or "needs review" dispositions.
• Monitoring: Continue monitoring the classified pattern for drift, and at the appropriate time feed back to the "needs classification" pipeline.

This loop makes the taxonomy self-extending and makes the system ready for AI-enhanced adversarial harm.

Models from the ROOST Model Community connect to this work: gpt-oss-safeguard already provides reasoning-based policy evaluation with bring-your-own-policy support, and as the community grows, models suited to clustering and anomaly detection could plug into the "needs classification" pipeline.

Proposed Scope

Taxonomy schema spec: A declarative format for expressing policy across all three dispositions and entity scopes, including their clusters and inter-entity relationships.
Coop and Osprey integration: Both tools consume the outcomes in terms of their rules, with Coop specifically handling manual reviews.
Classification feedback: Coop-based workflow tooling for the full loop.

[tpepper]

This makes sense to me. Two small notes:

"AI assistants can reason over it" risks overstating the possible extent to which assistance may be possible. Perhaps instead of "reason over", phrase as "attempt to perform inference on". In a way this aspirational delta is highlighted later by wanting to plumb MCP servers and have simple table queries.

"Feedback Loop": has four steps, where a few paragraphs earlier there were five. The longer list of five steps is more expressive in a helpfully explanatory way.