AtomicGuard — Complete Administrator Guide

AtomicGuard is AtomicBot’s guild-level Discord content moderation system.

It is designed to give Discord administrators broad control over moderation behavior without forcing them to manually manage every individual rule.

AtomicGuard can detect and manage content such as:

• Profanity
• Harassment
• Sexual harassment
• Hate / slurs
• Threats
• Scam / phishing content
• Advertising
• Discord invites
• NSFW content
• Custom server-specific words
• Custom phrases
• Custom domains

AtomicGuard combines:

• A global AtomicBot built-in rule catalog
• Per-Discord category policies
• Per-Discord built-in rule overrides
• Custom guild rules
• Rule exceptions
• Violation history
• Private evidence
• User strikes
• Timeout escalation
• Moderator reviews
• Audit logging
• Evidence retention management

---

Quick Summary

The recommended way to configure AtomicGuard is:

1. Enable AtomicGuard.
2. Set it to OBSERVE.
3. Configure a moderator report channel.
4. Configure your broad Category Policies.
5. Leave most built-in rules on INHERIT.
6. Review violations for false positives.
7. Add exceptions or individual rule overrides where necessary.
8. Configure strike escalation.
9. Switch AtomicGuard to ENFORCE once you are comfortable with the configuration.

The important concept is:

Categories handle broad policy.

Built-In Rule overrides handle individual exceptions.

Custom Rules handle content specific to your Discord.

Exceptions handle safe uses of otherwise restricted content.

---

1. AtomicGuard Overview

Open:

Dashboard → Security → AtomicGuard → Overview

The Overview page gives you a quick summary of AtomicGuard activity for the current Discord.

It may show information such as:

• Total violations
• Violations during the last 24 hours
• Number of active built-in rules
• Number of custom rules
• Category overrides
• Individual rule overrides
• Users with active strikes
• Current AtomicGuard operating mode
• Recent violations

The Overview page is useful for quickly checking whether AtomicGuard is active and how much moderation activity it is seeing.

---

2. AtomicGuard Settings

Open:

AtomicGuard → Settings

This is where you control the overall behavior of AtomicGuard for the current Discord.

---

3. AtomicGuard Enabled

The:

AtomicGuard Enabled

setting is the master switch.

Enabled

AtomicGuard scans messages according to your configured policies.

Disabled

AtomicGuard stops processing content moderation rules for the current Discord.

This does not delete your configuration.

You can disable AtomicGuard temporarily and enable it again later.

---

4. Operating Mode

AtomicGuard has two operating modes:

• OBSERVE
• ENFORCE

---

OBSERVE

Recommended while initially configuring AtomicGuard.

AtomicGuard will:

• Scan messages
• Detect matching rules
• Record violations
• Store evidence
• Send moderator reports if configured

But AtomicGuard will not apply the configured punishment.

For example, a rule configured as:

STRIKE

will still be detected and recorded while in OBSERVE mode, but the user will not actually receive the strike.

OBSERVE mode is ideal for:

• Initial setup
• Testing new rules
• Checking for false positives
• Testing category policies
• Reviewing the built-in catalog

---

ENFORCE

AtomicGuard will apply the configured moderation action.

Depending on the effective rule action, AtomicGuard may:

• Monitor
• Delete the message
• Warn the user
• Add a strike
• Timeout the user

Only switch to ENFORCE once you are comfortable with your configuration.

---

5. Moderator Report Channel

Under Settings, configure:

Moderator Report Channel ID

This should be the Discord channel where AtomicGuard sends moderator reports.

Example channel:

#atomicguard-reports

Enter the Discord channel ID, not the channel name.

AtomicGuard moderator reports are intentionally sanitized.

The original offending message is not repeated into Discord.

Authorized administrators can view the full original evidence privately through the AtomicGuard dashboard.

---

6. Review URL Base

AtomicGuard can store a:

Review URL Base

This is used to create links from Discord moderator reports back to the AtomicGuard dashboard.

The purpose is to allow a moderator to click a report and jump directly to the corresponding violation record.

Example concept:

https://your-domain.example/dashboard.php

The running AtomicBot handler must also support this setting for the Discord button to use it correctly.

---

7. Scan Policy

AtomicGuard can scan different Discord actor types.

Available options include:

• Users
• Bots
• Webhooks

Recommended defaults:

| Actor | Recommended |
|---|---|
| Users | ON |
| Bots | OFF |
| Webhooks | ON |

---

Users

Normal Discord members.

This should normally remain enabled.

---

Bots

Other Discord bots.

Bot scanning normally defaults to OFF because legitimate bots may output text that accidentally matches a moderation rule.

Enable this only if you intentionally want AtomicGuard to inspect other bots.

---

Webhooks

Messages generated through Discord webhooks.

Webhook scanning is useful because compromised or abused webhooks can be used to post spam or scam content.

---

8. Protected Staff Logging

AtomicGuard protects authorized staff from automatic punishment.

If:

Log Protected Staff

is enabled, AtomicGuard can still record a suspicious staff message for review while suppressing punishment.

This allows you to audit detections without risking AtomicGuard automatically timing out or striking administrators.

---

9. User Warnings

If:

User Warnings

is enabled, AtomicGuard may send sanitized user-facing warnings for rules configured to use warning behavior.

User warnings do not repeat restricted content.

---

10. Settings Autosave

The AtomicGuard dashboard now saves most Settings changes automatically.

Checkboxes and dropdowns save when changed.

Text and number fields save when editing is completed.

You normally do not need to manually submit the entire Settings page after every change.

When a value is saved, the dashboard displays a success notification.

---

11. Strike Escalation

AtomicGuard can track repeat offenders through strikes.

Strike configuration is found under:

AtomicGuard → Settings

Important settings include:

• Strike Window Days
• Timeout After Strikes
• First Timeout Minutes
• Repeat Timeout At
• Repeat Timeout Minutes
• Auto Ban At Strikes
• Immediate TIMEOUT Rule Duration

---

12. Strike Window Days

This determines how long active strike escalation is considered.

Example:

30 days

If the user's previous strikes fall outside the configured strike window, their escalation state can reset when a new violation occurs.

---

13. Timeout After Strikes

Example:

3

This means a user reaching 3 active strikes can receive the configured first escalation timeout.

---

14. First Timeout Minutes

Example:

10

If the configured strike threshold is reached, AtomicGuard can timeout the user for 10 minutes.

---

15. Repeat Timeout At

Example:

5

If the user continues receiving strikes and reaches this number, AtomicGuard can apply the longer repeat-offender timeout.

---

16. Repeat Timeout Minutes

Example:

60

A repeat offender reaching the configured threshold could receive a 60 minute timeout.

---

17. Auto Ban At Strikes

Example:

0

A value of:

0

means automatic strike-based banning is disabled.

This is the recommended conservative setting if you prefer moderators to manually review users before banning them.

---

18. Immediate TIMEOUT Rule Duration

Some individual rules may be configured directly as:

TIMEOUT

This setting determines the timeout duration used for those immediate TIMEOUT rules.

---

19. Recommended Strike Configuration

A conservative starting configuration is:

3 strikes → 10 minute timeout

5 strikes → 60 minute timeout

Auto-ban → Disabled

This provides automatic escalation while still leaving permanent banning to moderators.

---

20. Category Policies

Open:

AtomicGuard → Categories

Categories are the preferred way to control broad types of content.

Instead of changing dozens of individual rules, you can apply one policy to an entire category.

Common categories include:

• PROFANITY
• HARASSMENT
• SEXUAL_HARASSMENT
• HATE_SLUR
• THREAT
• SCAM_PHISHING
• ADVERTISING
• DISCORD_INVITE
• NSFW
• CUSTOM

---

21. Category Actions

Each category can use:

• INHERIT
• ALLOW
• MONITOR
• DELETE
• WARN
• STRIKE
• TIMEOUT

---

INHERIT

Use AtomicGuard's built-in behavior.

Recommended when you do not need a server-specific policy.

---

ALLOW

Explicitly allow the content.

Example:

A mature Rust Discord may use:

PROFANITY → ALLOW

This allows profanity without disabling the global detectors.

---

MONITOR

Record and report matches without applying punishment.

Useful for:

• Testing
• Borderline categories
• Manual moderator review

---

DELETE

Delete the offending message.

No strike is necessarily added.

---

WARN

Delete the message and optionally send a sanitized warning to the user.

---

STRIKE

Delete the message and add an AtomicGuard strike.

Strike escalation settings may then trigger timeouts.

---

TIMEOUT

Delete the message, add a strike, and immediately timeout the user.

This should generally be reserved for serious violations.

---

22. Category Autosave

Category policies now save automatically.

When you change:

This Discord's Policy

AtomicGuard saves the new policy immediately.

You do not need to press a separate Save button for every category.

---

23. Understanding INHERIT

AtomicGuard uses a hierarchy.

For an individual built-in rule action, AtomicGuard checks:

1. Individual Guild Rule Override
2. Guild Category Policy
3. AtomicBot Built-In Rule Default
4. AtomicBot Category Default

The first value that is not INHERIT wins.

---

24. INHERIT Example

Suppose:

Rule:

AG-PROF-001

Individual Guild Action:

INHERIT

Guild PROFANITY Category:

ALLOW

The effective result is:

ALLOW

You do not need to manually change every profanity rule.

---

25. Individual Rule Override Example

Suppose:

PROFANITY → ALLOW

but one particular built-in rule should still be monitored.

Set that individual built-in rule to:

Guild Action → MONITOR

That individual rule override takes priority over the category.

The rest of the profanity category remains allowed.

---

26. Built-In Rules

Open:

AtomicGuard → Built-In Rules

This page contains AtomicBot's shared global detection catalog.

You can find a rule using:

• The built-in AtomicGuard search box
• Browser Ctrl+F
• Category filter

Search can include:

• Rule key
• Pattern
• Category
• Description

---

27. Built-In Rule Columns

Each built-in rule may include:

• Rule Key
• Pattern
• Category
• Catalog Active
• Atomic Default
• This Discord
• Guild Action
• Guild Severity
• Save Status
• Catalog Editor

---

28. Catalog Active

Catalog Active controls whether the detector exists globally inside AtomicBot.

This control is available only to the AtomicBot owner.

---

Catalog Active = ON

The rule is globally available.

Discord guilds may inherit it, disable it locally, or change its action.

---

Catalog Active = OFF

The rule is disabled globally.

No Discord can use that detector while it is inactive.

This is a master catalog control.

Use it only when the detector itself should no longer operate anywhere.

Examples:

• Incorrect rule
• Obsolete detector
• Severe false positive
• Duplicate rule
• Rule intentionally retired

---

29. Important Global Rule Behavior

If a catalog rule is globally inactive:

Catalog Active → OFF

guild-level rule controls are unavailable for that detector.

This is intentional.

A Discord cannot force-enable a detector that AtomicBot has globally removed from the active catalog.

---

30. This Discord

The:

This Discord

setting controls whether a built-in rule is active for the current Discord.

Options include:

• INHERIT
• ENABLED
• DISABLED

---

INHERIT

Use the global AtomicBot catalog state.

This should normally be the default.

---

ENABLED

Explicitly enable the detector for this Discord.

---

DISABLED

Disable the detector for this Discord only.

Other Discord servers are unaffected.

---

31. Guild Action

The:

Guild Action

setting controls what the current Discord does when the rule matches.

Options:

• INHERIT
• ALLOW
• MONITOR
• DELETE
• WARN
• STRIKE
• TIMEOUT

---

32. Guild Severity

The:

Guild Severity

setting allows the current Discord to override the built-in severity.

Options:

• INHERIT
• LOW
• MEDIUM
• HIGH
• CRITICAL

Most servers should leave this as:

INHERIT

unless they have a specific reason to change it.

---

33. Built-In Rule Autosave

Built-in rule guild controls save automatically.

Changing:

• This Discord
• Guild Action
• Guild Severity
• Catalog Active

saves the setting immediately.

The row may display:

Saving...

followed by:

Saved ✓

---

34. ALLOW vs DISABLED

These settings are not identical.

---

ALLOW

AtomicGuard recognizes the detector but your Discord explicitly allows matching content.

Use this when the detector is still valid but your policy permits it.

Example:

This is profanity, but profanity is allowed here.

Use:

Guild Action → ALLOW

---

DISABLED

AtomicGuard does not use that detector for this Discord.

Use this when the detector itself is irrelevant or undesirable for your server.

In most moderation-policy situations:

ALLOW

is the better choice.

---

35. Editing Global Built-In Rules

AtomicBot owners can edit global catalog rules.

The global editor may include:

• Rule Key
• Pattern
• Match Type
• Category
• Default Action
• Severity
• Description
• Obfuscation Detection
• Catalog Active state

Editing an existing catalog rule can autosave changes.

Creating a brand-new built-in rule still requires the initial create action.

Changes here affect the global AtomicBot catalog and should be used carefully.

---

36. Custom Rules

Open:

AtomicGuard → Custom Rules

Custom rules belong only to the current Discord.

They do not affect other AtomicBot guilds.

Custom rules are ideal for:

• Server-specific scam phrases
• Server-specific advertising
• Community-specific banned phrases
• Known malicious domains
• Unique moderation requirements

---

37. Custom Rule Types

Custom rules support:

• WORD
• PHRASE
• DOMAIN

---

WORD

Matches a specific word.

---

PHRASE

Matches a phrase.

---

DOMAIN

Matches a domain.

Example:

example-bad-domain.com

---

38. Custom Rule Configuration

Custom rules can include:

• Pattern
• Match Type
• Category
• Action
• Severity
• Description
• Obfuscation Detection
• Enabled / Disabled state

---

39. Custom Rule Actions

Custom rules can use:

• MONITOR
• DELETE
• WARN
• STRIKE
• TIMEOUT

Custom ALLOW rules are intentionally not used.

Safe exceptions should be created through the Exceptions system instead.

---

40. Editing Custom Rules

Existing custom rules can be edited through the dashboard.

Existing rule changes may autosave depending on the control.

Creating a brand-new custom rule still requires the initial Create action.

---

41. Obfuscation Detection

Obfuscation Detection helps AtomicGuard catch basic attempts to bypass a filter.

Depending on the rule, AtomicGuard may recognize variations involving:

• Spaces
• Punctuation
• Character substitutions

Examples may include patterns similar to:

word

w0rd

w o r d

w.o.r.d

Use this carefully because broader matching can increase false positives.

Domain rules do not use obfuscation detection.

---

42. Exceptions Manager

Open:

AtomicGuard → Exceptions

The Exceptions Manager lets administrators manage safe exceptions without waiting for a violation review.

Exceptions are tied to a specific rule.

You can:

• View exceptions
• Search exceptions
• Create exceptions
• Edit exceptions
• Enable exceptions
• Disable exceptions
• Delete exceptions

---

43. Exception Types

AtomicGuard currently supports:

• PHRASE
• DOMAIN

---

44. Phrase Exceptions

A phrase exception allows a specific safe phrase that would otherwise match a rule.

Use the smallest safe phrase possible.

Do not exempt an entire large message when a short phrase is enough.

---

45. Domain Exceptions

A domain exception allows a specific safe domain for the selected rule.

This is useful when a broad domain-related detector incorrectly matches a legitimate site.

---

46. Exceptions From Violation Review

You can also create an exception directly from a violation.

Open the violation and use:

Create Rule Exception

This automatically associates the exception with the rule that generated the violation.

---

47. Violations

Open:

AtomicGuard → Violations

This page contains AtomicGuard's moderation history.

A violation may include:

• Violation reference
• Actor
• Discord user ID
• Channel
• Category
• Rule
• Rule source
• Severity
• Resolved action
• Strike count
• Moderation status
• Timestamp

---

48. Violation Search and Filters

The Violations page now supports filtering.

Filters may include:

• Search text
• Category
• Severity
• Action
• Moderation status
• Rule source
• Date range

This makes it easier to review large moderation histories.

---

49. Violation Pagination

Violations are paginated rather than being limited to only a single fixed recent list.

Use the page navigation controls to move through older violations.

---

50. Private Violation Evidence

Click a violation reference to open the full evidence record.

Authorized administrators can view:

• Original message
• Normalized message
• Matched rule
• Rule pattern snapshot
• Actor information
• Channel information
• Severity
• Action
• Strike count
• Review state
• Moderator history

The original message is private dashboard evidence.

AtomicGuard does not echo it into the public or moderator Discord report.

---

51. Original Message

The:

Original Message

section contains the stored message exactly as AtomicGuard captured it.

This information should be treated as private moderation evidence.

---

52. Normalized Content

AtomicGuard also stores the normalized form used during matching.

This can help moderators understand why a rule matched content that may have contained:

• unusual spacing
• punctuation
• substitutions
• formatting changes

---

53. Matched Rule Pattern

The evidence page shows the matched rule pattern when stored.

This is useful for understanding exactly which rule triggered the violation.

---

54. Moderator Review

Moderators can review each violation.

Available actions include:

• Uphold
• Dismiss
• Remove Strike when applicable
• Create Exception

---

55. Uphold

Use:

Uphold

when AtomicGuard made the correct decision.

This marks the violation as confirmed.

The review action is added to the moderation audit log.

---

56. Dismiss

Use:

Dismiss

when the violation was:

• Incorrect
• Acceptable
• A false positive
• Otherwise not enforceable

For applicable STRIKE or TIMEOUT violations, dismissing the violation can also remove the strike created by that violation.

---

57. Remove Strike

A moderator can manually remove a strike from a violation when that violation actually created a removable strike.

The button is available only for applicable user violations such as:

• STRIKE
• TIMEOUT

AtomicGuard prevents the same violation's strike from being removed more than once.

---

58. User Strikes Manager

Open:

AtomicGuard → User Strikes

The User Strikes Manager provides a central view of current AtomicGuard strike state.

Administrators can:

• Search by user
• Search by Discord ID
• View active strike count
• View lifetime violations
• View last violation time
• Adjust strike counts
• Reset active strikes to zero

Strike changes are recorded for moderator auditing.

---

59. Adjusting Strike Counts

Use the strike manager when you need to:

• Correct an incorrect strike total
• Forgive previous strikes
• Reset a user's escalation state
• Adjust a moderation decision manually

Avoid changing strike counts without a clear moderation reason.

---

60. Audit Log

Open:

AtomicGuard → Audit Log

The Audit Log records administrator and moderator actions performed through AtomicGuard.

Examples may include:

• Upholding violations
• Dismissing violations
• Removing strikes
• Creating exceptions
• Strike adjustments
• Other management actions

The audit log helps answer:

• Who changed something?
• What did they change?
• When did they change it?
• Which violation was involved?

---

61. Evidence Retention Days

Under Settings, configure:

Evidence Retention Days

This controls how long AtomicGuard keeps sensitive stored message evidence.

When evidence expires, the cleanup process can remove:

• Original message content
• Normalized message content
• Rule pattern snapshots
• Stored matched-rule evidence

while preserving the violation metadata and moderator history.

This allows you to keep useful moderation records without storing sensitive message evidence indefinitely.

---

62. Manual Evidence Cleanup

AtomicGuard provides:

Run Evidence Cleanup Now

This manually processes evidence that has passed the configured retention period.

Use this when:

• You changed the retention period
• You want cleanup immediately
• You are testing retention behavior
• You do not want to wait for the scheduled cleanup event

---

63. Automatic Evidence Cleanup

AtomicGuard can also use a MySQL scheduled event to clean expired evidence automatically.

The maintenance event should run periodically, such as once per day.

It uses each guild's configured:

evidence_retention_days

setting.

The cleanup keeps moderation metadata while removing expired sensitive evidence.

---

64. What Evidence Cleanup Does Not Delete

Evidence cleanup should preserve information needed for moderation history, such as:

• Violation reference
• Actor ID
• Channel ID
• Rule key
• Category
• Severity
• Action
• Review status
• Moderator audit log
• Timestamp

The goal is to scrub sensitive message contents, not erase the fact that the moderation event occurred.

---

65. Recommended Evidence Retention

A reasonable starting value is:

90 days

Different communities may choose shorter or longer retention depending on their moderation needs.

Avoid retaining sensitive evidence indefinitely unless there is a clear operational reason.

---

66. Cache Behavior

AtomicGuard's running Node handler may cache settings and rules for roughly 60 seconds.

This means a dashboard save may update MySQL immediately but the running bot may not use the new value until its cache refreshes.

Restarting AtomicBot forces the running process to reload its configuration immediately.

A future runtime cache-invalidation system can remove this delay.

---

67. Recommended Configuration for an Adult Rust Discord

A reasonable starting point may be:

| Category | Suggested Policy |
|---|---|
| Profanity | ALLOW |
| Harassment | MONITOR |
| Sexual Harassment | STRIKE |
| Hate / Slurs | STRIKE |
| Threats | MONITOR or STRIKE |
| Scam / Phishing | TIMEOUT |
| Advertising | MONITOR |
| Discord Invites | MONITOR |
| NSFW | MONITOR |

Then leave most individual built-in rules as:

This Discord → INHERIT

Guild Action → INHERIT

Guild Severity → INHERIT

Only override individual rules when your Discord needs special behavior.

---

68. Recommended First-Time Setup

Use this process when enabling AtomicGuard for a new Discord.

Step 1

Enable AtomicGuard.

Step 2

Set:

Operating Mode → OBSERVE

Step 3

Configure the Moderator Report Channel ID.

Step 4

Configure Review URL Base if direct dashboard review links are being used.

Step 5

Open Categories.

Configure your broad server policy.

Step 6

Leave most Built-In Rules on INHERIT.

Step 7

Review the Built-In Rule Catalog for rules you know are inappropriate for your community.

Use guild overrides rather than globally disabling rules unless the detector itself is bad.

Step 8

Create any Custom Rules your Discord needs.

Step 9

Allow AtomicGuard to run in OBSERVE mode.

Step 10

Review the Violations page.

Look for:

• False positives
• Rules that are too strict
• Rules that are too lenient
• Safe phrases needing exceptions
• Categories needing adjustment

Step 11

Create Exceptions where appropriate.

Step 12

Configure strike escalation.

Step 13

Configure evidence retention.

Step 14

Confirm automatic evidence cleanup is installed.

Step 15

Switch AtomicGuard to:

ENFORCE

when you are satisfied with the behavior.

---

69. Quick Decision Guide

Use this when deciding where to make a change.

---

We want to allow an entire type of content

Change the:

Category Policy

Example:

PROFANITY → ALLOW

---

We want to allow one particular built-in word or phrase

Open:

Built-In Rules

Set:

Guild Action → ALLOW

---

One detector is irrelevant to our Discord

Open:

Built-In Rules

Set:

This Discord → DISABLED

---

A detector is globally bad and should not run anywhere

AtomicBot owner sets:

Catalog Active → OFF

---

We need to detect something unique to our Discord

Create a:

Custom Rule

---

A safe phrase is being caught by a rule

Create a:

Rule Exception

---

A user's strike count is incorrect

Use:

User Strikes Manager

---

A violation was wrong

Open the violation and:

Dismiss

---

A violation was correct

Open the violation and:

Uphold

---

We need to find old moderation activity

Use:

Violation Filters

or:

Audit Log

---

We need expired evidence removed immediately

Use:

Run Evidence Cleanup Now

---

70. AtomicGuard Policy Hierarchy

The most important rule to remember is:

Individual Rule Override
↓
Guild Category Policy
↓
Built-In Rule Default
↓
Category Default

The first non-INHERIT value wins.

This allows AtomicGuard to remain manageable even with a large built-in catalog.

---

71. Recommended Administration Philosophy

Do not manually override every built-in rule.

Use:

Categories

for broad moderation policy.

Use:

Built-In Rule Overrides

only for exceptions.

Use:

Custom Rules

for Discord-specific moderation.

Use:

Exceptions

for safe uses of otherwise restricted content.

Use:

Violations

to review AtomicGuard's decisions.

Use:

User Strikes

to manage repeat-offender state.

Use:

Audit Log

to track administrator changes.

This keeps AtomicGuard powerful without making the configuration impossible to maintain.

---

72. AtomicGuard vs AtomicShield vs HoneyPot

AtomicBot's security systems handle different problems.

AtomicGuard

Content moderation.

Examples:

• Profanity
• Harassment
• Scam phrases
• Threats
• Domains
• Custom words

AtomicShield

Behavioral security.

Examples:

• Message flooding
• Spam bursts
• Raid-style activity
• Multi-channel spam
• Bot/webhook abuse patterns

HoneyPot

Trap-channel enforcement.

A user posting where they should not post can trigger the HoneyPot response.

These systems are designed to complement each other rather than replace each other.

---

Final Recommendation

For most Discord communities:

• Start AtomicGuard in OBSERVE.
• Configure Categories first.
• Keep most individual rules on INHERIT.
• Review real violations.
• Add exceptions only where needed.
• Use conservative strike escalation.
• Configure evidence retention.
• Switch to ENFORCE only after reviewing the results.

AtomicGuard is designed so a Discord can have its own moderation policy without changing AtomicBot's global rule catalog for everyone else.