Back to top

Automated Legal Decision Making

Last modified Feb 22


Legal tech applications for automated legal advice such as Flightright, Bahn-Buddy, Abfindungsheld or Hartz4Widerspruch solve common simple legal problems in tightly defined applications, while being available 24/7, at a low cost. Hereby such applications focus on the accessibility for layman, as well as on the legal compliance with regard to current jurisprudence.

Generally, such systems consist of the following components:

  • A dialog component collects the relevant facts of the individual case via a sequence of structured questions to the user. The input is made via text fields, data fields, tables, selection lists etc. and can be supported by help texts and video tutorials.
  • A data acquisition component automatically collects additional case-related structured facts from the information systems, such as the weather, exchange rates, the current rental price index, or registry statements, as needed.
  • A decision-making component uses a decision-making logic firmly coded by the programmer to derive a structured recommendation for action or a simple decision from these facts.
  • An explanatory component provides the recommended action or decision in a form that is useful to the user (for example, as text documents, completed forms, spreadsheets, checklists, and diagrams).

Similarly, established products provide tax and financial advice to individuals and businesses, and to support decision-making within companies (e.g., financial accounting) and administrations (e.g., admission to enrollment). In the market, such systems are often positioned as specialized expert systems (or AI systems); a computer scientist would rather view them as classic information systems.

Hence, this research aims at supporting legal decision-making processes, which are based on legal requirements, in a dynamic fashion. For that reason, an expert systems will be developed. Such an expert system needs to provide the architecture and functionality, in order to dynamically create and infer rules which depict a decsion-making process. As a result, the system is able to capture various decision making processes. 



A challenge of such systems is the acquisition of knowledge, i.e. the initial acquisition and frequent updating of the expertise of the respective domain and the correct translation by programmers into suitable data structures for knowledge representation and formal algorithms for efficient and deterministic inference. These calculate the decision or recommendation based on the case-specific facts.

This is where rule-based expert systems ("AI systems / AI platforms") such as Berkeley Bridge Software, Bryter, Checkbox, Logicnets, Neota Logic, Oracle (Policy Automation) or VisiRule systems come into play. They replace the hard-coded decision-making data structures and algorithms with a generalized reasoning engine that uses a unified language for knowledge representation (ontology language) and a uniform language for logic-based rule definition (rule language). Unlike the functional or imperative programming languages ​​commonly used today, the order of execution of the inference steps (and possibly also the dialog steps) is not explicitly determined by the programmer, but the reasoning engine uses strategies (forward chaining, backward chaining) and heuristics, for example to logically derive legally relevant results or instructions from a given case.

Furthermore, rule-based expert systems introduce a knowledge acquisition component that allows subject matter experts to formulate their domain knowledge in the form of facts and rules in those languages. Furthermore, the other components (dialog component, explanatory component, and data acquisition component) are generalized to also build on these generalized languages.


Reference Architecture

A reference architecture for rule-based expert systems are sketched in Figure 1, whose characteristic feature is that the knowledge base (ontology and rule set) is realized as a database. This has the following advantages:

  • Simplified changeability of the knowledge base
  • Greatly reduced programming effort
  • Transparency of the underlying legal rules
  • Traceability of the conclusions for a specific case.
  • Automatic consistency check of rules and facts within the knowledge base. In case of inconsistencies, cases can be identified that would lead to contradictory chains.
  • Since the dialogue component and the explanatory component themselves are no longer "hard-wired" programmed, but "model-based" to the current concepts, characteristics, relationships and facts of the ontology and the current rules and general logic of the rule language reference, they follow seamlessly and consistent with knowledge base changes.
  • Simplified version management and reuse of complex knowledge bases.
    The knowledge acquisition component can facilitate the exchange of knowledge representations between different expert systems of the same manufacturer (with restrictions also across manufacturer's limits).