Static-config anticheats hit a wall in 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 closes that loop without an admin parked at the panel.
It is not a rebrand of a rule engine. Raven Mind is the live flow that sits on top of every Raven ban. It scores the shape of what was detected, takes the cheap action right away, and pushes the expensive action to Discord as a single-click card. The longer the network runs, the more decisions it has already made, so less of the queue ever reaches an operator.
What it does on every ban
When a Raven detection fires, the resource sends the ban payload through the flow before it is finalised on the server. The flow asks three questions in order.
- Has the network already ruled on this signal? If a prior decision exists for the exact identifier (a resource name, an event hash, a model spawn), Raven Mind replays it in the same tick. If that decision was "allow," the player is unbanned before the kick screen finishes rendering. If it was "block," the ban stays and picks up 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. An operator cannot whitelist a real attack by clicking through Discord notifications. - Is the action cheap to reverse? 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 on its own.
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 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, for when a baseline entry catches a vehicle a server legitimately ships.
- Tune the threshold or the timeframe. For when the protection is right 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 on a noisy detection while the operator collects evidence for a permanent rule.
- Disable the type or the option. The escape hatch when a protection is genuinely wrong for this server. The card warns you when this is the heavy-handed choice.
How a single approval propagates
The network share matters more than any single decision. When an operator on one Raven server approves a strategy, the decision is hashed by the signal it ruled on, not by the server it came from. The next time any Raven server produces that same signal, the flow replays the decision in the same tick and never opens a card.
So 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 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 the network has already cleared. That list is curated from real card approvals, not synthetic data. Day-one detections on a vanilla ESX or QBCore install pass through the 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, stated 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, never the player ID or the session payload.
What this looks like on a Tuesday
A new ESX framework resource ships an event that trips Raven's server-event protection on three servers within an hour. The first server's operator opens the Discord card, reads the event name, confirms it matches the new framework release, picks Whitelist event, and clicks approve. The two servers that triggered after that approval never produce a card. The unban is silent and instant. Servers four through forty that update to the framework later in the week never produce a card either. 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 your config. A bounded review flow that scales the work of one careful operator across the whole network.