Como registrar e auditar cada decisão do Jev em produção

Fala aí, beleza? Decisão automatizada que ninguém consegue explicar depois não é automação, é passivo 😛

Chega o cliente, o jurídico ou o próprio chefe perguntando ‘por que o sistema recusou isso aqui?’ e o time fica olhando pro log sem saber o que responder

O Jev é o modelo proprietário da TypeSafe AI, lançado em early access em 15 de setembro de 2026 e ainda nesse estágio

Segundo a página do Jev na Wikipedia), a TypeSafe chama ele de primeiro ‘System One model’ da empresa, nome inspirado no pensamento rápido (o Sistema 1) popularizado pelo Daniel Kahneman

E aqui vem a parte boa pra quem precisa prestar contas: o Jev não gera texto livre

Ele devolve valores tipados com estimativas de probabilidade e confiança, ou seja, não tem parágrafo pra interpretar, tem campo pra guardar

Então se o teu time responde por decisões automatizadas, bora montar um registro que te deixe auditar decisões do Jev meses depois, sem achismo

Antes de começar: o que você precisa ter?

• Acesso ao Jev: lembrando que ele segue em early access
• Perguntas já definidas em um dos três tipos que o Jev aceita: Choice, Score ou Noul
• Um lugar pra persistir os registros: banco, storage de logs, o que o time já usa (a escolha é tua)
• Saber por onde a chamada passa: direto na TypeSafe ou por um gateway, tipo LiteLLM ou o AI Gateway da Vercel

Esse último item parece bobo, mas ele muda o que aparece no log, já já tu vai ver o porquê

Passo a passo para registrar e auditar as decisões do Jev:

A ideia geral é simples: cada chamada vira um registro com entrada, veredito, probabilidade, confiança (quando o tipo de pergunta tem esse campo), versão do modelo e versão da pergunta

Com isso na mão, qualquer decisão pode ser remontada depois

1. Como montar o registro conforme o tipo de pergunta?

Cada tipo devolve campos diferentes, então o registro precisa respeitar isso

• Choice: escolhe uma opção e devolve choice, probabilities e confidence
• Score: trabalha com níveis ordenados e devolve score, probabilities e, quando vier, legend
• Noul: devolve a probabilidade de ‘sim’, de 0 a 1

Um formato de registro que dá conta dos três (a estrutura e os nomes das chaves são do teu time, os valores entre < > vêm da resposta do Jev):

[
  {
    "tipo_pergunta": "choice",
    "entrada": "<dados enviados na chamada>",
    "resposta": {
      "choice": "<opção escolhida>",
      "probabilities": "<distribuição devolvida>",
      "confidence": "<confiança devolvida>"
    }
  },
  {
    "tipo_pergunta": "score",
    "entrada": "<dados enviados na chamada>",
    "resposta": {
      "score": "<nível escolhido>",
      "probabilities": "<distribuição devolvida>",
      "legend": "<legenda, se vier>"
    }
  },
  {
    "tipo_pergunta": "noul",
    "entrada": "<dados enviados na chamada>",
    "resposta": {
      "prob_sim": "<probabilidade de 'sim', de 0 a 1>"
    }
  }
]

O erro comum deste passo: procurar um campo confidence no Noul

Ele não existe! A certeza está na própria probabilidade: perto de 0 ou de 1 é confiante, perto de 0,5 é incerto

Então nada de criar uma coluna de confiança vazia pro Noul, isso só confunde quem for auditar depois

2. Por que gravar o campo model em toda resposta do Jev?

O campo model da resposta informa o ID versionado que respondeu, algo como jev-1.13.0

É ele que diz QUAL modelo produziu aquele resultado, e sem isso a auditoria vira chute

{
  "modelo": "<valor do campo model da resposta, ex.: jev-1.13.0>"
}

O erro comum deste passo: gravar só o alias que você usou na chamada

O alias diz o que você pediu, o model diz o que respondeu de verdade, e nem sempre é a mesma coisa (o próximo passo explica)

3. Usar jev-latest ou fixar a versão do Jev?

Fixar, se você calibrou qualquer limiar 🙂

Segundo a documentação de modelos da TypeSafe, em 25 de setembro de 2026 os aliases jev-latest e jev-preview apontavam pra jev-1.13.0

Porém o alias muda quando sai versão nova

Aí as respostas podem mudar sem você ter mexido em nada do teu lado, e o limiar que funcionava ontem passa a cortar errado hoje

Por isso a recomendação da própria doc: ajustou limiar de confiança numa versão, fixa o ID dessa versão em vez do alias

{
  "modelo_fixado": "jev-1.13.0",
  "motivo": "limiares calibrados nesta versão"
}

O erro comum deste passo: calibrar limiar em cima do jev-latest

É tipo afinar o violão e deixar alguém trocar as cordas enquanto tu dorme haha

4. Como versionar a pergunta que o Jev responde?

O Jev versiona o modelo, mas a pergunta é tua, então quem versiona é tu

Dá um identificador próprio pra cada pergunta, mais uma versão, e salva os dois junto de cada chamada

{
  "pergunta_id": "<identificador definido pelo teu time>",
  "pergunta_versao": "<versão definida pelo teu time>"
}

Se quiser ir mais fundo, tem um post só sobre como versionar o schema de decisão sem quebrar o que já está rodando

O erro comum deste passo: editar o texto da pergunta e manter a mesma versão

Parece inofensivo, mas os registros antigos ficam incomparáveis com os novos, e ninguém percebe até a primeira auditoria 😛

5. Como registrar o limiar de confiança e a rota da decisão?

Probabilidade e confiança servem pra definir o que acontece nos casos incertos

O caminho clássico: abaixo de certo nível de confiança, a decisão vai pra revisão humana

E o registro precisa guardar o limiar que estava valendo NAQUELE momento e a rota que foi tomada

Juntando tudo, um registro completão fica assim:

{
  "registrado_em": "<data e hora da chamada>",
  "pergunta_id": "<identificador da pergunta>",
  "pergunta_versao": "<versão da pergunta>",
  "tipo_pergunta": "choice",
  "modelo": "<valor do campo model da resposta>",
  "entrada": "<dados enviados na chamada>",
  "resposta": {
    "choice": "<opção escolhida>",
    "probabilities": "<distribuição devolvida>",
    "confidence": "<confiança devolvida>"
  },
  "limiar_confianca": "<limiar vigente no momento da chamada>",
  "rota": "<automatica ou revisao_humana>"
}

O erro comum deste passo: guardar só a decisão final

Limiar muda com o tempo, e sem ele no registro tu não consegue dizer se aquela decisão seguiu a regra da época ou não

6. O que o gateway registra sobre a versão do Jev?

Se a chamada passa por gateway, confere o log dele antes de confiar

Se liga nessa diferença:

No LiteLLM a requisição fica registrada sob o modelo versionado, o que ajuda bastante

Já no AI Gateway da Vercel, a issue #21213 no vercel/ai relata que o que volta é o alias, não a versão resolvida

O erro comum deste passo: confiar no log do gateway como fonte da versão

A fonte é o campo model da resposta, gravado por você, sempre

Como auditar uma decisão do Jev depois que ela aconteceu?

Chegou o questionamento, bora remontar a decisão:

1. Localize o registro da chamada pela data, pela entrada ou pelo identificador da pergunta
2. Confira as duas versões: o ID do modelo gravado a partir do campo model e a versão da pergunta
3. Leia o veredito junto da distribuição: em Choice e Score, a confiança vem da distribuição de probabilidades, então distribuição concentrada é confiança alta e distribuição plana é confiança baixa (no Noul não tem campo de confiança, a certeza está na própria probabilidade: perto de 0 ou de 1 é confiante, perto de 0,5 é incerto)
4. Verifique o limiar: a confiança ficou acima ou abaixo do limiar gravado naquele registro?
5. Confirme a rota: se ficou abaixo, a decisão foi mesmo pra revisão humana? Se ficou acima, seguiu automática?

Pronto, tu consegue explicar por que o sistema agiu daquele jeito com dado na mão, não com ‘acho que foi isso’ 😀

Checagem de calibração em lote:

Auditar caso a caso resolve o questionamento pontual, mas vale olhar o lote também

Probabilidade calibrada significa que, dos casos em que o modelo marca 0,9, cerca de 90 em 100 devem ser positivos

Então pega os casos marcados com 0,9 e compara com o resultado real

Se o número destoar muito, é hora de revisar os limiares

Esse tipo de análise conversa direto com medir o impacto do Jev no processo como um todo

O erro comum desta etapa: misturar resultados de versões diferentes na mesma análise

Compare sempre dentro da mesma versão fixada, senão tu tá medindo dois modelos como se fossem um só

Próximo passo: comece pelo campo model e pela versão da pergunta

Recapitulando: com entrada, veredito, probabilidade, confiança (quando o tipo tem), ID versionado e versão da pergunta salvos, qualquer decisão do Jev pode ser explicada depois

Soma o limiar vigente e a rota tomada, e a auditoria fica completa

O próximo passo prático é bem pequeno: fixa o ID versionado hoje e confere se o gateway que tu usa registra a versão real ou só o alias

E como o Jev segue em early access, vale acompanhar as mudanças de versão de perto, porque é exatamente aí que um registro bem feito salva o time…

Até o próximo post! 🙂