Sentinel detection engine
Deterministic scoring. The score is its explanation.
Sentinel converts Discord events into signals, scores subjects against explicit weighted factors, and proposes actions that your enforcement mode gates. Every contributing factor is a visible (points, reason, category) entry shown verbatim to moderators — no opaque ML score anywhere in the pipeline.
Explainable scoring, live
Toggle factors below and watch the score recompute. This mirrors the real default weights — the same inputs always produce the same score, which is what makes false positives traceable to a specific factor and tunable.
Try the scoring model
Same inputs, same score — every timeComputed score
- Account < 24h old+25
- Joined during spike+20
Default weights and thresholds shown (25 / 50 / 75 → elevated / high / critical); every value is configurable per guild. When three or more unrelated categories trigger within ten minutes, the subtotal is multiplied ×1.5 — recorded as its own factor so the sum always equals the score. The score clamps to 0–100.
Signal categories
Every detector emits signals with a category, severity, confidence, source, normalized metadata, and a correlation ID. Nineteen categories cover member behavior, content, and administrative surface changes:
- join_behavior
- message_velocity
- duplicate_content
- mention_density
- link_reputation
- invite_posting
- attachment_risk
- account_age
- membership_age
- role_mutation
- permission_mutation
- channel_mutation
- webhook_mutation
- bot_addition
- moderation_velocity
- staff_behavior
- ban_activity
- config_change
- repeated_triggers
The enforcement-mode ladder
Detectors never act directly. Each protection has its own mode, per guild, so you climb from observation to automation one deliberate step at a time:
- offThe protection is disabled. Nothing is evaluated or recorded for it.
- dry_runRules evaluate and record what they would have done — no alerts, no actions. Useful for tuning before anyone sees a ping.
- log_onlySignals and proposed actions are logged and visible in the dashboard, but nothing is enforced. The safe default for message and link protection.
- human_approvalA durable, single-consume approval panel is posted to your alert channel; a staff member confirms or rejects each proposed action. The default for raid and anti-nuke responses.
- automaticApproved action types execute without a human in the loop, still within hierarchy checks and budgets. Automatic emergency lockdown is rejected at config validation — that step always requires a human.
Safe defaults: message and link protection start in log_only; raid and anti-nuke start in human_approval. Rejecting an approval panel records a false-positive event for tuning.
Raid detection: burst + corroboration
Joins are tracked in a sliding window against an adaptive baseline (EWMA). A burst alone — an absolute floor or a multiple of your baseline — is not enough to call a raid. Sentinel also requires a corroborating signal: at least 60% new accounts in the wave, or at least 50% sharing a username stem.
That corroboration requirement is deliberate: AEGIS never mass-bans purely on join velocity. A busy launch day is not a raid. Raid bursts also never poison the baseline, so one incident doesn't blind the detector to the next.
Verdicts open (or append to) a single active raid incident, alert staff, and — gated by your enforcement mode — escalate containment. Containment is durable, never auto-de-escalates, and is released explicitly by staff holding the release permission.
Containment levels
observe
Baseline: watch and record, no restrictions.
heightened_verification
New joins face stricter checks before participating.
quarantine_new_members
Members who joined during the window are quarantined pending review.
restricted_messaging
Slowmode and messaging restrictions limit the blast radius.
emergency_lockdown
Joins and messaging locked down. Never automatic — always requires human approval, and release requires the lockdown.release permission.