APRENDER. PRATICAR. EVOLUIR.Uma tabela coerente pode expressar a decisão errada
O laboratório cria uma variante em que R2 passa de REVIEW para AUTO. A tabela continua sem lacunas e sem sobreposições: todas as entradas válidas recebem uma única saída. Porém, o exemplo de negócio estabelecido separadamente exige REVIEW para uma operação confirmada de 150000 cêntimos, mesmo com 120 minutos restantes. A variante falha esse exemplo. Isto distingue verificar a qualidade do modelo de validar a sua adequação à necessidade. Se o teste calcular a resposta esperada a partir da própria regra alterada, os dois podem concordar no mesmo erro. Recolhe exemplos esperados com pessoas autorizadas, inclui condições que desafiem a proposta e guarda a origem do resultado esperado. A opinião de um único utilizador pode ser evidência de elicitação sem ser aprovação suficiente.
Comparar versões sem transformar diferenças em benefícios
A proposta v2 aumenta a janela de revisão de 15 para 20 minutos antes do fecho. Num conjunto fictício de 24 exemplos, três mudam de AUTO para REVIEW: operações confirmadas de 50000 cêntimos com 16, 18 e 20 minutos restantes. Os restantes exemplos mantêm a saída. A comparação identifica decisões para discutir, não prova que v2 é melhor. A organização pode querer reduzir processamento automático perto do fecho, mas a nova revisão pode criar uma fila sem capacidade suficiente. Pergunta qual problema a alteração pretende reduzir, quem recebe o trabalho adicional e que evidência permitirá avaliar o resultado. Os três exemplos não estimam o número de operações afetadas por dia: foram escolhidos para revelar comportamento nos limites e não amostrados de tráfego real.
Distinguir vigência, publicação e data do evento
A fixture usa datas organizacionais e intervalos com início incluído e fim excluído. V1 vigora de 1 a 15 de outubro; v2 começa no dia 15. A consulta de 14 devolve v1 e a de 15 devolve v2. Duas versões válidas no mesmo dia produzem uma ambiguidade que o script rejeita. Em produção seria necessário esclarecer muito mais: fuso horário, evento que determina a versão, regras para pedidos recebidos antes da mudança e reprocessados depois, e compatibilidade entre aplicações. Instalar código novo não decide automaticamente a política aplicável a um evento antigo. O analista deve tornar essas escolhas explícitas e relacionar regra, aprovação, data de vigência, implementação e testes. O laboratório não modela relógios distribuídos nem replay real.
Preparar operação e observar o resultado certo
Um painel mostra que 99% das decisões produziram uma saída, mas omite entradas rejeitadas por falta de reconciliação. Antes de aceitar esse indicador, define denominador, exclusões e tratamento de exceções. Para a mudança v2, acompanha a quantidade encaminhada para revisão, a idade da fila, o cumprimento do fecho e erros de encaminhamento confirmados. A definição deve distinguir uma alteração desejada de política de uma falha do motor. Guarda versão e dados necessários à explicação da decisão com os controlos de acesso e conservação acordados; não recolhas campos sensíveis sem necessidade. APS precisa de saber quem atua quando não há regra, quando os dados estão incompletos e quando a fila não pode ser tratada a tempo. Um estado técnico resolvido não demonstra conclusão do processo de negócio.
Organizar a revisão e conservar os limites da evidência
Prepara um pacote de decisão com a necessidade, as condições alteradas, exemplos que mudam e que não mudam, resultados esperados confirmados, impacto operacional e autoridade de aprovação. Os testes estruturais e as duas execuções do laboratório apoiam a revisão técnica; não substituem validação com stakeholders nem autorização de produção. Se surgir um novo estado de reconciliação, revê domínio, regras, interfaces, métricas e exemplos, em vez de o mapear silenciosamente para confirmed. Conserva a baseline anterior para explicar decisões históricas e distingue correção de erro de mudança intencional de política. No final, a conclusão deve dizer o que foi demonstrado, em que versão, para que domínio de entradas e que decisões humanas ainda faltam.
python3 content/labs/cbap-decision-rules/run.py --output /tmp/cbap-rules.json
# Inspect gapWitness, conflictWitness and changedExamples.V2 muda 3 de 24 exemplos. Uma variante errada de R2 passa os testes estruturais, mas falha o resultado esperado REVIEW para 150000 cêntimos.
Armadilhas comuns
Derivar o resultado esperado da mesma regra em teste; tratar diferenças sintéticas como frequência real; confundir data de instalação com vigência; esconder rejeições do denominador.
Tópicos relacionados: Arquitetura de requisitos · Validação e aceitação · Ciclo de vida das regras
Verificação prova propriedades delimitadas do modelo; validação liga a regra à necessidade, aos exemplos e às consequências do trabalho.
Referência: CBAP competencies · CBAP six-knowledge-area blueprint, May 2026 handbook