How we share safety information with other venues — and how we don't.

Bad actors don't usually limit themselves to a single venue. When someone is banned from one community for behavior that poses a credible safety risk, they often try the next one down the road. That makes a vacuum where there shouldn't be one — and across the broader scene, that vacuum is occasionally what allows someone to keep harming people.

Cross-venue safety alerts are how we close that vacuum a little. This page describes the practice in detail — what triggers an alert, what we share, what we won't share, and who's on the receiving end.

The full incident-handling context is in our incident reporting policy; this is the standalone page for the cross-venue piece.

What this is

An alert is a deliberate, person-to-person communication from someone on our response team to a vetter at another venue we have an established relationship with. It says, in effect: "This person has been banned from our space for safety reasons. Here is the general nature of the concern. We're letting you know in case they apply or appear at your venue."

Alerts are not posts. Not databases. Not lists circulated by email. Not gossip. They're individual messages to individual people who have agreed in advance to be reachable for safety conversations.

When we send an alert

Both conditions must be true:

1. The incident outcome was revocation. Not a note in the record. Not conditions on membership. Not a decline. A formal revocation — membership ended after panel review by the response team plus additional vetters.
2. The behavior was a credible safety risk. Not a personality conflict. Not a registry hit alone. Not something that's better described as "we couldn't make it work" than as "this person is dangerous."

Both conditions, no exceptions. A decline that didn't reach revocation doesn't generate an alert. A revocation for non-safety reasons (e.g., repeated failure to engage with the community) doesn't either.

When we don't send an alert

Even when the bar is met, we don't always share. Things that change the calculus:

• The reporter explicitly asks us not to. Sometimes a reporter is worried about retaliation, or about being identified by the subject through a small-scene grapevine. We weight their preference heavily.
• There's no relevant receiving venue. If the person has no plausible connection to any other community we work with, sending an alert means publishing information about them to people who can't act on it.
• The receiving venue's process can't handle the information well. If we don't trust their discretion, we don't share with them. The alert exists to make people safer, not to add an entry to someone else's records.

What we share

An alert message typically contains:

• The fact of the ban. That a revocation outcome was reached.
• The general nature of the concern. "Consent violation," "predatory pattern," "credible threats," etc. — not specifics of any one incident.
• Identifying information the receiving venue would need. Usually the scene name, sometimes a photo if the subject is likely to apply under a different name. The least amount of detail that lets the receiving venue recognize the person if they encounter them.
• A contact on our response team in case the receiving venue has questions.

What we do not share

• The reporter's identity. Not their name, not their pseudonym, not enough detail to identify them.
• The specifics of any incident. What happened, where, when, between whom.
• Speculation about the subject's pattern beyond what the report contained. We share what we know; we don't extrapolate.
• The subject's legal name or other ID data unless the receiving venue specifically needs it for vetting (rare; usually scene name is sufficient).
• Anything about other people involved — partners, witnesses, affected parties.

Who we share with

We share with vetters at other venues we have established relationships with. "Established" means specifically:

• There's a known, named human at the other venue with whom we've had at least one direct conversation before any alert is sent.
• That person has agreed to be reachable for safety conversations.
• That person has confirmed how their venue handles such information — that it goes only to their vetters or response team, not to general member lists or forums.
• We have some basis for trusting their discretion — usually a prior relationship, a mutual contact, or a track record we've observed.

We do not share with:

• Generic "safety lists" or "ban lists" that circulate publicly
• Venues we've never spoken to
• Online communities or forums (even kink-specific ones)
• Anyone whose discretion we don't know firsthand or by trusted reference

The subject's right to know

If we send an alert about someone, we tell them. Specifically:

• That an alert was sent
• To which venue(s)
• The general substance of what we shared
• Their right to dispute the underlying decision through our appeals process (covered in the incident reporting policy)

We do this because the alternative — secretly maintaining a quiet network they don't know about — is the kind of opaque process that erodes trust and is harder to defend when it goes wrong. People we ban deserve to know what we've said about them, even though they don't get a veto on whether we said it.

If your venue wants to be on our list

We add venues to our receiving network deliberately, not in bulk. If you run or vet for a venue that handles a comparable membership and you'd like to be reachable for safety conversations, here's how to start:

1. Email This email address is being protected from spambots. You need JavaScript enabled to view it. with who you are, where you operate, and how your venue handles incident information internally.
2. We'll respond within a couple of weeks. The initial conversation is mutual — you'll learn how we handle things too.
3. If the conversation goes well, we'll add a named contact on each side. From then on, we know how to reach each other when a safety conversation is needed.

We don't ask for fees, formal contracts, or reciprocity guarantees. We do ask for honesty about how your process actually works in practice — not just what your policy says.

When we receive an alert

The flip side: another venue may reach out to us about someone they've banned. Our protocol:

• The alert goes to the response team, not the general vetter pool.
• The information is logged in our system, gated to the response team.
• If the named person ever applies to us — or appears as a plus-one or potential guest — the alert surfaces.
• The alert is one input among several, not an automatic decline. The receiving-venue's information is weighted appropriately given what we know about that venue's process; we make our own decision.
• The named person is told if our decision was influenced by the alert.

We do not forward, publish, or otherwise re-share alerts we receive. They stay in our internal records and inform our decisions only.

What this is not

• A public registry. No.
• A way to retaliate against people we don't like. The bar is "revocation for credible safety risk." That bar is high on purpose.
• A way to outsource our vetting to other venues' decisions. We treat received alerts as data, not as verdicts.
• A guarantee. Someone determined to harm people can move further afield than our network reaches, change names, and start fresh. Alerts close some gaps; they don't close all of them.

Why we do this anyway

Community-safety information sharing has a checkered history in the broader scene — informal blacklists that turned out to be wrong, list-of-shame moves that were really score-settling, "missing stair" patterns that everyone knew about but nobody made formal. The alternative we're building isn't perfect, but it's deliberate: high bar, narrow scope, named human-to-human contact, transparency to the subject, internal accountability.

The goal is that a person who's banned here doesn't quietly land at the next venue over without that venue knowing anything. The goal is not, and has never been, to make sure anyone we don't like is unwelcome everywhere. Those are very different things and we hold the line between them.

Related: incident reporting policy (the policy framework), privacy policy (the data-sharing carveout in plain language). Questions: This email address is being protected from spambots. You need JavaScript enabled to view it..