“Claiming certainty where there is none would be the worse option”

Jan Liechti is a lawyer, MLaw, University of Bern. Most recently he worked in Legal & Compliance at a large retailer, before that as Head of Legal at an NGO. Since September he has been Legal Engineer at iudexnc, responsible for the legal calibration of the system: that the coverage check runs the way the policy conditions require, and that the result arrives in a form lawyers can work with.

The role

How would you explain to a head of claims what a legal engineer does?

I translate your legal logic, meaning coverage checks, deadlines and exclusions, into something that can be represented in software without losing legal precision. And I make sure the system only gives a clear assessment where the case supports one. Otherwise it has to state clearly what is open. The decision is taken by the person handling the case.

What drew you to the interface between law and software?

In my previous roles I regularly looked for tools that would make my work easier, for monitoring websites, for instance. What I needed did not exist off the shelf. So I started to look into it myself. What technology does to legal work has stayed with me ever since. At iudexnc I can help shape it instead of just watching.

The first weeks

What surprised you most?

How few people build and run a system of this complexity. That has to do with the way of working. There are few meetings, short decision paths and a lot of autonomy, but every step of the work is documented in writing. Coordination happens almost by itself as a result, rather than in meetings. As a lawyer you actually know this: a file that shows, traceably, who decided what and when replaces a lot of follow-up questions. The same applies to development here.

Where do lawyers and engineers talk past each other?

Both sides underestimate how hard the other's language is to understand. In the first weeks I read problem descriptions from engineering where even after several readings I could not say what had actually gone wrong. Conversely, a court ruling is just as complicated and impenetrable for most people.

Two kinds of “unclear”

“It depends” versus certainty. Have you felt that conflict?

That is exactly where it gets interesting for me as a lawyer. Instead of programming the “it depends” away, we want to point the lawyers handling the case specifically to ambiguities or conditions that need interpretation. Such cases should become visible in the case analysis, and further information can be requested if needed. Claiming certainty where there is none would be the worse option.

You have to keep two kinds of “unclear” apart. One is an information gap: a date is missing, a policy is missing. That is solvable, you request the document. The other is a genuine question of interpretation, where the condition supports both readings for this set of facts. No further document helps there. That needs a decision, and a person has to make it.

Patterns rather than single cases

How does your work differ from classic legal work?

I examine patterns more than individual cases. A single case that is assessed wrongly says little. It gets interesting when the same kind of error occurs several times. Then the question is what causes it. Is the system missing a piece of information, or is it drawing the wrong conclusion from what it has? The solution differs depending on the answer.

On top of that, you never solve just the one case. Every adjustment affects other cases. So you have to think legally and keep the architecture in view at the same time. And you have to decide whether a correction to the single case is enough or whether something in the system itself has to change.

What do you see that others on the team do not?

I notice different things than the others do. I have handled cases myself and know where they get stuck: which information you need at which point, in what order you check, what you have to read twice because it is in the wrong place. That shapes what I notice first when testing and what I propose when it comes to new features.

Jan Liechti is Legal Engineer at iudexnc, MLaw, University of Bern. Field notes show how the team works and what questions it is working on.