For those interested, a video of my October 9, 2014 talk at Stanford Law School entitled “Machine Learning Within Law” has now been posted here.The talk discusses the application of machine learning artificial intelligence applied to automate certain tasks traditionally done by attorneys.
Computable Contracts Explained – Part IIThis is the second part of a series explaining “computable contracts.” For more about what a computable contract is, please see the first part here. OverviewIn the last post I defined computable contracts as contracts that were designed so that a computer could “understand” what was being promised and under what terms and conditions (metaphorically).We can think of a computable contract as a partial workaround to a particular technological limitation: computers can not reliably understand “traditional” English language contracts.The goal of this second part is to explain the intuition behind how an ordinary contract can become a computable contract.Three Steps to Computable Contracting
There are three steps to creating a computable contract:
1) Data-Oriented Contracting
2) Semantic Contract terms
3) Automated assessment of contract terms
I will discuss each of these steps in turn.Step 1 – Data-Oriented ContractingRecall the primary problem of Part I – computers cannot understand traditional contracts because they are written in languages like English. Computers are not nearly as good at people at understanding documents expressed in “natural” written language (i.e. the “Natural Language Processing Problem”).What is the solution? Write the contract in the language of computers, not in the language of people.This is known as data-oriented contracting (my terminology). In a data-oriented contract, the contracting parties deliberately express contract terms, conditions and promises, not in English, but as data – the language of computers.
This partially gets around the natural language processing problem – because we are not asking the computer to understand English language contracts. Rather, the parties are deliberately expressing their contract in a format amenable to computers – structured data.
Example of Data-Oriented Contracting
What does it mean to express a contract term as computer data?
Let’s continue with our earlier example: an option contract with an expiration date. Let’s imagine that one contracting party has the option to purchase 100 shares of Apple stock for $400 per share from the other, and that this option to buy the Apple stock expires on January 15, 2015.
Recall that one of the impediments to computers understanding traditional contracts was the flexibility of natural languages. A party crafting this provision in English could express the idea of an expiration date in innumerable ways. One might write, “This contract expires on January 15, 2015”, or “This contract is no longer valid after January 15, 2015”, or “The expiration date of this option is January 15, 2015.”
These are all reasonably equivalent formulations of the same concept – an expiration date. People are very adaptable at understanding such linguistic variations. But computers, not so much.
A Data-Oriented Term Equivalent?
Is there a way that we can express essentially the same information, but also make it reliably extractable by a computer? In some cases, the answer is yes. The parties need to simply express their contract term (the option expiration date) as highly structured computer data.
For instance, the equivalent of an “expiration provision”, expressed as structured data, might look something like this:
<Option_Expiration_Date : 01-15-2015>
The parties made this contract term readable by a computer by agreeing to always express the concept of an “expiration date” in one, specific, rigid, highly-structured way (as opposed the linguistic flexibility of natural languages like English).
If contracting parties can agree to express data in such a standard way, a computer can be given a set of rules by which it can reliably extract contract data such as expiration dates, buyers, sellers, etc.
Endowing Data with Legal Meaning
You might wonder, how does a piece of computer data like <Option_Expiration_Date : 01-15-2015> can acquire the legally significant meaning necessary for contracting?
There are essentially two ways that this happens. First, the contracting parties might get together ahead of time and agree that computer data in the format “<Option_Expiration_Date : Date>” should always be interpreted as “the option contract will expire after the date listed.”
Alternatively the parties, might agree to adhere to a pre-existing data standard in which contract terms have been previously well defined. Standardization groups often design standards and protocols that others can adhere to. For example, many modern, electronically-traded financial contracts are expressed as data according to the predefined FIX protocol and other data standards.
Pretty much any computer data format or language can be used for this purpose as long at it is structured (has a well-defined, consistent format). For example, others have written about using the structured data format XML for this purpose.
Note that data-oriented contracting is not always conducted completely as computer data, but rather can involve a mix of “traditional” English contracts and data-oriented contracts. Data-oriented contracting is sometimes built upon traditional, English language “master agreements which serve as the foundation for subsequent electronic, data-oriented contracting.
In sum, the first step to creating a computable contract is data-oriented contracting. This means that contracting parties express some or all of their contract terms as data (the language of computers), rather than in legal-English (the language of people).
Step 2 – Semantic Contract Terms
We just discussed how people come to understand the meaning of contract terms expressed as data. How do computers come to understand the meaning of such contract terms? The second step to creating computable contracts is to create “Semantic Contract Terms.”
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.
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.