Static-config anticheats reach a ceiling within the first month. Operators get tired of clearing the same false positive on the same Lua menu, raise the threshold once to make the noise stop, and quietly lose detection on a real cheat surface that used to be loud. Raven Mind is the layer that closes that loop without an admin sitting at the panel.
Raven Mind is not a rebrand of a rule engine. It is the live flow that sits on top of every Raven ban, scores the shape of what was detected, takes the cheap action immediately, and pushes the expensive action to Discord as a single-click card. The longer the network runs, the more decisions it has already made, and the less of the queue ever reaches an operator.
What it actually does on every ban
When a Raven detection fires, the resource sends the ban payload straight through the live flow before it is finalised on the server. The flow asks three questions in order:
- Is this signal one the network has already ruled on? If a prior decision exists for the exact identifier (a resource name, an event hash, a model spawn), Raven Mind replays that decision in the same tick. If the prior decision was "allow," the player is unbanned before the kick screen finishes rendering. If it was "block," the ban stays and gets a one-line audit note.
- Does the shape look like a real cheat surface? A short classifier reads the event name, the resource, the payload size, and the call frequency. Names that look like cheat hooks (
setMoney,giveItem,runCode) get pinned as cheat-shape, which hides every whitelist option from the operator card. Operators cannot accidentally whitelist a real attack just by clicking through Discord notifications. - Is the action reversible cheaply? A false positive on a legitimate event gets auto-unbanned on the spot and the proposal card waits in Discord for review. A signature hit with replay evidence gets confirmed and logged. The reviewer only sees the cases the system was not confident enough to close itself.
The strategies a card can apply
When a card needs operator review, the strategy menu is bounded. Raven Mind does not invent new ways to mutate your config, it picks from a fixed set of operations the applier already knows how to apply safely:
- Whitelist a resource, event, model, weapon, texture, particle, or explosion. Appends the specific identifier to the correct config array. The applier knows which array each protection uses, so the operator never has to.
- Remove a model from a blacklist. The inverse of the above, used when a baseline entry catches a vehicle a server legitimately ships.
- Tune the threshold or the timeframe. Used when the protection is correct in principle but the numbers are too tight for this server's player base.
- Switch the action to kick. For protections where a ban is too aggressive but doing nothing is too permissive.
- Suppress this signature for 30 days. A soft snooze for a noisy detection while the operator collects evidence to decide on a permanent rule.
- Disable the type or the option. The escape hatch when a protection is genuinely wrong for this server. The card warns when this is the heavy-handed choice.
How a single approval propagates
The part that matters more than any single decision is the network share. When an operator on one Raven server approves a strategy on a card, the decision is hashed by the signal it ruled on, not by the server it came from. The next time any Raven server in the network produces the same signal, the live flow replays the decision in the same tick and never opens a card.
The practical effect: most operators never see a card for the noisy detections that fired across the network last week. By the time their server boots, those signals already have a decision, applied automatically, with the original approver credited in the audit log. Servers that join the network late inherit a year of operator review for free.
What ships pre-trained
A fresh server is not starting from zero. The seed rule set covers the long tail of legitimate Lua menus, framework resources, vehicle add-ons, and event names that the network has already cleared. The list is curated from real card approvals, not synthetic data. Day-one detections on a vanilla ESX or QBCore install will already be filtered through that baseline before they reach the reviewer.
The seed set is read-only on your server. Your own approvals layer on top of it, server-local where you scope them that way, network-wide where you opt them in. The split keeps a careless operator on one server from changing what the rest of the network sees.
What it does not do
Three deliberate limits, listed plainly so the marketing line does not promise more than the system delivers:
- It does not write new detection rules. Raven Mind only relaxes or tunes existing ones; new detection surfaces ship from the resource side on the regular update cadence.
- It does not act unilaterally on cheat-shape signals. Anything classified as a likely cheat surface gets the operator card without auto-unban, even when the prior network decision was "allow" on a similar-but-different identifier.
- It does not phone home with player data. The signal hash includes the event or resource identifier and the protection that fired, not the player ID or the session payload.
What this looks like on a Tuesday
A new ESX framework resource ships an event that triggers Raven's server-event protection on three servers within an hour. The first server's operator opens the Discord card, sees the event name, confirms it matches the new framework release, picks Whitelist event, and clicks approve. The two servers that triggered after the approval never produce a card; the unban is silent and instant. Servers four through forty that update to the framework later in the week also never produce a card. The operator who reviewed it spent fifteen seconds. The other thirty-nine spent zero.
That is the day-to-day shape of Raven Mind. Not a chatbot, not a generative model writing config. A bounded review flow that scales the work of one careful operator across the whole network.