Welcome to CAP-ROC Discussions!

[SPARK-NITT]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[SPARK-NITT]

What CAP-ROC is trying to prevent (and why this repo exists)

Most ROC work assumes the only question is: “How good is the model?”
CAP-ROC adds the missing question: “Do we actually have enough human review capacity to survive this operating point?”

This standard treats ROC tuning as a deployment feasibility problem, not just a math exercise. It couples each operating point to a documented human review budget, with optional Poisson overload checks (the δ-bound), so you can’t quietly move into a regime where false positives or edge cases will simply drown the people responsible for catching them.

In plain terms: CAP-ROC is a gate that forces teams to show their work on:

• what operating point they picked,
• how many human reviewers they truly have,
• what overload they’re willing to tolerate,
• and what happens when those numbers are wrong.

I’m opening this discussion for:

• questions about the spec or examples,
• feedback on whether the capacity constraints feel realistic in real orgs,
• and ideas for extensions (other domains, other overload models) that still respect the core “capacity-first” principle.

If you’ve ever watched a “high-AUC system” collapse real people under unreviewed edge cases, this repo is aimed directly at that failure mode. Curious to hear how it lands from your side.