Explainable Automated Decisions from the Digital Twin of Legislation

A decision without reasons can be challenged; an automated decision without reasons is not tenable. Anyone who wants to generate administrative decisions from a digital twin of legislation therefore has to deliver not only the correct result but also the path to it: which data, which provision, which parameter, which computational step. This article shows how the twin obtains that reasoning as a derivation log from its own execution, what experts from parliaments, academia, and legal practice demanded in our interview study, and where the explanation honestly ends.

The reasons are part of the decision, not its documentation

Administrative procedure law does not permit an adverse decision without reasons. In Austria, Section 58(2) of the General Administrative Procedure Act requires that a decision be reasoned as soon as a party's position is not fully accepted, and Section 60 defines what the reasoning must contain: the results of the investigation, the considerations that governed the assessment of evidence, and the legal assessment based on them. For tax decisions, Section 93(3) of the Federal Fiscal Code likewise requires reasons. In Germany, Section 39 of the Administrative Procedure Act imposes the duty to give reasons for every written administrative act.

For automated decisions, two European layers are added. The General Data Protection Regulation requires meaningful information about the logic involved in Articles 13 to 15 and restricts solely automated decisions with legal effect in Article 22. The AI Act, Regulation (EU) 2024/1689, in force since August 1, 2024, gives affected persons a right in Article 86 to an explanation of individual decisions based on high-risk systems and requires in Article 12 that such systems technically allow for the automatic recording of events over their entire lifetime. Whether a deterministic twin of legislation even qualifies as an AI system within the meaning of the regulation is secondary: the duty to give reasons under procedural law applies to every decision, regardless of who or what prepared it.

What matters is what reasoning has to accomplish. It must name the facts, the norm applied, the subsumption of one under the other, and the result, in a way that allows the affected person, the authority itself, and a court to retrace the path. Translated into software, this means the system must record the path from input data to result so that a caseworker, a judge, or the affected person can follow it without looking at the source code. An explanation reconstructed from the result after the fact does not meet this requirement. It has to arise during the decision itself.

What experts from parliament, academia, and practice demand

At the Institute of Business Informatics – Data & Knowledge Engineering at Johannes Kepler University Linz, Christoph Schütz and I investigated over the past months under which conditions automated decisions in administrative law are accepted at all. Methodologically we followed Grounded Theory as described by Strauss and Corbin: nine experts, interviewed in five interviews of 60 to 90 minutes, from the European Parliament (legislative governance, policy advice, IT strategy, IT unit, innovation lab), the legislative counsel of a national parliament, academia, notarial practice, and an ERP vendor for the public sector. The transcripts were condensed through open, axial, and selective coding with more than 60 open codes into four core categories. The study has been accepted for JURIX 2025, the international conference on Legal Knowledge and Information Systems in December.

The four core categories are: only part of the law can be automated; terms must be semantically aligned; laws need computable structures; and lawmaking and governance must adapt. What emerged across the categories during coding, however, was explainability. In our memos it was the intervening condition on which the acceptance of any automated execution depends.

"An inscrutable AI judge would never gain approval of the courts."

The sentence comes from an interviewee who himself completed judicial training but does not sit as a judge. A further statement from the interviews puts it from the perspective of a jurist: as a jurist he could not be satisfied with half-right solutions; he did not want something that is "probably" correct, he needed to know yes or no. Behind this lies a distinction that ran through all the interviews: deterministic computations such as levies, fees, or social insurance contributions are accepted as automatable because they are formulaic and produce the same result for the same input every time. Probabilistic statements, as produced by machine learning, were rejected for the legal yes-or-no decision, not out of skepticism toward technology, but because a decision that cannot state its reasons in legal terms does not hold up in court.

Three concrete requirements for a system that is allowed to decide follow from the interviews. First, it must state its reasons in the language of the law, with reference to the provision applied. Second, learning components, for instance for classifying submitted documents, may only be used upstream, must remain auditable, and must never be the sole basis of a decision. Third, escalation paths are needed: atypical cases, objections, and appeals go to humans, and the explanation must show which code path corresponds to which legal basis.

The derivation log: the reasoning arises while computing

We built exactly these three requirements into the architecture of the digital twin of legislation. In the article From Prose to Model we described the four layers that separate a law into text, ontology, configuration, and logic. For explainability, the decisive point is that each of these layers makes its own contribution to the reasoning and that the logic layer is built from the outset to log every step. The log is not a report about the computation; it is the computation, recorded in the order in which it took place.

For a business that has its contribution calculated under the Upper Austrian Tourism Act 2018, the derivation log reads roughly as follows:

1. Inputs. Municipality, business activity, and relevant revenue, each with its origin: declared by the business or taken from a register.
2. Subsumption. The business is a tourism business within the meaning of the act; its activity falls into a specific contribution group. Both statements refer to the definition in the text.
3. Assignment. The municipality belongs to a municipality class, with reference to the classification and its status in the contribution year.
4. Parameters. Percentage rate for the combination of contribution group and municipality class, cap on the assessment base, and minimum contribution, each with its source and period of validity from the configuration.
5. Calculation. Capped revenue times percentage rate, comparison with the minimum contribution, result.
6. Version. Version of the twin, status of the law, and timestamp of the execution.

This log is precisely the content that Section 60 of the General Administrative Procedure Act demands of a statement of reasons: facts, considerations, legal assessment. It is complete because no step can be executed without producing an entry. It is consistent because it stems from the same logic as the result and not from a downstream interpretation. And it is actionable: anyone who disagrees with the result can see which input to check or which provision to contest.

For oversight bodies and courts, the log changes the way they work. Auditors can replay the cases of a given period through the twin and establish whether every decision followed the codified law. A court can load the official twin, enter the facts, and compare the expected derivation with the contested decision; if the two differ, either the code was wrong or the data was, and both are immediately visible. If an error is discovered in the twin, there is a single place to fix it, and all affected cases can be recomputed with the corrected version. In a landscape where every authority and every software vendor codes the same provision independently, none of these three checks is possible.

Why a language model does not replace the reasoning

In the article Ontology or Language Model we compared both methods for turning law into code. For the explanation, the question is sharper. A language model's explanation is a text about a computation, not a record of it. In our experiments with the tourism levy, models that were given the statute and the inputs produced plausible-sounding chains of reasoning that differed between several runs with identical input and cited provisions incompletely or incorrectly. Such a text may be readable, but it proves nothing, because it does not come from the execution.

This does not mean that language models have no place in the explanation. The division of labor is different: the twin decides and logs, the model translates. Through the twin's interfaces, which we described in early September at the SEMANTiCS 2025 Developers Workshop as a REST API and via the Model Context Protocol, an assistant system can retrieve the derivation log, render it in plain language, and answer follow-up questions, for instance why the minimum contribution rule applied. Every statement it makes has an anchor in the log. The authority of the reasoning lies with the log, not with the prose. The twin for the tourism levy is publicly accessible at lawdigitaltwin.com, and its source code is openly available, so this division of labor can be examined and reproduced.

What the log cannot explain

An honest derivation log also shows where automation ends. The twin represents only what the law unambiguously determines. Discretion, undefined legal terms, the assessment of credibility, or a hardship case lie outside its model, and that is deliberate: our interviewees named asylum procedures as an example of what cannot be decided from documents alone. When the twin encounters such a case, incomplete data, or a constellation the law did not foresee, it must not invent a rule. It stops, hands the case over to humans, and records in the log at which step and for what reason. This entry, too, is part of the explanation.

Two further limits belong here. The log explains the execution of the wording, not the intent of the legislature; if a rule-compliant computation leads to a result that contradicts the purpose of the law, that is a finding for the legislature, not for the twin. And where upstream learning methods supply inputs, for instance when classifying a submitted receipt, the log must mark that input as such, with its own audit trail, so that it remains visible that the decision itself follows deterministically from the law.

For administrations that procure or build automated procedures, four requirements follow that belong in every call for tenders:

• The derivation log is a functional requirement with an acceptance criterion, not a documentation issue.
• Parameters carry a period of validity so that every case can be recomputed with the rules in force on its reference date.
• Provisions are cited via persistent identifiers so that the reasoning refers exactly to the version that applied.
• Escalation paths are part of the design, not of exception handling.

The next step

The vision from which this article stems is described on the page Digital Twin of Legislation. The papers on the architecture and on the interview study can be found under Publications. Anyone in a public authority who knows a procedure whose decisions must be reasoned and are to be generated automatically in the future is invited to walk through with us what the derivation log for it would have to look like.