Platform Safety Reporting

Why this exists

Every feature in the bot is designed to be used between consenting adults in age-restricted communities. We don't want this bot to ever become a tool for abuse. Neither for harming individual members nor for distributing content that breaks Discord's platform rules, especially anything involving minors.

Platform Safety Reporting is the back door for severe issues that can't wait for a server's moderation team. For instance, suspected child safety violations, threats of off-platform harm, or coordinated abuse spanning multiple servers. It exists so the bot operator can act on those reports directly, in addition to the reporter using Discord's own reporting flow.

What you should use this for

• Suspected child sexual abuse material or grooming behavior you've seen via the bot or in a server it's operating in.
• Credible threats of physical harm.
• Coordinated harassment or doxing campaigns spanning multiple servers that the local mod team can't address alone.
• Abuse of the bot itself to harm someone (e.g. weaponising verification, automod, or the dynamics features against an unwilling participant).

Day-to-day server moderation belongs in your server's existing moderation tools (/warn, /mute, /report). Platform Safety Reporting is for the rare cases that go beyond what any one server can handle.

What happens when you submit one

When a member runs /safety-report:

1. You pick a category (the modal lists severity-graded options). Selecting a child safety category triggers an explicit reminder that you should also report directly to Discord and, where relevant, to your country's child-protection authority.
2. You describe what happened in your own words. The bot does not surveil messages or attach context automatically; only what you type and any links / attachments you include become part of the report.
3. The report is stored in platform_safety_reports with a severity tag, the reporting user's ID, the source guild, and the description / evidence you submitted.
4. You receive a confirmation message that includes a link to Discord's own report flow for the same content. We encourage you to file there as well. Discord can act platform-wide in ways the bot cannot.

The report does not automatically take action against anyone. It's a notification mechanism that routes to the bot's safety reviewers, not an enforcement mechanism.

Who can read a report

• The bot owner.
• Members of the configured safety log guild who hold a safety admin role.
• Nobody else. Reporter identities are not shared with the reported user, the source server's mod team, or in any appeal record.

High-severity reports route to a dedicated safety log channel coloured by severity. Reporter identity is included for safety admins so they can follow up; it is never exposed to the subject of the report.

How risk scores work

Each guild has a risk profile in platform_safety_guild_risk_profiles. The score is a running total of:

• Severity-weighted contributions from confirmed safety reports against members of that guild.
• Discord native AutoMod and raid-heat events (only when the bot observes them).
• Bot-owner adjustments. Typically used to halve the weight of a report once the original incident has been resolved (de-flagging) rather than deleting history.

Risk scores are not visible to the reported user, the reporter, or your server's mod team. They influence whether the bot owner reviews additional automation suggested for that guild. For example, more aggressive raid-heat thresholds. And, in the most severe cases, whether the bot is removed from a guild.

What the reporter sees

Submitting a report ends with a private confirmation that includes:

• A copy of the category and the text you submitted, so you know what was logged.
• A direct link to Discord's own reporting article and to the in-client report flow for the relevant content type.
• A reminder that, for child-safety categories, you should also report to your country's authority (in the US, that's NCMEC's CyberTipline).
• The opaque public ID of the report, so you can reference it if you need to follow up.

Appeals and de-flagging

If a guild has its access to the bot revoked or restricted as a result of safety findings, the guild's current or snapshot-at-revocation owner can submit a written appeal:

• Appeals live in platform_safety_appeals keyed by a public ID.
• Submission requires the appellant to be the recorded owner and includes the appellant's stated context. Original reporters are never named in the appeal record, and never contacted by the appellant directly.
• The bot owner reviews each appeal and writes a decision into the same row. Decisions are advisory for the operator; we reserve the right to maintain a revocation if it remains in the community's interest.
• If an appeal succeeds, the corresponding entries on the guild's risk profile are de-flagged: their weight drops to zero (or, where partial culpability remains, is halved per the operator's note).

There is no public timeline guarantee on appeal decisions. The operator targets reviewing every appeal within seven days; severe cases (involving child safety) are reviewed sooner.

What we will not do

• We will not retaliate against the subject of a report on the basis of a single uncorroborated submission. Reports inform review, not automated bans.
• We will not share a reporter's identity with the subject of the report or with appellants under any circumstances.
• We will not use safety-report data for any purpose other than handling the report and adjusting risk profiles. Reports are not training data, are not commingled with general analytics, and are not shared with third parties absent a legal requirement.
• We will not allow the bot to be the only path for a reporter. Every flow nudges the user to also use Discord's own reporting mechanism, which has reach the bot does not.

If you've been falsely flagged

Contact the bot operator via the support server linked from the documentation index. If you're a guild owner whose access has been restricted, run the appeals flow described above. We're a single-operator project at the moment, so response times depend on real-life availability; severe cases are always prioritised.