How Quality Assurance for Justice Software Works

Last Updated on 29. October 2026

Quality assurance for justice software starts long before the first test. It starts with the question of how the law becomes a rule that a machine can execute. If you describe these rules in domain models instead of hiding them in program code, you can verify them before the application even runs. That way, many errors can be prevented instead of having to be tracked down later.

mgm technology partners has been applying this principle in tax administration for many years. On top of that, mgm brings experience from projects for clients in the legal services sector, whose work revolves around complex legal questions. This article shows why the approach matters so much for the judiciary, especially now that artificial intelligence (AI) brings new requirements.

Why Justice Software Can’t Afford Errors

Errors in justice software have direct consequences for people. A miscalculated deadline or a case file that ends up at the wrong court can delay proceedings and affect the rights of the parties involved. Judges, prosecutors, and judicial officers can only do their jobs well if they can rely on their IT.

Then there is the lifespan. Specialized applications in public administration often run for ten to twenty years. During that time, laws, responsibilities, and technical platforms change several times. A prototype can quickly show what is technically possible. A specialized application that courts work with for decades has to deliver far more. Quality assurance is not a phase at the end of a project here. It accompanies the software for as long as it is in use.

Where Errors in Justice Software Originate

Dr. Martin Varendorff, Quality Assurance Expert at mgm technology partners, explains: “In conventionally programmed software, a legal rule goes through several translations. The legislature formulates it, the administration interprets it, and developers convert it into code. At every step, it can drift away from its original intent.”

This is exactly the risk described in a short study on the digitalization of legislation (in German) published by Germany’s National E-Government Competence Center (NEGZ). “In the end, the business logic is scattered throughout the code, separate from the text of the law. Anyone who wants to check whether a rule has been implemented correctly first has to find it there. And with every change in the law, the translation starts all over again,” Varendorff adds.

Quality Assurance for Justice Software Starts with the Model

Model-driven software development shortens this chain. What counts is the domain model, not the code. Domain experts can review it themselves, even without programming skills. Because the code is generated from the model, the rule and the program cannot diverge. Errors surface earlier this way, often as early as requirements engineering.

A second effect concerns the technology. When code is generated from models, the team doesn’t have to verify every single line. The focus is on the generators and the building blocks they use. Applications built on the A12 AI Low Code Platform benefit from components that have already been quality-assured. Testers can concentrate on what defines each application: its business logic.

“That’s why quality assurance in model-driven enterprise software is our top priority at mgm,” Dr. Varendorff emphasizes. “It has to be clean and complete, because errors are simply not acceptable here. That follows from a simple relationship: An error in the model affects every place the model is used. The reverse is also true. Once a rule is corrected, it is correct everywhere after the next generation run.”

ELSTER: How Tax Law Becomes Verifiable Rules

The fact that this approach works at scale is demonstrated by ELSTER, Germany’s online platform for electronic tax returns (in German). The federal government and all states operate it jointly, with the Bavarian State Tax Office (Bayerisches Landesamt für Steuern, BayLfSt) in the lead. More than 25 million taxpayers now file their returns through it, and millions of users rely on the platform every day. mgm has supported ELSTER as a technology partner from the very beginning and continues to contribute to its development. At the core of the solution is the A12 platform.

As soon as data is entered, plausibility rules check whether information is missing or inconsistent. These rules are not scattered throughout the program code. ELSTER maps the legal framework in data models and captures the rule set in a domain-specific language (DSL) that is both human-readable and machine-executable. This single rule set automatically generates the checks for the Mein ELSTER online tax portal and for the programs of software vendors. In other words, a rule is described once and applies the same way everywhere. Because tax law changes regularly, a second point matters: The tax administration can adapt forms and rules on its own. The result: Error rates and processing times have dropped noticeably.

The Competence Center Public IT (ÖFIT) has described what this looks like in day-to-day work, using the example of digitalized corporate income tax (in German). At the Regional Finance Office (Oberfinanzdirektion) Frankfurt am Main, a team of tax experts without an IT background maintains the rules themselves. Anyone revising a rule writes the rule text directly instead of a separate specification, regenerates the application, and tests it. Automated comparisons help identify errors or contradictions between rules.

What the Judiciary Can Learn from This

The principle can be transferred to the judiciary. Here, too, the work is driven by rule-based domain logic: deadlines, jurisdiction, cost calculations, formal requirements. The more precisely these rules are described, the better they can be verified.

The NEGZ study (in German) shows that the approach is not limited to taxes. Authors from academia and practice, including experts from mgm, demonstrate that laws can be described in domain-specific languages and evaluated automatically. This explicitly applies to other areas of law as well, all the way to criminal law. One example from the study is closely related to the judiciary: statutory deadlines. Calculating them follows fixed rules, for example when a deadline falls on a weekend or a public holiday. Once described in a model, these rules apply the same way everywhere instead of being reprogrammed in every application.

Ensuring Quality Across the Entire Lifecycle

The model is the foundation, but it isn’t the whole of quality assurance. mgm sees QA as a continuous process, from requirements engineering to automated testing to stable operations. The benchmark is set by the people who will work with the software later on. In the judiciary, these are judges, prosecutors, and judicial officers, as well as court registry staff.

For hands-on work, mgm has built the Q12 Quality Landscape. Its tools for A12 applications start directly at the model. Q12-TDS checks rules, field definitions, and calculations during modeling. Q12-TDG generates suitable test data and checks the models for mathematical consistency. Q12-ATA generates UI tests from the A12 models. If a form changes, the tests are simply regenerated. Beyond that, Q12 covers security, performance, and accessibility, which is mandatory for public bodies in Germany anyway. For automated UI testing, mgm also uses QF-Test, the product of mgm subsidiary Quality First Software.

This pays off especially for long-lived applications. When a law changes, the model is updated, tests and test data are regenerated, and the regression tests run across the entire application again. This quickly reveals whether a change in one place has unwanted consequences elsewhere.

Outlook: AI and Law as Code

Interest in AI in legal practice is growing. For productive use, the same standards apply as for any other justice software. AI must be embedded in the specialized application in a traceable and manageable way, and it must work in the everyday reality of the courts.

The A12 AI Low Code Platform is designed as a deterministic AI framework for this purpose. It doesn’t come with built-in AI models but leaves the choice of language model open. The key is the division of labor: When models are created, AI can play to its strengths, for example when an AI agent generates an initial data model from a PDF form. At runtime, however, model interpreters and generators execute the rules deterministically. For the judiciary, this is the crucial point: AI helps describe the rules, but what gets applied is what’s in the verified model. Decisions remain traceable and auditable.

The NEGZ study gives good reasons for this separation: In AI systems, quirks in the training data can skew results, and not every result can be explained. That’s why mgm only uses AI within a manageable framework. Quality assurance, security testing, and build and deployment processes form this framework. Uncontrolled “vibe coding” has no place in business-critical applications. AI-supported features also need test cases, acceptance criteria, and a human who takes responsibility for the result.

The idea of “law as code” goes one step further. Today, experts still have to interpret a law manually before they can model it. As a result, contradictions and ambiguities often only come to light during implementation. The NEGZ study recommends creating models during the legislative process itself, jointly by lawyers, administrative experts, and IT specialists. The goal is laws that humans and machines understand equally well. Learn more in our article on the Legal Tech Think Tank (in German).

Dr. Martin Varendorff sums it up: “Whether it’s a tax return or court proceedings, the demands on the software remain the same. It has to be right, today and fifteen years from now. Thorough testing at the end isn’t enough. Quality is created where the law becomes a rule: in the model. Systematic quality assurance across the entire lifecycle ensures that this standard holds up in everyday practice.”

FAQ