By: Alexis N. Chun
Industry Director @ Computational Law Centre (CCLAW) at Singapore Management University
Co-founder of Legalese.com
In 2011, Marc Andreessen said “software is eating the world”. And with that in mind, a computer scientist and a lawyer decided to do just that. Legalese.com was born, and 5 years later, Singapore Management University’s Centre for Computational Law.
The Status Quo
Commas alone have cost one million (Canadian) dollars, millions in taxpayers’ dollars, and even gotten someone out of a parking ticket. Richard Susskind OBE has written about The End of Lawyers and the law firm’s business model has been described as “risking obsolescence”, “rigged to fail”, and trapped “in a death spiral”. The Atlantic said the legal profession was “the only job with an industry devoted to helping people quit”. That’s all rather grim, but probably not news. You get it, the status quo sucks.
But why does it seem to suck?
The legal industry has been described as being “trapped in 1995”. I think that’s rather generous.
Going back a little, let’s look at what a lawyer might have looked like in 1918, the year the typewriter was invented:
- They probably charged by the hour for input (not output), so that’s incentivising them to be the most inefficient lawyer they can get away with being
- Being humans, they were error-prone, have imperfect recall, and leaned on their experience
- They probably also relied on professional indemnities & a whole kitchen sink of assumptions
- And if they’re really fancy, they probably had a typewriter that was just invented!
Now what does the average lawyer look like 105 years later? Not that different – except they use Microsoft Word as their main technology (and some, like I was required to, are still trained to use typewriters for particular tasks).
That’s not great – 105 years on, lawyers still use technology to only help with the typing (i.e. the manual labour) but not with the thinking.
And if one may be permitted to speak frankly, in a world where cars drive themselves, computers are beating our doctors (and our lawyers), and AI is beating some of our best at Go, lip-reading, comprehension… it seems quite mad to pay a human $600 an hour to “copy and paste” words on a page.
But we’ve got LegalTech – yes, for quite some time now
LegalTech seems to be the buzzword these days following hot on the heels of FinTech and blockchain technologies. LegalGeek has mapped it out, Thomson Reuters, Stanford, Law Hackers, and hey, Legalese too (including a deadpool of those who have come and gone).
So why isn’t LegalTech (that’s been around for so long) being widely adopted?
The lazy answer:
“It is difficult to get a man to understand something, when his salary depends on his not understanding it”, said Upton Sinclair (1935).
The slightly less lazy answer:
If we look at the categories of innovation, they’re mostly still using technology that helps with the manual labour. In Peter Thiel’s Zero to One, he talks about progress coming in 2 forms:
One: horizontal / extensive progress (copying things that work)
Two: vertical / intensive progress (doing new things).
With horizontal progress, you look at a problem that’s currently being solved by a typewriter and innovate by throwing 10 typewriters at it. With vertical progress, you invent the word processor. And we think the time is ripe for computational law to introduce vertical progress to the legal industry.
Enter: Computational Law
But first… is law even amenable to computation?
With some fundamental innovations, we certainly think so. Just because law predates software (which is eating the world…), doesn’t mean that law or the legal industry is incompatible with software or computation. Our insight is that lawyers are kind of like the lost tribe of programmers.
If we look at the software industry 50 years ago, we can see a parallel with the legal industry of today. 50 years ago, software was proprietary, there were no high-level languages, there was no open source community, and there was no git. If you wanted something done, you hired a team of programmers to do it from scratch, by hand, with fees starting at a few hundred thousand. Doesn’t that look like most law firms today? If the analogy holds, the legal industry’s future might look a lot like the software industry’s past.
The language problem in law
Contract drafting seems to be, essentially, a small team of programmers (a fancy term for specialists with unusual skills in stylised language and abstract reasoning) writing proprietary code by hand. Contracts and programs are both, fundamentally, specifications for the distributed execution of business processes… except, lawyers have a language problem. Lawyers use different words to mean the same thing, and bewilderingly, also the same words to mean different things! That’s pseudocode.
Foundational technology: a domain-specific language for law
To bypass the natural language problem that plagues legal today, we propose to start by creating a domain-specific language (DSL) for law. That is, a formal programming language specifically designed to capture the semantics, deontics, and pragmatics of law. Once you have a skein of a DSL as infrastructure, you can then use it to write everything that makes up law: statutes, regulations, contracts, guidelines, business process logic, rules, quasi-legal documentation, you name it (for easy reference, we’ll call this collective of things capable of being written in a DSL “Law” from now onwards).
Syntax → semantics → pragmatics
And this is seminal because once you have a DSL, Law now has a common denominator. And a common denominator gets you from pseudocode to real code. That’s what we suspect a contract wants to be when it grows up: a program. And the marvellous thing about programs is that Law can graduate from simply expressing syntax (i.e. words on a page, legalistic expressions) that are essentially pseudocode to semantics (i.e. what does it mean in an objective or clearly defined fashion), to pragmatics (i.e. what does it mean for me). Semantics and pragmatics are the traditional demesnes of lawyers; these are things you’d pay and ask for a lawyer’s advice on. But lawyers’ service of semantics and pragmatics may be too much like a priesthood (and too expensive) for most end users: go forth with this blessed document, but don’t break your back carving out the laundry list of assumptions, professional indemnities, and deciphering what exactly it means for you. Take faith. This just might not cut it anymore for the increasingly tech-savvy and knowledge-driven common man on the Clapham omnibus who reviews and background checks everything including their drivers, romantic dates, and restaurants.
Next week in this 3-part series, we will talk a little more about what Computational Law might do for the future of law and lawyers. See you then.
Alexis is a recovering lawyer and self-taught programmer.
As cofounder of Legalese.com, Alexis spends her day exorcising legal demons and unlearning her bad habits. Legalese is a LegalTech startup that is developing a domain-specific language for computational law. By applying computer science to contract drafting, generation, and management, Legalese aims to eventually replace contract-drafting lawyers with contract-drafting software.
Since 2020, she has also been dual-hatting as Industry Director at the Computational Law Centre (CCLAW) at Singapore Management University( under the Computational Law Research Programme (the “Programme”).
In her previous life, she was a dispute resolution, technology, and IP lawyer in one of the largest transnational law firms in Asia. Alexis is an advocate and solicitor of the Supreme Court of Singapore. She has a Bachelor of Laws (Second Upper with Honours) from Queen Mary, University of London (2011). She loves Belle & Sebastian, computer games, and carbs-on-carbs. She is heavily influenced by science fiction, and when she grows up, she’d like to be Tina Fey.
This research / project is supported by the National Research Foundation, Singapore under its Industry Alignment Fund – Pre-positioning (IAF-PP) Funding Initiative. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not reflect the views of National Research Foundation, Singapore.