O que mandar como entrada do Jev: como montar o state que vira decisão tipada

Jogar todo o seu banco de dados dentro do campo state não é montar uma entrada, é empurrar o problema pro modelo

Fala aí, beleza? O Jev é o modelo System One da TypeSafe AI, anunciado em 15 de setembro de 2026, e ele faz uma coisa só: recebe estado não estruturado e devolve valores tipados com probabilidade calibrada, sem gerar texto

Ou seja, não é modelo de escrever, é modelo de DECIDIR

E aí muda tudo na hora de montar a entrada. Não interessa se o texto ficou bonito, interessa se ele carrega exatamente o que a decisão precisa comparar

Neste post tu vai ver o que incluir no state, o que cortar fora, como não estourar o orçamento de tokens e um checklist de revisão pra rodar antes de cada envio =)

O que você precisa antes de montar a entrada

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

O acesso ao Jev segue em early access, liberado por waitlist. Então o primeiro pré-requisito é esse mesmo: ter a chave na mão

Com a chave, tu guarda ela na variável de ambiente TYPESAFE_API_KEY, que é de onde o cliente do SDK lê por padrão

Depois é escolher o caminho:

# Python (exige Python 3.10 ou superior)
pip install typesafe-sdk

# JavaScript / TypeScript
npm install @typesafe-ai/sdk

Ou chamada direta na API, sem SDK nenhum:

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d @payload.json

O modelo padrão do cliente é jev-latest, que hoje resolve pra jev-1.13.0

Anota isso porque importa: se amanhã o alias apontar pra outra versão, o comportamento da tua entrada pode mudar sem tu ter tocado em nada

Como montar o state do Jev passo a passo

A divisão de responsabilidade é a espinha de tudo aqui. O state carrega o conteúdo e os fatos de apoio, e as questions definem os julgamentos sobre esse material

Se tu internalizar só essa frase, metade dos erros já morre antes de nascer

1. Separe o que é conteúdo do que é julgamento

Pega o teu caso e faça duas colunas mentais

De um lado o material: o texto do ticket, o registro do cliente, o trecho do contrato, o documento de referência. Isso é state

Do outro lado a pergunta: "isso é urgente?", "qual categoria?", "nota de 0 a 10 pra clareza". Isso é question

O erro comum deste passo: escrever a instrução dentro do state, tipo "avalie o texto abaixo e diga se é urgente". O julgamento não mora no state, mora na question

2. Escolha o formato e prefira objeto com nomes descritivos

O state aceita apenas texto: string, objeto JSON ou array de valores de texto

Imagem, áudio e vídeo não são suportados. Nada de multimodal por aqui, beleza?

A documentação recomenda usar objeto na maioria das requisições, pra que cada parte do state tenha nome descritivo e as relações fiquem explícitas

{
  "state": {
    "mensagem_do_cliente": "O pedido chegou com a caixa amassada...",
    "politica_de_troca": "Trocas aceitas em até 7 dias corridos...",
    "historico_de_contatos": [
      "2026-09-02: abriu chamado sobre atraso",
      "2026-09-11: pediu segunda via da nota"
    ]
  },
  "questions": [ ]
}

Olha como fica óbvio pro modelo o que é mensagem, o que é política e o que é histórico

Se tu joga tudo isso numa string concatenada, o modelo precisa adivinhar onde uma coisa termina e a outra começa

O erro comum deste passo: usar chave genérica tipo dados, info, texto1, texto2. Nome descritivo não é frescura, é sinal

3. Agrupe as partes que a decisão precisa comparar

A orientação oficial é agrupar informações relacionadas quando a decisão exige comparar essas partes

Faz sentido, né? Se a pergunta é "a resposta do suporte respeitou a política?", a resposta e a política precisam estar juntas no mesmo state

{
  "state": {
    "resposta_do_suporte": "Infelizmente não conseguimos trocar...",
    "politica_de_troca": "Trocas aceitas em até 7 dias corridos..."
  }
}

O erro comum deste passo: mandar a política numa requisição e a resposta em outra, esperando que o modelo lembre. Cada requisição vive sozinha

4. Mova regras de domínio e casos de borda pra instructions e criteria

Esse é o passo que mais gente pula

A documentação orienta colocar conteúdo proprietário, registros e material de referência no campo state, e codificar as regras de domínio e os casos de borda nas instructions e criteria de cada question

Então "cliente enterprise sempre entra como prioridade alta" NÃO é conteúdo, é regra. Vai pra question

O erro comum deste passo: transformar o state num manual de política interna. Aí o material real que deveria ser avaliado vira minoria dentro da entrada

5. Filtre em código antes de enviar

A recomendação oficial pra state inflado é recuperar e filtrar em código antes, enviando só os campos de que a pergunta precisa

Ou seja: a curadoria acontece no teu backend, não na cabeça do modelo

E quando não dá pra filtrar antes? A documentação sugere usar um Noul pra filtrar relevância, ou seja, um julgamento binário barato decidindo o que entra antes do julgamento caro

CAMPOS_DA_PERGUNTA = ("mensagem_do_cliente", "politica_de_troca")

def montar_state(registro: dict) -> dict:
    return {
        chave: valor
        for chave, valor in registro.items()
        if chave in CAMPOS_DA_PERGUNTA and valor
    }

Simples assim. Uma função boba que economiza acurácia e token ao mesmo tempo

O erro comum deste passo: mandar o registro inteiro do banco "por garantia". Garantia de quê? De distrator 😛

E não é achismo meu: o próprio fornecedor documenta pro Jev 1.13 que a acurácia cai conforme o state cresce com conteúdo não relacionado à decisão

6. Confira o orçamento de tokens

São dois limites e os dois valem ao mesmo tempo

O state mais todas as questions juntas precisam caber em 64K tokens. E o state mais a única question mais longa precisam caber em 32K tokens

Repara que a lógica aqui é bem diferente das janelas gigantes que a gente vê por aí: quem já brincou com contexto de 1M no GLM-5.3-Flash sabe que sobra espaço, mas no Jev o jogo é de curadoria, não de volume

O erro comum deste passo: só olhar o total de 64K e esquecer do teto de 32K com a maior question. Dá pra estar dentro de um e fora do outro

7. Mande as questions, que rodam em paralelo contra o mesmo state

Essa parte é massa: todas as questions de uma mesma requisição rodam em paralelo contra o mesmo state

E cada question extra custa apenas os próprios tokens

O número de questions não tem contagem fixa: o limite é o orçamento de tokens do request, que state e questions compartilham

{
  "state": {
    "mensagem_do_cliente": "O pedido chegou com a caixa amassada...",
    "politica_de_troca": "Trocas aceitas em até 7 dias corridos..."
  },
  "questions": [ ]
}

Cada item dentro de questions leva as próprias instructions e criteria, que é onde tu escreve a regra e o caso de borda daquele julgamento específico

O erro comum deste passo: disparar cinco requisições separadas com o mesmo state repetido em todas. Tu paga o state cinco vezes por nada

Três formatos de state e quando usar cada um

String solta: conteúdo único e curto

Um comentário, uma descrição de produto, um parágrafo de e-mail

Não tem relação a explicitar, então nome de campo não agrega nada. Manda a string e pronto

Na question tu pode usar um Choice pra categorizar, e uma question do tipo Choice aceita até 255 opções. Dá pra mapear taxonomia inteira sem gambiarra

A resposta de Choice vem com confidence entre 0 e 1, derivado da distribuição de probabilidade

Objeto JSON nomeado: o caso comum

Aqui é onde tu vai morar na maior parte do tempo

Material principal em uma chave, referência em outra, registro de apoio em uma terceira. Tudo com nome que descreve o que é

Na question, um Score funciona bem quando tu quer intensidade em vez de rótulo: também traz confidence de 0 a 1

Array de textos: lotes de trechos comparáveis

Quando tu tem N pedaços do mesmo tipo e a decisão olha pro conjunto

Trechos de uma transcrição, itens de um histórico, bullets de uma proposta

{
  "state": [
    "Entrega prometida para 3 dias úteis",
    "Entrega realizada em 9 dias úteis",
    "Cliente notificado apenas no 7o dia"
  ]
}

Pra esse tipo de checagem binária o Noul cai bem, porque ele retorna a probabilidade de sim

Só fica atento a um detalhe: respostas de Noul não trazem confidence, diferente de Choice e Score

State inflado: sintomas, causa e como cortar

O sintoma

A acurácia começa a cair e tu não consegue apontar o culpado

Com um state grande fica difícil identificar qual parte da entrada gerou a resposta errada. O debug vira caça ao fantasma

A causa

O próprio fornecedor documenta isso pro Jev 1.13: a acurácia cai conforme o state cresce com conteúdo não relacionado à decisão

O detalhe irrelevante age como distrator

É o famoso context rot, e vale pra qualquer janela: mesmo quando o teto é enorme, como acontece com a janela de 1M do Gemini 3.7 Flash, encher a entrada não é sinônimo de acertar mais

A solução

Primeira opção, sempre: recuperar e filtrar em código antes do envio, mandando só os campos de que a pergunta precisa

Quando não dá pra filtrar o state antes, a documentação sugere usar um Noul pra filtrar relevância

Pensa num porteiro barato antes do julgamento caro

Como prevenir

Duas práticas e acabou:

• dar a cada question só o contexto de que ela precisa
• revisar o payload contra o orçamento de tokens antes de disparar

Tome cuidado com o hábito de "depois eu limpo". Não limpa nunca, e o state cresce igual pasta de downloads 😀

Vídeo: contexto sobre ferramentas de IA para quem está começando

Pra começar do zero com o assunto de janelas de contexto em ferramentas de IA, este vídeo do canal mostra uma IA de programar grátis, sem login e com 1 milhão de contexto, o MiMo Code

Checklist de revisão da entrada antes de enviar

Roda isso antes de cada deploy novo, leva um minuto

• O state tem só texto? String, objeto JSON ou array de textos, sem imagem, áudio ou vídeo
• Cada parte tem nome descritivo, em vez de dados e info?
• As partes que a decisão precisa comparar estão juntas no mesmo state?
• As regras de domínio e casos de borda saíram do state e foram pras instructions e criteria da question?
• Cada question recebe o contexto mínimo de que precisa, e nada além?
• O payload cabe em 64K tokens no total e em 32K tokens contando o state mais a maior question?
• O filtro em código já rodou, ou tu tá mandando o registro inteiro por preguiça?
• A chave está em TYPESAFE_API_KEY e o modelo é o que tu espera (jev-latest resolve pra jev-1.13.0)?

Conclusão

A qualidade da decisão tipada depende da curadoria da entrada, não do volume dela

O Jev não gera texto pra tu ler e julgar depois: ele devolve valor tipado com probabilidade calibrada, então tudo que tu colocou de irrelevante no state vira ruído puro dentro da conta

Próximo passo sugerido: monta um state pequeno de teste, roda várias questions em paralelo contra ele e compara o confidence que volta em Choice e Score antes de ampliar o payload

Se o confidence despenca quando tu aumenta o state, tu achou o teu distrator

E lembra que o acesso segue em early access por waitlist, então testa com calma enquanto a fila anda…

até o próximo post!