From Prose to Model

A law is prose. Before software can apply it, someone has to read the text, interpret it, and translate it into rules, and today that happens anew in every agency, every software house, and every company. In the first post of this series we described what a digital twin of legislation is meant to deliver. This post shows how one is built: in four layers that separate text, meaning, parameters, and computation so that nothing is lost and every result can be traced back to the wording.

Why a single translation step is not enough

Today's path from statute to software is one big leap. Lawyers draft the text, it is promulgated, and then the work of implementation begins: business units interpret, developers code, and with every amendment the cycle starts over. Dag Wiese Schartum described this transition from legal sources to program code in 2020 as a multi-stage transformation process ("From Legal Sources to Programming Code"); it is precisely in this process that effort, errors, and diverging interpretations arise, in every organization that goes through it. For the Upper Austrian tourism levy, our current use case at the Institute of Business Informatics – Data & Knowledge Engineering at Johannes Kepler University Linz, roughly 29,000 liable businesses have to embed the same calculation in their accounting systems or spreadsheets. One law, thousands of implementations.

We have tried two paths ourselves that fall short. For our book "Der selbstfahrende Staat" (Springer Gabler 2024) we represented the Austrian IT collective agreement as a purely structural XML document. The structure was clean, but a program could derive nothing from it because the meaning of the terms was missing; the hoped-for savings did not materialize. Later we modeled the Upper Austrian landscape levy as a Prolog program. That was executable, but the evaluation, which is still under way, has so far shown that the code is not easily readable for lawyers or for most computer scientists. The lesson from both attempts: structure alone is too little, and logic alone is too opaque. What is missing is an architecture that connects both and never lets the trail back to the text break.

The blueprint: smart contracts and digital twins

Two concepts from other disciplines supply the building instructions. Smart contracts, as standardized by the Accord Project for automated agreements, separate three levels: the text of the agreement, a model holding the parameters, and the logic that executes when the conditions are met. Jason Allen described this interlocking of natural and formal language in 2022 as "wrapped and stacked": the formal part is embedded in the natural-language text, not put in its place.

Digital twins from mechanical engineering and manufacturing contribute the second principle. A twin never represents all of reality, only a deliberately limited slice of it, and it stays synchronized with its original (Tao et al. 2018). Applied to legislation, this means we do not model the entire body of law but those provisions that can be decided deterministically, and every amendment is carried into the model.

In our paper at the International Legal Informatics Symposium IRIS 2025 in February we brought both principles together and added a further layer: the ontology. A contract knows its parties, but a law has to define its terms for everyone who applies it. Without a shared, machine-readable meaning of "business", "revenue", or "municipality class", every system computes with its own interpretation.

The four layers

The architecture separates four concerns that are interwoven in the statutory text. The table shows them using the tourism levy as an example, which the Upper Austrian Tourism Act 2018 (Oö. Tourismusgesetz 2018) regulates as the tourism contribution (Tourismusbeitrag) payable by entrepreneurs.

Text: the law remains the law

The lowest layer is the statutory text itself, in its original format and without any adaptation to technical needs. This is not nostalgia but a prerequisite: every ontology class, every parameter, and every line of code must be traceable to a passage in the text. To that end, each provision receives a unique identifier, for instance according to the European Legislation Identifier (ELI), which the Austrian federal Legal Information System already supports. Anyone who later wants a decision explained always ends up here, at the wording.

Ontology: meaning that everyone shares

The second layer defines what the law is talking about. For the tourism levy, these are classes such as tourism business, liable revenue, tourism municipality, municipality class, and contribution group, together with their relationships: a business is located in a municipality, a municipality belongs to a municipality class, a business is assigned to a contribution group. We model this ontology in OWL, the W3C standard for ontologies, because it makes existing tools, existing legal ontologies, and links to other data sources usable. The ontology is the layer that lets software, statute, and reality speak the same language.

Configuration: what changes without the procedure changing

Laws contain numbers: percentages, allowances, thresholds, key dates. These values do not belong in the code but in a layer of their own that extends the ontology with concrete axioms. For the tourism levy, these are the rates per contribution group and municipality class, the minimum contributions, and the upper limit of the assessment base. In our first prototype for income tax, which we presented at IRIS 2025, they were tax brackets with a lower bound, an upper bound, and a rate. When the legislature changes a rate, one value in the configuration changes; the logic remains untouched.

The configuration also defines the twin's interface: which inputs a calculation needs and which output it delivers. Here a deliberate restriction applies. An interface exists only for decision fragments that can be computed deterministically from the defined inputs. Wherever discretion, open-textured legal terms, or missing evidence come into play, the twin offers no function and instead hands the case back to people.

Logic: the computation that explains itself

The top layer is the executable logic. For the tourism levy it reads in a single sentence: the contribution is the rate for the combination of contribution group and municipality class, applied to the capped revenue, but at least the minimum contribution. The function fetches rates and minimum contributions from the configuration, checks the classification of the business through the ontology, and logs every step with a reference to the underlying provision. From this log comes the explanation that a citizen or a company is entitled to demand.

We implement this layer in Python, not in a language invented specifically for law. Domain-specific languages promise elegance, but the learning curve is steep, experts are scarce, and readability for lawyers is no better. A widely used language with testing tools, version control, and a large community is the more pragmatic route. The logic is provided as a service with a REST interface so that government case-management applications and the business software of the companies concerned can both access it.

The working path from prose to model

So how do you get from a section of a statute to these four layers? In our prototypes, a five-step procedure has proven itself, repeated for every functionality of a law.

1. Delimit. Which provisions can be decided deterministically and which require judgment? Only the former are modeled. For the tourism levy, the amount of the contribution is computable; a waiver in an individual case remains a matter for the authority.
2. Slice into functions. The law is broken down into self-contained units such as "calculation of the contribution amount" or "determination of the liable revenue". Each unit receives a title, a scope, and the list of sections it covers.
3. Fix the terms. Classes, properties, and relationships for the ontology are extracted from the unit's text; every term points to the passage it comes from.
4. Extract the parameters. All figures, tables, and key dates move into the configuration; at the same time, the interface is defined.
5. Write and verify the logic. The calculation is implemented and tested against cases that tax experts have computed by hand. Only when the model and the expert judgment agree is the unit considered accepted.

Language models can supply proposals in steps two to five, such as an initial segmentation or candidates for ontology classes. They do not decide. Every proposal is confirmed, corrected, or rejected by people with legal and technical expertise. This is not temporary caution but a design principle: the twin is a verifiable, versioned artifact, not a chat transcript.

The text remains the law. The model is its verifiable application.

What the separation delivers and where it ends

The benefit of the four layers shows up when something changes. If a term changes, the ontology is adjusted; if a value changes, the configuration; if the procedure changes, the logic. Every change stays local, and the text shows what changed and why. An auditor can trace the definitions in the ontology, the values in force on a given date in the configuration, and the decision path in the code separately. And instead of a thousandfold translation there is one: a centrally provided twin can be used by everyone affected through its interface, whether from an agency's case-management application or from a company's accounting software. In our architectural design, a Digital Execution System takes on the task of receiving case data, invoking the twin, and passing on the results.

Just as important is what the architecture does not promise. It replaces no interpretation. Open-textured legal terms, balancing decisions, and hardship cases remain expressly outside the model; that is not a weakness but the reason the model is viable under the rule of law. A twin that computes only what the law unambiguously specifies and hands everything else back to people creates certainty on both sides: for the administration that deploys it and for the citizens who are subject to its results.

The next step

We presented the architecture in February at IRIS 2025 in Vienna and put it up for discussion in March as a works-in-progress contribution at the ACM Symposium on Computer Science and Law 2025 in Munich; you will find both papers under Publications. The vision behind it is described on the page Digital Twin of Legislation. Anyone in a public administration or a company who knows a provision that is reprogrammed many times over today is invited to walk it through the four layers with us.