Como usar o Jev para checar se um texto de marketing segue o guia da marca antes de publicar?

fluxo do Jev checando um texto de marketing contra o guia de marca
Resposta rápida

O Jev é o modelo de decisão tipada da TypeSafe AI: em vez de gerar prosa, ele devolve Choice, Score e Noul com probabilidades calibradas que o seu código consome direto. Dá pra usar isso como checagem de marca: você quebra o guia em perguntas fechadas, manda o texto no campo state, pede uma nota de aderência ao tom (Score), um sim/não pra promessa proibida (Noul) e um veredito publicar/ajustar/revisão (Choice). Depois lê confidence e decide o que vai automático e o que sobe pra revisão humana, calibrando o threshold com material real da marca 🙂

Fala aí, beleza? Todo time de conteúdo já viveu isso: o texto sai bonito, o tom tá levemente errado, e no meio do CTA aparece uma promessa que o jurídico nunca aprovaria

Aí a revisão vira gargalo, porque revisar tom de voz na mão não escala quando são dez peças por dia

O Jev é o primeiro System One Model da TypeSafe AI e foi feito exatamente pra esse tipo de ponto de decisão: ele não escreve texto, ele devolve decisão tipada com probabilidade calibrada que o código consome direto

São três primitivas de pergunta: Choice (escolhe uma opção do conjunto), Score (nota numa escala ordenada) e Noul (sim/não com probabilidade de verdadeiro)

Neste post eu mostro COMO transformar o guia da marca em perguntas objetivas e rodar essa checagem antes de publicar

O que você precisa antes de começar

Primeiro, acesso ao modelo. O acesso direto ao Jev ainda está em early access por lista de espera em typesafe.ai, sem data de disponibilidade geral anunciada

Mas existem outras portas de entrada:

Rota Como aparece Detalhe
Acesso direto TypeSafe API System One early access por waitlist
Vercel AI Gateway experimental_evaluate do AI SDK os tipos de pergunta expostos em TypeScript, e o sim/não aparece como boolean no AI SDK (na TypeSafe é noul)
OpenRouter typesafe/jev-1.13 listado como modelo

Para rodar local, tem SDK Python oficial:

pip install typesafe-sdk

Ele pede Python 3.10 ou superior, lê a variável de ambiente TYPESAFE_API_KEY e chama jev-latest por padrão

Usa Claude Code no dia a dia? A TypeSafe mantém um agent skill oficial no repositório typesafe-ai/skills, que instala como plugin:

claude plugin marketplace add typesafe-ai/skills
claude plugin install typesafe@typesafe-ai

E aí você invoca com /typesafe:typesafe-ai

E o requisito não técnico (o mais importante):

O guia da marca ESCRITO, com exemplo concreto do que pode e do que não pode

Se o guia só diz "tom próximo e profissional", não dá pra virar pergunta. Se ele diz "nada de garantir resultado em prazo" e mostra duas frases proibidas, aí sim vira checagem

Sobre dimensionar o que você envia: o Jev 1.13 aparece no OpenRouter com janela de contexto de 32.000 tokens, e o preço publicado é de US$ 0,042 por 1 milhão de tokens de entrada, com tokens de saída não cobrados

Ou seja: texto de marketing é barato de checar, mas guia gigante colado inteiro em toda chamada não cabe no contexto

Passo a passo: do guia da marca ao checklist automático

A ideia central é simples: cada regra do guia vira uma Question, e o conjunto de respostas vira a decisão de publicar

Bora ver na prática?

  1. Quebrar o guia em perguntas fechadas. Pega o documento e transforma cada regra em algo que se responde com uma opção, uma nota ou um sim/não. Se a regra não cabe em nenhum desses três formatos, ela ainda não é uma pergunta, é um desejo. O erro comum deste passo é criar a pergunta "o texto está bom?", que não tem critério nenhum por trás
  1. Montar o campo state com o texto a avaliar. O state aceita string, objeto JSON ou array de textos, e isso é ótimo aqui: dá pra mandar título, corpo e CTA separados em vez de um blocão só. O erro comum deste passo é jogar o guia da marca dentro do state. O state é o conteúdo avaliado; o guia entra como contexto na instructions da pergunta, que também aceita string, objeto ou array pra você quebrar uma instrução longa em estrutura com dados de referência
  1. Escrever a aderência ao tom como Score. No tipo Score, criteria é um array ordenado de descrições de nível, do extremo mais baixo pro mais alto. A documentação orienta descrever situações concretas em vez de graus, e é aí que quase todo mundo escorrega. Um Score precisa de no mínimo 2 níveis e a API aceita até 10
{
  "type": "score",
  "instructions": "Avalie o quanto o texto segue o guia de tom de voz da marca: primeira pessoa do plural, frases curtas, zero jargão corporativo, nenhum superlativo de venda.",
  "criteria": [
    "O texto usa jargao corporativo em varias frases e promete resultado com superlativo",
    "O texto mistura frases longas e corporativas com trechos no tom da marca",
    "O texto esta no tom da marca, com no maximo um deslize pontual de vocabulario",
    "O texto segue o guia inteiro: primeira pessoa do plural, frases curtas, sem jargao e sem superlativo"
  ]
}

Repara que nenhum nível diz "ruim", "médio" ou "bom". Cada um descreve uma cena que a pessoa consegue reconhecer no texto

  1. Escrever as promessas proibidas como Noul. O Noul é a pergunta booleana, com criteria definindo o que significa verdadeiro e o que significa falso. Uma pergunta por tipo de promessa, sempre
{
  "type": "noul",
  "instructions": "O texto faz alguma promessa de resultado garantido, prazo garantido ou devolucao de dinheiro?",
  "criteria": {
    "true": "O texto afirma ou sugere resultado garantido, prazo garantido ou reembolso",
    "false": "O texto fala de beneficio sem garantir resultado, prazo ou reembolso"
  }
}

O erro comum deste passo é escrever "o texto tem promessa exagerada?" e deixar o modelo adivinhar o que é exagero na sua marca

  1. Declarar o veredito como Choice. Aqui é o campo que o seu código vai ler pra decidir o destino da peça: publicar, ajustar ou mandar pra revisão. Como as respostas possíveis são definidas de antemão pelo schema, o modelo não retorna valor fora do conjunto que você forneceu, e isso é justamente a graça de um modelo de decisão tipada. Como toda Question, ela leva type e instructions, e o detalhe de cada tipo tá na documentação das primitivas
  1. Nomear as chaves do mapa questions pensando no código. questions é um mapa de objetos Question com chaves definidas por você, e a resposta volta sob a mesma chave. Detalhe importante: a chave não é enviada ao modelo e não é usada na inferência, então ela existe pro seu código, não pro Jev. Ou seja, tom_de_voz e promessa_garantia são ótimos nomes; toda a semântica precisa estar dentro de instructions e criteria. O erro comum deste passo é tentar "explicar" a regra no nome da chave e deixar a instructions pobre
  1. Fazer a chamada. O endpoint da API System One é POST https://api.typesafe.ai/v1/systemone e o corpo exige os campos model, state e questions
curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "jev-latest",
    "state": {
      "titulo": "Seu time entrega mais rapido a partir de segunda",
      "corpo": "Nos montamos o fluxo com voce e acompanhamos as duas primeiras semanas.",
      "cta": "Garanta seu resultado em 7 dias"
    },
    "questions": {
      "tom_de_voz": { "type": "score", "instructions": "...", "criteria": ["..."] },
      "promessa_garantia": { "type": "noul", "instructions": "...", "criteria": { "true": "...", "false": "..." } }
    }
  }'

O Jev avalia todas as perguntas declaradas em paralelo e devolve as respostas tipadas com as probabilidades, então não precisa fazer uma chamada por regra do guia

Prefere Python? Instala o typesafe-sdk, exporta a TYPESAFE_API_KEY e segue o quickstart oficial, que traz a chamada do cliente já apontando pro jev-latest

  1. Ler probabilities e confidence e transformar isso em decisão. Respostas de Choice e Score incluem probabilities, com a distribuição entre as opções ou níveis. O confidence é um número de 0 a 1 calculado a partir de como essa probabilidade está distribuída: pico único significa alta confiança, distribuição espalhada significa baixa confiança. A documentação usa confidence justamente pra decidir entre agir e escalar, e o exemplo dela é bem direto: confidence abaixo de 0.8 vai pra revisão humana
if resposta["promessa_garantia"]["confidence"] < 0.8:
    destino = "revisao_humana"
elif resposta["promessa_garantia"]["value"]:
    destino = "ajustar"
else:
    destino = "publicar"

E o threshold não é sagrado: a orientação é escolher pelo custo do erro. 0.5 quando agir com sim ou não custa o mesmo, mais alto quando um falso positivo é caro, mais baixo quando deixar passar um caso verdadeiro é caro

No caso de promessa proibida, deixar passar costuma doer MUITO mais que segurar um texto bom, então o threshold desce

Erros comuns ao traduzir o guia da marca em perguntas

Sintoma: a nota de tom fica pulando e a confiança sempre baixa

Causa: os criteria do Score descrevem graus em vez de situações. "Tom ruim", "tom mediano" e "tom ótimo" não dão ao modelo nenhuma âncora, então a probabilidade espalha entre os níveis vizinhos e o confidence despenca

Solução: reescrever cada nível como uma cena concreta, do extremo baixo ao alto, igual no exemplo do passo 3

Como prevenir: leia os níveis em voz alta pra alguém do time. Se a pessoa não consegue apontar qual nível é o texto sem perguntar nada, o critério ainda tá abstrato

Sintoma: o Noul responde "não" num texto que claramente viola o guia

Causa: regra composta numa pergunta só. "O texto está no tom certo e sem promessa exagerada?" carrega duas decisões, e a resposta acaba refletindo uma delas

Solução: quebrar em duas Questions com chaves separadas. Como tudo roda em paralelo na mesma chamada, não custa uma ida a mais

Como prevenir: proibir a palavra "e" no enunciado da pergunta. Já me salvou de várias

Sintoma: metade das peças caindo em revisão humana, e nenhuma delas era problema real

Causa: threshold copiado da documentação sem calibrar. O 0.8 é exemplo, não verdade absoluta pra sua marca

Solução: plotar confiança contra acurácia nos seus próprios dados, que é exatamente o que a TypeSafe orienta fazer, e escolher o corte olhando o gráfico

Como prevenir: guardar o histórico de probabilities e confidence de cada peça desde o primeiro dia, pra ter base de comparação quando for ajustar

Sintoma: erro ao enviar o material completo

Causa: texto e contexto passando dos 32.000 tokens de janela do Jev 1.13

Solução: mandar o material quebrado em array de textos no state, ou avaliar peça por peça. Guia inteiro dentro de toda chamada é desperdício: coloque na instructions só o recorte que aquela pergunta precisa

Como prevenir: tratar cada Question como autônoma, com o contexto mínimo dela

Outras checagens que cabem na mesma chamada

Montou o schema? Ele vira base pra um monte de variação

  • Classificar canal ou persona com Choice. Mesma peça, uma pergunta a mais: esse texto é de email, anúncio ou blog? Serve pra rotear a revisão pro time certo
  • Sinalizar claim sem prova com Noul. "O texto cita número, percentual ou comparação sem fonte declarada?" Pergunta simples, salva o jurídico
  • Ranquear variações de headline com Score. Manda as três opções e compara as notas com probabilities na mão. É a mesma mecânica de pontuação usada pra qualificar e priorizar leads no funil, só que aplicada a texto
  • Usar o conjunto como guardrail no fluxo automatizado. Se a publicação é disparada por automação, o Jev entra como portão antes do publish, do mesmo jeito que a checagem que barra jailbreak antes do LLM responder entra antes da resposta

Não é coincidência: a TypeSafe posiciona o Jev justamente pra pontos de decisão em software, tipo classificação, roteamento, verificação, ranking e guardrails, onde uma resposta tipada previsível vale mais que texto gerado

Próximo passo

O ganho aqui não vem de prompt esperto, vem de duas coisas chatas e concretas: criteria descrevendo situação real em vez de grau, e threshold calibrado com material da sua marca

Então o próximo passo é bem direto

Pega dez textos que o time já aprovou e dez que já reprovou

Roda o mesmo schema nos vinte

Compara o confidence e o veredito com o julgamento humano que já existe

Se bater, aí sim você liga a checagem no fluxo de publicação. Se não bater, o problema quase sempre tá nos critérios, não no modelo 😀

E lembra do acesso: direto ainda é early access por waitlist, e as rotas alternativas hoje são o Vercel AI Gateway com experimental_evaluate e o OpenRouter com typesafe/jev-1.13

Até o próximo post!

Perguntas frequentes

Dá pra usar o Jev sem entrar na lista de espera da TypeSafe?

Dá sim. O acesso direto pela API System One tá em early access por waitlist em typesafe.ai, mas o Jev também aparece no Vercel AI Gateway via experimental_evaluate do AI SDK e no OpenRouter como typesafe/jev-1.13.

Quanto custa checar um texto de marketing inteiro no Jev?

O preço publicado é de US$ 0,042 por 1 milhão de tokens de entrada, e tokens de saída não são cobrados. Pra uma peça de marketing normal, o custo fica bem baixo.

Qual o tamanho máximo do guia de marca que cabe numa chamada do Jev?

O Jev 1.13 aparece no OpenRouter com janela de contexto de 32.000 tokens. Por isso o guia inteiro não entra em instructions: o ideal é resumir a regra e colocar o texto avaliado em state.

O Jev avalia tom de voz, promessa proibida e veredito final numa chamada só?

Sim. O Jev roda todas as perguntas declaradas no mapa questions em paralelo e devolve cada resposta tipada com as probabilidades na mesma chamada.

Como usar o Jev direto no Claude Code pra checar peças de marketing?

A TypeSafe mantém um agent skill oficial no repositório typesafe-ai/skills. No Claude Code ele se instala como plugin com claude plugin marketplace add typesafe-ai/skills e claude plugin install typesafe@typesafe-ai, e depois invoca com /typesafe:typesafe-ai.

Que nível de confiança usar pra decidir entre publicar direto ou mandar pra revisão humana?

A documentação da TypeSafe usa como exemplo confidence abaixo de 0.8 indo pra revisão humana, mas orienta escolher o threshold pelo custo do erro: mais alto quando falso positivo é caro, mais baixo quando deixar passar um caso verdadeiro é caro. O ideal é calibrar isso testando com os seus próprios dados.



Escrito por | Matheus Battisti

Matheus Battisti
Fundador da Hora de Codar

Programador apaixonado pelo mundo das tecnologias, sempre buscando em aprender e se aprofundar em linguagens, frameworks e o que mais for necessário para executar um bom trabalho. Agora tem uma nova missão que é de passar seu conhecimento adiante para formar novos programadores e especializar mais os que já são.

Subscribe
Notify of
guest

0 Comentários
Oldest
Newest Most Voted

Formações

Formação Claude Code

Formação Claude Code

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

  • 120 aulas
  • 4 projetos
  • 9h 48min

Blog | Mais populares