Computable Contracts Explained – Part 1

I had the occasion to teach “Computable Contracts” to the Stanford Class on Legal Informatics recently.  Although I have written about computable contracts here, I thought I’d explain the concept in a more accessible form.

(Part 2 of “Computable Contracts Explained” is found here)

I. Overview: What is a Computable Contract?

What is a Computable Contract?   In brief, a computable contract is a contract that a computer can “understand.” In some instances, a computer can automatically assess whether the terms of a computable contract have been met.

How can computers understand contracts?  Here is the short answer (a more in-depth explanation appears below).  First, the concept of a computer “understanding” a contract is largely a metaphor.   The computer is not understanding the contract at the same deep conceptual or symbolic level as a literate person, but in a more limited sense.  Contracting parties express their contract in the language of computers – data – which allows the computer to reliably identify the contract components and subjects.  The parties also provide the computer with a series of rules that allow the computer to react in a sensible way that is consistent with the underlying meaning of the contractual promises.

Aren’t contracts complex, abstract, and executed in environments of legal and factual uncertainty?  Some are, but some aren’t. The short answer here is that essentially, the contracts that are made computable don’t involve the abstract, difficult or relatively uncertain legal topics that tend to occupy lawyers.  Rather (for the moment at least), computers are typically given contract terms and conditions with relatively well-defined subjects and determinable criteria that tend not to involve significant legal or factual uncertainty in the average case.

For this reason, there are limits to computable contracts: only small subsets of contracting scenarios can be made computable.  However, it turns out that these contexts are economically significant. Not all contracts can be made computable, but importantly, some can.

Importance of Computable Contracts 

There are a few reasons to pay attention to computable contracts.   For one, they have been quietly appearing in many industries, from finance to e-commerce.  Over the past 10 years, for instance, many modern contracts to purchase financial instruments (e.g. equities or derivatives) have transformed from traditional to electronic, “data-oriented” computable contracts.   Were you to examine a typical contract to purchase a standardized financial instrument these days, you would find that it looked more like a computer database record (i.e. computer data), and less like lawyerly writing on a document.

Computable contracts also have new properties that traditional, English-language, paper contracts do not have.  I will describe this in more depth in the next post, but in short, computable contracts can serve as inputs to other computer systems.  For instance, a risk management system at a financial firm can take computable contracts as direct inputs for analysis,  because, unlike traditional English contracts, computable contracts are data objects themselves.

II. Computable Contracts in More Detail

Having had a brief overview of computable contracts, the next few parts will discuss computable contracts in more detail.

A. What is a Computable Contract?

To understand computable contracts, it is helpful to start with a simple definition of a contract generally. 

A contract (roughly speaking) is a promise to do something in the future, usually according to some specified terms or conditions, with legal consequences if the promise is not performed.   For example, “I promise to sell you 100 shares of Apple stock for $400 per share on January 10, 2015.”

A computable contract is a contract that has been deliberately expressed by the contracting parties in such a way that a computer can:

1) understand what the contract is about;

2) determine whether or not the contract’s promises have been complied with (in some cases).

How can a computer “understand” a contract, and how can compliance legal obligations be “computed” electronically?

To understand this, it is crucial to first understand the particular problems that computable contracts were developed to address.

B. The Problem: Computers Can’t Understand Typical Contracts

The essential problem is that computers cannot understand “traditional” legal contracts as they are generally written today. “Traditional” legal contracts – (what most of us think of when we envision a “contract”) – are typically written in English, often in (paper or electronic) documents.

Let’s explore three reasons why computers cannot understand such traditional contracts, and how computable contracts can be understood as a partial workaround to some of these problems.

Reason 1: The Natural Language Processing (NLP) Problem

Computer scientists refer to the ordinary language that people use to communicate with one another – like English -as “natural language.”  Thus, documents such as books, newspaper articles, or emails would be considered “natural language” documents (as contrasted with computer programs, which are not).

A traditional contract is written in “legal English” – an impenetrable variant of ordinary English understandable largely by lawyers – containing words of legalese like “wherein” and “herein.” (“Seller hereby agrees to convey to buyer…”). Computer scientists consider traditional contracts to be “natural language” documents because they are written in ordinary language (as opposed to computer language).  Thus, I am not intending to complement legalese by referring to it as “natural.” Rather, it is only considered natural  in comparison to the mathematically formal languages used to program computers.

The branch of computer science research devoted to the computer-based understanding of natural language documents like books, newspaper, articles, or legal contracts known as “natural language processing” (NLP).

The problem is that contemporary computers are not nearly as good at people as understanding natural language documents.  While there have been great strides in computer-based natural language processing, computers still fall far short in terms of processing the structure and understanding the meaning of even simple sentences, let alone complex documents like contracts, as compared to literate people.

Let’s take an example of where contemporary computers might fall short compared to people. Natural language documents such as contracts tend to be relatively unstructured in the sense that natural language allows for multiple ways of expressing the same idea.  People writing contracts, in other words, are not limited to one, and only one, choice of words to convey a concept.

For instance, imagine a contract provision that simply identifies the buyer and the seller.  An attorney crafting this provision might chose among any of the following, relatively comparable formulations:  “John, the seller, promises to sell to Sally, the buyer”  or “Sally, hereby referred to as the ‘buyer’”, and “John”, hereby referred to as the “seller.”   We imagine that a literate person could probably read either of these provisions and reliably understand who is the buyer and who is the seller.   However, these are just two variants of this concept. Natural language permits hundreds or thousands more, logically comparable formulations of the same simple concept, and people generally have little trouble understanding these variants.

However, even a simple variant in such natural language formulation might trip up a computer as compared to a person. Computers can make errors in reading even such simple natural language texts – missing contextual clues – and making basic errors that would be trivial for a literate person to determine.  Even relatively basic shifts in language (“John agrees to sell to Sally” or “Sally, hereby referred to as the ‘purchaser’”) might confuse a computer given the wide flexibility and variability of natural language.   Thus, it might prove to be a significant hurdle for a computer to reliably perform a basic task, such as simply identifying the buyer or the seller in an arbitrary natural-language contract, given the unstructured and flexible nature of natural language.  This is a task that would be trivial for an attorney.

If such simple parsing problems are hard for computers, you can imagine that the more advanced problems of understanding complex contract provisions, or understanding the meaning and nuance in contract language, are harder still.

Thus, while there have been huge advances in automated natural language processing by computers over the last 15 years, a computer can still not read an ordinary legal-English contract and understand its contents (who is promising what to whom) with the accuracy and understanding of a similarly situated attorney.

Reason 2: Contract Terms Involving Discretion and Abstraction

The second reason that contemporary computers cannot understand a typical “traditional” contract has to do with the meanings of contract terms themselves.   Contracts often contain terms that are abstract or involve discretion such as “best efforts” or “material” or “reasonable.”  In many contracting scenarios, these discretionary or abstract terms pose little problems for people that work together in long-term business relationships in determining what is or is not “reasonable” or “material” to a contract promise (e.g. “relational contracts”).  However, rules-based computers tend to have difficulty assessing and applying words of discretion and subjectivity.

Similarly, many contract provisions are highly abstract in nature.  For instance, contracts often contain a basic provision a “merger clause”, which essentially says, “This documents is the complete and only and final agreement – any other pieces of paper other than this should not be considered part of this contract.” In other words: if its not in this document, the parties are not agreeing to it.   This is a fairly simple idea for a person to understand, but it is incredibly abstract.  How does one convey such abstract ideas such as “other documents” and “other promises” to a computer?  The answer is – it is hard to do so today.

Thus, our second problem is that computers are not as good at people at working with words of discretion or abstraction that often appear in complex contracts.  We can imagine a scenario in which every person agrees that something is reasonable, or material, but that a computer would not be able understand or process this due to the abstraction.  To the extent that contracts contain such terms, a computer would not be able to handle them adroitly.

Reason 3 – Legal Uncertainty

The third reason that computers cannot easily assess a typical contract has to due with uncertainty.  In part, performance with a contract involves looking at what was promised, and then seeing whether or not what was promised, actually happened.

As lawyers know, there can be a lot of uncertainty in determining compliance with contract obligations or other legal obligations.   There may be uncertainty about the governing law, about what specific terms mean or do or do not cover, or external obligations imposed by law, etc.  Similarly, there may be uncertainty about the facts.  A contract often involves some activity that either did or did not happen in the world.  However, in many cases, the answer to whether the activity happened according to the contract may not be black and white: there may be uncertainty about what did happen, differing opinions about quality, or good excuses for not performing, etc.

Such legal and factual uncertainty is hard enough for lawyers, let alone computers, which often can be stymied in environments of uncertainty.

Computer-Understandable Contracts Impossible?

Given these technological and legal impediments, it might seem that it would be impossible for contemporary computers to understand contracts and automatically assess compliance with their promises.

However, there is an approach to automating certain contracts, provided it is done in the appropriate context – and that is the computable contracting approach.

(Part 2 of “Computable Contracts Explained” is found here)

Because of the length, I am splitting this explanation into two posts (appearing in the next day or so).  The next post will discuss the computable contracting approach, how it actually works, its limits, and how it can be understood as a partial solution to the three problems just described.