Princípios de Engenharia

No que acreditamos — e como isso aparece no produto.

Estas são restrições operacionais, não slogans. Cada uma delas é testável contra o produto. Se você encontrar uma exceção, ou o princípio está errado ou a implementação está errada; ambos são bugs.

01. Calibração em vez de veredictos

Sua equipe de fraude dá a palavra final — a Noxtica entrega a ela as evidências.

Não retornamos um sim ou não. Retornamos um nível de risco, uma medida de confiança e as razões por trás deles. Um chargeback não é um login com falha. Um novo cadastro não é um cliente recorrente com cookies resetados. Você conhece o seu contexto. Nós só damos a você inputs melhores.

Onde você verá isso

• Toda verificação retorna um nível de risco, uma medida de confiança e as razões por trás do score — nunca uma única flag de “isso é um bot”.
• O painel do operador mostra o detalhamento por categoria, não apenas o nível final.
• Os sinais subjacentes estão disponíveis se você quiser construir o seu próprio classificador por cima.

O trade-off

Você não pode colar a Noxtica em uma verificação de uma linha “se bot, bloquear”. Você escreve uma política. A política é curta — geralmente dez a vinte linhas — mas é sua.

02. Decisões que você pode defender

Quando uma sessão é sinalizada em um cliente real, seus engenheiros precisam defender a decisão — ao jurídico, ao produto, ao próprio cliente.

Toda categoria de detecção está documentada em /docs/threat-categories, e todo limiar é auditável. Se um resultado surpreender você, ele é rastreável. Se você discordar de uma calibração, ela é ajustável.

Onde você verá isso

• As razões numa verificação correspondem aos nomes nos docs exatamente. Sem codinomes, sem rebrands de marketing.
• Todo limiar carrega o raciocínio e os dados populacionais por trás dele.
• Os sinais que a Noxtica reporta são um contrato documentado, não um alvo em movimento.

O trade-off

Não podemos mudar o modelo silenciosamente. Apertar um limiar significa escrever a mudança, justificá-la no changelog e lançá-la como uma atualização versionada. Isso é mais lento do que uma caixa-preta seria. Achamos que a troca vale a pena.

03. Falsos positivos não são perdas aceitáveis

Um cliente bloqueado nunca volta. Um bot que escapa é um único chargeback que você pode contestar; um humano bloqueado é abandono — e o abandono se acumula.

Preferimos deixar um bot escapar a bloquear um cliente real em uma configuração incomum, mas perfeitamente legítima. Os limiares são enviesados para deixar casos limítrofes passarem de propósito. Os níveis de risco existem para que você possa escolher o seu próprio trade-off, mas os padrões são conservadores por um motivo.

Onde você verá isso

• Os níveis “observar isso” e “desafiar isso” estão deliberadamente afastados, para que a população entre eles seja principalmente de bots, não de humanos.
• Navegadores de privacidade reconhecidos são tratados com leniência por design, não como uma reflexão tardia.
• A política padrão nos nossos exemplos é desafiar, não bloquear — e bloquear é reservado para o nível mais alto, que por design só dispara quando múltiplos sinais concordam.

O trade-off

Sua taxa de captura com as configurações padrão é menor do que a de um concorrente ajustado de forma mais agressiva. Achamos que você vai capturar mais bots em termos absolutos ao longo de um ano, porque vai manter mais dos seus clientes reais para começar.

04. Privacidade por construção

Seu encarregado de proteção de dados dorme melhor porque construímos isso para o dele.

O coletor não coleta nenhum dado pessoal. Nenhum endereço de rede é armazenado por padrão — apenas contexto grosseiro como país, derivado e depois descartado. Nenhuma chamada de terceiros acontece durante a verificação. O que armazenamos é um resumo embaralhado e unidirecional, nunca valores brutos, e a chave de assinatura rotaciona regularmente. Não podemos vender o que nunca coletamos.

Onde você verá isso

• Durante a coleta, o navegador faz exatamente uma requisição: um envio de mesma origem ao seu próprio backend com o resultado selado. Sem telemetria de terceiros, sem beacons de analytics, sem fontes carregadas de outro lugar.
• A verificação do nosso lado não precisa de buscas extras — o quadro completo está no resultado, então não há nada para rebuscar.
• Os padrões de retenção de dados variam por plano, e a exclusão definitiva mediante solicitação é aplicada na camada de armazenamento, não como uma flag lógica.

O trade-off

Não podemos enriquecer o modelo com dados entre clientes. Um bot visto no site de um cliente não é automaticamente conhecido para a verificação de outro cliente. Usamos agregados em nível populacional para calibração, mas nunca vinculamos indivíduos entre clientes.

Como os princípios se compõem

Estes quatro princípios não são independentes — eles se reforçam mutuamente.

• Calibração em vez de veredictos (01) só funciona se as decisões são defensáveis (02), porque sem o raciocínio documentado você não consegue ler a calibração.
• Decisões defensáveis (02) são o que torna a aversão a falso positivo (03) verificável — você pode auditar os limiares e provar que os padrões são conservadores.
• Privacidade por construção (04) é o que mantém o modelo legível. Não temos mil features entre clientes; temos algumas dezenas, cada uma atrelada a um sinal que você pode ler nos docs.

Se adicionarmos um quinto princípio, ele precisará reforçar estes quatro. Se não reforçar, não o lançaremos.

Leitura relacionada

• Por que calibração, não veredictos — a filosofia que impulsiona o princípio 01.
• Categorias de ameaça — a superfície documentada que o princípio 02 promete.
• Casos de uso — como os princípios 03 e 04 se parecem em produção.