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. 

Overview

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.”

The word “semantic” has to do with the meaning of words.  We want the computer not just to be able to identify contract terms such as “expiration date”, but we also want to be able to convey the what the contract is about.

There is a problem – computers do not have the linguistic and cognitive abilities of people, and cannot understanding meaning of words in the way literate people can.  So how do computers come to understand the meaning of contract data?   Essentially, we tell them.  We provide the computer with rules by which it can react sensibly, in a way that is consistent with the actual meaning of the contract terms. 

For some (but not all) contract criteria, contracting parties can “translate” contract terms into analogous computer rules that faithfully replicate the meaning of the contract words.

Example of Semantic Contract Term

For example, how do we convey the semantics of a contract term – like an option contract expiration date – to a computer?   For such a term, it is possible to devise a set of computer rules that replicate the logic of what it means for a contract to have an expiration date.

Recall our contract term, “This option will expire on January 15, 2015” expressed in data as <Option_Expiration_Date:01-15-2015>”.

We can translate this to an analogous set of computer rules which essentially says the to the computer, “Don’t execute this option contract if today’s date is after January 15, 2015”

Semantic contract terms involves translating the logic or meaning of contract terms into a set of comparable computer-rules that allow a computer to react automatically in a manner that is consistent with the actual, human-understandable meaning of the contract term.  These rules can be quite complex and can allow for sophisticated automated behaviors.

The computer doesn’t actually understand the meaning of the contract words at the deep symbolic or cognitive level as a literate person.   However, the computer is able to react in a way that is functionally equivalent to what a similarly situated person, who understood the meaning, would have done.  A person, having read an option contract with a January 15, 2015 expiration date, would refuse to execute the contract if the date of execution was after the stated expiration date.

It is important to note that not all, or even most, contract terms or conditions can be translated into computer rules in this way (e.g. “Reasonable”).  But, importantly, some can, and those that can, can be converted into Semantic Contract Terms.

In sum, the second step to making a contract computable, is to make the contract terms Semantic – providing the computer with a series of computer rules by which the computer can automatically react in a sensible manner that is consistent with the underlying meaning of the contract terms or conditions.

Providing the computer with actionable rules (or data) is the key to making such a contract fully or partially automatable.

 

Step 3 – Automated Assessment of Contract Terms

The final step to making a contract computable is to enable a computer to automatically assess whether or not some of the contract terms have been complied with.

How can a computer know whether or not the contract terms have been performed?   In some significant part, contract performance hinges on on activities in the world – whether something that was promised actually happened according to the contractual conditions.

Increasingly, data that is relevant to determining conformance with many contract conditions – things like stock prices, transfers of money, deliveries — are now accessible to computers.  In the past, such information may have existed in inaccessible paper documents, or in peoples’ implicit knowledge. However, for the last 10-15 years, such information has been increasingly stored in computer databases and made accessible over computer networks such as the Internet.

Contract provisions sometimes hinge on data that is now automatically accessible. Thus, in some cases, the contracting parties can provide a computer with rules about where  to look for information that is relevant to determining whether or not the contractual agreemeents were complied with.

Example of Automated Assessment

For example, let’s continue with our scenario involving an option contract (one party is agreeing to sell another party Apple stock at a certain price as long as the option is executed before January 15, 2015).

A computer can be directed to sources of data that are relevant to determining conformance with key contract terms.  This can enable the computer to automatically determine conformance with these terms.

For instance, the parties can agree ahead of time about authoritative data sources about information such as price of the stock on a particular date. They can then provide a computer access to information about relevant information such as prices, whether or not the stock changed hands, and access to information about money flows, to see whether the money was transferred as promised.

In this way, a computer can make an automated, prima-face assessment of compliance with contract terms, because it has been given access (agreed to by the parties) to data pertinent to contract performance. Again, many modern financial systems can be characterized in this way, automatically able to assess whether financial instruments and money flows have changed hands.

Prima-Facie Automated Compliance

There are a few things to note about this.  First, the computer is able to only make an automated prima-facie (or “first cut”) assessment of compliance  with contractual terms, based upon the information that has been provided to it.  There may be other relevant legal considerations that are inaccessible to the computer, so the ultimate court-determination of compliance may disagree with the computer’s initial prima-facie assessment.

Thus, unlike the sophisticated analysis of a lawyer which might involve nuance or abstraction, this is a very basic, data-driven assessment. However, in contracting areas where things comparatively rarely go awry (compared to the volume of contracting), such a basic assessment may often be reasonably accurate.

Second, for the most part, computable contracts tends to only involve terms of comparative determinability and bright-line certainty – things like expiration-dates, stock-prices, money flows, and objects.   In other words, we are not asking the computer to make assessments of non-compliance with abstract, or highly uncertain contract terms or conditions.

“Captured Legal Assertions”

Is there a way that computers might be able to automatically assess compliance with even subjective or abstract contract terms?  Yes, to some extent.  I call this concept “captured legal assertions.”   Imagine that a contracting party makes a subjective assessment that some discretionary contract term has been met.  They can then “capture” their conclusions in a computer database, making these subjective conclusions accessible to a computer.

For example, imagine that a contract has a subjective term such as, “this building timeframe must be met according to best efforts.”  As mentioned in part I, computers on their own can’t easily assess such subjective terms even in scenarios where people might all be in agreement about the fact that “best efforts” were delivered.

However, if the contracting parties assess the project and agree that “best efforts” were delivered, they can “capture” this conclusion by entering it into a computer database – (e.g. Best-Efforts-Delivered = True).  The act of entering this key contract assessment into a structured computer database means that the computer can now access this legal conclusion.   The computer can then proceed to automatically determine that that this term has now been complied with – even though the term was subjective or abstract in nature.

Thus, the process of captured legal assertions allows computers to make automated assessments about compliance even in the face of subjective or abstract legal terms.  We are not asking the computer to make the assessment directly.   Rather, we are asking the contracting parties – people – to make this assessment, and then represent the outcome of their discretionary assessment in a form that is accessible to the computer – data.

New Properties

As mentioned earlier, computable contracts are interesting because they have new properties as compared to traditional, English-language contracts.    Most significantly, the contracts themselves can directly serve as inputs to other computer systems, because the contracts are computer data-objects.

For instance, financial firms have computer systems that attempt to assess the amount of money that they have at risk at a particular time.   Making their financial contracts computable – expressing them as computer data – allows these financial trading contracts to feed directly into computer systems that model risk. In the past, companies would create traditional contracts, and then duplicate their efforts by separately modeling these contracts in their risk-management computer systems.

As another example, many large companies have computer systems that they use to manage purchasing or selling of products.  When a contract is computable (in computer form), they can now do things that they could not do previously, like detecting conflicting contractual obligations.

For instance, imagine that a company had 100,000 contracts to deliver widgets to customers.  In the era of paper contracts, it would be difficult to detect whether the company had promised the same widget to two different companies – a conflict among legal obligations – given the large number of contracts.   When the contracts are computable, however, it is trivial for a computer to scan through 100,000 contracts and detect such a contradiction.

Thus, making contracts computable endows them with new properties, allowing the organizational and analytical abilities of computers to be applied to contracts, without having to manually duplicate the contracts in other systems.   Because the contracts are data objects themselves, they can be objects for analysis by other computer systems in ways that not possible with traditional, English-language paper contracts.

Limits

Its important to note that there are limits to the types of contracts or contracting scenarios that can be made computable.  To be clear, I am not arguing that all, or most contracts can be made automatically assessable in this way.   Rather, that certain subsets of contracting scenarios, with well-defined objects (e.g financial instruments), with  highly determinable criteria (dates),  and standardized products, are readily made computable.

For the moment at least, the highly complex, abstract contracts that tend to occupy lawyers, are not in the realm of computable contracts.

Conclusion

In these two posts, I’ve tried to convey the intuition behind computable contracts in generally accessible terms.  I’ve oversimplified a bit, and skipped over some details, so for a more in depth treatment, feel free to peruse my paper here.