Base Rates: The Arithmetic Nobody Shows

This is the single most important quantitative fact in behavioural analytics, and it appears in almost no vendor material.

The arithmetic

Suppose a detector is genuinely good: it catches 90 percent of malicious behaviour, and it falsely flags only 1 percent of innocent behaviour. Those numbers would be excellent in this field.

Apply it to 10,000 employees over a year, in which — realistically — perhaps two are doing something that warrants action.

The detector catches roughly both of them. It also flags 1 percent of the other 9,998, which is about 100 people.

Of 102 alerts, 2 are genuine. Precision is under 2 percent, with a detector performing far better than anything commercially available.

Why this is not a tuning failure

The result follows from the rarity of the event, not from the quality of the detector. Improving the false positive rate tenfold — to 0.1 percent, which nothing achieves — still yields 10 false alerts for 2 real ones.

You cannot tune your way out of arithmetic. What you can do is change the population, change the prior, or combine signals.

What actually helps

Reduce the population. Applying a detector to 400 privileged accounts rather than 10,000 employees changes the base rate by a factor of 25. This is why privileged-user monitoring is more productive than workforce monitoring, and it is the strongest practical lever available.

Raise the prior with context. Departing employees are a small population with a genuinely higher rate. The same detector applied there has far better precision. This is not because the detector improved; it is because the prior did.

Require multiple independent signals. Two detectors each flagging 1 percent, if genuinely independent, jointly flag 0.01 percent. Independence is the load-bearing assumption and it is frequently violated — features derived from the same activity are not independent evidence.

Accept the queue as a prioritisation, not an accusation. If the realistic expectation is that most alerts are innocent, the process, the language and the analyst's mindset should reflect that. This is a design decision about the whole programme, not a detail.

The prosecutor's fallacy

The specific error this arithmetic invites.

An analyst reasons: "if this person were doing something wrong, this alert would fire; the alert fired; therefore they are probably doing something wrong."

The conditional runs the wrong way. The probability of the alert given wrongdoing is high. The probability of wrongdoing given the alert is low, because wrongdoing is rare.

This mistake is easy to make, it feels like sound reasoning, and it has produced real consequences for innocent people in more consequential fields than this one. Any programme where alerts lead to conversations about a person should have named it explicitly in training.

What to say to executives

The instinct is to hide this, because it sounds like an admission that the system does not work.

State it instead, early and plainly: at realistic rates, most of what this system surfaces will be innocent, by arithmetic rather than by fault. Our job is to review candidates efficiently and to be right when we escalate.

That framing sets expectations that survive the first quarter, and it forecloses the demand to "reduce false positives" that would otherwise arrive and be satisfied by turning detection down.

The design consequences

Scope narrowly. Fewer entities, higher prior, better precision.

Layer, do not blanket. High-precision detectors on the whole population; sensitive detectors on small, high-prior populations.

Never automate consequences. At these rates, an automatic action on a single detector is an automatic action against innocent people, at scale.

Build the review process for volume, because the volume is not going away.

Working the arithmetic for your environment

Do this once, on a slide, before anyone sets an expectation.

Estimate your population size for the detector in question.

Estimate the realistic incident rate. Nobody knows this precisely; published estimates and your own history give an order of magnitude. Being wrong by a factor of two does not change the conclusion.

Take the vendor's false positive rate, or measure your own from a month of adjudication.

Multiply. Population times false positive rate gives expected false alerts. Population times incident rate times detection rate gives expected true alerts.

Compare the two numbers. That ratio is your realistic precision, and it is the number to set expectations against.

Then run it again for a narrower population — privileged accounts, departing employees, one sensitive system. The improvement is usually dramatic and it is the strongest argument for scoping narrowly.

Common false positives

Base rate effects explain most of what an analyst sees, and naming the categories helps:

Ordinary variation in a large population, which produces extreme values daily by chance alone.

Correlated detectors firing together on one action, which feels like corroboration and is not.

Repeat individuals whose structural difference from their peer group is permanent.

Rare-but-legitimate activity, which is common in aggregate because the population is large.

Novel behaviour during change, which is universal during any rollout.

None of these indicates a defective model. They indicate a rare target in a large population, which is the permanent condition of this work.

Blind spots and assumptions

That signals are independent. Usually they are not, and the joint precision gain is smaller than the multiplication suggests.

That the base rate is known. It is not; the estimate of two per ten thousand is illustrative and the true figure is unmeasurable.

That improving the model changes the picture. Only marginally, unless the improvement is orders of magnitude.

That analysts intuit this. They do not, without being told. Under queue pressure, an alert feels like evidence, and the arithmetic is what stops it from being treated as one.