Logic: the building block of legal automation

From the beginning of Josef, we’ve focused on making the process of creating bots easy. We aimed to make it as easy as possible for anyone to tell a legal bot what to say, when to say it and what to produce.

While we got most of that right – it never ceases to amaze me what even non-technical people can build on Josef in a couple of hours – the thing we didn’t anticipate from the outset was the stuff that happens before people start building their bots. 

Our users quickly grasped how to tell the bot what to say; they just didn’t know what the bot should be saying in the first place. They found the process of breaking down a legal task or process or concept hard. And fair enough!

So, we went back to the drawing board. How could we help people do this? How could we teach them to think like a bot?

1 + 1 = Guilty!

Luckily, we weren’t the first people to deal with these sorts of questions. 

In the 1600s, Gottfried Leibniz, a German philosopher, mathematician and jurist, began to explore how we could express legal propositions using mathematics. His mission was to make the legal system more certain.

Leibniz was in some ways the first practitioner of computational law, a field of research concerned with the mechanisation of legal reasoning. 

And one could almost draw a straight line from his work to the first legal bots built in the United States in the 1960s and 70s. One of the earliest examples was a bot called TAXMAN, which was created at Stanford University and could provide automated advice in relation to the taxation law consequences of a corporate reorganisation.

Interestingly, even with these limited early examples, their creators could see the potential future benefits of legal technology. As one of the creators of TAXMAN noted in a 1977 paper:

“… the TAXMAN system provides a number of techniques that should be useful in automating the more mundane aspects of legal research and analysis.”

Breaking down the law

So, how did they do this? And what can a 17th century mathematician teach us about building legal bots in 2020?

Just like Leibniz and the Fellows of Stanford Law School in the 1970s, when building a legal bot, our first task is to break down a legal concept or task into something that a computer could understand.

The way that we do this now is remarkably similar to the way it was done in the past. 

One of Leibniz’s favourite examples of a legal obligation was drawn from a Classical hypothetical. It is the simple story of a shipping contract between Primus (the First) and Secundus (the Second). In this story, the original contractual obligation was expressed as follows:

“Secundus’s right to receive 100 dinar from Primus is suspended until the ship arrives from Asia.”

To express this using formal logic, Leibniz turned the contractual obligation into the following:

“If a ship arrives from Asia, then Primus must pay 100 dinar to Secundus.”

This second construction is what is called a conditional statement, which is the same type of logic builders use at Josef to digitise legal processes. A simpler example of a conditional statement is:

“If it rains, I’ll get wet.”

A conditional statement like this describes a relationship of truth between the antecedent (the first thing, being the rain) and the consequent (the second thing, being a wet version of me). In other words, if the first thing is true, the second thing must also be true.

If we take a more modern example, section 3 of the Victorian criminal code states:

“Notwithstanding any rule of law to the contrary, a person convicted of murder is liable to level 1 imprisonment (life).”

If we wanted to express this in a conditional statement, how would you do it? One way is:

“If murder, then liable to life imprisonment.”

Map it out!

Once we’ve got a handle on how to do this for one step in the process, we can repeat it for every stage, creating a kind of map or decision-tree.

The above image from Margaret Hagan’s work is a perfect example, using conditional statements at every step in the flow to come to an ultimate conclusion, here being whether or not something is hearsay. 

Some builders do this directly using the flowchart functionality in Josef, others in a Word document and yet others using a pen and paper. What matters isn’t how it happens, but that it does happen.

(If you want to check out more of Margaret Hagan’s work, visit her website! It’s well worth a look.)

Old dogs can learn new tricks

What I find most interesting when working with our users is that, no matter how foreign this stuff can seem at the start, it quickly becomes second nature. 

In some ways, this isn’t surprising at all. As legal professionals we’re taught the importance of thinking clearly and precisely, and that is exactly what this kind of work requires of us.

But, in another way, it also teaches us something quite profound: no matter how confident we are in the way we do things, no matter how certain we are that we know everything we need to know, no matter how sure of ourselves we are, there is always more to learn. 

And, as trite as it may sound, all you have to do is have a go.

If you want to learn more about logic and legal automation, book in a time with one of our automation experts!