Gating por confiança e escalonamento para uma pessoa

A página anterior defendeu que o código deve ser dono do limiar. Esta página é sobre o que o limiar divide — as três faixas de cada lado dele.

Três faixas, não duas

Os projetos reais raramente fazem «automático ou não». Três faixas é a forma comum:

A terceira faixa é fácil de esquecer e é a mais barata das três. «Não olhado» e «uma pessoa espreita» diferem de uma pessoa.

Uma implementação de triagem é típica: pagina só quando P(SEV1) + P(SEV2) ≥ 0.80; descarta abaixo de 0.20 só quando uma verificação de acionabilidade também discorda; manda a faixa do meio para uma pessoa.

A faixa do meio é onde vivem os problemas reais

Assim que existem as três faixas, todas as perguntas difíceis passam para a do meio:

É capacidade humana, não capacidade livre. Quanto mais larga a faixa, mais escalonamentos, mais uma pessoa trata. Uma taxa de escalonamento de 9% parece baixa — até a taxa base ser milhares por dia.

Precisa de um fail-safe, ou fica presa em silêncio. Assim que entregas uma decisão a uma pessoa, nada acontece até uma pessoa olhar. Num painel, isso parece exatamente «está tudo bem». A resposta da ferramenta de triagem é direta: sem confirmação em 15 minutos, pagina de qualquer forma. Melhor acordar alguém do que deixar um P1 numa fila.

A própria condição de escalonamento pode falhar. Uma barreira de autonomia dentro de um agente continua só quando um Choice ultrapassa 0.6 e um Noul de segurança de autonomia ultrapassa 0.5, devolvendo o turno à pessoa em caso contrário. Ambos os números têm de passar — porque «o que devo fazer» e «isto é seguro» são perguntas separadas, e uma só confiança não pode responder honestamente às duas.

Fixar o limiar: medir primeiro

Escolher 0.8 ao calhas é a abordagem mais comum e a que mais provavelmente se torna ruído três meses depois. A abordagem reproduzível é medir, nos teus próprios dados anotados, o limiar necessário para atingir a tua exatidão-alvo.

Um exemplo público: com 0.7 como barreira de baixa confiança, uma execução sobre n=130 apanhou 3 de 3 classificações erradas com uma taxa de escalonamento de 9%. A amostra é pequena. O seu valor não é o 0.7 — é que é assim que um número desses deve ser reportado: dimensão da amostra, taxa de escalonamento e o que foi apanhado.

A latência é o risco subestimado

Os números medidos da ferramenta de triagem merecem uma tabela própria:

O p95 é 3.5× o p50. Isso significa que a cauda importa mais do que a média — porque a política de timeout dispara na cauda, e quando dispara estás no ramo de recurso, não no ramo que concebeste. A chamada mais lenta ficou a 151 ms do timeout, ou seja, o determinismo do sistema dependeu de uma moeda que por acaso não caiu mal.

Por isso os sistemas de gating costumam falhar não por «julgar mal», mas por esgotar o tempo e seguir o plano de recurso. Testa o ramo de recurso independentemente do caminho principal.

Duas direções de recurso, ambas corretas

Quando algo dá erro, as implementações públicas dividem-se em dois campos, e ambos estão certos:

• fail-closed: um juiz de permissões nega em caso de timeout ou erro. Uma barreira de segurança tem de funcionar assim — uma barreira de segurança fail-open é um buraco silencioso.
• fail-open: um hook Stop do Claude Code permite em qualquer erro. Uma barreira de eficiência tem de funcionar assim — uma barreira de eficiência fail-closed bloqueia todo o fluxo.

O critério não é «qual é mais segura», mas qual custo é maior: um bloqueio falso ou um bloqueio falhado. E tem de ser decidido quando escreves o código, porque o que determina é o caminho de exceção, não o principal.

Numa frase

Numa conceção de três faixas, o trabalho está na faixa do meio: a sua largura é um custo, o seu fail-safe é uma propriedade de fiabilidade. Concebe ambos explicitamente em vez de deixar os valores predefinidos.