RegelRecht Validation: From Analysis-First to Execution-First

Problem statement

Turning law into working software is hard. For fifteen years, teams have worked in silos on methods, frameworks, and languages for formalizing legal rules. None of them scale.

This document traces those fifteen years and sets out a validation method that fits the way RegelRecht works. The procedure as it runs today is summarized on Execution-First Validation; this page is the argument behind it.

Existing methods

Wetsanalyse

Wetsanalyse is a legal analysis method developed in the practice of Dutch implementation agencies (Belastingdienst, UWV, DUO). The method is codified in the book Wetsanalyse (Ausems, Bulles & Lokin, 2021) and maintained by Lokin (Hooghiemstra & Partners) and Gort (ICTU).

The core of Wetsanalyse is the Juridisch Analyseschema (JAS): a classification system of 13 element types that labels every formulation in legislation, from legal subject and legal relationship to derivation rule and condition.

The process has six steps:

It has three characteristics:

1. People do everything: annotation, definition, modeling, and validation are all human work
2. Validation checks your own work: the multidisciplinary team reviews models it built itself
3. Traceability is built in: every element in the knowledge model points back to the source text in the law

The output is a knowledge model consisting of a data model (FBM/ER), rule model (DMN decision tables), and process model (BPMN). This model is the basis for building an IT system.

Common ground across existing methods

Despite differences in terminology, existing methods follow the same pattern:

1. Decomposition: break the legal text into manageable units
2. Identification: recognize key concepts (who, what, when, what consequence)
3. Interpretation: explicitly record what the law means
4. Modeling: organize into data, rule, and process models
5. Validation: test against concrete scenarios and test cases
6. Traceability: trace every rule back to the source

All these methods are analysis-first: they start from the law and work toward a model or rule set. The translation is done entirely by people.

The RegelRecht ecosystem

RegelRecht is a broad execution ecosystem for making laws machine-executable, wider in scope than a method or a DSL. Three principles set it apart from the analysis-first tradition.

Execution-first

Where existing methods share an analysis-first approach, RegelRecht aims to create a coherent system of machine-executable legislation. Laws interact across boundaries and citizens are not burdened with complexity.

The rulework gets single source of truth status for how the law works. It is not an analysis layer that leads to a translation. The output of the analysis is the law in executable form.

Transparent and simple

The execution-first starting point requires transparency: open source, and understandable to experts from different disciplines when they need to reach a joint decision on how laws work.

The core of the schema consists of simple logical operators that people can verify. No vendor lock-in, no convoluted stack of schemas.

Scalable analysis

Existing methods laid the groundwork for dealing with the legal reality of machine-executability. That process is interdisciplinary and intensive.

Within the RegelRecht ecosystem, generative AI is the starting point: AI generates candidate ruleworks, and the analysis (or validation) runs against those candidates. This creates potential for faster and broader coverage.

The expert’s changing role

AI changes the role of the legal expert:

The bottleneck moves from creation to validation.

Risks of the shift

The shift introduces specific risks that do not exist in analysis-first:

• Automation bias: the tendency to accept AI output as correct
• Anchoring: the AI’s proposal influences the expert’s judgment
• Blind spots: the AI does not know what it does not know; neither does a reviewer who is not actively searching
• Implicit interpretation choices: where the law is ambiguous, the AI makes a choice without documenting it

Where legal validation fits

When this page was first written, the automated pipeline ended at reverse validation, and the step after it was a gap: nobody had a structured way to judge the AI’s proposal as a lawyer would. The desk checks have since closed part of that gap.

The automated and desk steps cover:

• Structural correctness: schema validation
• Behavioral correctness: BDD tests based on MvT examples
• Traceability: reverse validation checks whether every element points to the legal text
• Fidelity to the letter: an audit per lid that separates what the text says from what the toelichting explains
• Conceptual soundness: a check that a value bound across two laws means the same thing in both

What remains for the expert is judgement: where the law allows more than one reading, where practice decides, where the text is defective. That differs from the Wetsanalyse validation step (step 4), because:

1. The expert did not build the proposal; the mental model is absent
2. The AI does not document its interpretation choices; they must be uncovered
3. The scale demands an efficient process; not every law can take weeks

Validation method in four phases

Phase A: Generate (automated, in use)

This is the current pipeline, run by hand through the law-interpret skill or at scale by the enrich worker. The AI generates a candidate rulework and automated checks filter structural errors and untraceable elements. The output is a proposal with documentation:

• Traceability report: which elements are grounded in the legal text, which are assumptions
• BDD results: which MvT scenarios pass and fail
• List of assumptions: elements that do not follow directly from the text but are needed for execution

Phase B: Expert preparation

The expert reviews the proposal before scenarios are run. It draws on insights from Wetsanalyse. The desk skills now prepare most of the material for it: the corpus review reports coverage (B1), reverse validation lists the assumptions (B2), and the letter-fidelity audit lists the places where the letter and the toelichting part ways (B3). The judgement on each item is still the expert’s.

B1. Completeness check: Are all articles covered? Did the AI skip articles that contain executable logic? This is analogous to the scope step (step 1) of Wetsanalyse, asked after the fact: has everything been analyzed?

B2. Assumption assessment: Reverse validation has flagged assumptions. The expert assesses each one: is this a defensible choice, or does it need to change? This addresses the risk of implicit interpretation choices.

B3. Interpretation inventory: Where does the law allow multiple readings? Which reading did the AI pick? Is it defensible? This is analogous to the meaning step (step 3) of Wetsanalyse, asked in reverse: is the AI’s reading correct? This step counters automation bias.

Phase C: Scenario validation (workshop)

The expert validates the behavior of the rulework, not the YAML itself.

C1. Walk through MvT scenarios: The engine runs scenarios from parliamentary documents. The expert checks whether the outcomes follow from the law as enacted, and where they differ from the example, which of the two is right.

C2. Build adversarial scenarios: This is where the expert is irreplaceable. The AI has no access to case law, implementation practice, or political context. The expert builds scenarios that stress-test the rulework:

• Edge cases from practice and case law
• Exception paths (“unless” clauses)
• Boundary values (just above/below thresholds)
• Concurrence situations (interaction between laws)

C3. Run adversarial scenarios: The engine runs them. The expert checks the outcomes. Errors lead to iteration.

Phase D: Wrap-up

Analogous to the policy-gap step (step 5) of Wetsanalyse:

• Policy gaps are noted, where the law underspecifies and a choice was made
• Assumptions are formally accepted or rejected
• Expert sign-off is recorded

Design principles of the method

The expert does not read YAML

The expert reviews reports and outcomes, not the rulework itself. The automated pipeline delivers:

• A traceability report in readable form
• Scenario outcomes with references to legal articles
• A list of assumptions and interpretation choices

The expert challenges the proposal

The difference with Wetsanalyse validation matters: the expert did not build the proposal and must actively search for errors. The method structures that search by asking for adversarial scenarios.

The letter leads, the MvT tests

The first version of this method treated worked examples from the Memorie van Toelichting as ground truth: when the engine disagreed with an example, the rulework was wrong. Practice showed that rule to be too strong. An MvT explains the bill as introduced, and Parliament then amends it; in the Wet op de zorgtoeslag the original memorandum works out an example in which an insured person with an uninsured partner receives no allowance at all, an outcome a nota van wijziging rejected and replaced with the rule in the law today. An example is therefore a test to be checked against the enacted text, not a norm. When the two disagree, the text decides, and the disagreement itself is a finding worth recording.

The method is iterative

The method itself is developed via a Design Science Research approach:

1. Design a hypothetical validation process based on insights from Wetsanalyse and Human-GenAI interaction
2. Present it to experts from the legal domain
3. Run the process in workshops with real cases
4. Evaluate and iterate
5. Publish findings

Comparison with Wetsanalyse

The method keeps the discipline of Wetsanalyse (traceability, scenarios, policy gaps) but adapts the execution to the reality that the expert judges rather than builds.

Status

The generate, check and desk steps are in use; the skills that carry them are listed on Execution-First Validation. The expert phases are designed and have their tooling (regelrecht-audit-products for a validation session, regelrecht-uitvoeringstoets for a session with implementation practice), but the repository records no validating workshop yet. What it does record is a legal expert’s written review of three RFCs (RFC-002, RFC-008 and RFC-009), whose eleven corrections seed the curated legal memo in RFC-027, and a session with OCW and DUO around one proof of concept. The Design Science Research loop above has not yet reached its workshops, and there are no findings to publish.