> ## Documentation Index > Fetch the complete documentation index at: https://docs.flunora.com/llms.txt > Use this file to discover all available pages before exploring further. # Playbook versionado > As regras de julgamento comercial que a plataforma aplica, como elas mudam e o que precisa passar antes de uma versão entrar em produção. O modelo de linguagem que a Flunora usa é de fronteira, mas o julgamento não é dele. O que decide o que conta como critério de decisão, o que conta como objeção respondida e quando um negócio está qualificado é um **playbook de vendas versionado**, escrito por gente, com regras identificadas uma a uma. ## Como o playbook é escrito O playbook é um conjunto de módulos de regras. Cada regra tem um identificador estável, uma condição de aplicação e um texto normativo. Elas vão para o contexto do modelo em blocos, e o bloco que entra depende do perfil da sua organização. Regra com identificador não é burocracia. É o que permite dizer, meses depois, que um campo foi produzido por uma regra específica, e reabrir a discussão sobre aquela regra sem reabrir a discussão sobre o produto inteiro. ## Modo de operação por perfil Três perguntas sobre a sua operação decidem quais regras se aplicam: o tamanho do cliente típico, quanto tempo dura um ciclo de venda e quantas pessoas participam da decisão do outro lado. As respostas derivam um modo, `pme`, `mid` ou `enterprise`, e o modo escolhe o conjunto de regras. Uma venda de duas semanas para um dono de empresa não é julgada com as regras de um comitê de compras de seis meses, e forçar uma sobre a outra produz análise que soa sofisticada e não descreve nada. As três perguntas ficam em Configurações e podem ser mudadas a qualquer momento. ## O que acontece antes de uma versão entrar no ar Nunca no prompt direto. Ajustar a instrução do modelo para consertar um caso é como consertar um teste mudando o teste: funciona uma vez e some no histórico. A versão do playbook e a versão do prompt passam a viajar na proveniência de todo campo produzido dali em diante. Qualquer registro do CRM diz que regras o produziram. Um conjunto de calls sintéticas com resultado esperado escrito à mão. A análise real roda contra cada uma e o resultado é comparado com o esperado. Casos marcados como obrigatórios que falham bloqueiam a subida. Quando o resultado fica na fronteira entre duas leituras defensáveis, o caso vai para decisão humana registrada, e não para um ajuste no texto do prompt até o caso passar. Ajustar até passar é como um modelo aprende a acertar o teste e errar a realidade. ## O que isso te dá A mesma evidência produz o mesmo resultado. Duas reuniões parecidas não recebem leituras opostas porque o modelo acordou diferente. Um campo estranho na ficha de um contato é rastreável até a reunião, a fala e a regra. A pergunta "de onde saiu isso" tem resposta. Uma versão nova não pode piorar em silêncio o que já funcionava, porque a suíte roda antes e o caso obrigatório reprovado impede a subida. O que você corrigiu na ficha continua valendo depois da nova versão. Veja [Decisão humana](/evidencia/decisao-humana). ## O que o playbook não faz Ele não substitui o seu processo comercial e não obriga o seu time a vender de outro jeito. As etapas do funil continuam sendo as suas, com os nomes que vocês usam, e o playbook opera sobre elas. O que ele padroniza é a leitura da evidência, não a operação.