Usable legal artifacts: a thought experiment
Imagine a Voight-Kampff test to distinguish lawyers-who-draft-for-a-living from everyone else. The relative weight placed on precision over succinctness would likely be part of it.
The problem is implicit in Lord Bingham’s first principle of the rule of law: the law should be “accessible and so far as possible intelligible, clear and predictable.”
But sometimes clarity requires detail. And what does “accessibility” mean? Accessible to anyone, or just to anyone with enough reading comprehension, focus and time?
Two centuries ago, Jeremy Bentham was ambitious for more:
To promulgate a law, is to present it to the minds of those who are to be governed by it in such manner as that they may have it habitually in their memories, and may possess every facility for consulting it, if they have any doubts respecting what it prescribes.
You don’t have to have read David Graeber to feel afflicted by overwhelming legal complication: even lawyers struggle with it, outside their niche. The OECD has written about it. So has the UK Parliamentary Counsel’s Office, noting in 2013 that:
… while there are many reasons for adding complexity, there is no compelling incentive to create simplicity or to avoid making an intricate web of laws even more complex.
But still the problem grows. Even in B2B, it afflicts regulations, contracts, compliance manuals, process guides, corporate constitutions and more.
This article first discusses the causes of the problem and current approaches to it. It concludes with a thought experiment about another possible way to address it, accepting that there is no single, simple solution.
Ten causes of complication
There are at least ten causes of complication in legal artifacts:
First, we may just need detail to predictably deal with a nuanced issue in various foreseeable scenarios.
Secondly, the scope of law’s empire seems ever increasing: what is regulated, how intensely, and how harsh are the consequences of breach. This prompts further complication in the private legal artifacts that help businesses cope with all that law.
Thirdly, we tend to confuse complexity with complication: to assume that the latter can help with the former when relationships and collaboration might be more fruitful.
Fourthly, where drafters expect their wording to be attacked by people looking for holes, they “penetration test” the wording and fill those holes.
Fifthly, legal texts are typically negotiated by people with differing commercial, political or organisational interests; and with varied attitudes to complication. If a counterparty suggests a complication, it is often smart to agree to it if you can live with it, perhaps introducing a further complication to smooth off any sharp edges. As loud tends to drive out quiet, and bad money drives out good, complicated drafting seems to drive out simple.
Sixthly, some people use complication deliberately, as a tool.
Seventhly, the individual drafter may feel defended by complication. To put it in jobsworth terms, nobody gets fired for overcomplicating.
Eighthly, those who work with legal text usually don’t have the time, mandate or motivation to make it better. You have to go along with things that you know are dysfunctional. We’ve all been there: don’t hate the player.
Ninthly, it’s already hard enough to train lawyers on the use of plain, clear language. Training on simplification is another level of hard, given all the complicating forces.
Tenthly, legal work cultures are highly fragmented between places, sectors, organisations and other contexts. The pressure of having to communicate really well outside one’s fragment is often just not there.
It’s a tough problem.
Addressing the problem
There are many valid, established ways to cope with legal complication, but each has limitations.
The most important ways are low-tech: industry-standard terms and shorthands for specialised transactions (e.g. INCOTERMS, LMA); bespoke plain English summaries of complicated legal regimes or documents; bespoke attention to the wording and design of legal documents so users can quickly grasp the points they care about; just shortening artifacts and accepting some imprecision risk; or in certain narrow contexts, imposing word limits. Having judges who are prepared to throw the book at the verbose is somewhat useful; hands-on regulation (trust the regulator, not the contract) may also help; legislating for conciseness in the abstract (e.g. GDPR article 12(1)) perhaps less so.
Technology has some value. Software can now nudge us towards better drafting habits, or debug legal text by checking definitions and cross-references. There are many commercial libraries of established text, and we are now seeing early versions of software that suggests clauses to use in context. Technology can help manage complication for sophisticated customers by applying rules in a consistent, auditable way: e.g. smart contracts or the legislative equivalent. There is now also a plethora of tools for identifying and extracting some structured information from unstructured text.
But still the problem grows. Without wishing to suggest that there is a single solution, the rest of this article explores whether there might be something else that could help.
Thought experiment
The following thought experiment doesn’t rely on experimental tech, but on ideas which are mainstream in the tech industry but not in law: different perspectives; modularity and progressive disclosure; and community culture.
Different perspectives
Legal drafting skill is like the expertise of a software engineer. “Being clear and precise”, in the way lawyers mean it, isn’t the same as “communicating effectively with normals”. I’m not being pejorative here: lawyers who talk about better drafting sound to me like software engineers discussing “clean code”. It’s a wonderful idea, but not enough to communicate outside the priesthood. Making their things understandable to the wider world is not something that engineers, or lawyers, can effectively manage alone.
Software firms have long addressed this by involving designers, with a different set of skills, to help engineers make things that speak to the outside world while retaining precision under the bonnet.
So there’s a clue: I don’t think lawyers can be left to solve the problem alone. They need help.
Modularity and progressive disclosure
Modularity and progressive disclosure can best be illustrated with examples:
Single attribute
Consider a contractual term with a single attribute. Ideally, the reader would see something like this:
Governing law: France
Not a sentence or paragraph, and not an abbreviation (“GL: FRA”). Just a really succinct, human-readable statement. The aim is to convey the practical meaning, but no more.
This could be turned into a component to allow you to substitute any other legal system. It could be implemented manually: a statement within the contract that you are relying on a certain set of components, and something to indicate when you’re actually doing so.
Such a component could also be automated, for example as an add-on to a word-processing application. Doing so would make it fairly trivial to save users from common pratfalls such as specifying “US” or “UK” law. “Governing law” might also have a unique code so that the user can see it as “proper law”, “applicable law”, “choice of law” or a corresponding phrase in another language.
That would be it so far as the ordinary reader is concerned, most of the time.
But, underlying it would be contractually binding text to ensure that the choice of law works as expected by a normal person, taking into account specific local quirks and practices, such as the US practice of specifically excluding renvoi and the growing EU practice of addressing non-contractual liability as well as contractual issues, in reliance on the Rome II Regulation.
In other words, the sort of thing that no normal person needs to read, but which it’s useful to include so as to avoid nasty surprises and arguments.
This approach involves ideas similar to those reflected in INCOTERMS for a century. Succinct trade usages in contexts such as insurance also have some similarities. But the suggestion is to generalise those basic ideas and make them widely usable by creating components containing multiple levels of detail, for all sorts of legal uses, in regulations, procedural codes, contracts and beyond. That’s modularity.
Multiple attributes
For a more sophisticated example, let’s try a contractual term with multiple attributes.
Here’s what the reader would see:
Confidentiality:
Each party agrees to keep the other party’s information confidential.
Exceptions:
(1) existence of this agreement
(2) disclosures agreed in writing
(3) audit
(4) professional advice
(5) compliance with legal orders
Duration of obligation: as long as the information remains confidential
This would be clear enough for most people’s practical purposes most of the time. The background text would cover all the usual clarifications and edge cases. With a bit more effort, the component could be linked up to the requirements of specific laws e.g. affecting possible duration.
Such a component could be configured to have an even simpler level of summary such as this:
Confidentiality:
Each party agrees to keep the other party’s information confidential.
Limited standard exceptions apply.
Or even:
Confidentiality: Mutual.
Those three examples could then be combined: you can see an ultra-compact two-word version, then expand progressively to see the two longer versions, and finally the full glory of the legal text in its “plain and clear” unreadable wordiness. Stop when you’ve seen enough.
It’s really a question of how far you want to take this approach in levels and the precise wording of each. I’m just illustrating the principle of progressive disclosure.
Statute
A similar concept could be applied to a statutory provision. Take this example, based on UK public order legislation. The ultra-compact version of an offence might be along these lines:
Affray: use or threat of unlawful violence
Further dimensions could be shown on demand, such as:
Required effect: a person of reasonable firmness hypothetically present at the scene would fear for their personal safety
Required state of mind: the accused either
(1) intended to use or threaten violence or
(2) was aware that their conduct may be violent or threaten violence
Maximum sentence: one or both of:
(1) three years imprisonment or
(2) an unlimited fine
This example is structurally different from the confidentiality one, because criminal offences have a predictable set of elements. The kind of disclosure and filtering required should be tweaked for context, though ideally with common design elements.
As with the contractual example, there would be detailed supporting text.
If such a component is well-designed, and its content kept up-to-date, it should also allow you to compare the position between countries much more easily than is currently possible.
All of the above is readily achievable, technically. It doesn’t rely on AI or any particularly fancy technology. But reliable and really well-designed content striking the right balance between summarisation and detail is quite a difficult thing to build and maintain, as illustrated by the limited impact of many past attempts to do something analogous (ranging from countless bespoke textual summary projects to Mozilla’s privacy icons experiment a decade ago).
A significant problem is trust: if the content of such components is built by a particular party or supplier group, it won’t be universally accepted. It needs to be looked at and negotiated from a number of perspectives if it’s to be widely credible.
Another issue is affordability: if a significant outlay is required, that will limit use.
Community culture
That brings us to the idea of “community culture”.
The competitive instinct is so ingrained that the idea of lawyers collaborating for their common benefit may be a hard sell. But models have evolved in the tech world for this sort of project, including open source aspects where people can build and share together, develop expertise and also share objective feedback without offence being taken. Wikipedia is probably the most famous, but within the software world there are many examples (Linux, Python, HTML and countless others), platforms such as GitHub for sharing materials on, and even guides on how to run such projects. Details vary (e.g. the emphasis on QA may be higher in a security project than for Wikipedia, even if this slows things down somewhat). But they always involve building some sort of community.
Would something like that be culturally possible in law? Clearly, not everyone would get it initially, but is it possible for those who do to make sufficient impact for it to work, perhaps in niches first but always with an eye to bigger possibilities?
Implementation might take different forms: a library of freely usable contract components covering whatever topics a viable community can form around. Small clause-level components might conveniently be combined to create larger components to cover more complex topics or even entire transactions.
There would always be a need for some bespokery but, over time, common terms would become accepted, with additions and improvements being progressively made over time.
Elements could be automated but with the role of natural language being retained for things which aren’t feasible or desirable to automate fully.
The component approach suggested here would probably not be part of the official law, for the near term: legislative and judicial practices are understandably conservative. But a trustworthy community could make summaries available in a common format if effectively organised and motivated.
Legal component communities?
So that’s the idea. Make things really short by putting the details behind a curtain with a trusted community to verify its legitimacy. Add some fairly straightforward tech to present it conveniently in human- and machine-readable formats, and allow people to implement it in their own products.
I think it’s worth doing because succinctness and trust in this area, if achievable, are important, not just economically but also to counter the crisis of alienation from legal materials. Bespoke “plain English” which is so wordy that hardly anybody reads it, and within which traps can be hidden, is arguably just as problematic in many ways as old school legalese.
Could this approach work? My intuition is that it might just make the world a slightly better place. I’d be interested to hear thoughts and to prompt a discussion. Is it feasible? If so, how could it become a reality? Where and how would we start?
Author:
Graeme Johnston is the CEO of Juralio, a software company based in Scotland. Before that, he was a partner at a global law firm, working in London and Asia. He’s also coordinating the open source legal project https://noslegal.org Feel free to get in touch via that website.
This article was originally published by Olly Buxton in his fabulous December 2020 newsletter, The Devil’s Advocate.
