LAWDACT

(VERY ROUGH DRAFT THOUGHTS)

Overview

Legal documents need to be unambiguous. Legal documents need to be easily modifiable and adaptable. Legal documents need to be concise. Legal documents need to be simple to draft and to read.

English is just about the worst possible language you could pick for drafting legal documents.

In English, even the meaning of a single word can be a subject of interpretation. Computers do not have the ability to exercise judgment, so computer programmers have a lot of experience creating and using non-English languages that are meticulously unambiguous by only allowing definitions to flow directly from universal axioms (we call them "primitives").

Like lawyers, computer programmers often create new works by assembling existing pieces into frameworks while adding a small amount of customization. Lawyers use "boilerplate text" and "standard clauses", where computer programmers use more formal and structured concepts like "objects", "parameters", and "components".

Legal documents written in English can be, and often are, internally inconsistent. Even well trained lawyers often miss these inconsistencies while tirelessly reading though endless pages of prose. Computer programmers have tools to find and eliminate internal inconsistencies from our programs. We even have tools that can locate possible semantic and stylistic problems in our code1.

I propose defining a new meta-language that was created solely for representing legal documents. It would look much like a computer programming language.

Here is a very simple example of what it might look like...

English LawDact
I, Josh Levine (the Buyer) agree to purchase the bunny identified as "Ralph" (the Bunny) from Murell Levine (the Seller) for the price of $10.00 which will consist of a down payment of $5.00 payable today, January 10th, 2005, plus a final payment of $5.00 to be made upon delivery of the Bunny on January 24th, 2005. clause BunnyContract extends Us.Ny.Ucc.Contract
   in buyer is Us.Common.Natural_Person
   in seller is Us.Common.Natural_Person
   in gross_payment is Currency
   in payout_delay is Date_Range
   in payout_split is Percentage
   in execution_date is Date
   in bunny is Freeform_Name
 

   on (execution_date)
      buyer->seller transfer (gross_payment*payout_split)
   on (execution_date+payout_delay)
      buyer->seller transfer (gross_payment*inverse(payout_split)
      seller->buyer transfer bunny

Document BunnyContract
   buyer="Josh Levine"
   seller="Murell Levine"
   gross_payment=$10.00
   payout_delay={0/14/0}
   payout_split=0.50%
   execution_date={TODAY}
   bunny="Ralph"

At first glance, the English version might look a bit more pithy, but that is only because I've defined an entirely new document type (a "bunny contract") in the LawDact version for illustrative purposes. If I were in the bunny business, it is likely that I would have had my lawyer draft the "clause" section for me many years ago2, and I would only need to include it by reference, making the whole document be only...

Document BunnyContract
   buyer="Josh Levine"
   seller="Murell Levine"
   gross_payment=$10.00
   payout_delay={0/14/0}
   payout_split=0.50%
   execution_date={TODAY}
   bunny="Ralph"

 Notice that the BunnyContract clause itself is based on an existing document, notably the United States Uniform Commercial Code contract form with New York State adaptations. This document itself is based on the more general non-state specific United States Uniform Commercial Code form.  In the English version, this is all implied rather than stated explicitly, so there is room for misunderstanding if, say, the buyer assumed that they contract would be enforceable under New Jersey laws because he lives in NJ. 

The real beauty in the LawDact version comes when something changes, and things always change. Say that the buyer gets stuck in traffic on the day when he was supposed to sign and make his down payment. The seller is understanding postpones the meeting until the next day and instructs her attorney to make any necessary adjustments. The attorney happily changes the "January 10th, 2005" to "January 11th, 2005". Unfortunately in the English version, it is unclear that the parties had intended the delivery date to be 2 weeks after the contract signing, rather than specifically on 1/24/2005. In the LawDact version the agreed meaning is clear and the attorney would not have needed to do anything, since the contract date is defined as TODAY, which will be correct no matter what day the contract is executed. The delivery date will also always automatically be correct in the LawDact version.

With the English version, the two parties would have needed to read the new contract before signing it. Maybe they would have noticed that the contract no longer matched their intentions and they would have called upon the attorney to alter it again to fix it. More likely, they would not have noticed the mistake and on delivery date would have had a problem that could have ultimately resulted in litigation.

You can imagine any number of other scenarios where small changes to this transaction would result in redrafting of the actual text of the English document whereas in LawDact, only the stipulated parameters would need to be adjusted. In LawDact, the entire document automatically reflects any changes consistently, without requiring anyone to re-read the new document to find possible inconsistencies or changes in meaning.

Adoption and Backwards Compatibility

It is unrealistic to think that every lawyer in the world will immediately drop English and start using LawDact. It is even more unrealistic to think that any jurisdiction will initially accept a LawDact document as a legal enforceable contract.

Luckily, because LawDact is highly structured, it is possible create a LawDact to English transcoder. This would be a program that would read in a LawDact document and output a legal document written in English that corresponded exactly to the contents of the LawDact document. There could even be a variety of different transcoders available- one that created standard style legalese or one that created "plain English" output.

At first, LawDact would serve only as an intermediate tool to aid in creating a final document in English. There would be large productivity gains for firms and people that adopted LawDact even in this limited, internal usage. This would be especially true for firms with specialized practices where their re-occurring documents could be drafted in LawDact once and then quickly "run-off" each time a new version is needed.

The next step would be the use of LawDact during negotiation between firms. By direcly exchanging a LawDact version of a document, firms could avoid the need to re-read each page of each revised draft. Instead, they could focus on the actual semantics of changes in each version. This would also force parties to these contracts to actualy deal with and resolve ambiguities in the document during the negotiation stage, rather than after the contract is executed. Again, even though the ultimate work product would still be an transcoded English document, that document would be much more efficient to create thanks to LawDact. It would also avoid any inconstancies and ambiguities that might be present in a document created directly in English.

The next step would be to have native LawDact document become recognized as legally enforceable contracts. This would probably start with a few progressive jurisdictions who noticed that many of the English contracts coming before them were really just shadows of more expressive and concise LawDact documents. Dealing directly with the LawDact in these cases would be faster and fairer.

Finally, the dream is to have new legislation actually drafted directly in LawDact, possibly required by a constitutional amendment. Imagine living in a world where laws were internally consistent and understandable!

Note that in each of the adoption steps the people who adopt are better off than they were before adopting LawDact, and in no case much they give up anything to make the adoption. These are key attributes that can ease the widespread adoption of new and radical ideas.

The Pitch

I really think that it could change the world. There is currently so much time and effort wasted in drafting, reading, interpreting, and then litigating ambiguous legal documents. The whole concept of "meeting of the minds" has been lost in modern day contract law. Everyday there are a thousand examples of disputes and litigation that would have never happened if the contract had been drafted using a meta-language. How many billions of dollars of GNP are wasted each year in similar disputes?

If the new legal meta-language really took off for contracts, you might even have a shot at applying it to the drafting of legislation. Imagine a constitutional amendment that required that all new bills pass an automated internal-consistency check? What if you could feed two laws into a tool that would instantly output any contradictions between them?

Links

The Tractatus Logico-Philosophicus
The philosopher Wittgenstein once embarked on a much harder and broader problem by attempting create formal meta-language for all argument. I think LawDact could succeed where Tractus failed because the domain of legal documents is very limited and amenable to structure.

https://catala-lang.org/
Catala is a domain-specific programming language designed for deriving correct-by-construction implementations from legislative texts. It is far more developed, thought out, and impressive than LawDact. (added 6/20/2021)

https://resources.jetbrains.com/storage/products/mps/docs/MPS_DTO_Case_Study.pdf
https://www.youtube.com/watch?v=_-XMjfz3RcU
The Dutch goverment implemented a domain specific lanuage in their tax system (added 7/23/21)

Thoughts On Intentional Vagueness

I know that currently lots of deals have designed-in vagueness and each side independently thinks that the looseness benefits them. While this maybe be true, it is probably not true in the way that they think. Vagueness on material terms is probably zero sum at best, so both people can’t be right.

Maybe one of the sources of value of this vagueness is that it increases the cost of litigation for both sides and thus acts as a deterrence. This is a very inefficient way to get to this goal. Much better I think to have a true meeting of the minds on all terms, including an *explicit* agreement as to the value of litigation avoidance to both parties.

Another value of the vagueness is that it avoids drafting expenses. No reason to pay attorneys to hammer out details of things that are unlikely to be material since the net present value of the possible future litigation costs are lower than the net present value of the drafting costs. Again, I think a LawDact type system could help here by lowering the drafting costs so that finding agreement and avoiding litigation becomes the rational choice.

Finally, I think lawyers today are culturally biased to vagueness in contact drafting. This might be the hardest thing to change, but once clients demand tighter contacts lawyers will have to comply or lose business.

 

Notes

1) A company could easily create a LawDact "pre-processing filter" that could automatically detect violations in company policy in any potential contracts the company was considering signing.

ERROR: "This document was rejected because of a POLICY VIOLATION in line #233."
LINE: "rate=WSJ_Prime_Rate+0.01%"
POLICY: "US CORP only enters into debit contracts with interest rates at below or below prime rate."

2) Or I could have downloaded a free and publicly available pre-defined BunnyContract off the internet. Or I could have purchased a standard Blumberg BunnyContract along with the rights to include it by reference in my own documents for a year. Hopefully a whole industry would emerge that did nothing but develop new base documents for others to adapt and use. Like the current world of software, you'd likely be able to get many base documents for free (many even from the government) but they might be hard to use or lacking in other ways, while there could be very expensive base documents available for license that could be worth the price for some document consumers. 
 

2006-11-04 - Published
2006-12-24 - Expanded, notes added

###