Computable Contracts Explained – Part II
This is the second part of a series explaining “computable contracts.” For more about what a computable contract is, please see the first part here.
In 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 Contracting
Recall 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.”