Detection Signals

Noxtica reads several evidence layers and checks whether the available picture is coherent. It then returns customer-facing policy inputs: score, risk tier, confidence, and named reasons where applicable. Optional modules can add agent, attestation, behavioral, identity, or policy status.

Signals describe a browser, device, connection, or interaction context—not a person’s identity or intent. No single layer establishes “human,” “bot,” “fraudulent,” or “safe,” and this page intentionally does not publish hidden probes, exact weights, anti-evasion methods, or proprietary implementation.

When to use detection signals

Collect at a decision point where additional context can change a proportionate action: signup, login, checkout, account recovery, promotion redemption, content/API access, or an investigation. Do not collect every optional signal simply because it exists. Match the enabled layers, cache cadence, retention, and downstream use to a documented purpose.

Use browser callbacks when the page needs a reversible experience choice. Send the device handle to your trusted backend and use a scoped server integration when authentication, money, account access, or another consequential decision is involved.

Four questions, one answer

Noxtica groups customer-visible interpretation into four layers. The questions below are operational shorthand, not claims that one layer can prove the answer.

Contradictions between independent layers can be useful, but agreement does not prove identity or intent. Absence also has meaning: a layer can be unavailable, disabled, unsupported, denied by policy, sampled out, cached, or simply inconclusive.

Configure the evidence you need

Core browser collection

1. Add the exact origin in Backoffice → Domains and copy its Site Key.
2. Install the supported collector pattern from Getting Started.
3. Select the collection mode supported by the current SDK and customer journey.
4. Use checkOnce() for the configured cache behavior, or request a fresh assessment only when the decision justifies the extra client work.
5. Monitor noxtica:collected, noxtica:cache-hit, and noxtica:error as documented in Browser Runtime.

Optional evidence

Enable attestation, behavioral biometrics, replay/RUM, detailed network context, KYA, identity, or investigation modules only when they are entitled and their domain/tenant settings, client support, quota, purpose, consent/legal basis, redaction, and retention have been reviewed.

A feature page in Backoffice normally shows its status and configuration links when the signed-in operator has access. If the page, toggle, or output is absent, treat the capability as unavailable for that deployment until provisioning or configuration is confirmed.

Trusted consumption

Create the narrowest required Server API key under API Config and keep it on the backend. Handle authentication errors, authorization errors, missing/expired records, rate limits, timeouts, and unavailable optional providers as explicit states. Never make a missing result silently equivalent to minimal risk.

One calibrated risk tier

The core web assessment maps the numeric score to a five-level customer contract:

• Minimal (0–19) — little risk evidence in the available assessment.
• Low (20–39) — minor or potentially explainable anomalies.
• Medium (40–59) — mixed or incomplete suspicious evidence.
• High (60–79) — strong suspicious evidence.
• Critical (80–100) — multiple or strong reason families agree.

The tier does not arrive alone. Read it with:

• confidence: how much usable evidence supported the assessment;
• flags or reasons: the public evidence families that influenced it;
• fingerprintId: the tenant-scoped device handle returned by the browser integration;
• cache/freshness and timestamps: whether the decision is using a current or reused assessment; and
• optional statuses: agent verification, device/app integrity, identity case, or policy action where enabled.

The ranges are integration vocabulary, not universal action thresholds. Use Why Calibration, Not Verdicts to choose route-specific policy.

Interpret risk and confidence together

A policy can also consider the route’s value, authentication state, transaction/account context, device familiarity, supported agent identity, and confirmed customer outcomes. Noxtica’s output should complement—not replace—those controls.

Sealed before it leaves the browser

Noxtica protects the assessment in transit from the browser so your supported verifier can detect invalid, expired, mismatched, or altered results. The customer contract is the outcome: trusted code validates the supported result before relying on it.

This integrity protection does not make all client data inherently trustworthy, does not prevent every replay or endpoint misuse by itself, and does not authorize the action. Keep secret credentials on your server, validate the result through the documented integration, bind it to the intended workflow where supported, enforce expiry, and retain your own authentication and authorization checks.

The exact cryptographic construction, challenge method, hidden signal probes, and internal anti-evasion controls are not customer configuration and are intentionally omitted here.

How a signal becomes a decision

Walk through a signup attempt:

1. Admission and collection. The configured collector starts for the registered domain. Optional capture runs only if its policy, consent or legal-basis, sampling, and other admission conditions allow it.
2. Assessment. Noxtica evaluates the available browser, network, device, and eligible interaction context. Unsupported, disabled, denied, cached, or missing evidence affects what is available.
3. Output. The browser callback returns the documented fields. Your frontend can send the device handle with the signup request; it never sends a secret Server API key.
4. Trusted lookup. Your backend uses its scoped credential or supported SDK to read the eligible current record and handles errors, expiry, and unknown explicitly.
5. Customer policy. A route-specific rule combines risk, confidence, reasons, signup/account context, and any approved-agent or integrity status.
6. Action. The application allows, observes, requests a reversible step-up, holds for review, or blocks under the reviewed rule.
7. Review. Operators inspect Analytics, Fingerprints, Risk Actions, and Audit where enabled, then compare confirmed abuse with challenge completion, abandonment, support contacts, and reversals.

Public policy example

function decideSignup({ riskLevel, confidence, resultState }, confidenceFloor) {
	if (resultState !== 'available') return 'step_up_or_defer';
	if (confidence < confidenceFloor) return 'step_up_or_observe';
	if (riskLevel === 'critical') return 'strong_challenge_or_review';
	if (riskLevel === 'high') return 'step_up';
	if (riskLevel === 'medium') return 'observe';
	return 'allow_with_normal_controls';
}

The confidence floor and action mapping are intentionally yours. Determine them from representative shadow traffic and labeled outcomes rather than copying an internal or universal weight.

Expected outputs by customer surface

Eligibility and limitations

Core collection requires an activated account, registered domain, Site Key, and supported browser integration. Outputs depend on collection mode, browser capabilities, cache state, network, retention, and service availability. Optional families require their own entitlement, tenant/domain activation, role, scope, quota, supported client or provider, and sometimes consent or legal-basis review.

Detection signals are probabilistic and can be incomplete, stale, or wrong. They do not prove identity, account ownership, accessibility needs, fraud, or intent. No universal detection rate, false-positive rate, latency, availability, or privacy outcome is promised here. Measure the behavior of your actual integration and apply the terms in your current contract.

Related reading

• Threat categories — interpretation and limits for each public reason family.
• Browser runtime — collection modes, caching, events, CSP, and troubleshooting.
• Backend integration — trusted lookups, response fields, errors, and rate limits.
• Why calibration, not verdicts — choose route-specific action from risk and confidence.
• Customer capability reference — every customer family, surface, output, eligibility, and limitation.