Blog / Product

Measurement is not proof (and why that is fine)

A detection score is an estimate, not a verdict of identity. That is not a weakness — it is the only honest way to describe what session scoring can do.

Every detection product eventually faces the same question: can you prove this is a bot? The honest answer is no — and systems that imply otherwise tend to fail in the places that matter.

Proof is the wrong bar. What a session tells you is evidence: timing, client integrity, how a request arrived, whether an agent disclosed itself. A score summarises that evidence. It is an estimate of human-likeness, not a claim about identity.

What a score actually is

A score on a 0–100 scale is a reading, like a thermometer. It goes up with consistent, varied interaction and intact client signals; it goes down with automation tells and contradictions. A reading is not a diagnosis, and a diagnosis is not proof.

This is why Volance separates three things that are easy to conflate:

  • Classification — the traffic class we estimate: human, agent, or bot.
  • Verdict — the policy band the score falls into, such as likely human or suspicious agent.
  • Action — what your application chooses to do: allow, flag, or block.

None of those is a statement of fact about a person. Together they are a defensible basis for a decision.

Why "proof" would be a trap

If a tool insists it knows, you lose the ability to reason about the middle — the ambiguous sessions where real traffic lives. You also lose the ability to explain a block. "The system says so" is not an answer you can give a customer, a support agent, or an auditor.

Worse, certainty invites over-blocking. Every real detection system has false positives; the question is whether the operator can see them and tune the policy. A number labelled "proof" hides that work instead of enabling it.

What good looks like

Good session scoring does four things:

  • Returns a graded score, not a coin flip, so you can treat the middle differently from the extremes.
  • Attaches the evidence — which checks ran, what they read, and which moved the score.
  • Offers a way to gather more evidence when it is uncertain, rather than guessing.
  • Leaves enforcement to you, so the estimate never silently becomes a block.

Volance is built around those four. A response names its signals, flags hard overrides such as an exposed automation flag, and can suggest additional checks when a session lands mid-band. Your server decides what happens next.

The practical payoff

When you stop asking a score to prove anything, the workflows get easier. You run in monitor mode first and watch the split. You tune thresholds against your own traffic. You allow verified agents by policy. And when someone asks why a session was blocked, you have a list of reasons instead of a shrug.

Measurement is not proof. It is something more useful: a transparent estimate you can act on and explain.

Frequently asked

Does Volance claim to detect bots with certainty?

No. It returns an estimate of human-likeness with the evidence behind it. The classification and verdict are estimates, and your application decides what to do.

How do I handle the uncertain middle?

Treat mid-band scores as a prompt to gather more evidence or route to a review path, rather than forcing a binary allow or block. Cascades exist for exactly this.

See the evidence
for yourself.

One script on your site.
One API call from your server.
Every signal behind the verdict, in your own portal.

Open the portal Read the docs