The asymmetry
The two failure modes of an anticheat are not symmetrical, and treating them as though they are is the most common design mistake in this market.
Missing a cheater is bad: someone has an unfair evening, people complain, the cheater is usually caught later by something else. Banning an innocent player is worse in a way that compounds. That player tells their friends. Your staff loses confidence in the tool. And the fix, every single time, is the same one: the rule gets disabled, or the whole product does.
An anticheat that occasionally bans the wrong player gets switched off faster than one that lets a few cheaters through, and once it is off it catches nothing at all.
Which means a false-positive rate is not a quality metric sitting alongside detection coverage. It is the thing that determines whether any of the coverage ever gets used.
Where they come from
They are not random. In practice they cluster, and most of the clusters are about game state rather than about cheating at all.
| Cause | Looks like | Needs |
|---|---|---|
| Spawn transition | Position, health and invincibility are briefly in an in-between state, so movement and godmode rules fire on every join. | A grace window after spawn. |
| Legitimate teleports | A script moves the player deliberately; a movement rule sees an impossible jump. | A registry of the paths that are allowed to move a player. |
| Network conditions | A lag spike or an interior transition looks like a discontinuity. | Tolerance derived from measurement, not from a guess. |
| Scripted world events | A fuel tanker explodes as designed; an explosion rule counts it against the nearest player. | Whitelists for the events your own scripts cause. |
| Fixed thresholds | A number picked in a meeting rather than from data. Legitimate outliers cross it. | Comparison against a cohort rather than an absolute limit. |
| One-hit sanctions | A single ambiguous signal is enough to act on. | Accumulation over time, with decay. |
The pattern across the whole table: a false positive is usually a rule that was correct about the observation and wrong about the context.
Making the rate measurable
The fix is procedural rather than clever. A rule should not be allowed to punish anyone until somebody knows how often it is wrong, and the only way to know that is to run it without consequences first.
- Shadow. The rule logs and nothing else. It does not score, it does not alert, no player is affected, however obviously correct it looks.
- Warn. Once it has enough observations and a measured error rate under target, it scores and raises alerts for staff. Still no automatic sanction.
- Enforce. Full effect, with an automatic drop back to warn if it starts misfiring, rather than waiting for somebody to notice.
Two details make the difference between this working and being a diagram in a document. The rule state belongs in the database, not in a config file, or the discipline gets skipped the first time somebody is in a hurry. And the promotion criteria have to be numbers: a count of observations and a measured error rate, because "it seems fine" is how every rule gets promoted otherwise.
Appeals are the measurement
You cannot measure how many cheaters you missed. You can measure how many people you were wrong about, because they tell you. Appeals are the only ground truth an anticheat ever receives.
That only works if two things are true:
- Every sanction carries a reproducible record: what fired, the raw values, the surrounding window. Without it an appeal is one person's word against a log line, and gets decided by who is more persistent.
- An upheld appeal feeds back into the rule that caused it. If nothing changes, you have a complaints process rather than a measurement.
What to ask
Of any vendor, including us: what is the false-positive rate of your rules, and how did you measure it?
Nobody in this market publishes one. That is worth sitting with for a moment. For a product whose main risk is being wrong about a person, not one vendor reports how often it is. Detection percentages get advertised instead, and those are the number nobody can verify.
A vendor who has measured it can describe the method. A vendor who has not will answer with a feature list. It remains the single most informative question you can ask, and the one that gets asked least.