Reflections on the design, applications and implementations of the normative specification language eFLINT

TL;DR

This paper discusses the design and application of eFLINT, a domain-specific language for automating legal compliance checks in software, addressing challenges like legal interpretation and evolving regulations.

Contribution

It provides a reflective analysis of eFLINT's design, linking legal and computational concepts to facilitate automated compliance in software systems.

Findings

eFLINT effectively formalizes legal concepts for computational reasoning

The language supports compliance checks at various stages of software execution

Design insights can guide future development of compliance automation tools

Abstract

Checking the compliance of software against laws, regulations and contracts is increasingly important and costly as the embedding of software into societal practices is getting more pervasive. Moreover, the digitalised services provided by governmental organisations and companies are governed by an increasing amount of laws and regulations, requiring highly adaptable compliance practices. A potential solution is to automate compliance using software. However, automating compliance is difficult for various reasons. Legal practices involve subjective processes such as interpretation and qualification. New laws and regulations come into effect regularly and laws and regulations, as well as their interpretations, are subjected to constant revision. In addition, computational reasoning with laws requires a cross-disciplinary process involving both legal and software expertise. This paper reflects on the domain-specific software language eFLINT developed to experiment with novel solutions. The language combines declarative and procedural elements to reason about situations and scenarios respectively, explicates and formalises connections between legal concepts and computational concepts, and is designed to automate compliance checks both before, during and after a software system runs. The various goals and applications areas for the language give rise to (conflicting) requirements. This paper reflects on the current design of the language by recalling various applications, the requirements they imposed, and subsequent design decisions. As such, this paper reports on results and insights of an investigation that can benefit language developers within the field of automated compliance.