Strike System

The Strike System allows staff to give members points when they break a rule, and lets you configure a ladder of automatic actions that fire as those points build up. It’s ideal for servers that want a consistent punishment system, with automatic reactions. Point accumulation will automatically escalate to more severe actions.

Every strike is worth a number of points. Points accumulate on a member and count toward a ladder of rungs, each with its own point score and its own actions to be fired. When a member’s points cross upward into a rung, that rung’s actions run.

How points work

By default a strike is worth your server’s base points (10 by default), but the exact amount can come from three places:

• an explicit point value (mutually exclusive ↓),
• a severity (mutually exclusive ↑),
• or the preset reason the strike used.

Whichever applies, the number is fixed at the moment the strike is issued.

Each strike also has its own lifetime

Every strike has a window (30 days by default), and your pool decides how a strike loses its weight as that window runs out. There are three ways:

• Counts in full, then expires: a strike is worth its full value right up until its window runs out, then stops counting all at once. Simple and predictable.
• Fades gradually: a strike loses weight little by little across its lifetime instead of dropping off in one step. See Decay curves below.
• Never expires: nothing in the pool stops counting on its own. A strike only stops counting when somebody pardons it.

Individual strike sources can also be marked as permanent strikers, so their strikes never expire regardless of what the pool says.

Either way, an expired or pardoned strike still exists on the member’s record, for historical records. It just stops contributing to their point total.

Decay curves

Under Fades gradually, you also choose the shape of the fade—how much of a strike’s value is gone by any point in its lifetime.

A straight line sheds value evenly. Curving it means a strike can hold most of its weight for the first stretch and then fall away quickly near the end (so recent behavior keeps counting), or drop off sharply at first and then linger (so a member gets most of the benefit early).

You edit this using an interactive curve editor, found in the Pools page of the dashboard. The editor only appears when the pool is set to fade gradually.

Strike pools

A pool is a whole strike system of its own: its own sources, its own action ladder, and its own running score on each member. Every server starts with one, named Default, and can run several.

The point of a second pool is that the scores do not add up. Spam and harassment are different problems that deserve different ladders, and on one shared score a member three strikes into a spam ladder is inching toward a ban meant for something else entirely.

Plan	Pools
Free	2
Plus	5
Pro	10

The default pool

One pool is your default, marked as such on the Pools page. It is simply the oldest one.

It matters in two places:

• A manual strike with no reason lands here. /strike without a preset reason and without the pool option uses this pool’s manual source, so its points and lifetime are the ones that apply. Pick a preset reason and the reason’s own pool wins instead.
• It is the fallback if routing has nowhere to go. A source whose pool was deleted underneath it would otherwise have no destination, so its points land here rather than being dropped.

Otherwise it is an ordinary pool. You can rename it, give it whatever ladder you like, and delete it as long as it is not your last one. “Default” is not a special pool name.

Changing default pool

The default cannot be changed directly, but you can change it indirectly; if you have 2 or more pools, you can delete the default pool. On deletion, the second-oldest pool becomes the new default.

Usually it is not worth it, because you must re-configure the pools when you add new secondary ones.

Which pool a strike lands in

The source decides. Every preset reason, every built-in source and every automatic source belongs to a pool, set on the Sources page, and a strike issued through it counts toward that pool. Staff pick what happened, then the strike flows into the correct pool.

For the times the same offence belongs somewhere else just this once, /strike has an optional pool option, and the right-click form grows a pool picker on servers running more than one. Both default to leaving it where the reason says.

An Discord and Archivian Auto-Mod rules can be pointed at several pools at once, in which case tripping it executes them separately. See One rule, several pools.

Note

When you create a new pool, it autoamtically sets up manual strike sources:

• the /strike command,
• the right-click message interaction, and
• the right-click user interaction

You can configure them, but you cannot delete them. They get deleted when you delete the associated pool.

Creating and deleting pools

When you create a new pool, we populate the manual strike sources automatically (mentioned in the callout above). Nothing else is created along with a new pool.

From then on, you can start building out new strike rungs that fire off their own actions, set up new preset reasons that can be entirely different from the other pools, and basically treat it as a completely separate strike system.

Some global settings are still shared among all pools though; those are found in the Settings section of the Strike System category.

Deleting a pool removes its ladder, its sources (including the manual ones), and every member’s standing in it. It does not take the strikes: those stay on each member’s record as history—they just don’t count anymore, nor can they trigger anything.

There must always be at least 1 pool in the server.

Notifications

Everything the ladder does needs a rung to be crossed, which leaves a member’s first strike doing nothing anyone can see. These two settings are the exception: they run on every strike, rung or no rung. Both live under Settings → Notifications.

Telling the member

On by default. The member gets a DM saying what the strike cost them, what they’re now on, the reason it was recorded with, and when it stops counting.

Name the moderator who issued it is a separate checkbox, off by default. Turning it on adds the moderator to the DM, so the member can take it up with the person who made the call—which is usually what you want in a small server and usually not what you want in a large one. Strikes issued automatically are never attributed to anybody.

Plenty of people have DMs from servers switched off, and there’s nothing either of us can do about that: the strike still counts, and whoever issued it is told in their reply that the message didn’t get through, so they can follow it up in a channel if it matters.

This is separate from a rung’s own Send a message action, and a strike that sets off a rung which DMs will send both. They say different things: this one is the member’s record, the rung’s is what just happened to them. If you’d rather they only got the rung’s message, switch this off.

Telling your staff

Off by default. Turn it on to post one message per strike in a staff channel: who was struck, by whom, what for, which pool it landed in, and which rungs (if any) it set off. It’s the running log of the moderation being done, which is a different thing from the Staff alert rung action—that one is a rung asking a human to come and look. A server that configures both gets both.

Leave the channel empty to use your server’s default alert channel. With neither set there’s nowhere to post and no alert is sent; the settings page says so, and so does the reply of whoever issues the next strike.

The action ladder

A rung (a points threshold) is a point score plus a set of actions. A rung fires when a member’s points cross into it on the way up.

If a member is already sitting at 45 points and picks up a strike that brings them to 50, nothing fires unless 50 crosses a rung’s score for the first time since it last fired.

Each rung can run any combination of five kinds of action:

• Add roles — give the member one or more roles. Useful if you have your own quarantine roles.
• Remove roles — take away one or more roles, or every role the member has.
• Create a case — open a note, warning, timeout, kick, or ban on the member. Executes the case as it normally would when using Archivian.
• Send a message — a DM to the member, a message in a named channel, or both, using an embed you write with variables like the member’s ID, the reason, and their new point total.
• Staff alert — post to a channel (or your server’s default alert channel) with an optional note and pings, so a human reviews what happened instead of, or alongside, an automatic action.

A rung can also be turned off without deleting it.

Execute on Crossing vs. Execute Highest

Individual rungs can be flagged to always run even when a member’s points jump straight past it into a higher rung (see the worked example below for why that matters).

Hysteresis: re-arming and cooldowns

Hysteresis is an important aspect worth familiarizing yourself with.

• Once a rung fires, it doesn’t fire again just because the member is still above its score; it has to re-arm first.
• Each rung has its own re-arm score, which must be lower than the rung’s own score.
• After firing, the member has to drop back below the re-arm score (by a pardon, by strikes expiring, or by the pool’s decay settings) and climb back up past the rung’s score again before it can fire a second time.

This latching behavior is important due to point decays.

Without this, a member sitting right at a rung’s threshold could trigger it on every single strike, repeatedly firing for barely moving past the line and dipping right back below it as points decay, rather than for a real escalation.

A rung can also have a cooldown: a minimum amount of time that must pass before it’s allowed to fire again, on top of re-arming. This guards against a burst of strikes landing in quick succession from re-triggering the same consequence over and over in a short window.

An example

Here’s the five-rung ladder every server starts with when the Strike System is first turned on, shown with its score, its re-arm score, and its cooldown:

Rung	Score	Re-arms below	Cooldown	Actions
Notice	20	10	1 minute	DM the member
Timeout (1 hour)	40	30	5 minutes	DM the member, timeout for 1 hour
Timeout (24 hours)	60	50	10 minutes	DM the member, timeout for 24 hours
Kick	80	70	30 minutes	DM the member, kick
Ban	100	90	1 hour	DM the member, ban

Walking through a scenario:

1. A member has 0 points. They get a 15-point strike. Nothing fires — 15 is below Notice’s score of 20.
2. A week later they get a 10-point strike, bringing them to 25. This crosses Notice’s score of 20, so Notice fires: they’re DMed. Notice is now disarmed. It won’t fire again until the member drops back below 10 points (the re-arm threshold).
3. Staff pardon the first, 15-point strike. The member’s total drops to 10; still not below the re-arm score, so Notice stays disarmed.
4. Later, more strikes expire and the member’s total falls to 5 points; below Notice’s re-arm score of 10. Notice re-arms.
5. The member gets another strike that brings them back up to 22, crossing Notice’s score again. Notice fires a second time (assuming its 1-minute cooldown has already passed).
6. Instead, suppose the member had jumped from 15 straight to 45 points in one strike — crossing both Notice’s score (20) and Timeout (1 hour)’s score (40) in a single leap. By default, only the highest rung actually reached fires — Timeout (1 hour) — and Notice’s DM does not also fire for that strike. If you want Notice’s actions to run even when a member’s points jump straight past it, enable “Always run” on the Notice rung.

Reaching the end of the ladder

Your last rung cannot escalate any further, which leaves a question nothing else answers: the member is now parked above the top of the ladder, so what does their next offence mean?

If left alone; nothing. They keep accumulating points that can never fire anything again, and the ladder is effectively over for them. Depending on your setup, especially if it ends with a ban, this might be acceptable. But even with bans, since they can be appealed, it could be the wrong outcome

Therefore, you can tell Archivian what the top rung will mean. On the Settings page, under The end of the ladder, switch it on and pick an option:

Option	What it does
Wipe their score	They start again from nothing and have to climb the whole ladder to get back here.
Take a percentage off	They keep the rest, so the next round escalates faster than the first.
Leave them on a percentage	The mirror of the above, but this is what they keep, not what they lose.
Take a fixed number of points off	Useful when your rungs are evenly spaced and you want them dropped by exactly one.
Set their score to a fixed number	Wherever they were, they come out here.
Drop them to the middle of your ladder	Halfway between your lowest and highest rung, and it follows the ladder when you tweak it.
Drop them to the middle of your strike values	Halfway between the least and the most points any of your sources hands out.

The dashboard works the answer out against your own top rung as you configure it, “a member who reaches your last rung on 100 points comes out on 25”, so you don’t have to work out the math yourself.

Strikes that were absorbed because of a reset/subtraction are not deleted. Their records stay on the member, they simply stop counting, and you can still find them with /strikes browse status:Absorbed.

Appending permanent points

Alongside the reset, you can add a number of permanent points: points that never decay and survives top-of-ladder resets. Someone who tops out twice starts the second climb further along than they started the first.

Because a member’s points can hover near the boundary of two thresholds, rapidly retriggering, this has its own cooldown. This is the period where it must wait a given time before another permanent strike can be issued.

Set the points to 0 to skip issuing permanent points entirely.

Note

A reset never touches permanent points. Whatever a member has that never expires stays with them through a reset. It’s a behavior to avoid quietly forgiving the strikes you specifically marked as unforgettable.

Strike Sources: Where strikes come from

Strikes arrive two ways: a moderator issues one, or something automatic causes it.

• Manually, that is the /strike command, right-clicking a member, and right-clicking a message.
• Automatically, it is a Discord- or Archivian Auto-Mod rule that you have set up as a source for a specific ladder.

Each of these is a source, and every source can set its own points, lifetime and pool that override your server’s base settings.

Preset reasons

Staff can define up to 20 preset reasons, each has:

• a display name
• a pre-filled reason for the strike
• optional overrides for points,
• optional lifetime and permanence.

Preset reasons are offered by the /strike command and by both right-click context menus, so a moderator picks one from a list instead of typing a reason out each time.

This allows you to create a rigid, unopinionated (by the individual staff), and predictable system. For example, if five different moderators each type their own wording and their own idea of how many points “spamming in general chat” is worth. A preset reason fixes the wording and the points once, so every strike issued for the same behavior counts the same.

Staff can still write their own reason for anything that doesn’t fit a preset, or if presets are overkill for your community.

Severity levels

Independently of preset reasons, a server has a set of severity levels. This is an alternative to deciding on how many points to give.

These severities exist to give you the ability to pick a relative point amount. That comes in handy whenever you want to give points manually, but you have no idea what is considered little or a lot of points, since it depends on the server’s action ladder setup.

Where the levels come from

You choose this on the Settings page, under Points. There are three options:

---

A. Follow the action ladder (default)

Each level is an even share of your highest rung, and they keep pace automatically whenever you retune the ladder:

• Low — 25% of highest rung
• Medium — 50% of highest rung
• High — 75% of highest rung
• Extreme — 100% of highest rung

So if the highest rung in the server requires 100 strike-points to activate, using a Low severity will grant 25 points.

---

B. Follow the strike sources

The same even sharesas A, but measured against the most any one of your strike sources hands out, rather than against the ladder.

---

C. Set them myself

Exact point values you choose, up to 10 of them, each with its own name. They stay where you put them. Beware, as this means they can be “out of sync” if you later tweak your ladder thresholds.

---

Whichever you pick, the dashboard shows you the resulting numbers as you configure it, so you always see what staff will actually be offered.

Tip

The derived options exist because a fixed list stops meaning anything the moment you retune the ladder it was written against. “High” at 50 points is severe on a ladder topping out at 60, and trivial on one topping out at 500.

Example

You want to give a pretty solid amount of points in a strike. You need to pick an amount. But what is an appropriate amount?

For example, if your first rung requires 60 points, 50 points is not a lot. If the most extreme rung is 30 points, then 25 points is way too much.

The severities exist to make this easy. You don’t need to know if 25 points is a lot or little to give. You simply pick “Medium” and it should do the trick.

Automatic sources

You can make Discord Auto-Mod rules and Archivian Auto-Mod rules automatically issue strikes. Both are added from the Sources page and configured exactly like a preset reason: points, lifetime, permanence and which pool they feed.

Nothing is automatic by default. You pick the individual rules and checks that should cause strikes, one at a time.

For example, you likely want an Auto-Mod rule for slurs to automatically issue a strike, but maybe not for soft rules like “No links in #general”.

Discord Auto-Mod rules

When you click Add rule it lists every Auto-Mod rule in your server, each showing what kind of rule it is and what Discord already does when it trips (e.g. block message). Using this information you’ll be able to distinguish between types of Auto-Mod rules if you don’t hve unique names.

Tripping a rule issues a strike, no matter which action(s) your Discord rule takes, even if it’s just a staff alert. If you don’t want a monitoring-only rule to cause strikes, simply don’t add it as a source.

Renaming a rule in Discord doesn’t have any effect. Deleting a rule in Discord leaves its source in place, and marks it with “Rule deleted” rather than quietly discarding the points and lifetime you configured. This gives you the opportunity to copy the setup to another rule before deleting it.

Turning off a Discord Auto-Mod rule means it will also no longer issue strikes.

Note

To list your server’s Discord Auto-Mod rules, Archivian needs the Manage Server permission. Without it the page says so and keeps showing the rules you already added, which will continue to work.

Archivian Auto-Mod rules

When you click Add check it offers the checkers that can point to a single member. That means auto-mod rules like Channel Spam cannot be used as a source.

A single message can trigger multiple auto-mod checks, for example, a user sending a server invite in multiple channels can trigger both Server Invite and Cross-Posting auto-mod. If you have both set up as strike points, bot may trigger a strike each.

Turning off an Archivian Auto-Mod rule means it will also no longer issue strikes.

Editing a message that still breaks the rule

Both Discord and Archivian’s Auto-Mod looks at an edited message as if it is a new message, so by default, a member who edits a message and trips the same rule(s) again gets striked again.

There is, however, an option to change this behaviour; Charge a message at most once.

With Charge a message at most once, found under Automated sources in Strike Settings. It will only strike the same message at most once, which can be triggered when the message is first sent, or by a later edit.

To re-iterate, a user can first send a message that does not match any Auto-Mod rule, but then they edit the message into content that does, it will then strike the member. Then, further edits that would also trigger Auto-Mod once again, are ignore instead of re-issuing a strike.

Note

Note that this deduplication of strikes per message is scoped per pool. For example, with Charge a message at most once enabled:

1. A user can do something that trigger a strike in pool A but not pool B.
2. Then they edit it in a way that will trigger strike in pool A and B—but A had already issued a strike previously;
3. Pool A skips, but this is pool B’s first time, so pool B issue a strike.

Either way, two different checks catching one message always strikes separately, and a rule feeding two pools strikes in both.

Rules that block the message

Charge a message at most once has no effect on Auto-Mod rules that block the message.

Discord only give us a message ID if message isn’t blocked. When a rule blocks a message, there is no message check against. So every violation causes a new strike no matter how this setting is set. Most keyword rules block by default, so check the rule’s actions in Discord if you expect the setting to apply. Rules that only alert or time out keep the message, and those dedupe normally.

The same goes for rules that judge a member’s profile rather than something they posted. There is no message involved, so each violation is charged separately.

One rule, several pools

An Auto-Mod rule can feed more than one pool.

You can simply select a different pool in the dropdown when you add a new strike source, and the Auto-Mod rule option becomes available. The dashboard will let you know if a rule is already in another pool.

Setting it up for multiple pools will cause a strike in each pool on violation.

Biases & Multipliers

Sometimes the same offence should not cost everybody the same. A two-day-old account that joined this morning is a different proposition from a member of three years, and most servers already treat them differently by hand.

All of this is switched off out of the box. Every multiplier starts at 1×, and nothing changes until you go and turn something on. You’ll find it on the Settings page.

There are three multipliers, and they multiply together:

• Harsher for newer accounts: strikes on accounts registered with Discord recently get more points than usual. Measured from when the account was created.
• Harsher for newer members: strikes on members who joined your server recently get more points than usual. Someone who leaves and rejoins starts over, because that is what Discord records.
• Roles that change what a strike costs: give a role a weight, and strikes on the people who hold it count for more or less than normal. 0.5 is “half price”, 0 means the strike is recorded but “costs them nothing”, and above 1 makes it will give more points than usual by that multiplier amount.

Multiplying together means exactly what it sounds like. A 10-point strike on a brand-new account that joined today, from someone with no weighted role:

10 × 3 × 2 = 60 points
│    │   │
│    │   └ new member
│    └──── new account
└───────── base points

The two age settings use the same kind of curve as decay: you set how much harsher it is at its harshest, how long before the effect wears off completely, and you can drag the shape in between.

Tip

Set the age curves’ multiplier to 1× to make them inert.

Caution

Because the factors multiply, they compound faster than they look. Two innocuous-seeming 3× settings make a 9×. This could be the difference a first offense being a warning and a first offense being a permanent ban.

This is where the Limits on the finished multiplier comes in. It’s a floor and a ceiling applied after everything above has been multiplied together:

10 × 3 × 3  →  9× the base   →  90 points    without a ceiling
10 × 3 × 3  →  capped at 5×  →  50 points    with a 5× ceiling

The dashboard shows you the band a strike can actually land in, in points, so you can see what the settings add up to before anybody is struck by them.

If a member holds more than one weighted role, only one is used; all of them do not get multiplied together. The highest of those roles in your server’s role list is picked.

Whenever a strike’s points end up different from “what’s expected”, /strikes inspect shows the breakdown of which factors were applied, what it multiplied by, and how many points it moved.

Issuing, browsing, and pardoning strikes

/strike

Documentation: /strike

Give a member a strike. You must supply either a preset (autocompleted from your server’s preset reasons) or your own reason—one of the two is required. You can optionally set a severity (autocompleted from your server’s severity presets) or an exact points value instead; these two are mutually exclusive.

/strikes

This parent command houses some of the other less used commands for strikes. Documentation: /strikes

/strikes browse

Lets you browse, search, and filter strikes. You can use any combination of these, all together, or none of them, to help you narrow things down easily.

• on lets you find strikes on a user
• by lets you find strikes a staff member has issued
• pool lets you narrow to one strike pool
• status lets you filter by strike status
  • Still counting is the default. Strike is active, valid, and is being counted.
  • Lapsed (expired) were valid but expired naturally
  • Pardoned shows only pardoned strikes
  • Absorbed shows strikes that stopped counting because the member reached the end of the ladder and their score was reset
  • Any finds any of them
• page lets you browse a specific page

When using the on filter, the top of the search result will show their standing in every pool they have points in.

It will, based on your filters, show when it was issued, how it was issued, when it expires, count of points, reason, by whom, and on whom. It may also show the status of the strike if it is pardoned or lapsed.

/strikes inspect

Lets you inspect a specific strike. The auto-complete will suggest strikes to look up.

/strikes pardon

This essentially invalidates a strike.

The strike record is kept around, it just stops counting.

/strikes unpardon

Reverses a pardon, putting the strike’s points back into the member’s total.

This needs its own permission, separate from pardoning: deciding a strike was wrong and deciding it was right after all are different calls, and a server may well want different people making them.

The strike list presented in this command shows only pardoned strikes.

Note

If the strike expired while it was pardoned, un-pardoning it changes nothing: the record starts counting again, but its lifetime already ran out, so it is worth nothing. Archivian says so explicitly rather than reporting a points change that did not happen.

Un-pardoning also cannot bring back a strike that was absorbed by a ladder reset—otherwise a reset could be undone one strike at a time.

Context menus and the in-chat form

You can also strike a member by right-clicking on their profile, or strike a user based on their message.

1. Pick your strike method
   • Strike member when right-clicking on a member
   • Strike for message when right-clicking on a message
2. Pick one a reason for the strike
   • one of the server’s pre-made reasons, or
   • “Write my own reason…” for a custom one or if no presets are set up
3. Decide on the points to give
   • leave as-is for the preset reasons’s pre-configured points, or
   • use the severity selector if you want to override it or use custom reason
4. Click the Strike button to strike
   • if using a custom reason, it will open a modal asking for the reason, then issue the strike.

You can also click the Cancel button to abort.

Exemptions

Some members should never earn a strike, no matter what triggered it. The Strike System exempts:

• Yourself when using /strike — it will always reject this.
• Bots / Apps — strikes are meant for users. It will also reject manual /strikes.
• Staff — your registered staff never earn strike points, as one switch that stays accurate as staff come and go.
• Configurable Members — specific users, listed individually.
• Configurable Roles — anyone holding one of the listed roles.
• Configurable Channels — a strike originating from a listed channel is skipped; exempting a category covers every channel inside it.

Never assign/revoke roles

Rungs can add and remove roles as part of their actions, which means a rung can hand out or take away power. A rung that says “remove all roles” would happily strip a moderator’s role, and a rung that adds roles could be pointed at one carrying Administrator.

The role pickers don’t let you select a role with moderation power in the first place, but permissions change over time and roles get re-purposed. So there are two guards that run at the moment a rung fires, on adds and removes alike—including “remove all roles”:

Never touch registered roles

The roles you registered under Server Role Management: your core staff hierarchy, your shared staff role, and any specialist role you marked as counting as staff. This catches the role that is powerful only by convention—that is, a role with no permissions of its own, for example used for channel access and pings, which is something the permission check cannot see.

Never touch roles with these permissions

Any role carrying one of the permissions you tick. A permission list rather than a role list, because roles come and go while the permissions that make a role dangerous do not, so it keeps working through a rename or a rebuild.

The permission list is fully editable, grouped into Server control, Over members and Over content, and starts on a recommended set covering everything that can be used to hurt the server. There’s a one-click way back to that recommended set if you’ve drifted from it.

Both guards fail safe: a role Archivian cannot resolve is skipped rather than acted on.

Caution

Your quarantine role is deliberately not covered by the staff guard, it can never be registered as a staff role, so “add the quarantine role” keeps working as a rung action with the guard on.

Minimum Reason Lengths

You can configure the minimum length required for strikes and pardons. The max is always at 128 characters for both.

The dashboard

Configure the Strike System from your server dashboard, under Strike System:

• Settings: the master on/off switch, then, in order: your base points and default strike lifetime, your severity levels, the biases and multipliers, what happens at the end of the ladder, the exemptions above, the role guards, how automated sources treat a re-offence on same message, and the minimum reason lengths.
• Pools: create, rename and delete your strike pools, see how strikes in them lose weight over time, and the decay curve when you’ve picked a gradual fade.
• Actions: the ladder itself. Add, edit, reorder by score, and delete rungs, and configure each one’s actions.
• Sources: your preset reasons, the Discord/Archivian Auto-Mod rules that issues strikes, and the built-in fallbacks used when a strike is issued without a reason.

Turning off the strike system will make the system stop accepting new strikes in all pools.