Você já enviou suas fontes e o job está em andamento. O ID do engine veio no 202, e a configuração dele está sendo preenchida. Esta página responde à pergunta que define se você vai confiar no resultado: o que, exatamente, está sendo preenchido?
"Uma IA configurou meu engine" é o tipo de frase que deixa qualquer engenheiro com um pé atrás — e esse instinto está certo. Isso pode significar uma caixa-preta impossível de inspecionar. Pode significar registros espalhados por idiomas sem que você saiba explicar onde estão. Pode significar que o agente leu uma fonte superficial, não encontrou quase nada e criou quase nada sem alarde. Por isso, esta página é objetiva nos três pontos: o agente produz três tipos de configuração, cada um é mapeado para seus idiomas por uma regra previsível, e o job devolve um resumo que identifica cada registro criado. O resultado são registros comuns que você pode ler e editar — não um veredito que você precisa aceitar no escuro.
Está começando agora em provisioning assíncrono? Comece pela Visão geral da API de Provisioning Assíncrono para entender o modelo mental e veja Tipos de fonte para saber o que faz uma fonte valer a pena. Esta página trata do que sai do outro lado.
Nesta página
- Os três componentes
- Como cada um é mapeado para um idioma
- O resumo da saída
- Como ler um resumo enxuto
- Próximos passos
Os três componentes#
O agente lê tudo — tanto páginas rastreadas quanto conteúdo bruto — e cria três tipos de configuração do engine. Não é um formato novo, exclusivo do provisioning. São exatamente os mesmos primitivos que você criaria manualmente em um engine, por isso tudo o que o agente gera pode ser editado depois no dashboard, da mesma forma que você editaria qualquer coisa criada por conta própria.
| Componente | O que ele procura | Exemplo |
|---|---|---|
| Voz da marca | Tom, estilo, nível de formalidade, convenções de escrita | "Use alemão formal (forma Sie). Mantenha as frases concisas e diretas." |
| Itens de glossário | Nomes de produtos, termos técnicos, traduções específicas da marca, termos não traduzíveis | "Acme" → não traduzível, "workspace" → "Arbeitsbereich" (de) |
| Instruções | Regras de formatação, convenções culturais, diretrizes específicas do domínio | "Sempre formate datas como DD.MM.AAAA nas traduções para o alemão." |
Esses são os três elementos que fazem uma tradução soar como o seu produto, e não como uma versão genérica — a formalidade que você escolheu, os nomes que nunca traduz, o formato de data que sempre usa. O papel do agente é encontrar essas decisões onde quer que estejam declaradas nas suas fontes e registrá-las.
Vale deixar uma consequência bem clara, porque ela define o teto do que você deve esperar receber: o agente extrai o que está declarado, não o que está implícito. Uma fonte que explicita uma regra gera um registro; uma fonte que apenas demonstra um bom tom sem nomear a regra gera pouco. Isso é uma característica das fontes, não do engine — Tipos de fonte mostra como escolher fontes que deixem suas regras explícitas.
Como cada um é mapeado para um idioma#
A configuração de um engine de localização é indexada por idioma de destino, então um registro não diz só qual é a regra — diz também onde ela se aplica. O agente atribui um idioma a cada registro seguindo uma regra previsível, e o curinga * é a parte que vale entender antes de olhar a saída.
- Voz da marca e instruções usam
*quando se aplicam a todos os idiomas. Uma regra de tom como "mantenha as frases concisas e diretas" não é específica do alemão; é a forma como seu produto escreve em qualquer idioma. O agente atribui a ela o idioma de destino*, e ela passa a valer para todos os idiomas para os quais o engine traduz. Já uma regra que realmente seja específica de um idioma ("use a forma Sie em alemão") é atribuída àquele idioma. - Itens de glossário são criados por par de idiomas, porque uma tradução sempre acontece de um idioma para outro específico — "workspace" → "Arbeitsbereich" é um fato sobre o alemão, e só sobre o alemão.
- Termos não traduzíveis são a exceção e usam
*. Um nome de marca que você nunca traduz — "Acme" — é não traduzível em todos os idiomas, então ele é armazenado uma vez em*, em vez de ser recriado para cada par de idiomas.
Por isso, quando você vê * em um registro criado pelo job, isso não é um placeholder nem uma lacuna. Significa "isso vale em todos os lugares" — uma regra global de tom, uma instrução global ou um termo que nunca é traduzido em nenhum idioma. Já um código de idioma específico significa o oposto: essa regra vale apenas para aquele idioma.
Por que o curinga é um recurso, e não um padrão para substituir
Uma leitura cética de * seria: "o agente nem se deu ao trabalho de descobrir a qual idioma isso pertence". É exatamente o contrário. Uma voz da marca ou um termo não traduzível que está correto em todos os idiomas deve ser global — vinculá-lo a um único idioma faria com que ele deixasse de se aplicar silenciosamente aos demais. O curinga é a forma de a configuração dizer "isso é verdadeiro independentemente do idioma", que é exatamente o que uma regra de tom ou um nome de marca normalmente representa.
O resumo da saída#
Quando o job termina, ele retorna um resumo que identifica tudo o que o agente criou. Esse é o comprovante: cada registro, contabilizado e identificado, além de uma lista com tudo o que falhou.
{
"brandVoices": {
"count": 3,
"ids": ["bv_A1b2C3d4", "bv_B2c3D4e5", "bv_C3d4E5f6"]
},
"glossaryItems": {
"count": 12,
"ids": ["gi_A1b2C3d4", "gi_B2c3D4e5", "..."]
},
"instructions": {
"count": 5,
"ids": ["ins_A1b2C3d4", "ins_B2c3D4e5", "..."]
},
"errors": []
}Cada componente informa um count e os ids dos registros criados — bv_ para voz da marca, gi_ para itens de glossário, ins_ para instruções. Não são confirmações opacas; são os IDs de registros reais no engine. Você pode pegar qualquer gi_ dessa lista, abri-lo no dashboard e ler ou alterar exatamente o que o agente extraiu. É assim que o resumo transforma "a IA fez alguma coisa" em "aqui estão as vinte coisas específicas que ela fez" — toda a diferença entre uma caixa-preta e registros comuns que você pode ler e editar.
O resumo chega pelo canal que você configurou ao criar o job: na payload do webhook que sua URL de callback recebe na conclusão, onde ele vem no campo summary. Se você estiver acompanhando o job via WebSocket, ali o que existe é um feed de atividade — ele transmite o progresso do rastreamento e da configuração, não esse objeto de resumo. O resumo vem no webhook de conclusão; o WebSocket te avisa quando é hora de ir lê-lo.
Um item com falha não faz o job falhar.
Se um único registro não puder ser criado, isso não derruba o restante. A falha é registrada no array errors, os registros que deram certo continuam sendo aplicados ao engine, e o job ainda é concluído. Você recebe um engine parcialmente configurado junto com uma lista precisa do que precisa revisitar — não um engine vazio e um stack trace. O job falha como um todo quando a execução não produz nada com que trabalhar — por exemplo, se todas as fontes falharem no rastreamento; esse caso de falha, e sua payload provisioning.failed, está em Entrega de webhook.
Como ler um resumo enxuto#
O resumo mostra não só o que foi criado, mas também, pelos seus totais, se a execução valeu a pena. Um count de 0 para um componente não é um erro — o resumo está bem formado e o engine existe — mas é um sinal importante. Três vozes da marca e doze itens de glossário indicam um engine configurado. Zero em tudo e um array errors vazio indicam um engine que voltou quase em branco, e o agente está mostrando que encontrou poucas regras para extrair.
Quando isso acontece, a causa quase sempre está na origem: as fontes declararam poucas regras concretas para o agente aproveitar. O resumo é onde você percebe isso; Tipos de fonte é onde você corrige. A expectativa mais honesta para levar para a primeira execução é esta: o comprovante só reflete o que suas fontes realmente disseram — um resumo rico significa fontes ricas, e um resumo enxuto significa que havia pouco a encontrar.
É por isso que o resumo importa tanto quanto o engine: ele permite verificar a configuração em vez de simplesmente presumir que está certa. Leia os totais, abra alguns registros pelos IDs e confirme se o agente captou o que você esperava — registros comuns que você pode ler e editar, com um comprovante que mostra exatamente o que conferir.
