Nesta página
Propriedade de arquitetura
O COADF P-8, tal como publicado: as regras contra as quais uma decisão é medida são dados, o motor que as avalia não muda quando uma regra muda, e um registro de decisão fica preso à versão do conjunto de regras que o produziu, o que estende o rastro do P-4 até a procedência das regras. O próprio COADF nomeia o estado da técnica: conjuntos de regras recarregáveis, com registros de decisão ligados à sua versão, já existem, e o Open Policy Agent é o exemplo evidente.
O COADF reserva parte do P-8, e diz isso em sua página de princípios. Nada nesta página descreve essa parte. Os exemplos usam um assunto deliberadamente genérico: quais funcionalidades um ambiente de deploy pode habilitar.
Por que importa
As regras mudam com mais frequência que o código, e por razões diferentes: a orientação de um regulador, um contrato, um mercado novo. Quando uma regra vive no código, cada mudança é uma liberação, vários serviços se afastam uns dos outros, e ninguém consegue dizer qual versão de uma regra produziu uma decisão tomada no trimestre passado.
O último problema é o caro. Uma decisão que não pode ser reconstruída não pode ser explicada, e uma decisão que não pode ser explicada não pode ser defendida.
Estratégias de implementação válidas
A forma é pequena: a aplicação pergunta por meio de uma interface que é dela, a interface consulta material de políticas versionado, e a decisão que volta carrega a revisão desse material.
Arquitetura de exemplo · Não normativa
Regras como dados
- Fluxo de dados neste exemplo
Descrição textual. Uma aplicação envia sua pergunta, como entrada, a uma interface de política que pertence à aplicação. A interface consulta um motor de política, que não muda quando as regras mudam. O motor lê o material de política versionado, revisão r, como dados. A resposta do motor é registrada como um registro de decisão que carrega a resposta e a revisão r.
- Uma interface de políticas que pertence à aplicação. A aplicação faz uma pergunta nos seus próprios termos, e o motor fica atrás de um adaptador.
- Material de políticas versionado. Regras e seus dados são artefatos com um identificador por revisão, com deploy independente da aplicação.
- A revisão em cada decisão. O registro de decisão carrega a resposta, a revisão e o suficiente da entrada para reproduzi-la.
- Revisões antigas mantidas recuperáveis. Uma reprodução precisa do material como ele era, não como ele é.
- Avaliação reproduzível. Uma política que busca dados ou lê o relógio enquanto avalia não pode ser reproduzida só a partir da sua entrada e da sua revisão. Esses fatos devem entrar como entrada, e ser registrados.
- O motor também versionado. Uma atualização do motor pode mudar o significado: o OPA 1.0 tornou obrigatórias as palavras-chave
ifecontains, por exemplo. A versão do motor deve ser registrada onde quer que a reprodução importe. - Falha controlada. Uma revisão desconhecida, uma revisão ausente, uma resposta malformada ou um motor inalcançável produz um desfecho que o dono da regra escolheu de antemão, nunca um padrão não registrado. Não existe uma resposta certa universal: recusar a ação é o certo para uma regra de acesso a funcionalidades como a do exemplo do perfil Python; para outra decisão, quem é dono dela define o que significa falha, e registra a escolha.
Opções de tecnologia
- Open Policy Agent. Um motor de políticas de uso geral que desacopla as decisões de política da sua imposição, com políticas escritas em Rego. Um bundle pode carregar um manifesto com uma revisão, e os logs de decisão do OPA registram a revisão do bundle usada em cada decisão. Sua API REST devolve um
decision_idquando o log de decisões está habilitado. - Tabelas de regras que pertencem à aplicação. Linhas com uma revisão e um período de vigência, avaliadas por código que não muda quando as linhas mudam.
- Tabelas de decisão e DMN, onde quem é dono das regras são analistas e não desenvolvedores.
- Outras linguagens e motores de políticas. O OPA é um exemplo aqui. O COADF não o exige.
Modos de falha
Regras duplicadas ou fixas no código em vários serviços
Cada cópia é alterada no seu próprio ritmo, e a mesma requisição é permitida num lugar e recusada em outro.
A revisão não guardada com o resultado
A decisão existe; quais regras a produziram, não.
Recarregar uma regra muda o significado de decisões históricas
Um relatório recalcula as decisões do mês passado com as regras de hoje e as apresenta como sendo do mês passado.
Ambientes rodando revisões diferentes sem procedência
Durante uma atualização gradual, versões antigas e novas rodam ao mesmo tempo, e um ConfigMap lido por variáveis de ambiente não é atualizado até o pod reiniciar. Por um tempo, duas revisões respondem, e só o registro de decisão consegue dizer qual delas respondeu.
Uma decisão antiga não pode ser reconstruída
O material foi sobrescrito, ou a avaliação dependia de dados buscados no momento em que rodou.
Indefinido lido como resposta
Em Rego, uma regra cuja entrada está ausente é indefinida, e um valor padrão responde no lugar dela. Uma chave de entrada escrita errado cai, portanto, silenciosamente no padrão, o que os próprios testes do exemplo fixam. Um teste de contrato do lado de quem chama pega o erro de grafia.
Um cache de decisões que ignora a revisão
Respostas guardadas em cache a partir do material antigo sobrevivem ao rollout do novo.
Um motor inalcançável tratado como permissão
Um cliente que permite quando o motor não responde transforma uma indisponibilidade numa política.
Verificação
Teste unitário
Passa quando: Os próprios testes das regras rodam contra o seu material:
opa testexecuta toda regra com o prefixotest_, e uma tabela de regras tem o equivalente.Prova de dentes: Alterar o material: os testes que fixam as respostas antigas falham enquanto a regra em si permanece inalterada.
Teste de integração
Passa quando: Toda decisão registrada nomeia uma revisão, igual à revisão do material carregado.
Prova de dentes: Carregar material sem revisão: o cliente se recusa a registrar uma decisão.
Teste de integração
Passa quando: A mesma entrada sob a mesma revisão dá a mesma resposta, reproduzida contra material arquivado.
Teste de contrato
Passa quando: A entrada que a aplicação envia é a entrada que a política lê.
Prova de dentes: Renomear um campo de entrada de um dos lados: o teste de contrato falha, em vez de a política cair no seu padrão.
Teste de implantação ou de admissão
Passa quando: Cada ambiente informa a revisão que está rodando, e o informe é comparado com o registro de liberação.
Evidência manual
Passa quando: Uma amostra de decisões históricas é reproduzida contra as revisões que elas registraram.
Realizações alternativas
- Regras no código, com a revisão do build registrada em cada decisão. Viável para um sistema pequeno. Cada mudança de regra passa então a ser uma liberação, e o motor muda sempre que uma regra muda, o que o P-8 exclui.
- Serviços de feature flags. Parecidos com políticas, e muitas vezes sem procedência de decisão: qual configuração de flags respondeu a uma dada requisição frequentemente não é registrado.
- Um serviço de decisão de outra equipe, consumido pela mesma interface, com a revisão na resposta.
Limitações
- O padrão dá procedência, não correção. Uma regra errada bem versionada continua errada.
- Ele não cobre as partes do P-8 que o COADF não publica, nem como uma decisão de política encontra qualquer outro controle.
- O Open Policy Agent é um motor de exemplo. Nada aqui o torna um requisito.
Fontes
- Open Policy Agent: Upgrading to OPA 1.0 · documentação oficial · OPA 1.20 · Verificado em 2026-09-11
- Open Policy Agent: Open Policy Agent: introduction · documentação oficial · OPA 1.20 · Verificado em 2026-09-11
- Open Policy Agent: Bundles: bundle file format · documentação oficial · OPA 1.20 · Verificado em 2026-09-11
- Open Policy Agent: Decision logs · documentação oficial · OPA 1.20 · Verificado em 2026-09-11
- Open Policy Agent: REST API: get a document with input · documentação oficial · OPA 1.20 · Verificado em 2026-09-11
- Kubernetes: Deployments: rolling update · documentação oficial · Kubernetes 1.37 · Verificado em 2026-09-11
- Kubernetes: ConfigMaps: updates and immutability · documentação oficial · Kubernetes 1.37 · Verificado em 2026-09-11
- Open Policy Agent: Policy testing · documentação oficial · OPA 1.20 · Verificado em 2026-09-11
