Por que o ObligationFirst Difere do LegalRuleML e Akoma Ntoso

Nota: este post foi revisado com o lançamento da v0.5.0 em 25 de julho

Quando apresentamos o ObligationFirst, dissemos que não se tratava da primeira tentativa de tornar a legislação legível por máquinas, mas que era, até onde sabíamos, a primeira construída para agentes. Isso é fácil de afirmar e mais difícil de demonstrar. Este post é a demonstração, comparando com a especificação atual (v0.5.0) e não com intenções.

A comparação é feita com os dois predecessores mais influentes: Akoma Ntoso, o padrão OASIS para documentos jurídicos, e LegalRuleML, o padrão OASIS para as regras que esses documentos expressam. Ambos são maduros. Ambos funcionam bem para os públicos para os quais foram criados. Nenhum deles foi projetado para um sistema que precisa decidir se pode agir agora mesmo, e essa diferença aparece nas escolhas de campos.

Para que servem os predecessores

Akoma Ntoso é um vocabulário XML para documentos legislativos e judiciais: seções, artigos, parágrafos, referências, emendas, assinaturas. É um Padrão OASIS desde 2018 e é usado em produção pelo Senado italiano, pelo Congresso brasileiro e pelo parlamento queniano, entre outros. É excelente para representar o que um documento jurídico é e como suas partes se conectam a outros documentos.

LegalRuleML é o padrão OASIS para representar normas jurídicas, construído sobre o RuleML. Ele fornece operadores deônticos explícitos (Obrigação, Permissão, Proibição, Reparação) e trata a derrotabilidade por meio de DefeasibleRule e hierarquias de exceção. É a camada de regras que se situa, conceitualmente, acima da camada de documentos.

Esses padrões são maduros e úteis. Onde o ObligationFirst se vincula a eles, queremos deixar isso explícito. Onde diverge, a divergência é deliberada e o público-alvo é a explicação.

A diferença de público

O Akoma Ntoso foi projetado para parlamentos, tribunais e as ferramentas de legal-tech operadas por humanos que absorvem seus resultados. A granularidade reflete isso. Uma seção é uma seção. Uma emenda é uma alteração rastreada. A fidelidade importa porque os consumidores são redatores e advogados.

O LegalRuleML foi projetado para motores de raciocínio jurídico e para a comunidade de pesquisa que os constrói. É expressivo por intenção: consegue codificar relações deônticas complexas, regras derrotáveis e hierarquias de exceção, porque seus consumidores precisam lidar com casos-limite da mesma forma que um advogado cuidadoso lidaria.

O ObligationFirst é projetado para um agente que decide se e como executar uma ação. Esse agente precisa saber: esse dever se aplica a mim, o que ele exige, é exequível hoje, e o que respalda a citação. O orçamento de expressividade vai para campos operacionais, não para codificar cada nuance que um futuro motor de raciocínio possa querer.

O que o ObligationFirst não duplica

O sinal mais claro de intenção é o que o esquema se recusa a possuir.

Onde existe uma codificação Akoma Ntoso autoritativa, um registro do ObligationFirst faz referência a ela em vez de reescrevê-la. O IRI do elemento Akoma Ntoso acompanha o registro como um crosswalk tipado akn_uri, nunca como identificador. eli_uri, urn_lex e citation desempenham a mesma função para o European Legislation Identifier, o urn:lex e a citação convencional. As classes de entidade se vinculam à ontologia superior Semantic Arts gist em vez de inventar uma nova.

O Akoma Ntoso modela documentos. O ObligationFirst modela o conteúdo normativo que esses documentos criam. O crosswalk entre eles é explícito quanto à lacuna: para of:Obligation, a coluna do Akoma Ntoso traz "sem equivalente direto", porque o Akoma Ntoso codifica texto, e as obrigações são derivadas do texto por interpretação. Essa lacuna é a razão de ser de todo o esquema.

Granularidade, e o que ela custa

No LegalRuleML, um único dispositivo legal pode se decompor em várias regras, cada uma com seu próprio operador deôntico, condições e estrutura de exceção. Isso é adequado para raciocínio, mas incômodo para um agente que precisa de uma única resposta.

O ObligationFirst mantém a obrigação como unidade. Um dever, um registro, acessível em um IRI estável.

Pagamos um preço real por isso, que recentemente se materializou. Manter a obrigação como unidade tenta você a tornar essa unidade grosseira demais. Nossa própria implementação de referência fez exatamente isso: a EveryAILaw publicou dez conceitos amplos (transparência, supervisão humana, prevenção de viés, e assim por diante) como seus registros de obrigação, de modo que 134 termos estatutários colapsaram em dez. As consultas retornavam uma categoria quando deveriam retornar um dever.

A correção, já disponível na v0.5.0, foi um segundo tipo, e não um tipo mais frouxo. of:ObligationCategory mantém o conceito neutro em relação à jurisdição; as obrigações se associam à sua categoria por meio de skos:exactMatch. Uma categoria não carrega jurisdição, titular do dever, nem termo criador, porque ninguém pode cumprir uma categoria. Duas leis em jurisdições diferentes permanecem comparáveis por meio da camada de conceito, enquanto a camada de dever permanece fiel ao que cada estatuto de fato exige.

Essa é a compensação em sua forma honesta. A comensurabilidade entre jurisdições é genuinamente valiosa, e pertence ao seu próprio tipo, em vez de ser contrabandeada para dentro da obrigação.

O que nenhum dos predecessores modela

A maior diferença estrutural não é uma escolha de campo. É um eixo inteiro.

O LegalRuleML modela a regra, não a questão jurídica que depende da regra. Não tem representação formal de um processo, uma alegação ou uma decisão. O Akoma Ntoso consegue representar o documento de julgamento que um tribunal produz, mas não a questão que o originou como objeto consultável.

O ObligationFirst adiciona of:Proceeding, of:Allegation e of:Determination. A separação entre alegado e determinado é o ponto central: uma afirmação em uma questão jurídica é alegada até ser decidida, e modelar isso como um sinalizador de status em uma única entidade força uma classificação prematura. Três tipos preservam a distinção. Uma alegação é o que foi afirmado. Uma determinação é o que foi decidido. Um processo acumula ambos ao longo de sua existência.

É isso que permite que uma decisão se vincule ao dever que ela interpreta. Nas três implementações ativas, há atualmente 59 referências entre projetos desse tipo, todas elas resolvendo corretamente.

Estado, causa e o passo extra

Uma lei pode estar em vigor e ser inexequível ao mesmo tempo. Ambos os fatos importam para um agente.

O ObligationFirst os divide em dois campos planos no instrumento. status carrega o estado legislativo (proposed, enacted, in-force, amended, sunset, repealed, superseded, withdrawn). enforcement_status carrega se os deveres podem ser atualmente exigidos (routine, constrained, unsignaled). Eles são independentes, e qualquer combinação é válida.

O que a enumeração deliberadamente não carrega é o motivo. Não há stayed-by-court, nem enjoined, nem pending-rulemaking. A causa reside no eixo do processo, como uma determinação que se ancora à obrigação afetada.

Isso custa um passo extra para quem quiser exibir "suspenso à espera de regulamentação" como uma única frase, e a especificação diz isso claramente. Assumimos esse custo de propósito. As causas de inexequibilidade são abertas: ordens judiciais, postura da agência reguladora, pausas legislativas, ação do executivo, declarações de emergência. Cada nova causa, do contrário, exigiria uma extensão da enumeração e uma migração por parte dos adotantes. Várias causas também podem se aplicar simultaneamente, e um campo escalar só comporta uma. Separar a causa também é o que torna duas jurisdições comparáveis, já que ambas podem estar como constrained por motivos totalmente diferentes.

O padrão se sustentou a jusante. A PubLedge dividiu de forma independente seus próprios registros de instrumento em status legal e status editorial, e adicionou um vocabulário de ciclo de vida no nível da obrigação que inclui never-operative, para um dever que foi promulgado, mas cujo instrumento de implementação foi extinto antes de entrar em vigor. Nenhum dos predecessores expressa isso de forma tão clara.

Substituição e derrotabilidade

O Akoma Ntoso trata o versionamento por meio de emendas e versões consolidadas, com um grafo de emendas fiel ao processo legislativo. O LegalRuleML trata isso por meio de condições temporais na regra.

O ObligationFirst separa duas coisas fáceis de confundir. A substituição de um instrumento inteiro é supersedes, afirmada de instrumento para instrumento depois da promulgação, com wouldSupersede para o caso subjuntivo antes disso. A sobreposição no nível de cláusula é defeats, afirmada de termo para termo.

Essa segunda relação é onde mantivemos mais do LegalRuleML do que uma narrativa de "esquema mais simples" sugeriria. defeats tem duas subpropriedades, rebuts e undercuts, carregando exatamente a distinção do LegalRuleML: um termo refutador afirma a conclusão oposta, um termo anulador nega que a regra se aplique aqui, sem contradizê-la em outro contexto. Não achatamos a estrutura de exceção. Nós a movemos de dentro de uma regra para entre termos, onde um agente pode percorrê-la.

O Colorado é o exemplo real. O SB 24-205 está registrado como não mais em vigor, substituído pelo SB 26-189, que entra em vigor em 1º de janeiro de 2027. A relação de sucessão é afirmada, não inferida, e uma consulta filtrada por data retorna qualquer que seja o dever em vigor na data consultada. Nada é sobrescrito no lugar; o registro mais antigo permanece disponível para litigantes e historiadores.

O problema que nenhum dos predecessores tinha

Ambos os predecessores pressupõem um documento que se pode apontar diretamente. Uma federação de conjuntos de dados jurídicos publicados de forma independente tem um problema que nenhum dos dois aborda: o identificador de quem prevalece.

A resposta do ObligationFirst é que o de ninguém prevalece. Todo identificador de registro é local ao adotante, opaco e permanente, e as junções entre conjuntos de dados se apoiam em crosswalks padronizados, em vez de slugs compartilhados. Cada publicador declara sua própria gramática de identificadores em um perfil legível por máquina em /.well-known/obligation-first-naming-profile.jsonld, que especifica o padrão de URI para cada tipo de entidade e quais crosswalks ele fornece. A especificação valida esse perfil; nunca prescreve a gramática.

Isso é pouco glamouroso e é o que faz o grafo funcionar. Três conjuntos de dados mantidos de forma independente, 579 registros, nenhum registro central, nenhuma renomeação coordenada.

Interoperabilidade é o objetivo

Nenhuma dessas diferenças é um argumento contra o LegalRuleML ou o Akoma Ntoso. São argumentos a favor de moldar um esquema em torno de seu consumidor.

Onde os dados se sobrepõem, o mapeamento está dentro do escopo e já foi parcialmente escrito. O quarteto deôntico se alinha um a um com os quatro operadores do LegalRuleML, e of:Reparation é mantido como uma subclasse distinta especificamente para preservar esse alinhamento. Os documentos de crosswalk transmitem a lógica de regra de um Term para uma codificação LegalRuleML por meio de um campo lrml_encoded_as, embora devamos ser precisos quanto ao status: isso está documentado no crosswalk, ainda não é um predicado no esquema, e se deve ser formalizado ainda é uma questão em aberto na especificação. of:executableEncoding já aponta para codificações Catala, Blawx ou OpenFisca, de modo que o trabalho de regras executáveis dessa comunidade se compõe em vez de competir.

Dois limites honestos. of:Reparation tem, até agora, zero instâncias nas implementações ativas, então o alinhamento do quarto operador está projetado, mas ainda não foi exercitado. E os mapeamentos não são gratuitos e nem sempre serão isentos de perdas.

Esperamos que implementações maduras rodem vários esquemas simultaneamente, cada um atendendo ao consumidor para o qual foi moldado. O ObligationFirst é a superfície voltada para agentes. Os demais permanecem úteis por trás dele.

O que isso significa para você

Se você está construindo algo que precisa operar dentro de um ambiente regulado, um copiloto de conformidade, um pipeline de auditoria, um painel voltado a reguladores, o ObligationFirst é moldado para suas consultas. Comece por ali.

Se você está fazendo pesquisa rigorosa em raciocínio jurídico, ou construindo ferramentas para redatores legislativos, o LegalRuleML e o Akoma Ntoso continuam sendo as ferramentas principais corretas. Use o ObligationFirst como a superfície complementar onde padrões de consulta voltados a agentes são necessários.

Se você está construindo infraestrutura que outros vão adotar, a existência de vários esquemas é um recurso, não um problema. Os pontos de interoperabilidade entre eles são onde o ecossistema acumula valor, e pull requests contra a camada de mapeamento são bem-vindos.

O enquadramento nativo para agentes é a contribuição. A interoperabilidade é o que a mantém útil conforme o ecossistema muda ao seu redor.

Tem dúvidas? Fale conosco ou leia nossa Política de Privacidade.