(This post is a transcript of a presentation on formal contract languages at the Computable Contracts Session of the 2021 FutureLaw Conference.)

A computable contact is one that provides a computable specification for the terms and conditions of the contract. Given a computable contract and a set of circumstances, it should be possible for one to determine compliance of those circumstances with the contract’s terms and conditions in a purely mechanical way – without the help of human experts and without further clarification from the contracting parties.

Computable contracts are can be represented in different ways for different purposes – as documents in “legalese” written by and for lawyers, as “smart contracts” intended for laymen, and as programs 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.

A better alternative is to encode contracts in a single, neutral representation – a contract definition language. 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.

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.

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.

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, are investigating way in which computable contracts can benefit their businesses, and they are looking for languages like CDL to encode such contracts.

Citation: Genesereth, Michael R.: “Contract Definition Language”, Complaw Corner, Codex: The Stanford Center for Legal Informatics, 2021, https://law.stanford.edu/2021/04/07/contract-definition-language/.