Risk summaries and analytics
Interpret deterministic, descriptive summaries as review aids and trace every consequential conclusion back to visible records.
- Audience
- senior reviewer · team lead · server admin
- Availability
- premium preview · private beta access
- Maturity
- alpha · partial
Last reviewed
On this page
A summary is a lead, not a verdict
Analytics and profile summaries organize recorded activity and deterministic rules. They help staff decide what to inspect; they do not establish intent, truth, guilt, or an automatic moderation outcome.
From summary to source review
| Displayed item | What it means | Required review |
|---|---|---|
| Count or trend | A descriptive aggregate over available records | Check date range, filters, missing data, and source events |
| Risk or attention label | A deterministic classification from configured/stored signals | Open the signals and evidence; do not enforce from the label |
| Behavior summary | A rule-based synthesis of available samples | Read sample quality, context warnings, and representative source records |
| Comparison | Relative values under one calculation and scope | Avoid causal or cross-server conclusions |
Trace the number back to visible records
Read scope and status
Confirm server, time range, filters, feature maturity, and sample-quality warnings.
Check: The number or label has a defined population and timeframe.
Open contributing records
Inspect representative visible events, cases, messages, or notes behind the summary.
Check: The displayed claim is traceable to source records.
Look for missing context
Check redaction, gaps, role changes, imported records, and alternative explanations.
Check: Uncertainty remains explicit.
Make a human decision elsewhere
Use the normal case or moderation workflow if action is warranted.
Check: The summary remains a review aid, not an enforcement engine.
A reviewer can describe what the summary measures, its limits, and which visible records support any subsequent human judgment.
Understand deterministic review aids
A deterministic summary applies fixed code and stored inputs. The same visible inputs produce the same output under the same version/configuration. That makes the calculation explainable, but not necessarily complete, fair, or correct for a moderation decision.
| Can | Cannot |
|---|---|
| Count stored actions, open Cases, appeals, or selected events. | Observe off-platform behavior or hidden/expired data. |
| Apply fixed weights or thresholds to visible counts. | Infer intent, truth, motive, danger, or guilt. |
| Sort or highlight items for review. | Authorize warnings, mutes, jails, bans, staffing decisions, or punishment. |
| Show a repeatable snapshot at a time. | Guarantee current state after new events or permission changes. |
| Reveal its contributing fields where the viewer may access them. | Make restricted source material visible. |
Trace a risk/attention signal
Read the label definition
Identify the fixed counts/window/threshold represented.
Check: The displayed signal has a known calculation.
Open contributors
Review each visible action, Case, appeal, or event that contributed.
Check: Source records support or challenge the summary.
Check exclusions/gaps
Identify redacted records, imported data, retention, and current filters.
Check: Missing context remains explicit.
Check current state
Determine which incidents were reversed, appealed, expired, duplicated, or resolved.
Check: Historical counts are not treated as active risk.
Record a human conclusion
Explain whether further review is needed and why.
Check: The signal stays advisory.
| Question | Purpose |
|---|---|
| What exact time window is used? | Prevents lifetime/short-window confusion. |
| Which sources are included? | Separates native, imported, and hidden records. |
| Does one incident create multiple rows? | Identifies duplicate/correlated counts. |
| Were actions reversed or appealed? | Prevents stale enforcement interpretation. |
| Can I inspect the contributors? | A consequential conclusion requires visible source review. |
Report analytics without overstating them
| Part | Example |
|---|---|
| Scope | “In Server X, July 1–17, native records visible to this reviewer…” |
| Measure | “…show 18 warnings, 6 mutes, and 2 bans…” |
| Caveat | “…excluding restricted Cases and records outside retention…” |
| Interpretation | “…which suggests reviewing spam escalation and event staffing…” |
| Decision boundary | “…not taking action against any member without source-record review.” |
Actively changing analysis remains reserved
Actively changing investigation, prediction, scoring, suggestion, and staff-performance features are listed only in Reserved guides. This guide provides no prompts, formulas, thresholds, decisions, setup, or release claims for them.
Record uncertainty before acting
Deterministic rules can produce false positives, sample-quality problems, stale values, and misleading comparisons. Cross-server identity or causal inference is not promised.
A cross-workflow state is unclear
What you see: The visible status, permission, source, or execution result does not support a confident next action.
What may be happening: The viewer may be reading a stale surface, a narrowed view, a separate lifecycle stage, or a partial operation result.
What to do
- Reset filters and confirm the selected server and date range.
- Inspect source records and sample-quality warnings.
- Treat missing or redacted data as uncertainty.
- Escalate a reproducible mismatch with the visible inputs and expected calculation.
Scores, summaries, and MIRA are different
Watchlist attention states are deterministic workflow facts such as an unresolved alert or due review, not a risk score or finding. Moderator Scorecards are a controlled staff-evaluation preview. MIRA is a separate coming-soon AI investigation workflow that can generate cited but fallible findings. None of these outputs authorizes automatic punishment.