Lógica de negócio e conhecimento operativo

01

A lógica de negócio raramente vive num único lugar

Uma aplicação empresarial executa decisões continuamente: que dado é válido, que estado pode seguir-se a outro, que condição bloqueia uma operação, que cálculo se aplica, quem pode autorizar, que exceção muda o percurso e que efeitos produz cada ação.

Com o tempo, essas decisões distribuem-se entre:

• código e procedimentos armazenados;
• configurações do ERP e motores de workflow;
• tabelas de decisão e regras;
• formulários, validações e interfaces;
• documentação funcional e técnica;
• folhas de cálculo e modelos;
• incidentes e tickets que explicam exceções;
• dados históricos e rastos de execução;
• conhecimento que determinadas pessoas conservam.

Quando a organização precisa de modernizar, integrar, automatizar ou auditar, descobre que conhece o sistema por fragmentos, mas não dispõe de uma representação comum da lógica que realmente governa o trabalho.

Construímos sistemas para reconstruir essa lógica, torná-la examinável e mantê-la ligada às suas evidências e às pessoas capazes de a validar.

02

Não geramos uma explicação única e damo-la por certa

Um modelo pode ler código ou documentação e produzir uma descrição convincente. Esse resultado é útil como ponto de partida, mas não demonstra que a lógica seja completa, esteja em vigor nem seja correta.

Distinguimos vários estados:

• observado: aparece de forma direta num artefacto;
• inferido: deduz-se de vários sinais, mas precisa de validação;
• confirmado: uma pessoa ou um teste suficiente valida-o dentro de um âmbito definido;
• contraditado: outra evidência mostra uma versão incompatível;
• obsoleto: pertenceu ao sistema, mas já não deveria aplicar-se;
• desconhecido: falta evidência para representar a decisão.

Esta distinção permite utilizar modelos para acelerar a investigação sem converter a sua fluência em autoridade.

04

A proveniência faz parte de cada regra

Uma regra sem origem é difícil de discutir e perigosa de reutilizar.

Cada elemento deve conservar:

• o artefacto e a localização de onde procede;
• o fragmento de código, configuração, documento ou rasto relevante;
• a versão e o âmbito;
• o método com que foi extraída ou inferida;
• as evidências que a apoiam e a contradizem;
• o seu estado de validação;
• as pessoas ou testes que intervieram;
• as relações e dependências conhecidas;
• as perguntas ainda em aberto.

Assim, uma pessoa pode passar de uma explicação de alto nível ao detalhe que a sustenta e corrigir o conhecimento sem refazer toda a investigação.

05

A intervenção humana valida significado, não copia resultados

As pessoas de domínio não deveriam rever uma lista interminável de regras isoladas. O sistema deve agrupar e priorizar aquilo que merece atenção:

• contradições entre fontes;
• inferências com evidência fraca;
• regras com grande impacto ou muitas dependências;
• diferenças entre documentação e execução;
• exceções frequentes;
• comportamentos sem responsável claro;
• decisões que afetam autoridade, cumprimento ou risco;
• âmbitos onde uma regra pode ter sido demasiado generalizada.

A revisão deve permitir confirmar, rejeitar, editar, limitar o âmbito, acrescentar uma exceção ou declarar que a intenção organizativa deve mudar ainda que o software atual faça outra coisa.

08

Do inventário ao conhecimento operativo

O resultado não deveria ser um relatório que envelhece a partir do momento em que é entregue.

Deve poder manter-se como uma camada de conhecimento operativo:

• versionada;
• consultável por pessoas;
• acessível por software através de contratos;
• ligada a testes e observabilidade;
• capaz de representar contradições;
• explícita sobre aquilo que ainda não sabe;
• útil para a decisão de mudança seguinte.

Esta linha de trabalho alimenta-se da experiência de DocuLogic: investigar como converter artefactos de sistemas empresariais numa representação mais auditável da sua lógica, sem confundir extração, inferência e aprovação.

09

Observado, inferido, validado e acordado

A representação distingue quatro estados de uma mesma regra:

• comportamento observado: aquilo que o software executa hoje e que os rastos permitem verificar;
• lógica inferida: a explicação candidata que uma análise propõe, com a sua evidência e a sua incerteza;
• conhecimento validado: aquilo que uma pessoa com autoridade de domínio confirmou e delimitou;
• decisão organizativa: aquilo que a organização acorda que deve acontecer a partir de agora.

Esta distinção permite utilizar o software existente como fonte conservando a autoridade onde ela corresponde. Uma implementação pode conter uma adaptação histórica, uma inconsistência ou um comportamento que a organização deseja mudar.

10

DocuLogic, KIR e tecnologias semânticas

DocuLogic mantém o conhecimento reconstruído como uma camada de autoria e revisão humana: exprime conceitos, regras, cálculos e exceções em formatos legíveis e versionáveis, juntamente com proveniência, estado de verificação, vigência, âmbito, ciclo de vida e relações. Uma pessoa pode lê-lo, discuti-lo e corrigi-lo sem trabalhar sobre uma base de dados nem sobre uma representação de execução.

KIR — Knowledge Intermediate Representation — é a representação intermédia tipada e canónica que recebe esse conhecimento e o projeta para bases relacionais, grafos, índices semânticos, motores de regras, APIs, MCP e agentes.

Consoante o caso, a estrutura pode apoiar-se em LinkML para definir esquemas, TypeDB ou outros grafos tipados para relações complexas, PostgreSQL e pgvector para conhecimento relacional, lexical e semântico, Datalog para dedução, DMN para decisões, CEL para validações e Tree-sitter e LSP para estrutura de código.

Esta página aprofunda uma capacidade da inteligência informacional: tornar examinável a lógica que hoje vive repartida entre software, configurações, documentação e experiência.