Why we don’t tell you “this is a bot.”
A binary label hides uncertainty and invites the same action everywhere. A login, a checkout, a public article, and an account-recovery change have different costs when a decision is wrong. Noxtica therefore returns calibrated policy inputs: risk, confidence, and explainable reason categories.
Calibration does not mean the system knows a visitor’s identity or intent. It means the output has ordered levels that your team can compare with labeled outcomes and map to proportionate action. Noxtica provides the measurement and eligible policy surfaces; your application and operators remain responsible for the decision.
The receipt model
Read the risk level, confidence, and reasons together. Apply the policy for this customer journey. Keep the decision reviewable.
A useful receipt answers five customer questions:
- What was assessed? The tenant, domain, device or request handle, and time.
- What did Noxtica return? Score, risk tier, confidence, and public reason categories.
- What context was available? Cached or fresh result, enabled modules, and any missing or unknown evidence visible through supported surfaces.
- Which policy applied? The customer-owned route or workflow rule.
- What happened next? Allow, observe, challenge, hold, review, or block—and any appeal or later confirmed outcome.
Use browser events for reversible in-page experience choices and a scoped server lookup or supported server SDK when a trusted backend must decide. Use Fingerprints, Analytics, Risk Actions, Quality & Calibration, and Audit in Backoffice where those surfaces are enabled for your role and tenant.
The receipt deliberately does not disclose hidden probes, scoring weights, anti-evasion methods, or proprietary implementation. Explainability is a stable customer outcome and reason contract, not an attacker’s recipe.
Binary verdicts hide the cost of being wrong
A binary verdict has two familiar failure modes:
- False positive: legitimate activity receives an unnecessary challenge, hold, review, or denial. Possible costs include abandonment, inaccessible journeys, support load, and loss of trust.
- False negative: abusive automation or fraud receives ordinary treatment. Possible costs include account abuse, operational load, inventory or content extraction, and financial loss.
There are also two operational failures that a binary field tends to erase:
- Unknown: the required result, module, or evidence is absent or unavailable.
- Low confidence: the assessment has too little usable evidence for the action being considered.
These states need explicit policy. Treating missing data as “safe” creates bypasses; treating it as “malicious” punishes restricted browsers, outages, and integration mistakes. A common starting posture is to preserve ordinary controls, defer a high-impact action, or request a reversible step-up while the cause is investigated.
The five-tier risk model
Noxtica’s public web response uses five risk tiers:
| Tier | Current score range | Interpret as | Example starting action—not a default guarantee |
|---|---|---|---|
minimal | 0–19 | Little risk evidence in the available assessment | Allow under normal application controls |
low | 20–39 | Minor or explainable anomalies | Allow and observe |
medium | 40–59 | Mixed or incomplete suspicious evidence | Observe, queue, or use low-friction step-up |
high | 60–79 | Strong suspicious evidence | Challenge, hold, or review |
critical | 80–100 | Multiple or strong reason families agree | Strong challenge or block only under reviewed policy |
The response ranges provide a consistent integration vocabulary. They are not a promise that one threshold fits every tenant or that a tier will never change meaning under a versioned service contract. Use Backoffice distributions and your own confirmed outcomes to select actions.
Configure policy by surface
| Surface | What to configure | Why it differs |
|---|---|---|
| Public content | Observe, rate limit, or apply agent-specific policy | The action is usually reversible and low value |
| Signup or promotion | Detect repeated or automated attempts; step up before granting value | Shared devices and legitimate retries are common |
| Login | Combine device familiarity with authentication and account context | A new device is not proof of takeover |
| Checkout | Combine assessment with transaction and account controls | The cost of a false denial and fraud both matter |
| Recovery or credential change | Require stronger authentication when risk or confidence warrants it | The operation is high impact even for known devices |
Start in shadow or observe-only mode where available. Record which action would occur, compare it with confirmed outcomes and customer-friction measures, and promote only the reviewed route policy.
Confidence is a separate axis
Risk answers “how concerning is the available evidence?” Confidence answers “how much usable evidence supported that assessment?” They are not substitutes.
| Risk | Confidence | Safer interpretation | Possible response |
|---|---|---|---|
| Low | High | Available evidence is consistently ordinary | Allow under normal controls |
| Low | Low | Little concern was seen, but little was known | Preserve normal controls; avoid granting extra trust |
| High | High | Strong concern with substantial corroboration | Challenge, hold, review, or apply a reviewed block rule |
| High | Low | Concern exists but evidence is incomplete | Reversible step-up or review; investigate missing evidence |
Confidence can be affected by collection mode, browser support, page timing, caching, consent choices, optional-module status, or integration errors. Do not infer a person’s behavior or disability from a confidence value.
The reasons are the audit trail
Named reasons tell an authorized operator which public evidence family influenced the result: for example automation, consistency/tampering, network/infrastructure, privacy-browser handling, device integrity, or interaction context. They help support and fraud teams answer “why did this assessment move?” without exposing the hidden test or its weight.
Use reasons to:
- distinguish a potentially explainable anomaly from corroborated abuse;
- find the relevant threat category;
- compare an individual record with its domain’s population;
- choose a better step-up or allow treatment for approved automation;
- label a confirmed outcome through the supported customer surface; and
- investigate policy regressions after a browser, traffic, or configuration change.
Do not use reasons to:
- turn one flag into a permanent deny list;
- infer protected or sensitive traits;
- reproduce or probe the detection mechanism;
- assume two matching reasons prove the same person or actor; or
- promise a customer that the result is error-free.
Calibrate with your own outcomes
- Define the unit: signup, login, transaction, request, account change, or moderation case.
- Define known outcomes: confirmed abuse, confirmed legitimate, challenge passed, appeal upheld, chargeback, review disposition, or another defensible label.
- Run observe-only: collect enough representative traffic for the routes and cohorts you will govern.
- Compare: inspect risk, confidence, reasons, unknown/error rates, customer friction, and action volume.
- Choose thresholds: start with reversible actions and route-specific exceptions.
- Review after launch: watch drift, challenge completion, abandonment, support contacts, reversals, and missed abuse.
- Change deliberately: record the rationale, reviewer, effective time, and rollback condition.
Quality or calibration surfaces may be plan- or role-gated. If your account does not expose them, agree on the supported labeling and review process with your Noxtica contact before enforcement.
Calibration over verdicts
The short version:
- A risk tier is an ordered measurement, not identity or intent.
- Confidence expresses evidence coverage, not safety.
- Reasons make the outcome reviewable without publishing sensitive detection mechanics.
- Different customer journeys need different actions.
- Unknown, error, and low-confidence states need explicit safe handling.
- Your labeled traffic and customer-friction data—not an unsupported universal metric—determine whether policy works.
Eligibility and limitations
Core risk fields are available with an activated collection integration. Advanced scoring endpoints, quality/calibration tooling, attestation, behavioral, agent, identity, investigation, and enforcement modules can require plan entitlement, tenant or domain activation, operator permissions, quota, a supported client, or legal-basis review.
Calibration reduces hidden uncertainty; it does not eliminate model error, adversarial adaptation, incomplete data, or traffic drift. Exact false-positive rates, detection rates, latency, threshold stability, and change-notice commitments apply only when defined by a current measurement record or customer contract.
Related reading
- Threat categories — interpret the public reason families.
- Detection signals — understand evidence layers and missing data.
- Engineering principles — the operating constraints for rollout and review.
- Use cases — route-specific reference patterns.
- Customer capability reference — customer surfaces, outputs, eligibility, and limits.