Link Search Menu Expand Document


Automated decision-makingLegislation: executionLegislation: representation
Main research: March 2022


  1. What does it claim to do?
  2. Substantiation of claims & potential issues
  3. How might the end-user assess effectiveness?
  4. What form does it take?
  5. Is it currently in use?
  6. The creators
  7. Jurisdiction
  8. License

What does it claim to do?

RegelSpraak is a ‘controlled natural language’ (CNL), a form of :domain-specific language, designed for representing Dutch taxation rules. RegelSpraak rules can simultaneously be read by non-technical experts and executed by a machine to produce tax calculations. It is developed by the Dutch Tax Authority.

Claimed essential features

  • Represent tax laws in a human-readable and machine-executable form.
  • Enable integration of tax rules directly into production applications.
  • Identify the state of rules at any given point in time.

Claimed rationale and benefits

  • To facilitate a single representation usable by tax lawyers, IT developers, citizens, and machines.
  • To enable a “single point of definition” for tax laws.

“create a reusable specification of rules … based on the text of legislation and policy rules and validated by tax experts, enabling an automatic translation to high power execution code” (Corsius et al. 2021, p. 2)

  • Facilitate maintainable tax code (rules) and software code (programming).
  • Facilitate public-facing services, such as web-portals.

Claimed design choices

  • RegelSpraak is a controlled natural language (CNL) based on RuleSpeak, a business rules approach.
  • Executable rules have a single unambiguous result.
  • Rule syntax is tailored to Dutch natural language grammar.
  • Legal rules are decomposed into single statements more susceptible to software implementation (Wilmont et al. 2021, p. 6)
  • Conversion into executable code via translation and validation pipeline called the Agile Law Execution Factory (ALEF).

Substantiation of claims & potential issues

  • The rules currently used in the Dutch Tax Authority’s production systems are not publicly available, making their independent assessment difficult to perform.
  • Depending on the quality of the translation of legal provisions into RegelSpraak rules, the output might not be legally sound.
  • Those coding RegelSpraak interpretations of the law may not have the legal authority to conclusively determine the meaning of the rules (since they will usually not be working in a judicial capacity). This could be problematic if they are relied upon as authoritative statements of the law and are assumed to have legal effect.
  • Maintaining RegelSpraak representations of legal provisions may impose significant overhead due to changing judicial interpretations of (i) the original legal provisions, and (ii) fundamental rights that impact their application.
  • There may be a risk that RegelSpraak is used to formalise areas of law that are necessarily too complex or ambiguous for the kind of deductive reasoning the system is capable of.


  • Regelspraak is designed specifically to deal with Dutch taxation rules.


  • All rules take the form [RESULT] IF [CONDITIONS] (Corsius et al. 2021, p. 3)

  • Rule syntax, and the results of calculations, are tailored to Dutch grammar to support intelligibility in the Netherlands (ibid.)


  • A set of rule patterns have been developed to promote consistency in rule-writing, e.g. ‘basic calculation’ and ‘disjunction’ (Corsius et al. 2021, p. 4-5)

  • Reduces legal rules to single statements, more susceptible to software implementation (Wilmont et al. 2021, p. 6)


  • Currently there is no authoritative public reference available for either RegelSpraak or the toolchain built by the DTA for the language around the ALEF project for those who wish to study or inspect the software and language implementation.
  • Parts of the policies and motivations for the design of the compilation chain, have also been documented in academic writing. Notable Fokkenrood (2011), Lokin (2018), Jetbrains (2019) and most recently Wilmont et al. (2021) and Corsius et al. (2021).
  • The system around RegelSpraak at the DTA is best described through the process presented by Corsius et al. (2021), and gives a transformation pipeline that turns legislation into software:

    1. Analyse (new) legislation and draw up test cases annotation of the legislation, labelling pre-defined legal concepts, using ‘iKnow Cognitatie’ (a third-party specialist tool for this purpose).
    • Human readability is one of the explicit syntactic design choices of the RegelSpraak language. The origin of RegelSpraak is that its expressions are also syntactically correct Dutch. The semantics are enforced through the compilers (such as ALEF). The test-cases – while core to the process of software maintenance – implicitly encode assumptions about the correct mode of legal reasoning for these rules.
    1. Rule analysts develop rules based on the annotations, either using RuleXpress (another third-party application for rule-writing) as an intermediate, or directly into ALEF, and write these rules in the Regelspraak language.
    • ALEF contains the parser, compiler and object (type-)system for RegelSpraak, and was developed on the JetBrains MPS language workbench by the DTA.

    • In principle, the RegelSpraak toolchain can be developed independent from the rulesets it aims to turn into executables. This reinforces the idea that the ruleset is a single point of definition for the software.

    • Such an idea presumes that the compilers and their mode of rule based reasoning are not part of the definition process.

    1. The RegelSpraak rules are tested using the provided test cases, and the results assessed by a tax expert.
    • The machinery for rule-based reasoning is provided in the ALEF and Blaze compilation steps.

    • These execution models of these compilers are where the semantics are defined. However, the provided test can be additional authoritative constraints on the precise semantics of the RegelSpraak language.

  • 4.Once validated, the rules are translated again into Blaze, a “high-performance proprietary rule engine”

    • The DTA uses Blaze as a compilation target, but has in the past also built web, Java and COBOL applications through a similar system.

    • Typically, one would like to convey that these different products behave identical. This can be done through (empirical) testing, but it is also possible to prove that the compiler generates equivalent programs. It is unclear if the DTA has done the latter.

  • 5.The Blaze executable is again verified against the test cases to ensure the expected results. If validated, the resulting code is deployed in a production application.

    • The Rulespeak ruleset is validated both in the context of the compilation chain and the executable environment. This makes re-use of the ruleset only sensible in an environment that has the same compilation pipeline.

Rationale and Benefits

  • The core motivation of the system design by the Dutch Tax Authority (DTA) was the change to a more maintainable agile software development process, which focuses on short feedback loops between developers and domain experts, and rapid iterative improvement of the software.
  • The claimed ‘single point of definition’ is primarily to the benefit of software maintainability. The process from rules to executable consists of three distinct translation steps. The first is a human effort to rewrite legal rules into RegelSpraak rules. The other two are automated steps to respectively move from RegelSpraak code to Blaze code, and from Blaze code to an executable.



How might the end-user assess effectiveness?

Based on the descriptions provided of the rule-creation process, the output calculations are assessed and validated at least twice by tax law experts before they can be integrated in production applications. The literature does not, however, discuss any independent external verification, or publication, of these assessments.


What form does it take?


Component, Application


RegelSpraak is both a component (in terms of its controlled natural language element) and an application (in terms of the specific implementation, within a broader process, that leads to its practical use within the Dutch Tax Authority).

In terms of others making use of it, in principle the individual tools that make up the CNL and the rule creation pipeline could be brought together by another party, or combined in different ways (for example with fewer or more assessment steps, use of a rules engine other than Blaze, or some other differences).

It is bespoke in two senses: (i) the underlying CNL has been tailored to the Dutch language, and (ii) the goal is to write custom RegelSpraak rules that represent contingent tax laws.


Is it in current use?

According to Corsius et al (2021), “RegelSpraak now is a much appreciated and crucial tool in the DTA.”


The creators

Created by

In-house developers


The system has developed in-house by the Dutch Tax Administration since around 2011.



Background of developers

The Netherlands

Target jurisdiction

The Netherlands

Target legal domains

Initially taxation, though the creators are expanding its use within the Dutch administration to other fields.



The system is used internally by the Dutch Tax Administration. At time of writing, its RegelSpraak rules are not made available the public. As with other domain-specific languages (DSLs), in principle anyone can write text that fits the requirements of the language – but at time of writing the precise technical specification of RegelSpraak is also not available publicly.


Updated Top