Rollout Planning

A good anticheat rollout is boring: nothing bans anyone until staff have watched real traffic and agreed the policy is right. This guide is the sequence we recommend for every community, from a 30-slot roleplay server to a multi-server network.

§6.1The four stages

§6.1.11 · Inventory sensitive actions

Before any tooling, list what actually needs protecting. Get the people who built your resources in a room (or a Discord thread) and write down:

• Money events — anything that credits cash, bank balance, or items of value. Include admin/give commands.
• Inventory events — item grants, transfers, crafting outputs, shop purchases.
• Permission-sensitive actions — job changes, whitelist changes, staff commands, vehicle spawning for privileged roles.
• World actions — entity spawns, deletions, explosion triggers, door states, property access.

For each, note which resource owns it and who should legitimately be able to call it. This list is your future policy — the Event Policy Worksheet turns it into rules.

§6.1.22 · Start in observation

Once the resource is installed, observe first. The catalogue ships armed, so turn on observation mode before real players join: set sculk_observe "true" in server.cfg (the shipped server.cfg.example already has it). Every detection runs, strikes count and events and webhooks fire, but automatic kicks and bans — from detections, the handshake policy and your own advanced triggers — are held and reported as OBSERVE would kick / would ban in the console and as review events on the anticheat dashboard. Warnings still happen, and staff actions from the dashboard, in-game panel or REST API are never held. The console reminds you every 30 minutes how many kicks and bans it has held. Give it one to two weeks of real traffic. The goal is to find where your inventory was wrong — the resource nobody remembered, the event that fires oddly during restarts, the legitimate admin tool that looks like abuse.

§6.1.33 · Set containment rules

Only after observation, decide per detection what happens when it fires, then run set sculk_observe false in the live console — it takes effect at once, no restart — and remove the line from server.cfg:

• Ban or Kick — the player is removed. Reserve Ban for detections staff validated during observation as unambiguous.
• Warn — the player stays, the detection is logged and posted, staff review it.
• Log — recorded only, for anything still under review or any detection you want silenced permanently on your server. Separately, Sculk Mind holds a ban on a pattern it has not seen before for staff review rather than issuing it.

§6.1.44 · Review and refine

Policy is never done. Set a monthly habit: read the incident timelines, check what staff overturned, tighten what proved reliable, loosen what generated noise. Evidence beats instinct.

§6.2Timeline expectations

Budget roughly: one staff meeting for the inventory, an hour to draft policy, two weeks of observation, then enforcement. Communities that skip straight to enforcement spend the same time anyway — arguing with players about wrong bans instead.

§6.3Where support fits

Licence holders can open a rollout ticket any time, FiveM support with the "Rollout question" topic. Bring your inventory list; policy review against it is exactly what that channel is for.