#RulesAsCode: LOGIAK as an environment for drafting logic

Matthew Waddington of the Legislative Drafting Office, Jersey has written a blog post to illustrate in the simplest way how formalizing the logical structure in law is compatible with leaving interpretations of concepts within the law to the normal complexity of human contextual interpretation:

Using Excel's if/and/or/not logic as a demo of "Rules as Code" for legislative drafters

In this article, I will re-use Matthew’s one rule example as an occasion to illustrate a small part of LOGIAK and to show its relevance for legal applications, in particular the drafting of provisions — #RulesAsCode

LOGIAK is an environment within which it is possible to represent logic formally, but also to compute with it — to test and validate it. Moreover, when you are happy with the logic you have created, you also — automatically — have an interactive system embodying your logic, with which people can interact, which can collect responses… (we stop now here to avoid going too far into other aspects of LOGIAK).

The whole thing is shown in a video here and the textual explanation below is provided in case it is helpful.

For now, we will

REPRESENT

1. Show how to represent the clause in LOGIAK

MODIFY AND EXPLORE

1. Show how we can immediately test and “debug” the clause.
2. Play a bit with the clause to show how easily we can modify things

VALIDATE

1. Define test cases!

The example is tiny, of course, but the advantage of that is that the whole thing doesn’t get outweighed by detail.

The single-rule example in the LOGIAK environment

The imagined legal provision in Matthew’s example is:

To get started, we need to create a Process.

LOGIAK Applications are assembled from components. A special kind of component is the Process.

Processes are (usually) interactive dialogues in which the system gathers information from the user and/or the database and performs reasoning and calculations with that information.

So let us make a Process which first gathers information we need to reason with Matthew’s imagined clause. We will define 3 steps in this Process:

First, we create a question:

STEP 1

This is a multiple-select question, which is non-mandatory (user check none).

Then we create two possible responses from the system:

STEP 2

STEP 3

Conditions

Next we define the logic. We do this via declarative definitions which, in LOGIAK, we call “Conditions”.

We can define what we might call “base conditions” which are defined in terms of the user responses (and potentially other sources of information).

We can also define “meta-conditions”. These are conditions which are defined by combing conditions already defined with logical connectives, such as AND and OR.

Matthew’s clause is: A person X must sing if X walks and either eats or drinks.

On the first step — the question — we define a condition which is true when the person walks and we give it an appropriate name “Person walks”. Here is what it looks like:

Then we define a second such condition which is true if the person either Eats or Drinks:

Now we are in a position to define a condition which represents Matthew’s clause. It is a meta-condition because the clause is true iff “Person walks” is true AND “”Person eats or drinks” is true,

Negation

One can easily define the negation of any condition with a single click, and it is useful in this case to have the negation of the clause:

Condition which represents the negation of the condition

Use conditions as Preconditions

Now we simply attach the conditions as preconditions to steps in the Process. When a step has a precondition, the step is not used unless the precondition is true.

We attach the positive condition as precondition for step 2 and the negation to step 3.

Debugging, modifying, validating

These steps are shown in this video, along with how to immediately debug the logic which has been defined, and even validate it with test cases.