Tramas e regras que funcionam no processo
O livro de regras não deve ser um oráculo remoto
As regras de negócio costumam ser apresentadas como algo simples. Um cliente é elegível ou não. Uma transação passa ou falha. Uma proposta recebe um desconto. Um utilizador pode aceder a um recurso. Depois as regras crescem, chegam as exceções, a conformidade pede evidências e, de repente, a verificação simples tornou-se um serviço de políticas, um intérprete, uma cache, um trabalho de reconciliação e uma reunião com o fornecedor. Maravilhoso. Reinventámos um semáforo com um plano de subscrição.
A Lattice parte de uma ideia menos teatral: o livro de regras deve ser executado onde a decisão é tomada. A página atual da Lattice descreve um componente Rust sob licença Apache 2.0 que compila regras antecipadamente num artefacto binário mapeável em memória. A avaliação é uma travessia de árvore compactada dentro do processo. O artefacto inclui somas de verificação. As mesmas regras e os mesmos dados são descritos como produzindo a mesma resposta nos alvos suportados. Nenhum serviço extra precisa de se interpor no caminho de uma decisão. Essa é a forma útil.
Isto não é contra a governação. É o oposto. A governação enfraquece quando as regras vivem longe dos sistemas que as utilizam e as explicações têm de ser reconstruídas mais tarde. Um livro de regras versionado, compilado, com soma de verificação, carregado no processo e reproduzível dá aos auditores algo mais concreto do que perguntámos ao serviço de políticas e ele disse que não. Essa frase pode ser verdadeira. Não é suficiente.
Compile uma vez, deixe de interpretar para sempre
O pipeline da página é claro: criar, compilar, empacotar, avaliar. As regras e as restrições vivem ao lado do código-fonte e do histórico de versões. A compilação classifica as restrições e fixa o motor de resolução. O empacotamento produz um artefacto binário com somas de verificação XXH3-64 sobre o cabeçalho, o conteúdo e o ficheiro. O carregamento é uma chamada de sistema, não uma análise sintática. A avaliação percorre a árvore compactada dentro do processo. Essa sequência é importante porque transforma trabalho de execução em trabalho de compilação.
Os intérpretes são convenientes até estarem em todos os pedidos. Um serviço de políticas remoto é conveniente até o salto de rede fazer parte do orçamento de latência e o serviço se tornar mais uma coisa que pode falhar. Um JIT é conveniente até diferentes anfitriões, versões ou otimizadores fazerem parte da explicação. A Lattice é propositadamente menos dramática. Diz que o livro de regras deve tornar-se um ficheiro que a aplicação pode mapear e executar de forma determinística. O caminho do pedido não deve redescobrir as regras de cada vez.
A página apresenta números de referência para o caminho atual do artefacto, incluindo um número de avaliação a quente, uma consulta a frio após mmap e valores de débito. Esses números pertencem à página e ao seu contexto de referência, não a um mito que deva ser copiado para cada lançamento futuro. O ponto de engenharia duradouro é o design: um artefacto compactado, avaliação local à cache, sem analisador no caminho crítico, sem alocador no caminho crítico e sem salto de rede por decisão.
Uma API de regras única não deve esconder a realidade dos resolvedores
As regras não são todas iguais. Algumas são verificações booleanas puras. Algumas combinam lógica com aritmética. Algumas são programas lineares. Algumas precisam de decisões inteiras. Algumas são restrições de domínio finito. Algumas são problemas de caminho ou restrições suaves. Um motor de regras sério não deve forçar todos os casos através de um único buraco de fechadura em forma de resolvedor. Deve classificar a regra e encaminhá-la para o motor certo.
A página Lattice apresenta SAT, SMT, LP, MIP, CP, A* e MaxSAT sob uma única API de regras. SAT cobre regras booleanas puras e gates de funcionalidades. SMT lida com teorias mistas, como lógica, aritmética, arrays e bitvectors. LP cobre otimização contínua. MIP ou ILP trata decisões inteiras. CP lida com domínios finitos e restrições não lineares. A* e MaxSAT cobrem problemas de caminhos e de restrições flexíveis. A frase importante do produto é que quem chama escreve regras, não chamadas ao solver.
Isso importa para a manutenibilidade. Se cada equipa de produto escreve código de integração específico do solver, a camada de políticas torna-se uma coleção de truques locais engenhosos. Truques locais engenhosos são caros em auditorias porque ninguém se lembra qual truque era engenhoso e qual era apenas de sexta-feira. Uma superfície de regras classificada dá às equipas um único lugar para inspecionar a regra, a sua classe de backend, o artefacto compilado e a resposta que produziu.
A latência também é uma regra de negócio
Os sistemas de decisão adoram fingir que a latência é um pensamento técnico posterior. Não é. Se uma verificação de conformidade está em cada transação, a latência faz parte do produto. Se o controlo de acesso está num gateway, a latência faz parte da segurança. Se a precificação ocorre no momento da cotação, a latência faz parte da receita. Se a triagem de fraude ocorre antes da liquidação, a latência faz parte do risco. Uma regra lenta pode estar correta e ainda assim estar operacionalmente errada.
É por isso que a avaliação em processo importa. A página atual da Lattice contrasta verificações interpretadas ou remotas à escala de milissegundos com o caminho do artefacto compactado, e destaca o custo dos saltos de rede, serviços sidecar e lacunas de auditoria. O número exato de um benchmark é menos importante do que a forma do custo. Se um pedido precisa de dez verificações, talvez o caminho antigo sobreviva. Se um pedido precisa de dez mil verificações, o caminho antigo começa a ocupar espaço no orçamento do pedido. Nesse ponto, o motor de regras já não é um componente. É aquilo por que os utilizadores estão à espera.
O benefício operacional não é apenas a velocidade. São menos peças móveis. Sem serviço de políticas extra. Sem caminho de rede para manter saudável. Sem processo de parser separado. Sem cache separada para explicar. O livro de regras fica com a aplicação, dentro da jurisdição e do limite operacional que já controla. Isso é menos glamoroso do que um dashboard. Também é menos provável que acorde alguém.
A resposta de auditoria é a reprodução
Quando um auditor pergunta por que uma decisão foi negada, a pior resposta é um parágrafo reconstruído de memória. A segunda pior resposta é um screenshot. A resposta útil é: esta versão do livro de regras foi executada com esta entrada e produziu esta saída, aqui está o checksum do artefacto, aqui está a regra, aqui está a reprodução. A Lattice foi construída para tornar essa resposta possível.
A página liga a Lattice a decisões automatizadas ao abrigo do RGPD, à transparência exigida pelo Regulamento da UE sobre IA, à resiliência operacional da DORA e à garantia da cadeia de abastecimento da NIS2. Esses rótulos podem tornar-se pó de brochura se o sistema não conseguir mostrar nada de concreto. A parte concreta é o artefacto. Um livro de regras compilado pode ser nomeado. Uma soma de verificação pode rejeitar adulterações. As entradas registadas podem reproduzir a decisão. Uma saída bit a bit exata significa que a failover não deve alterar silenciosamente uma resposta. Executar em processo dentro de sistemas controlados ajuda a evitar o problema do serviço externo no caminho da decisão.
Onde se encaixa primeiro
A Lattice faz mais sentido em pontos de decisão que acontecem com frequência e precisam de evidências mais tarde. Verificações de conformidade em transações. Preços e elegibilidade no momento da cotação. Decisões de acesso em gateways. Triagem de fraude antes da liquidação. Verificações de elegibilidade no setor público. Portões de subscrição em seguros. Permissões de fluxo de trabalho interno. Estes são lugares onde sim ou não não chega. O sistema tem de saber qual versão de sim ou não aconteceu.
Também se encaixa em lugares onde a mesma decisão tem de permanecer igual entre servidores. Uma failover não deve alterar um resultado de conformidade. Uma implementação regional não deve interpretar uma regra de forma diferente porque uma versão de biblioteca divergiu. Uma reprodução de auditoria não deve precisar de que o mesmo serviço de fornecedor alojado ainda exista. O livro de regras deve ser portátil o suficiente para correr onde a organização o controla, e explícito o suficiente para que os custos de mudança se mantenham baixos.
É por isso que o código aberto também importa aqui. Um motor de regras que participa em conformidade, acesso, preços ou fraude não é uma dependência decorativa. É parte do plano de controlo. Se ninguém dentro da organização o puder inspecionar, fixar, testar e manter, então o livro de regras não é realmente deles. É autoridade alugada.
O que rever antes de adotar
Primeiro, identifique os pontos de decisão. Não comece com uma migração de plataforma. Comece com um livro de regras que dói hoje. Com que frequência corre? O que protege? Quem pergunta porquê? O que acontece se o serviço estiver em baixo? Que evidências estão disponíveis seis meses depois?
Segundo, reveja a forma das regras. As restrições são booleanas, aritméticas, lineares, inteiras, de domínio finito, semelhantes a caminhos ou suaves? Que classe de backend deve ser dona delas? Se a regra não consegue explicar por que encaminha para uma família de solvers, a abstração é mágica demais.
Terceiro, reveja a disciplina do artefacto. Onde está armazenada a regra de origem? Que build produziu o artefacto? Que soma de verificação foi carregada? Que versão da aplicação a usou? Que entradas foram registadas? Que caminho de reprodução prova a resposta? Se a resposta está espalhada por três sistemas e uma pessoa chamada Jan, o livro de regras ainda não é um objeto de auditoria. É uma tradição.
A lição
A Lattice é uma história de motor de regras, mas é realmente uma história de controlo. Compile o livro de regras antes do pedido. Embale-o num artefacto que a aplicação possa mapear em memória. Verifique o artefacto antes de o carregar. Encaminhe as restrições para a família de solvers certa. Avalie em processo. Reproduza mais tarde com a mesma entrada e a mesma versão do livro de regras.
Isso não é glamoroso. Ainda bem. As regras de negócio não devem ser glamorosas. Devem ser aborrecidas, rápidas, explícitas e revistas. Os sistemas de decisão importantes numa empresa não devem depender de oráculos remotos, loops de parser e arqueologia de auditoria. Devem carregar os seus livros de regras como infraestrutura.
O livro de regras não deve ser um oráculo remoto. Deve ser algo que o sistema possa correr, nomear e reproduzir.