introduction

In general, computable contracts can be represented in a variety of ways - as documents in "legalese" written by and for lawyers, as "smart" documents intended for laymen, and as computer code for computers. Unfortunately, independently authoring contracts in different representations is not ideal. It is time-consuming, and there are risks of inconsistency between the different versions.

Rather than having multiple representations for different purposes, we believe it is desirable to encode computable contracts in a single formal "contract definition language" (CDL) - one with precise semantics that makes the terms and conditions clear and unambiguous. If this language is properly designed, it should be possible to use contracts encoded in this one language for multiple purposes and thereby avoid the costs and dangers of independently authored versions.

Computable contracts encoded in this way can be used for multiple purposes. They can be drafted and read by lawyers, they can be browsed and understood by laymen. And they can be used as *data* in computer systems capable of doing useful calculations, such as compliance checking in real or hypothetical cases, planning, and analysis of contracts for completeness and consistency with other contracts.

Desiderata

To be adequate for this purpose, a contract definition language of this sort must have several important properties. (1) It should have a well-defined syntax and semantics so that contracting parties can encode contractual terms and conditions with confidence. (2) It should be sufficiently expressive to accurately encode the terms and conditions of a wide range of contracts. (3) It should be sufficiently constrained so that it is possible to process contracts expressed within the language in useful ways without excessive computation.

In order for the language to be useful, (1) there should be tools capable of using contracts to perform useful legal calculations – such as compliance checking, planning, and analysis. (2) There should be tools capable of explaining the results of such calculations. (3) And there should be tools that help individuals understand and author contracts in this language.

Contract Definition Language

Over the last few years, researchers at CodeX have been working toward the design of a language with these properties. The current leading candidate (called CDL) has three main components - a concept definition language, a legal ontology, and a collection of domain ontologies.

The concept definition language in CDL provides a way for users to define higher level concepts in terms of lower level concepts. The concept definition component of CDL is Epilog, a modern Logic Programming language developed at Stanford over the last thirty years. Epilog has a precise syntax and semantics, and it provides a good balance of expressiveness and computability. There is an efficient interpreter, and there are rudimentary tools for explanation and authoring.

The legal ontology of CDL is a collection of concepts related to contracts in general - notions such as meeting of the minds, offer and acceptance, consideration, and so forth. While this ontology is essential for ensuring that contracts are valid, it is unnecessary for determining compliance of situations with the terms and conditions of contracts. For that we need a domain ontology.

A domain ontology consists of words to describe the relevant features of situations. The domain ontology used in writing contracts typically varies from domain to domain. For example, in the case of health insurance, it contains words for diseases and drugs and medical procedures. In the case of car insurance, it contains words for car parts and repair techniques. For homeowners insurance, it contains words for foundations and finishes and fences. In encoding contracts, devising a suitable domain ontology is often the most difficult step. Ironically, in discussions of computable contracts, it is the component that often gets least attention.

Roadmap

The idea of a single contract definition language is an appealing one, and research on languages like CDL suggests that it may be feasible. At this point, our job as a community is to move this work from the laboratory to the real world. We need to see whether it works in contract-intensive areas; and, if not, we need to understand its weaknesses. Luckily, things are moving forward here. Insurance companies, such as Allstate and AXA and Chubb, are investigating way in which computable contracts can benefit their businesses, and they are looking for languages like CDL to encode such contracts.