Undecided Is Information: Turning Legal Reasoning Gaps into the Next Question

TL;DR for operators

A compliance system does not always fail because the rules conflict. Sometimes it has identified the relevant rules but lacks one or more facts needed to determine whether any of them is satisfied.

Bouche-Pillon and Zarat’s legal decision-support framework¹ makes that distinction operational. It represents cases and legal knowledge as knowledge graphs, executes formalized rules, handles defaults and exceptions, combines the surviving results into an overall normative conclusion, and connects decided outcomes back to their legal sources.

The more interesting design choice concerns cases that remain undecided. Instead of treating them as generic failures, the framework analyzes the structure of the applicable rules and identifies the conditions that are still unmet. Those conditions become targeted questions for the user.

For a regulated organization, that suggests a different architecture for automation: automate decisions whose rule paths are sufficiently determined, route genuine contradictions to experts, and use incomplete cases to drive structured information collection. The paper establishes the formal mechanism and demonstrates it as a proof of concept. It does not establish production-scale performance.

An unresolved case does not always need escalation

Consider a policy engine evaluating a case submitted by an employee, customer, investigator, or compliance analyst. The system determines that the governing regulation applies, yet none of its compliance rules can currently produce a decision.

There are several possible explanations. The case may contain conflicting legal conclusions. It may fall outside the regulation altogether. Or the relevant rule may simply depend on a fact that the user did not provide.

Those states demand different operational responses.

The framework separates them explicitly. A coherent result can be returned with its supporting legal rules. A contradiction exposes the conflicting rules and is intended for human expert validation. If no applicability rule is satisfied, the situation is treated as outside the scope of the encoded regulation. Only when rules are applicable but no compliance rule is satisfied does the system move into information elicitation.

That makes explainability part of workflow control rather than a report generated after reasoning is complete.

The rule engine is staged, not flat

The architecture begins with structured representations. General legal concepts, rule metadata, use-case-specific concepts, and individual situations are represented in ontology-compatible knowledge graphs. Separate named graphs compartmentalize user queries so information belonging to one case does not enter another.

Legal provisions are then decomposed into different rule roles: applicability rules determine whether a provision governs the situation; compliance rules encode the conditions under which a normative conclusion follows; implicit defaults supply conclusions under specified absences; and exception or priority rules can override earlier conclusions.

The paper implements these rules using SPARQL, used here as both a way to query structured facts and to express conditions over the knowledge graph.

Reasoning occurs in two stages. Explicit and implicit rules first add conclusions. Exception and priority rules then remove conclusions that have been superseded. This is a form of non-monotonic reasoning: a conclusion that was initially supported can be withdrawn when a relevant exception or higher-priority rule becomes applicable.

The remaining rules are combined using four deontic categories—Permission, Facultative, Obligation, and Interdiction. The paper formalizes their combinations with a truth table and Boolean expressions, yielding outcomes including a coherent normative status, simultaneous Permission and Facultative status, contradiction, or no respected compliance rule.

This separation matters because “no answer” is not one state. The explanation module needs to know why reasoning stopped before it can decide what the system should do next.

The decision trees diagnose rules; they do not predict outcomes

The paper’s use of decision trees can be misleading to an AI reader. These are not classifiers trained from historical cases.

They are constructed deterministically from the logical structure of applicable SPARQL rules.

Suppose an applicable compliance rule contains several predicates and nested logical conditions. The framework translates that structure into an explanation tree whose nodes correspond to conditions that must hold. The case knowledge graph is then evaluated against the tree. Traversal can reveal where the rule stopped being satisfiable under the currently supplied facts.

The output is therefore diagnostic: which condition prevents this rule from being established?

That changes the role of explanation. For a decided case, explanation traces a conclusion backward to supporting legal sources. For an undecided case, explanation looks forward by identifying information that could allow reasoning to continue.

This is particularly relevant to workflows in which missing facts can be obtained interactively. Instead of returning “insufficient information,” the system can identify what information is insufficient.

Finding the first failed condition is not enough

The paper also exposes a weakness in its initial diagnostic procedure.

A naive traversal stops at the first decisive unmet conditions and uses relative depth in the tree to estimate which rule is closest to satisfaction. That is attractive because it is simple. But tree depth is not the same thing as the number or structure of missing requirements.

A rule can fail early and still require only a small amount of additional information. Another can survive deeper into its tree while depending on several unresolved conditions. Stopping at the first failure can also hide later conditions that would remain unsatisfied even if the first one were supplied.

The optimized procedure therefore iterates. After detecting an unmet condition, it removes that condition from the analyzed structure, examines dependencies among variables, reconstructs the corresponding rule tree, and traverses it again. Repeating this process identifies a largest respected sub-rule together with the remaining relevant unfulfilled conditions.

The improvement is conceptual as much as algorithmic. A useful explanation of an incomplete case requires understanding the dependency structure of what is missing, not merely exposing the first predicate that evaluated unsuccessfully.

For compliance products, explanation becomes routing logic

The paper directly demonstrates a symbolic architecture and its explanation procedures. The broader product implications require inference.

For organizations maintaining formal policy or compliance engines, the design suggests four distinct system actions:

This distinction could reduce unnecessary escalation in workflows where many unresolved cases arise from incomplete inputs rather than substantive legal conflicts.

The same architecture also separates concerns that are often collapsed in policy engines: representing the governing rules, executing them, resolving exceptions, determining an overall normative status, and explaining the outcome. For maintainers, that separation could make rule changes easier to inspect because applicability, compliance, defaults, exceptions, and priorities have explicit roles.

There is also a governance benefit in the use of named case graphs: concurrent situations remain compartmentalized rather than sharing an undifferentiated working state.

These are design implications, not measured business outcomes. The paper does not quantify analyst time saved, error reduction, throughput, or deployment cost.

The formal machinery is ahead of the deployment evidence

The evidence is methodological rather than empirical. The framework is demonstrated through a limited European law-enforcement data-sharing and processing use case, with Article 10 of Directive (EU) 2016/680 serving as a principal running example. There is no reported large-scale benchmark or real-world case evaluation.

Several production questions therefore remain open.

Rule extraction and formalization are manual. Scalability across substantially larger legal rule bases has not been established. SPARQL is the evaluated rule formalism, while comparison with alternatives such as LegalRuleML is left for future work. The explanation mechanism is grounded primarily in enacted law rather than case-law precedent, and the system does not yet incorporate case-based reasoning from earlier decisions.

Most importantly, the paper shows that the proposed symbolic structures and algorithms can support the intended reasoning workflow. It does not show that comprehensive legal domains can be encoded economically, maintained reliably as regulations evolve, or operated at production scale.

Those are not secondary implementation details. They determine whether the architecture remains a tractable formal system or becomes an operational compliance platform.

An explanation can tell the system what to ask next

Much of explainable AI is framed around a completed decision: the system produces an answer, then explains where that answer came from.

This paper extends the role of explanation into cases where there is not yet an answer.

Its central architectural contribution is the integration of formal legal representation, executable symbolic reasoning, deontic aggregation, exception handling, and outcome-specific explanation. But the sharper operational idea is what happens at the unresolved boundary: an incomplete inference can itself contain enough structure to determine the next information request.

For regulated decision-support systems, that creates a useful separation. Decisions supported by the encoded rules can remain traceable. Genuine conflicts can be escalated. Out-of-scope requests can be identified. Incomplete cases can be interrogated before consuming expert attention.

Whether that workflow scales beyond a constrained proof of concept remains unanswered. The paper nevertheless identifies a concrete design principle: when a rule-based system cannot decide, its reasoning structure may still be able to explain precisely what it needs before trying again.

Cognaptus: Automate the Present, Incubate the Future.