Hierdie vertaling is masjiengegenereer en wag op hersiening. Skakel oor na Engels
Kontroleskerm

Engineering Principles

What we believe — and how it shows up across the product.

These are operating constraints, not slogans. Every one of them is testable against the product. If you find an exception, the principle is wrong or the implementation is wrong; both are bugs.

01. Calibration over verdicts

Your fraud team makes the final call — Noxtica gives them the evidence.

We don’t return a yes-or-no answer. We return a risk level, a confidence measure, and the reasons behind them. A chargeback isn’t a failed login. A new signup isn’t a returning customer with reset cookies. You know your context. We just give you better inputs.

Where you’ll see this

  • Every verification returns a risk level, a confidence measure, and the reasons behind the score — never a single “this is a bot” flag.
  • The operator dashboard shows the breakdown by category, not just the final tier.
  • The underlying signals are available if you want to build your own classifier on top.

The trade-off

You can’t paste Noxtica into a one-line “if bot, block” check. You write a policy. The policy is short — usually ten to twenty lines — but it’s yours.

02. Decisions you can defend

When a session is flagged on a real customer, your engineers need to defend the decision — to legal, to product, to the customer themselves.

Every detection category is documented in /docs/threat-categories, and every threshold is auditable. If a result surprises you, it’s traceable. If you disagree with a calibration, it’s tunable.

Where you’ll see this

  • The reasons in a verification match the names in the docs exactly. No code names, no marketing rebrands.
  • Every threshold carries the rationale and the population data behind it.
  • The signals Noxtica reports are a documented contract, not a moving target.

The trade-off

We can’t quietly change the model. Tightening a threshold means writing the change, justifying it in the changelog, and shipping it as a versioned update. That’s slower than a black box would be. We think the trade is worth it.

03. False positives are not acceptable losses

A blocked customer never comes back. A missed bot is a single chargeback you can dispute; a blocked human is churn — and churn compounds.

We’d rather miss a bot than block a real customer on an unusual but perfectly legitimate setup. The thresholds lean toward letting borderline cases through on purpose. The risk tiers exist so you can choose your own trade-off, but the defaults are conservative for a reason.

Where you’ll see this

  • The “watch this” and “challenge this” tiers are deliberately spread apart, so the population in between is mostly bots, not humans.
  • Recognized privacy browsers are handled leniently by design, not as an afterthought.
  • The default policy in our examples is challenge, not block — and block is reserved for the top tier, which by design only fires when multiple signals agree.

The trade-off

Your catch rate at default settings is lower than a more aggressively tuned competitor’s. We think you’ll catch more bots in absolute terms over a year, because you’ll keep more of your real customers to begin with.

04. Privacy by construction

Your data-protection officer sleeps better because we built this for theirs.

The collector gathers no personal data. No raw network address is stored by default — only coarse context like country, derived and then dropped. No third-party calls happen during verification. What we store is a scrambled, one-way summary, never raw values, and the signing key rotates on a regular schedule. We can’t sell what we never collected.

Where you’ll see this

  • During collection, the browser makes exactly one request: a same-origin send to your own backend with the sealed result. No third-party telemetry, no analytics beacons, no fonts pulled from elsewhere.
  • Verification on our side needs no extra lookups — the full picture is in the result, so there’s nothing to re-fetch.
  • Data retention defaults vary by plan, and hard-delete on request is enforced at the storage layer, not as a soft flag.

The trade-off

We can’t enrich the model with cross-customer data. A bot seen on one customer’s site isn’t automatically known to another customer’s verification. We use population-level aggregates for calibration, but never link individuals across customers.

How the principles compose

These four principles aren’t independent — they reinforce each other.

  • Calibration over verdicts (01) only works if decisions are defensible (02), because without the documented reasoning you can’t read the calibration.
  • Defensible decisions (02) are what make false-positive aversion (03) verifiable — you can audit the thresholds and prove the defaults are conservative.
  • Privacy by construction (04) is what keeps the model legible. We don’t have a thousand cross-customer features; we have a few dozen, each tied to a signal you can read about in the docs.

If we add a fifth principle, it’ll need to reinforce these four. If it doesn’t, we won’t ship it.