{"id":230,"date":"2014-06-16T12:07:39","date_gmt":"2014-06-16T18:07:39","guid":{"rendered":"http:\/\/harrysurden.com\/wordpress\/?p=230"},"modified":"2016-06-08T12:25:12","modified_gmt":"2016-06-08T18:25:12","slug":"computable-contracts-explained-part-2","status":"publish","type":"post","link":"https:\/\/www.harrysurden.com\/wordpress\/archives\/230","title":{"rendered":"Computable Contracts Explained – Part 2"},"content":{"rendered":"

Computable Contracts Explained – Part II<\/strong><\/span><\/p>

This is the second part of a series\u00a0explaining “computable contracts<\/a>.” \u00a0 For more about what a computable contract is, please see the first part here<\/a>.\u00a0<\/em><\/p>

Overview<\/span><\/p>

In the last post I defined\u00a0computable contracts<\/span><\/a>\u00a0as contracts that were designed so that a\u00a0computer could \u00a0“understand” what was being promised and under what terms and conditions (metaphorically).<\/p>

We can think of a\u00a0computable contract\u00a0<\/em>as a partial workaround to a particular technological limitation: computers\u00a0can not reliably understand “traditional” English language contracts.<\/p>

The goal of this second\u00a0part\u00a0is to explain the intuition behind\u00a0how an ordinary contract can become\u00a0a\u00a0computable contract.<\/em><\/p>

Three Steps to Computable Contracting<\/strong><\/p>\n

There are three steps to creating a computable contract:<\/p>\n

1) Data-Oriented\u00a0Contracting<\/strong><\/p>\n

2) Semantic\u00a0Contract terms<\/strong><\/p>\n

3) Automated assessment of contract terms<\/strong><\/p>\n

I will discuss each of these steps\u00a0in turn.<\/p>

 <\/p>

Step 1 – Data-Oriented Contracting<\/span><\/strong><\/p>

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”).<\/p>

What is the solution? \u00a0Write\u00a0the\u00a0contract in the language of computers, not in the language of people.<\/em><\/p>

This is known as\u00a0data-oriented contracting\u00a0<\/strong>(my terminology). \u00a0In a data-oriented contract<\/em>, the contracting parties deliberately express contract\u00a0terms, conditions and promises, not in English, but\u00a0as data – the language of computers.<\/p>\n

This partially gets around the natural language processing problem – because we are not asking the computer to understand English language contracts.\u00a0 Rather, the parties are deliberately expressing their contract in a format amenable to\u00a0computers – structured data.<\/p>\n

Example of Data-Oriented Contracting<\/span><\/p>\n

What does it mean to express a contract term as computer data?<\/p>\n

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\u00a0option to buy the Apple stock expires on January 15, 2015.<\/p>\n

Recall that one of the\u00a0impediments to computers\u00a0understanding traditional contracts was the flexibility\u00a0of natural languages. \u00a0A party\u00a0crafting this provision in English could express the idea of an expiration date in innumerable ways. \u00a0One might\u00a0write, \u00a0\u201cThis contract expires on January 15, 2015\u201d, or \u201cThis contract is no longer valid after January 15, 2015\u201d, or \u201cThe expiration date of this option is\u00a0January 15, 2015.\u201d<\/p>\n

These are all reasonably equivalent formulations of the same concept – an expiration date. People are very adaptable\u00a0at understanding such\u00a0linguistic variations. \u00a0But computers, not so much.<\/p>\n

A Data-Oriented Term Equivalent?<\/span><\/p>\n

Is there a way that we can express essentially the same information, but also make it reliably extractable by a computer? \u00a0 In some cases, the answer is yes. \u00a0 The parties need to simply express their contract\u00a0term (the option expiration date) as highly structured computer data.<\/p>\n

For instance, the equivalent of an “expiration provision”, expressed as structured data, might look something like this:<\/p>\n

<Option_Expiration_Date :\u00a0 01-15-2015><\/strong><\/p>\n

The parties made this\u00a0contract term readable by a computer<\/em> by agreeing to always express the\u00a0concept of an “expiration date” in one, specific, rigid, highly-structured way (as opposed\u00a0the linguistic flexibility of natural languages like English).<\/p>\n

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.<\/p>\n

Endowing Data with Legal Meaning<\/span><\/p>\n

You might wonder, how does a piece of computer data like <Option_Expiration_Date : 01-15-2015><\/strong>\u00a0can acquire the legally significant meaning necessary for contracting?<\/p>\n

There are essentially two ways that this happens.\u00a0 First, the contracting parties might get together ahead of time and agree that computer\u00a0data in the format\u00a0\u201c<Option_Expiration_Date : Date>\u201d should always be interpreted as \u201cthe option contract will expire after the date listed.\u201d<\/p>\n

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.\u00a0 For example, many modern, electronically-traded financial contracts are expressed as data according to the predefined FIX protocol<\/a>\u00a0and other data standards.<\/p>\n

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). \u00a0For example, others have written about using the structured data format XML<\/a> for this purpose.<\/p>\n

Note that\u00a0data-oriented contracting is not always conducted\u00a0completely as computer data, but rather can involve a mix of \u201ctraditional\u201d English contracts and data-oriented contracts. \u00a0Data-oriented contracting is sometimes built upon traditional,\u00a0English language \u201cmaster agreements<\/a>\u00a0which<\/span>\u00a0serve as the foundation for subsequent electronic, data-oriented contracting.<\/p>\n

In sum, the first step to creating a computable contract is data-oriented contracting<\/em><\/strong>. \u00a0This 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).<\/p>

 <\/p>\n

Step 2 – Semantic Contract Terms<\/strong><\/p>\n

We just discussed how people come to understand the meaning of contract terms expressed as data. \u00a0 How do\u00a0computers\u00a0<\/em>come to understand the meaning of such contract terms? The second step to creating computable contracts is to create\u00a0\u201cSemantic Contract Terms.\u201d<\/strong><\/p>\n

<\/p>\n

The word \u201csemantic\u201d has to do with the meaning of words<\/a>.\u00a0 We want the computer not just to be able to identify<\/span> contract terms such as \u201cexpiration date\u201d, but we also want to be able to convey the\u00a0what the contract is about.<\/span><\/p>\n

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. \u00a0So how do computers come to understand the meaning of contract data? \u00a0 Essentially, we tell them. \u00a0We provide the computer with rules by which it can react\u00a0sensibly, in a way that is consistent with the actual meaning of the contract terms.\u00a0<\/em><\/p>\n

For some (but not all) contract criteria, contracting parties can “translate”\u00a0contract\u00a0terms into analogous computer rules<\/span> that faithfully replicate the meaning of the contract words.<\/p>\n

Example of Semantic Contract Term<\/strong><\/span><\/p>\n

For example, how do we convey the semantics of a contract term – like an option contract expiration date – to a computer? \u00a0 For such a term, it is possible to devise\u00a0a set of computer rules that replicate\u00a0the logic of what it means<\/em> for a contract to\u00a0have an expiration date.<\/p>\n

Recall our\u00a0contract term, \u201cThis option will expire on January 15, 2015\u201d expressed in data as <Option_Expiration_Date:01-15-2015>\u201d.<\/p>\n

We can translate this to an analogous set of computer rules which essentially says the to the computer, \u201cDon\u2019t execute this option contract if today\u2019s date is after January 15, 2015\u201d<\/em><\/p>\n

Semantic contract terms<\/span> involves translating the logic or meaning of contract terms into a set of comparable computer-rules that allow a computer to react\u00a0automatically in a manner that is consistent with the actual, human-understandable meaning of the contract term. \u00a0These rules can be quite complex and can allow for sophisticated automated behaviors.<\/p>\n

The computer doesn\u2019t actually understand <\/i>the meaning of the contract words at the deep symbolic or cognitive level as a literate person. \u00a0 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. \u00a0A 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.<\/p>\n

It is important\u00a0to note that not all, or even most, contract terms or conditions can be translated into computer rules in this way (e.g. \u201cReasonable\u201d).\u00a0 But, importantly, some can, and those that can, can be converted\u00a0into Semantic Contract Terms.<\/p>\n

In sum, the second step to making a contract computable, is to make the contract terms Semantic<\/em><\/strong> – 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.<\/p>\n

Providing the computer with actionable\u00a0<\/em>rules (or data)\u00a0is the key to making such a\u00a0contract fully or partially automatable.<\/p>

 <\/p>\n

Step 3 – Automated Assessment of Contract Terms<\/span><\/strong><\/p>\n

The final step to making a contract computable<\/em> is to enable\u00a0a computer to automatically assess<\/em> whether or not some of the contract terms have been complied with.<\/p>\n

How can\u00a0a computer know whether or not the contract terms have been performed? \u00a0 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.<\/p>\n

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

Contract provisions sometimes hinge on data that is now automatically accessible. Thus, in some cases, the contracting parties can provide a\u00a0computer with rules about where\u00a0<\/i> to look for information that is relevant to determining whether or not the contractual agreemeents\u00a0were complied with.<\/p>\n

Example of Automated Assessment<\/span><\/p>\n

For example, let’s continue\u00a0with our scenario\u00a0involving 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).<\/p>\n

A computer can be directed\u00a0to sources of data that are relevant to determining conformance with key contract\u00a0terms. \u00a0This can enable the computer to automatically determine conformance with these terms.<\/p>\n

For instance, the parties can agree ahead of time about authoritative data sources about information such as\u00a0price of the stock on a particular date. They can then\u00a0provide a\u00a0computer 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.<\/p>\n

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

Prima-Facie Automated Compliance<\/span><\/p>\n

There are a few things to note about this.\u00a0 First, the computer is able to only make an automated\u00a0prima-facie<\/i><\/span> <\/i>(or \u201cfirst cut\u201d) assessment of compliance \u00a0with contractual terms, based upon the information that has been provided to it.\u00a0 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\u2019s initial prima-facie assessment.<\/p>\n

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\u00a0often be reasonably accurate.<\/p>\n

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. \u00a0 In other words, we are not asking the computer to make assessments of non-compliance with abstract, or highly uncertain contract terms or conditions.<\/p>\n

\u201cCaptured Legal Assertions\u201d<\/span><\/p>\n

Is there a way that computers might be able to automatically assess compliance with even subjective or abstract contract terms?\u00a0 Yes, to some extent. \u00a0I call this concept\u00a0“captured legal assertions.” \u00a0 Imagine that a contracting party\u00a0makes a subjective assessment that some discretionary contract term has been met. \u00a0They can then \u201ccapture\u201d their conclusions\u00a0in a computer database, making these subjective conclusions accessible to a computer.<\/p>\n

For example, imagine that a contract has a subjective term such as, “this building timeframe must be met\u00a0according to best efforts<\/span>.\u201d\u00a0 As mentioned in part I, computers on their own can’t\u00a0easily assess such subjective terms even in scenarios where people might all be in agreement about the fact that “best efforts” were delivered.<\/p>\n

However, if the contracting parties assess the project and agree that “best efforts” were delivered, they can “capture” this conclusion\u00a0by entering it into a computer database – (e.g. Best-Efforts-Delivered = True). \u00a0The act of entering this key contract assessment\u00a0into a structured computer database means that the computer can now access this legal conclusion. \u00a0 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.<\/p>\n

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

New Properties<\/span><\/p>\n

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

For instance, financial firms have computer systems that attempt to assess the amount of money that they have at risk at a particular time. \u00a0 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.<\/p>\n

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

For instance, imagine that a company had 100,000 contracts to deliver widgets to customers.\u00a0 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. \u00a0 When the contracts are computable, however, it is trivial for a computer to scan through 100,000 contracts and detect such a contradiction.<\/p>\n

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. \u00a0 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.<\/p>\n

Limits<\/span><\/p>\n

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

For the moment at least, the highly complex, abstract contracts that tend to occupy lawyers, are not in the realm of computable contracts.<\/p>\n

Conclusion<\/span><\/p>\n

In these two posts, I\u2019ve tried to convey the intuition behind computable contracts in generally accessible terms.\u00a0 I\u2019ve oversimplified a bit, and skipped over some details, so for a more in depth treatment, feel free to peruse my paper here.<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

Computable Contracts Explained – Part IIThis is the second part of a series\u00a0explaining “computable contracts.” \u00a0 For more about what a computable contract is, please see the first part here.\u00a0OverviewIn the last post I defined\u00a0computable contracts\u00a0as contracts that were designed so that a\u00a0computer could \u00a0“understand” what was being promised and under what terms and conditions […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/www.harrysurden.com\/wordpress\/wp-json\/wp\/v2\/posts\/230"}],"collection":[{"href":"https:\/\/www.harrysurden.com\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.harrysurden.com\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.harrysurden.com\/wordpress\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.harrysurden.com\/wordpress\/wp-json\/wp\/v2\/comments?post=230"}],"version-history":[{"count":3,"href":"https:\/\/www.harrysurden.com\/wordpress\/wp-json\/wp\/v2\/posts\/230\/revisions"}],"predecessor-version":[{"id":750,"href":"https:\/\/www.harrysurden.com\/wordpress\/wp-json\/wp\/v2\/posts\/230\/revisions\/750"}],"wp:attachment":[{"href":"https:\/\/www.harrysurden.com\/wordpress\/wp-json\/wp\/v2\/media?parent=230"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.harrysurden.com\/wordpress\/wp-json\/wp\/v2\/categories?post=230"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.harrysurden.com\/wordpress\/wp-json\/wp\/v2\/tags?post=230"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}