Conceptual FAQ

• Will a judge interpret statute or contract clauses where there are ambiguities in language generated by the AI?

• Do judges have to read the L4 code?

• Will there be no more ambiguities in the law by relying on code?

• A judicial decision or a change in administrative procedures can have a profound effect in law. How can an Integrated Development Environment (IDE) for law deal with these kinds of changes?

• Can a computer really predict the possible outcomes for each contract?

• Wouldn’t contracts have to be hard-coded and thought up by the lawyer in the first place?

• At what scale/volume does the L4 development team see L4 gaining traction in law?

• Is this a matter of finding a uniform “language” that is accessible by all? If so, the main difficulty seems to be convincing everyone why the computational law “language” should be preferred over any another.

• Even if everyone in the legal domain agrees that there should be a common language to translate contracts into, why should we translate contracts into a computational “language”?

• How important is learning a programming language for a law student?

• Different jurisdictions share similarities but also express differences in legislation. How should lawyers manage regulations across jurisdictions?

Will a judge interpret statute or contract clauses where there are ambiguities in language generated by the AI?

The natural language generated by L4 is controlled by rules written by people; it is not generated by statistical AI like ChatGPT. The natural language is then reviewed and approved by law people.

It is possible that in the future, we may start to harness Large Language Models (LLMs) to help to speed up the first step: The encoding of laws into L4. But there will still be a human review step after that. The judge will not interpret the statute, it’s the agency in charge of the legislation. There will always be a human in the loop.

Do judges have to read the L4 code?

We are not expecting a judge to read L4; we are expecting the judge to read the English generated in L4.

Will there be no more ambiguities in the law by relying on code?

We, the L4 developers, make a distinction between vagueness and ambiguity and will define these two words. We are conscious that other people discuss vagueness and ambiguity differently.

Ambiguity refers to ‘language scoping’ issues, such as “John must eat and drink or dance”. Here, does John need to (eat and drink) or dance? Or does John need to eat and (drink or dance)? Vagueness refers to ‘definition’ issues. In the above example, what does ‘drinking’ mean? Does it mean taking a sip? Consuming a glass of drink? What kind of drink? These are issues of definition.

L4 aims to eliminate ambigiuity while giving you the choice to be as vague or specific as you want. You have the option of detailing exactly what terms mean. Alternatively, you can leave terms vaguely defined to allow for human input.

A judicial decision or a change in administrative procedures can have a profound effect in law. How can an Integrated Development Environment (IDE) for law deal with these kinds of changes?

The task of an IDE is to deal with the volatility of the source code. Using the IDE, you get to decide what is being enforcable. You might say: Disregard all pronouncements of what the government says about the law and enforce a legislation.” An alternative version is to say “let us respect what the government has said about a legislation and not enforce anything.” It is the job of the IDE to support both of these interpretations.

Can a computer really predict the possible outcomes for each contract?

There’s a subfield in Computer Science called “Formal Verification” that aims to solve the problem of getting computers to predict all possible outcomes given a scenario. A contract has a limited number of possible outcomes with some edge cases. Assuming that we can translate these scenarios and their outcomes into code, a computer can predict the outcomes for each contract.

Wouldn’t contracts have to be hard-coded and thought up by the lawyer in the first place?

In the first version of L4 we did hard code contracts since we knew the answer we were looking for. In the current and subsequent versions of L4, we will look at scenarios that are abstract and not hard-coded.

At what scale/volume does the L4 development team see L4 gaining traction in law?

Very slowly, then all at once. We would like people to view L4 as the first step into the future of computational law and argue that the future of computational law will be based on the L4 of today.

Is this a matter of finding a uniform “language” that is accessible by all? If so, the main difficulty seems to be convincing everyone why the computational law “language” should be preferred over any another.

The L4 encoding should be preferred because it’s easier to understand for laypeople. If we can explore the contract with animations and colours and diagrams, people may put in effort to understand the contracts they need to wrestle with. In the future, Large Language Models (LLMs) could use an L4 plugin to answer questions in LLMs in a way that gives more explainability.

Even if everyone in the legal domain agrees that there should be a common language to translate contracts into, why should we translate contracts into a computational “language”?

The biggest advantage after translating contracts into computational language is that we can represent the contract in different ways rather than just using paper. We imagine that people will be able to explore contracts as diagrams with animation.

How important is learning a programming language for a law student?

Law students around the world want to learn to program. More and more law schools are adding a programming module as they understand that computational thinking is important. It is important for law students to learn computational thinking, and rigorous and logical thinking. We believe that L4 is a way to improve lawyers’ critical thinking and logical reasoning.

Different jurisdictions share similarities but also express differences in legislation. How should lawyers manage regulations across jurisdictions?

We are sympathetic to the idea of different jurisdictions behaving differently. In software, we have Windows, Mac, and Linux as Operating Systems (OS) for computers. Programs written for one OS may not work in other OS. However, it’s possible to download source code for a program and run it in any of the above OS because programming langauges are a good way of unifying these parts together.

Software overcame this problem of incompatible code using libraries, and L4 anticipates this. It will have import statements and imports for regulations and jursidictions. For example, we might import an L4 library for Singapore, or Hong Kong. Both the Singapore and Hong Kong libraries can import the commonwealth library.