PaperlayerView exact revision on arXiv

Source-linked AI summary

A decision-support system applied to Law: Reasoning and explainability of the decision

Jeremy Bouche-Pillon, Pascale Zarat{é}, Yannick Chevalier, Nathalie Aussenac-Gilles

arXiv:2609.35370v1cs.AI

TL;DR

The paper addresses the challenge of reasoning over formalized legal rules while providing explanations that help human agents understand compliance decisions. It presents a symbolic, SPARQL-based decision-support framework with procedures for explaining results and handling undecided cases by seeking missing information. The authors describe the framework and its reasoning and justification methods, while noting limitations in a naive approach to identifying missing conditions.

  • Problem

    Legal-rule formalisms may lack working reasoning mechanisms, and pure logic reasoning does not explain how a decision follows from its premises.

    Source: §1 · p. 2

  • Method

    The framework reasons over ontology-based situation descriptions using formal rules represented in SPARQL and adds an explainability module for failed or undecided reasoning.

    Source: §1 · p. 3, §3.2 · p. 12

  • Results

    The paper presents methods for formalizing legal rules, generating justified decisions, and using decision trees to identify unfulfilled conditions when no rule is satisfied.

    Source: §6 · p. 27

  • Takeaways & Limitations

    For undecided cases caused by insufficient information, the framework can guide users toward additional information that may allow reasoning to reach a conclusion.

    Source: §1 · p. 3, §6 · p. 27

    The naive approach can miss further unfulfilled conditions and ranks rules poorly by relative depth, making it ineffective for more complex rules.

    Source: §5.3.1 · pp. 25–26

Abstract

from arXiv · show

The emergence of the digital transition brought an increasing need to control the processing of digital information, including in Law Enforcement Agencies (LEAs). At the EU level, in recent years, many regulations have emerged to control data processing and exchange. Texts other than the GDPR, such as the ''Law Enforcement Directive (LED)'', appeared to regulate specifically how Law Enforcement Agencies (LEAs) could process data. A formal representation of these regulations can be part of decision systems that support LEAs in processing data in compliance with the regulations. Although many new formalisms have emerged to represent legal norms and rules, few are provided with a reasoning mechanism. Furthermore, systems used in decision-making processes in critical contexts such as medical diagnoses or legal decisions cannot be fully automated, and the explainability of their results is essential to ensure user confidence in decisions. This explainability aspect, while crucial, is lacking in most modern approaches that rely on machine learning. This paper describes a framework to operate formal rules from regulations, by focusing on explainability of the decision. After describing the general architecture of the proposed decision support framework, the paper showcases how symbolic AI and the SPARQL query language can support legal reasoning. It then describes an algorithm to generate a justification for the reasoning results, and outlines the procedure to be followed when the reasoning does not lead to a satisfactory conclusion. We notably focus on a method based on decision trees to determine what additional information to request from the user.

1. Introduction

The paper proposes a decision-support framework for checking legal compliance, motivated by the need to operationalize regulations and explain decisions to human agents. It uses symbolic reasoning over formalized rules and addresses undecided cases by identifying information to request or reporting inconsistencies.

1. Introduction

  • The paper situates its work in the need to govern digital processing through domain-specific laws, including the GDPR and Digital Services Act.It frames its LEA use case around regulatory control of data processing while respecting citizens’ privacy.Source: §1 · pp. 2–3
  • Legal-rule formalisms do not always provide operational reasoning mechanisms, while pure logic reasoning reports entailment without explaining how a decision was reached.The paper notes that LegalRuleML originally lacked reasoning mechanisms and that Carneades was unsuccessful in testing and did not appear maintained.Source: §1 · p. 2
  • The framework combines formalized legal rules and reasoning with explanations so human agents can receive compliance suggestions grounded in regulations.When reasoning fails because of insufficient input or inconsistent applicable rules, an explainability module identifies missing information or reports the inconsistency.Source: §1 · pp. 2–3
  • The framework applies symbolic AI and SPARQL-formalized rules to a human agent’s ontology-based description of a situation.The use case checks whether LEA data sharing and processing conforms to European regulations, including the Law Enforcement Directive.Source: §1 · p. 3

2. Decision-Support Framework

The framework pairs rule-based legal reasoning with a module that justifies decisions and guides users when reasoning is undecided. Its components use legal sources, ontologies, knowledge graphs, and formal rules to represent situations and assess compliance.

2. Decision-Support Framework

  • The framework’s interactive decision-support system combines operable formal rules with explanations of reasoning results.The explanation is returned to the user alongside the decision suggestion.Source: §2 · p. 4, §2.7 · p. 7

2.1. General architecture

  • A rule-based module can produce decided conclusions or an undecided result, while a second module justifies the output and seeks improved input for undecided cases.Undecided results can arise when no rule triggers or when applicable rules conflict.Source: §2.1 · pp. 4–5, §2.6 · p. 7

2.2. Legal sources

  • Legal sources contribute definitions and normative articles: definitions inform the ontology and knowledge base, while articles are formalized as rules.Source: §2.2 · p. 5

2.3. Ontology for the reasoning module

  • The ontology represents both reusable legal-rule knowledge and use-case-specific situation knowledge, which is encoded in knowledge graphs for reasoning.The legal-rule portion can be generic, whereas the situation ontology must be built for each use case.Source: §2.3 · pp. 5–6

2.4. Input of the reasoning module

  • User input is encoded in a knowledge graph, and storing each query in a named graph compartmentalizes it from unrelated information.The alternative—storing all queries in a global graph—risks identifier collisions that could lead to flawed reasoning and incorrect suggestions.Source: §2.4 · p. 6

2.5. Formal rules of reasoning module

  • The framework distinguishes applicability, compliance, and exception rules, with compliance rules assigned a deontic type.Regulations must be adapted to the scenario in which the framework is used.Source: §2.5 · p. 7

2.6. Possible outcomes of the rule-based reasoning module

  • Decided outcomes are obligation, prohibition, permission, or facultative; undecided outcomes are indecisive or contradictory.Indecisive cases have no triggered rule, whereas contradictory cases arise when applicable compliance rules yield conflicting deontic answers.Source: §2.6 · p. 7

2.7. Explainability module

  • The explainability module justifies decided conclusions with their legal sources and handles contradictory or indecisive cases differently.Contradictions are registered for expert review; indecisive cases prompt users for input that could help reach a decided conclusion.Source: §2.7 · pp. 7–8

3. Using SPARQL for non monotonic reasoning

The framework represents regulatory rules in a Semantic Web knowledge graph and uses SPARQL for reasoning, with explicit rules supplemented by defaults and conflict-resolution rules. Its SPARQLTree formalization supports translation between SPARQL and first-order logic via ASP.

3. Using SPARQL for non monotonic reasoning

  • SPARQL expresses rules over RDF and OWL data, while rule execution can query knowledge graphs through engines such as GraphDB or Apache Jena Fuseki.The paper presents the rules in first-order logic using a Conditions →Effect syntax for clarity.Source: §3 · p. 8

3.1. Explicit rules from regulations

  • Each explicit legal rule is classified as permission, obligation, or prohibition and encoded as separate applicability and compliance queries.For LED article 10, the permission concerns sensitive personal data and requires necessity, safeguards, and one of three alternative conditions.Source: §3.1 · p. 9
  • SPARQLTree gives a structural account of query bodies and their solutions, forming the basis for algorithms that explain why a query has no solutions.The framework also formalizes SPARQL rules using a body-to-effect form applied to a knowledge graph.Source: §3.1 · pp. 11–12

3.2. Identifying implicit rules and conflict-solving rules

  • Implicit default rules and conflict-solving rules, identified with legal experts, model exceptions and priorities; for LED article 10, permission is treated as an exception to a default prohibition.The framework's explicit rules formalize normative articles, while implicit rules define defaults and conflict-solving rules implement defeasible reasoning.Source: §3.2 · p. 12

4. Reasoning and explainability

The framework applies explicit and implicit rules to a situation, then resolves conflicts to produce a deontic conclusion. It explains the result through supporting legal sources or, for problematic cases, by identifying conflicts or requesting missing information.

4. Reasoning and explainability

  • Reasoning applies explicit and implicit rules to the situation graph, then applies exception and priority rules to remove decisions superseded by others.The system also aims to explain the decision it suggests to the end user.Source: §4 · p. 12

4.1. Evaluating the resulting deontic conclusion

  • The deontic truth table maps combinations of respected permissions, obligations, interdictions, and facultatives to an overall conclusion, including conflict and undecided outcomes.The framework distinguishes seven outputs: clear conclusions, contradictions, and undecided cases.Source: §4.1 · pp. 13–14
  • A Karnaugh-like representation of the truth table yields a minimal combination of deontic types for computing the reasoning module's conclusion.The paper presents this representation as Table 2.Source: §4.1 · p. 14, Table 2 · p. 14
  • Permission and interdiction, facultative and obligation, or obligation and interdiction rules each produce a contradictory conclusion when both are respected.Permission and facultative rules together yield a double conclusion: the action is neither obligated nor prohibited.Source: §4.1 · p. 14

4.2. General algorithm for explainability

  • When respected rules are coherent, the explanation identifies supporting regulations; unresolved conflicts are reported with the conflicting rules and a request for the user to choose which prevails.The user's choice becomes a temporary conflict-solving rule for expert validation; when no applicability rule is satisfied, the situation is reported outside the verified regulations' scope.Source: §4.2 · p. 15
  • When applicable rules exist but none is respected, the algorithm asks the user for potentially missing information to improve the result.This is the no-respected-rules branch of the explanation algorithm.Source: §4.2 · p. 15

6 else

The algorithm maps consistent sets of respected deontic rules to a conclusion and returns contradictory when their conclusions conflict.

6 else

  • When every respected rule is a Permission, the algorithm returns Permission; when every rule is Facultative, it returns Facultative.These cases return the respective list of respected rules with the conclusion.Source: §6 · p. 15
  • A set containing only Permission and Facultative rules returns Permission & Facultative, while a mix of Obligation and Permission returns Obligation.The algorithm returns the respected rules alongside the conclusion.Source: §6 · p. 15
  • A set containing only Prohibition and Facultative rules returns Prohibition; other combinations of respected rules return Contradictory.The latter branch represents contradictory respected rules.Source: §6 · p. 15

5. Handling undecided cases using decision trees

For undecided cases, the framework uses decision trees to identify unfulfilled rule conditions and relevant supplementary information to request, then retries reasoning when input is updated. Its optimized approach identifies unfulfilled conditions together while accounting for variable dependencies.

5. Handling undecided cases using decision trees

  • The system builds trees for applicable rules, uses unmet conditions to request supplementary information, and retries reasoning with any updated input before classifying unresolved cases as undecided.This procedure is presented as contributing to identifying relevant information to request from the user (RQ4) and providing better explanations (RQ3).Source: §5 · p. 16

5.1. Architecture of the decision trees

  • Each applicable rule becomes a binary tree whose condition nodes branch on positive or negative checks and whose negative leaves explain why the rule was not respected.The section also proposes explanation forests to structure failure searches, including for FILTER NOT EXISTS and universal constraints, treating a universal failure as the failure of its consequence rather than its condition.Source: §5.1 · pp. 16–17

5.2. Constructing the trees from the SPARQL queries

  • SPARQL rules are parsed into NORMAL, NEGATION, UNIVERSAL, and UNION blocks, which are mapped to tree patterns; ASK queries evaluate node conditions and select branches.The block patterns preserve correspondence between tree nodes and rule conditions, while query construction tracks conditions already checked as satisfied.Source: §5.2 · pp. 19, 21, 22

5.3. Exploring the forest to identify unfulfilled conditions

  • Two traversal approaches are proposed: a naive search for the first unmet decisive conditions in each applicable rule, and an optimized search for the largest satisfied subset.The optimized approach aims to identify all unmet decisive conditions rather than only the first set.Source: §5.3 · p. 23, §5.3.2 · p. 26

5.3.1. A naive approach: Seeking the first unfulfilled decisive conditions

  • The naive approach follows condition checks to a leaf, then ranks applicable rules by relative tree depth; it can miss later unmet conditions and misrank rules with fewer failures.It assumes that deeper conditions tend to be more precise and indicate closer compliance, but the paper notes that this can fail when early context conditions are unmet.Source: §5.3.1 · p. 25

5.3.2. An optimized approach: Seeking all the unfulfilled conditions

  • The optimized procedure repeatedly finds unmet conditions, removes them and dependent conditions from a simplified rule, rebuilds its tree, and checks again.Determining which dependent conditions to remove requires dependency analysis among rule conditions.Source: §5.3.2 · p. 26
  • The method splits a rule into its biggest respected sub-rule and all unfulfilled conditions, which can be requested from the user at once.The procedure is repeated until the tree reaches a leaf indicating that the rule is respected (labeled “OK” in the examples).Source: §5.3.2 · p. 26
  • To avoid removing conditions that depend on variables introduced by violated conditions, the method uses a dependency graph under a sequence-parallel assumption.It removes violated conditions, then removes an unverified condition only when all its variables depend on removed variables; otherwise, it keeps the condition.Source: §5.3.2 · pp. 26–27

6. Conclusions

The paper presents a decision-support framework for reasoning over and justifying regulatory decisions, including decision-tree methods for identifying information to request when rules do not yield a conclusion. Its LEA data-sharing use case is proof-of-concept; broader rule coverage and large-scale real-world benchmarking remain future work.

6. Conclusions

  • The framework combines legal-rule reasoning and justification with decision trees that identify unfulfilled conditions when no rule is satisfied.The trees help identify relevant information to ask the user.Source: §6 · p. 27
  • The approach is illustrated through a use case on data sharing among European Law Enforcement Agencies.Source: §6 · p. 27
  • Current tests are limited to proof-of-concepts, and the authors plan a full benchmark with real-world data.Source: §6 · p. 27
  • Future work includes extending the tested rules to newer directives and automating formal-rule extraction with NLP methods.Source: §6 · p. 27
  • The authors also propose testing standards such as LegalRuleML and adding case-based reasoning using past decision traces.Source: §6 · p. 27

Appendix A

Appendix A describes a naive tree-traversal procedure that executes ASK queries against an endpoint and returns the reached node together with unrespected conditions.

Appendix A

  • The traversal takes a query, its associated tree, and an endpoint, and returns the reached node and list of unrespected conditions.Source: Appendix A · p. 29
  • Traversal continues while the current node is not a leaf, including special handling for UNION sub-blocks.Source: Appendix A · p. 29
  • For a UNION sub-block, the procedure adds node conditions to a temporary query and executes an ASK query at the endpoint.Source: Appendix A · p. 29
  • After the UNION block, traversal advances using the query result and continues through subsequent nodes.Source: Appendix A · p. 29

26 end

The appendix defines a function for advancing through the tree based on an ASK-query result and returning the updated node and unrespected conditions.

26 end

  • The traversal procedure returns the node reached and the unrespected conditions.Source: §26 · p. 29
  • The appendix labels this function as the mechanism for advancing through the tree according to the ASK-query result.Source: §26 · p. 30
  • The next-node function takes the boolean query result, current node, and unrespected-condition list, then returns an updated node and list.Source: §26 · p. 30

3 else

The displayed algorithm fragment adds a node's content to the list of unrespected conditions.

3 else

  • The fragment adds the current node's content to the unrespected-condition list.Source: §3 · p. 30

6 end

The closing line returns a pair consisting of a node and an `unrespected` value.

6 end

  • The routine returns a pair containing a node and an `unrespected` value.Source: §6 · p. 30
Loading 2609.35370v1…