Via @chbusca and the Legal Informatics blog, I learned that Harry Surden of the University of Colorado Law School has published in the UC Davis Law Review an article with the concise title Computable Contracts. (It makes a change from the tedious business of cutesy title, colon, long-winded subtitle.)
Here’s the abstract:
It is possible to formulate contractual obligations so that computers can “understand” and make prima-facie compliance assessments with specified terms and conditions. Such a contractual obligation, formulated specifically for computer processability, is what this Article terms a “computable contract.” Computable contracts are not merely theoretical, but instead are increasingly being used in economically significant domains. Certain widely used financial contracts exemplify this model. The emergence of computable contracts has largely been unrecognized in the legal literature. However, computable contracting is not extensible across all, or even most, contracting scenarios. Rather, it is limited to a small subset of contracting scenarios involving standardization, and relative legal and factual certainty.
Drawing upon computer science research, this Article provides a theoretical account of computable contracting. It first explains how firms can communicate contracting information to computers by representing contracts as data instead of (or in addition to) the traditional written language form. Formalizing contractual obligations in this way is what is termed “data-oriented” contracting. The representation of contractual obligations as data, in turn, allows for novel contracting properties. For example, parties can effectively “translate” certain contractual criteria into a comparable set of computer-processable rules. To make contracts “computable”, parties provide computer systems with external data that is relevant to performance. This model is supported by contemporary examples of computable contracts in domains ranging from finance to intellectual property. This Article also provides principles for distinguishing contracting scenarios that are amenable to computability from those that are not.
What the article describes might seem like a utopian vision of the sort that cybertypes have wistfully outlined to me in the course of brainstorming. But in the limited context specified in the article, it seems a feasible idea.
But I confess that I’ve only scanned the article, as it is and, I suggest, always will be irrelevant to the broader world of contracts.
Thank you for posting the link. This is a very interesting article. I agree that it is very few contracts that as a whole have the potential to be “computable contracts”. At the same time I have a hard time imagining any commercial contract that could not be made partially “computable”, resulting in a significant reduction of transaction costs.
There’s a big part of me that wants to agree with that (put the easy stuff off to the side and put our high-value drafting skills to work where they are more useful). (Computer programmers have done that for decades — write a library of code once that you can attach to your new codes over and over again.) But, I’m afraid that one person’s obvious boilerplate, easily dumped into the automated part, is another person’s deepest pet area for thinking about. Also, I was just the other day reminded that it’s hard to isolate even the most innocuous parts of a contract from consequences that might flow from other parts of the deal. I had one where I was pulling elements of many old forms together into a new mix, and was noting that the termination clause from Form A really did great violence to what might have been agreed upon under the licensing clause of Form B — And so, if I’d automated the termination clause, I might well have missed that. Sometimes I need to see the whole program (to go back to the computer program analogy above) before I can mentally debug it.
Ambiguities in computer programming are called bugs. Ambiguous code means the program doesn’t work because the computer can’t understand the code. Contract drafting, unfortunately, is full of bugs. Perhaps the process of drafting contracts can learn from the process of programming computers.
I’ve used that analogy for years. But, as I think Ken has suggested, the analogy has a problem — The only debugger I know of is a courtroom. Programming at least allows us to figure out our mistakes without being embarrassed by a judge.
The notion of reducing elements of contract terms to elements that can be mixed and matched into a data set that is easily transmitted by machines is an old one. No doubt it’s older than the first example I know of that was called EDI in its day. Today many are working on business XML, more or less a modern form of EDI. I recall a failed effort to try to reduce website privacy policies to a form that could be read by a browser, allowing the user to let the browser to decide what sites might be visited and which should be avoided.
Still, even the strongest advocates of these systems realize their shortcomings. For purposes of this discussion I will ignore issues of assent, record-keeping, authentication, and the like (although they are fascinating in their own right). And, as a drafter, I would be forced to pick a discrete set of acceptable terms that could be used (which may work fine in describing an order for car parts, but which may be limiting if I’m describing the new merger agreement I’m working on.)
Those points aside, the thing to remember about these reductions to tokens that represent contractual terms (and this new thing may look more sophisticated than EDI, but that’s all it is in the end) is that somebody still needs to originally express that which is being reduced. So, once we reconstitute the tokens back to their original forms we’re left with what that first drafter gave us. That may be crap or it may be Adams’ finest stuff. But the act of having reduced it to something a computer can deal with didn’t alter the character of what it stared with. Or, as the programmers have long said, “GIGO.”
I knew this would be up your alley.