Ban Review
Review a ban request, record a human decision, and execute an approved action through a separate authorized step.
- Audience
- senior reviewer · team lead
- Availability
- premium preview · feature flagged · private beta access
- Maturity
- beta · partial
Last reviewed
On this page
Decision first, execution second
Ban Review turns a request into a senior-review workflow. The decision and the later Discord action are separate, permission-checked states.
Confirm reviewer and executor roles
Start from the registered ban-request command or user context menu, then continue in the Ban Reviews dashboard for packet review, decision, and any authorized execution.
- A specific member, proposed reason, and relevant server-scoped evidence.
- A reviewer with Ban Review decision permission.
- For execution, the required ban or mute permission and a still-valid target state.
Review, decide, execute, and finalize
Open the request
Create the ban request with a reason and review packet, then verify the target and selected server.
Check: The request enters a reviewable state without applying punishment.
Review and decide
Inspect available evidence and choose approve ban, approve a supported lesser action, reject, or escalate with a reason.
Check: The human decision is recorded and the request moves to an explicit decision state.
Execute separately
If approved, an authorized staff member uses Apply Ban or the matching supported action and confirms again.
Check: Execution records completed, blocked, failed, or retryable state independently of approval.
Finalize and notify
Review the final record and requester-notification status.
Check: The review closes with an auditable decision and records each side effect.
Ban Review examples
The request shows a reviewer decision, a separate execution state, and finalization/notification outcomes without conflating approval with punishment.
/ban-request user:@Maya reason:Repeated phishing after prior enforcementThe command creates a Ban Review request. It does not ban the member. An authorized reviewer must inspect the packet, record a decision, and a separately authorized executor must apply any approved action.
- Approve a ban and leave it in approved-pending-execution until an authorized executor applies it.
- Approve a lesser mute and verify that the specific action—not a ban—was executed.
- Retry only a failed or pending-retry execution after checking the existing record.
Build a review-ready request packet
A strong Ban Review request lets a senior reviewer understand the proposed action without recreating the incident from scattered messages. The requester should state the policy issue, timeline, prior interventions, current risk, relevant evidence, and why a lesser response may or may not be sufficient.
| Item | Include | Avoid |
|---|---|---|
| Target | Verified member identity and selected server. | Display name alone or a cross-server assumption. |
| Proposal | Ban or supported lesser action being requested. | Vague ‘deal with this user’ language. |
| Reason | Specific behavior, policy basis, time/context, and prior intervention. | Labels such as toxic, risky, or bad without source facts. |
| Evidence | Permission-aware source messages, context, files, history, or transcripts. | Pasting restricted material into a broad summary. |
| Urgency | Why normal review can proceed or why immediate safety handling is needed. | Using urgency to skip authority checks. |
| Alternatives | Why warning, mute, jail, or no action was considered. | Treating a ban as the only possible response without analysis. |
/ban-request user:@Maya reason:Repeated phishing after prior enforcement; evidence attached in the review caseDecision options and meaning
| Decision | Meaning | Next step |
|---|---|---|
| Approve ban | The reviewer authorizes a ban outcome based on the reviewed packet. | A separately authorized executor must confirm and apply the ban. |
| Approve lesser action | The reviewer authorizes a supported alternative such as a mute. | Execute exactly the approved alternative and verify its result. |
| Reject / no action | The request does not support the proposed enforcement at this time. | Record the reason and any monitoring, education, or evidence request allowed by server policy. |
| Request more evidence | The packet is incomplete for a confident decision. | Name the missing question and responsible owner; keep the case pending. |
| Escalate | A higher-authority or specialized reviewer is required. | Assign the review and preserve the current analysis and deadline. |
Execution, confirmation, and duplicate safety
Read the current decision
Confirm the request is in an executable approved state and identify the exact authorized action.
Check: The executor does not substitute a different punishment.
Check current target state
Verify membership, existing ban/timeout, hierarchy, and whether another execution already completed.
Check: The action is still necessary and valid.
Confirm once
Use Apply Ban or the matching supported lesser-action control and accept the explicit confirmation.
Check: One execution attempt is recorded with a stable identity where supported.
Read the result
Distinguish completed, already handled, blocked, failed, or retryable state.
Check: The requester and reviewer can see what actually occurred.
Finalize and notify
Check Case finalization and requester notification separately.
Check: A side-effect failure does not erase the decision or cause a duplicate punishment.
Senior reviewer quality checklist
- The target and server are verified.
- The packet includes source-aware evidence rather than only a narrative.
- The reviewer can identify the applicable server policy and prior actions.
- Contradictory or mitigating context was considered.
- The written decision explains proportionality and remaining uncertainty.
- The authorized action is specific, and execution permission is assigned separately.
- The final record includes execution, finalization, and notification outcomes.
Execution failed after approval
What you see: The case is approved, but Apply Ban or the lesser action returned failed, denied, or retryable.
What may be happening: Current Discord permissions, hierarchy, target state, stale case state, or a transient action error can block execution.
What to do
- Do not change the recorded decision merely to make the error disappear.
- Read the existing execution attempt and exact failure.
- Correct only the named boundary.
- Use the supported retry when the record permits it and verify finalization.
Approval does not equal execution
Ban Review is Beta and Partial: the core decision/execution workflow exists, while feature flags, permissions, notification delivery, finalization side effects, and some recovery states can vary. A requester DM failure does not erase the recorded decision.
Recover pending or failed execution
The result is not what you expected
What you see: A request is blocked, approved but not executed, failed, or waiting for retry.
What may be happening: Evidence/readiness requirements, reviewer permission, executor permission, target hierarchy, or a side effect may be incomplete.
What to do
- Read the current decision and execution labels before acting.
- Do not create a duplicate request for an approved-pending-execution item.
- Resolve the specific permission or readiness block.
- Retry only when the recorded execution state permits it and then verify finalization.
The handoff must include the Ban Review case, reviewer decision, execution status, and next authorized actor—not just a screenshot of an approval message.
Use private Ban Review spaces
A Ban Review packet can be posted to a configured private decision board and worked in a separate private workspace or thread. Reminders, requester notifications, restricted-evidence requests, draft uploads, and final archive state are supporting records; the canonical Case remains the durable review record.
- A decision does not execute a ban or mute; a separately authorized person must confirm execution.
- Restricted evidence remains unavailable until the viewer has its source permission.
- A requester DM failure does not reverse the recorded decision.
- The workflow is Beta and still requires deployment-specific Discord privacy and routing verification.