Calibration
Definition. Calibration is the practice of treating a Noxtica result as a risk read, not a binary verdict. The result includes a score, a risk level, a confidence value, and flags or reasons. Your team decides what combination justifies observation, review, step-up, or denial on each surface.
The problem it solves is false certainty. A single “bot” label hides uncertainty and makes it hard to explain customer friction. A multi-field result lets a reviewer see both the assessed risk and how much evidence supported it.
Calibration here describes how the current product exposes and applies risk information. It is not a guarantee that a particular score has the same business meaning for every tenant, route, geography, or time period.
When it applies
Use calibration whenever the cost of being wrong differs by workflow:
- signups where automated account creation is costly but conversion matters;
- login or recovery where a false positive can lock out a customer;
- checkout where device evidence is one input alongside transaction context;
- public content where observation may be preferable to friction; and
- policy reviews where operators need to explain why a threshold exists.
How Noxtica does it
- Score and tier. The numeric score and named risk level provide an ordered risk signal that application code and operators can consume.
- Confidence. Confidence indicates how much weight to place on the assessment; it is a separate dimension from severity.
- Flags or reasons. Named contributing conditions provide an investigation trail rather than an unexplained label.
- Operator-owned thresholds. Your code and enabled policy controls determine what happens at each threshold.
This is a public output contract, not a disclosure of internal weighting or detection mechanics. For the current response shape, see Getting started: Response Format and Backend integration: API Reference.
Using the outputs
| Read | Question it answers | Decision use |
|---|---|---|
| Score | Where does this assessment sit on the risk scale? | Sort, segment, or apply a customer-defined threshold |
| Risk level | Which named operating band contains the score? | Map the assessment to a route-specific policy |
| Confidence | How much evidence supported the assessment? | Prefer observation or reversible step-up when confidence is limited |
| Flags or reasons | What contributed to the result? | Investigate, explain, or tune the customer-owned response |
Review these fields together. A higher-risk result with limited confidence may call for more evidence rather than a hard block. A repeated pattern with corroborating flags may justify stronger treatment on a sensitive route.
Operating a calibrated policy
- Start with observation on representative traffic.
- Separate results by surface and customer outcome; do not assume one threshold fits every route.
- Review score, risk level, confidence, and flags together.
- Choose the least disruptive action that addresses the measured risk.
- Record false-positive and false-negative outcomes in your own review process.
- Revisit thresholds after traffic, product, or attacker behavior changes.
The console and API provide inputs for this process. Your team owns the labels, outcome data, escalation path, and final policy.
Supported limitations
- A score does not prove that a session is automated, fraudulent, or operated by a particular person.
- Confidence is not identity assurance and should not replace authentication or authorization.
- Missing or blocked browser capabilities can reduce available evidence.
- Scores should be evaluated against your own traffic and outcomes before enforcement.
- Changes in traffic mix can make an old threshold less useful even when the response schema is unchanged.
Where we’re headed
This section is forward-looking and not part of the current product contract.
Today, operators tune policies and thresholds. Self-calibration and feedback-driven threshold changes are being explored for future releases.
The current workflow does not autonomously learn from customer outcomes or change policy. If your organization maintains labels or review outcomes, use them to evaluate the thresholds you control rather than assuming Noxtica will tune itself.
Where it fits
Calibration sits beneath Know Your Device and Browser Intelligence, which produce the read, and Browser Security, which turns a customer-owned policy into an action.
Read deeper
- Why calibration, not verdicts — the full decision philosophy.
- Features: risk and decisioning — where the output appears.
- Engineering principles — calibration as an operating constraint.
- Detection signals: how a signal becomes a decision — the public assessment flow.
- Backend integration — consume the result in server-side logic.