Glossary

Created when a member clicks a button on a support panel (or opens modmail). Lives as a dedicated channel or thread that staff can claim, comment in, and close. Tickets are about the conversation, not the moderation action.

Not the same as a case. A ticket can lead to a strike or ban; the strike itself is the case.

Each enforcement action creates a case row with its actor, target, reason, severity, and timestamp. Cases compose into a player's history and feed the composite risk score.

A ticket is the support-inbox conversation; a case is the enforcement record. They can be related (a ticket that ended in a strike will link to the case) but they aren't the same row.

Routed through a dedicated appeal flow that staff review separately from regular support tickets. Appeals carry the original case reference, the member's argument, and staff's decision (approved, denied, deferred). Denied appeals carry a cooldown before the member can appeal again (default 180 days).

Configurable per-guild. A rule is a trigger (e.g. word filter, regex filter, caps spam, invite link) paired with an action (delete, warn, mute, strike, ban, notify). Free tier supports the delete action; Pro unlocks warn / mute / strike / ban so AutoMod can drive real enforcement instead of just flagging.

See AutoMod Rules.

Umbrella term spanning AutoMod (message-content rules) and the rule-enforcement engine (policy presets for compound conditions like "3 warnings in 24h → auto-strike"). When the docs say "rules", context tells you which subsystem — AutoMod owns per-message triggers; rule enforcement owns aggregated-state triggers.

Verified link between a Discord user and a game-platform identity. Two paths: OAuth (member clicks a verify button, Discord redirects through Steam / Xbox / Alderon login) or in-game (member types a one-time code into game chat which the SFTP log monitor picks up).

Once linked, strikes / bans / warnings can target the member by Discord ID or in-game ID and the audit log shows both. See Linking IDs.

Industry-standard protocol most game servers expose for live control: kicking players, broadcasting messages, restarting the world. Arkanis Pro speaks RCON to your server, so staff can run game-side commands from Discord and the dashboard without SSH'ing into the box. Pro feature.

Open-source dashboard for hosting game servers (used by communities like NodeCraft, Pebble Host, many self-hosters). Arkanis Pro connects to your Pterodactyl panel via its API to read server state, send commands, and stream logs. Pelican (the Pterodactyl fork) works with the same integration. Pro feature.

For game servers that don't expose RCON or events natively, Arkanis can SFTP into the host and tail the chat / kill / admin logs. Lines get parsed into events (player joined, chat message, admin action) that feed AutoMod, identity-linking, and the audit log. Pro feature.

Open protocol that lets AI clients (Claude Desktop, Claude Code, Cursor, Zed, Continue, Cline, Windsurf, Cody, Goose, etc.) call structured tools on a local server. Arkanis ships@arkanis/mcp-serveras an npm package; the binary arkanis-mcp serveruns locally and exposes the same capabilities your dashboard does, to any MCP-compatible client.

MCP is the protocol. Claude Control is what you get when you point Claude Desktop or Claude Code at arkanis-mcp serve: conversational access to your guild's state and actions, with the same capability gates and re-auth windows as the dashboard. Pro Labs.

Unlocks game-server integration (RCON, Pterodactyl / Pelican, SFTP logs), identity tracking across Steam / Xbox / Alderon, AutoMod actions beyond delete (warn / mute / strike / ban), public REST API access, and Claude Control. See /pricing.

Included in Pro at no extra cost. The "Labs" label means we may evolve the surface based on real-world feedback before treating it as fully stable. Today: Arkanis CLI and Claude Control / MCP. Treat these as production-usable but expect the next major version to refine ergonomics.

Arkanis doesn't check "is this user an admin" — it checks "does this user's role grant theenforcement_strikescapability?". Each capability covers one verb (issue a strike, view billing, rotate an RCON credential, open a re-auth window). Server owners assign capabilities to roles in the Roles & Permissions panel, not to commands.

On the dashboard, an admin can switch the UI into "view as <role>" mode. Buttons stay rendered but disable to match what that role's capabilities actually allow. Lets you audit a role before trusting a person with it. See View Dashboard as Role.