O Que É Uma Proposição

Proposição na prática: o que realmente é e como você lida com ela todo dia

Você provavelmente já trabalhou com proposições sem perceber que estava fazendo isso. Um formulário que bloqueia o envio se um campo obrigatório estiver vazio. Uma regra de aprovação que exige dois gestores para liberar um orçamento acima de determinado valor. Um fluxo de atendimento que decide automaticamente qual fila o cliente entra com base no tipo de solicitação. Tudo isso é proposição sendo usada no dia a dia, e a definição técnica que a maioria das pessoas aprende é muito mais fria do que isso. O que é uma proposição, em termos que não vêm de livro didático, é uma declaração sobre a qual um sistema pode decidir se é verdadeira ou falsa e, a partir dessa decisão, tomar uma ação. A parte mais importante não é a definição, é o que acontece depois da decisão. Sem uma ação vinculada à resposta da proposição, ela é só uma afirmação sem utilidade. A ação é o que transforma a lógica em algo que impacta resultados.

No meu trabalho com sistemas de automação e governança, eu construí uma camada inteira de regras que funcionava assim: cada solicitação passava por uma série de proposições encadeadas antes de chegar a alguém para aprovação manual. O problema que eu encontrei e que quase destruiu o projeto foi com proposições compostas — aquelas que combinam várias condições usando E e OU. A equipe de negócio escreveu regras como "se o cliente for premium E o valor for maior que 5 mil OU a urgência for alta". A ambiguidade no uso de E e OU era constante. O mesmo texto era interpretado de formas diferentes por desenvolvedores e analistas. A solução foi forçar a notação binária com parênteses explícitos em toda regra composta e nunca aceitar uma proposição sem parênteses no documento de especificação. Eu criei um validador simples que rejeitava qualquer regra sem parênteses corretos antes dela sequer entrar em produção. Isso reduziu erros em campo em cerca de 80% no primeiro trimestre após a implementação. Aqui está algo que poucos mencionam: proposições não são sinônimo de regras de negócio. Proposição é o bloco lógico mínimo. Regra de negócio é o conjunto de proposições organizadas para produzir um comportamento. Você pode ter uma regra complexa feita de cinquenta proposições encadeadas, e a maioria dos erros que eu vi acontecer em sistemas operacionais não veio da lógica em si, mas da forma como as proposições eram escritas e revisadas. A qualidade da proposição individual importa menos do que a qualidade da cadeia delas.

Outro detalhe que as pessoas frequentemente ignoram é a diferença entre proposição atômica e proposição derivada. Atômica é aquela que não se decompõe — algo como "o status é igual a aprovado". Derivada é uma combinação que o sistema calcula a partir de outras proposições. Sistemas mais avançados, como os baseados em engines de decisão Drools ou até soluções mais modernas com PMML, usam derivadas para evitar repetição. Se você tem cinco regras que precisam todas saber se "o cliente é de alto risco", não repita a verificação nas cinco regras. Crie uma proposição derivada chamada "cliente_risco_alto" e referencie ela. Isso economiza tempo de execução, facilita manutenção e reduz drasticamente a chance de inconsistência quando uma condição muda. Um ponto onde proposições falham completamente e você precisa entender isso antes de implementar é quando o domínio é inerentemente vago. Vou dar um exemplo prático. Eu trabalhei em um projeto onde a proposição central era "o risco do empréstimo é aceitável". A equipe queria automatizar a aprovação baseada nessa proposição. O problema era que "aceitável" não tem limite binário claro. Score de crédito, renda, divida existente, histórico de inadimplência — todos esses fatores influenciam, mas nenhum deles transforma a proposição em verdadeira ou falsa de forma direta. A proposição simplesmente não era decidable dentro do modelo proposto. A solução não foi melhorar a lógica, foi reformular a proposição em faixas probabilísticas com limiares definidos por política. O sistema passou a calcular "probabilidade de calote" e comparou com um limiar, em vez de tentar decidir uma proposição que nunca poderia ser precisa.

Se você está começando a lidar com proposições agora, o erro mais comum é escrever proposições que dependem de dados que ainda não existem no momento da avaliação. Isso acontece muito em pipelines onde a proposição é avaliada em tempo real, mas a informação necessária só chega segundos depois em outro serviço. Você pode ter uma proposição perfeita logicamente, mas ela sempre vai retornar false porque o dado ainda não carregou. A correção é mapear a linha do tempo de disponibilidade de cada atributo antes de escrever qualquer proposição que dependa dele.

Como estruturar uma proposição que funciona em produção

A abordagem que eu recomendo, baseada no que funcionou e no que quebrou ao longo dos anos, é começar pela decisão. Antes de escrever qualquer condição, defina claramente o que significa verdadeiro e o que significa falso. Depois, identifique quais dados de entrada são necessários para chegar a essa resposta. Em seguida, escreva a proposição usando nomes de variáveis e operadores conhecidos, sem ambiguidade linguística. Finalmente, teste com pelo menos três casos extremos: um onde todos os dados estão no limite perfeito, um onde todos estão no limite ruim e um onde há dados ausentes. Aqui está um exemplo concreto. Suponha que você precise decidir se uma fatura será processada automaticamente. A proposição inicial seria algo como "a fatura é válida para processamento automático". Os dados necessários seriam valor da fatura, situação cadastral do fornecedor, existência de divergência no pedido de compra e prazo dentro da política de pagamento. A versão implementada ficou assim: valorentre_100_e_50000 AND situacao_cadastral EQUALS ATIVA AND divergencia_pedido EQUALS NENHUMA AND prazo_atendido EQUALS TRUE. Quando qualquer uma dessas subproposições retornasse falso, a fatura ia para fila de revisão manual. Simples, mas funciona porque cada parte é testável individualmente.

Preciso ser honesto sobre as limitações. Proposições, especialmente em sistemas grandes, tornam-se difíceis de auditar quando o número de condições excede aproximadamente doze. A partir desse ponto, a taxa de erro humano na revisão aumenta significativamente. Não existe fórmula mágica para resolver isso além de dividir o problema em camadas menores e criar proposições derivadas que resumo cada camada. Outra limitação séria é que proposições não lidam bem com contextos que mudam dinamicamente sem reinicialização. Se um dado pode ser atualizado concorrentemente enquanto uma proposição está sendo avaliada, o resultado pode ser inconsistente dependendo da ordem de leitura. Isso exige sincronização ou versionamento dos dados, o que adiciona complexidade operacional. O que eu vejo mais acontecer é gente tentando usar proposições para resolver problemas que não têm natureza binária. Classificação por score contínuo, previsões estatísticas, julgamento qualitativo — essas coisas não são proposições. Elas podem alimentar proposições, mas não são proposições por si sós. Confundir isso é a principal razão pela qual projetos de automação falham nos primeiros meses. A proposição é uma ferramenta poderosa quando o domínio é claro. Quando o domínio é nebuloso, a proposição é umaarmadilha.

Erros comuns que eu vejo em quem nunca trabalhou com proposições reais

O primeiro erro é esquecer que proposições são avaliadas na ordem em que são escritas. Em many engines, a ordem importa para performance e para short-circuit evaluation. Se você coloca uma condição cara e rara primeiro, o sistema pode estar gastando recursos desnecessários antes de encontrar uma condição que já poderia ter decidido o resultado. A otimização básica é colocar condições baratas e frequentes na frente.

O segundo erro é tratar proposições como documentação estática. Elas evoluem. Condiciones que faziam sentido hoje podem não fazer daqui seis meses. Eu mantive um repositório de proposições ativas com data de criação, última revisão e responsável. Proposições sem revisão há mais de doze meses eram flagradas automaticamente. Isso parece bobo, mas na prática evita que regras obsoletas continuem afetando decisões reais por anos. O terceiro erro, e talvez o mais grave, é não ter um ambiente de staging para testar proposições antes de ir para produção. Eu vi uma regra que deveria bloquear pagamentos para fornecedores com pendência judicial ser ativada diretamente em homologação porque ninguém testou o caso de um fornecedor com pendência parcial. A proposição estava escrita de forma que pendência parcial também era considerada pendência total. O resultado foram bloqueios errados e reclamações de fornecedores que estavam em dia. A correção levou duas semanas e custou crédito operacional.

Aprendi no final que a habilidade mais importante ao trabalhar com proposições não é saber lógica booleana avançada. É saber quando NÃO usar proposição. Problemas fuzzy, problemas multiobjetivo, problemas que dependem de contexto subjetivo — esses pedem outra abordagem. Proposição é excelente para classificação binária clara com dados disponíveis no momento da decisão. Fora disso, ela é apenas um padrão que parece certo até dar problema. Se você quer se aprofundar, a literatura técnica sobre engines de regras como Drools, IBM ODM ou até mesmo a especificação PMML é o caminho. Mas o conhecimento prático vem da experiência de ver proposições falharem em produção e aprender a evitar os mesmos erros. Nada substitui ter visto uma regra boa causar um dano real e ter que consertar isso com stakeholders exigentes e pressão operacional.