Today, I will continue my meander through contract digitisation, taking a deeper look at contractual obligations and rights and the theoretical background of “contracts as promise”, and I begin to outline a data model that captures some of the concepts.
Theoretical Background
In “Contract as Promise: A Theory of Contractual Obligation”, Charles Fried argues that the moral basis of contract law is lodged in the promise principle, “that principle by which persons may impose on themselves obligations where none existed before”. Fried places contract law within a moral framework. A useful review of Fried’s important work is available in the 1983 Michigan Law Review.
Furthermore, because a contract “is first of all a promise, the contract must be kept because a promise must be kept”.
Charles Fried
Personally, I find Fried’s moral conception of contracts to be a useful one, as it emphasises the role of trust, convention and moral authority in establishing contractual relationships: one may not always be LEGALLY obligated to perform a promised action, but the repercussions of not fulfilling the promise could be morally and reputationally very damaging.
“Relationships between businesses are invariably based on considerations of mutual interest and risk assessment. In risk-laden business-to-business relationships, the establishment of accountabilities through explicit performance standards and monitoring may be in conflict with interpersonal trust. If contracting parties are genuinely open, their behaviour will facilitate the exchange of information that is necessary to move the process of value creation forward; but this openness might be exploited by counterparts who are more concerned with value-claiming. Conversely, if the contracting parties are competitive in claiming value, they might limit or prevent the achievement of joint gains through give-and-take processes. Although trust might be more applicable to interpersonal relationships, its importance as a relevant aspect of exchange relationships, invites us to look at indicators of trust, such as the occurrence of repeated exchange between contracting parties, and examine the particularities of contractual arrangements in which we can observe the existence of mutual trust.”
Source: “A Proposed Taxonomy of Contracts” Stefanos Mouzas and Michael Furmston
Digitisation
As we digitise a contract we inevitably need to digitise the promises made by the parties to the contract. These promises are heavily contextual — parties are promising to engage (or indeed, to not engage) in some future course of behaviour, given a set of circumstances. A promise is composed of two parts:
- A description of the action to be taken (or not to be taken)
- A description of the circumstances applicable to the promise
Note also that some promises are explicit (described in the contract), some are implicit (for example, described in common law, or in statute). It is therefore rarely the case that a computer could analyse (just) the text of a contract and digitise all the promises between the parties. There is significant legal context inherent in entering into different types of contract (sales of goods, or employment, for example) — in AI what we call semantic grounding, as well as implicit legal and societal precedent and expectation.
Deontic Logic
When expressing the logic of promises giving we quickly enter the realm of deontic logic, that is, the logic of obligations, permissions and related concepts. This is a complex subject with lots of potential traps, largely because the natural language we use to express obligations is not the simple logic of boolean truth values. A good introduction to some of the subtleties for legal drafting is the paper SHALL, MUST, MAY: THE LOGIC OF LEGAL OBLIGATION AND PERMISSION, by Ben Russell.
For example, take the trivial phrase, “Jack may have coffee or tea” and attempt to interpret the phrase to build a computable representation. Most people will interpret the phrase using free-choice inference to be:
- Jack may have tea
- Jack may have coffee
- Jack may not have both
- Jack may have neither
- Jack may not have lemonade
Take a look at the five reasonable computable interpretations of the phrase, (spoiler alert) the one closest to our intuitive understanding is Interpretation Five.
“Jack may have coffee or tea”
Interpretation One
// jack's first drink must be tea or jack's first drink must be coffee
return jack.drinks[0] === 'tea' || jack.drinks[0] === 'coffee'; Interpretation Two
// the drinks of jack include tea, or the drinks of jack include coffee
return jack.drinks.includes('tea') || jack.drinks.includes('coffee');Interpretation Three
// the drinks of jack may be empty, or the drinks of jack include tea
// or the drinks of jack include coffee
return jack.drinks.length === 0
|| jack.drinks.includes('tea') || jack.drinks.includes('coffee');
Interpretation Four
// jack must drink exactly one drink, and it must be either tea or coffee
return jack.drinks.length === 1
&& (jack.drinks[0] === 'tea' || jack.drinks[0] === 'coffee');
Interpretation Five
// jack may have no drinks, if he has a drink it must be either tea or coffee
// jack may not have more than one drink
return jack.drinks.length === 0 ? true
: jack.drinks.length === 1
? (jack.drinks[0] === 'tea' || jack.drinks[0] === 'coffee')
: false;| Data | One | Two | Three | Four | Five |
| drinks: [‘tea’] | true | true | true | true | true |
| drinks: [‘coffee’] | true | true | true | true | true |
| drinks: [‘tea’, ‘coffee’] | true | true | true | false | false |
| drinks: [‘lemonade’] | false | false | false | false | false |
| drinks: [‘tea’, ‘lemonade’] | true | true | true | false | false |
| drinks: [‘lemonade’, ‘tea’] | false | true | true | false | false |
| drinks: [] | false | false | true | false | true |
Even this trivial example highlights how hard it can be to interpret deontic phrases, in some cases, even for experts. Ken Adams (who writes extensively about clear drafting of contracts) also has a nice post of how to draft contracts to express the absence of obligation.
Describing Obligation and Rights
Enough theory!
Let us take another look at the summary of rights and obligations in a simple supply chain contract:
When a given situation occurs (which could simply be the passage of time) the parties to the contract (Customer or Supplier) assert either an obligation or a right.
Obligations within contracts are varied, but an obligation to make a payment, or to send a notification are very common. Rights are more diverse and could include a right-to-terminate, option-to-renew, right-to-claim-damages or assignment of copyright or intellectual property rights. Rights are classified as perfect or imperfect, positive or negative, and real or personal.
Promises are often qualified, such as via Limitation of Liability clauses, which may cap the amount of damages that a customer could claim from a supplier.
Triggers
To describe WHEN a promise is applicable we introduce the concept of a Trigger. A trigger is an event that has occurred in the real-world. A simple data model for triggers defines an abstract concept of a Trigger, and then specialises it across the temporal dimension (trigger at a specific timepoints, or every N days), across the logical dimension (AND, OR, NOT to combine triggers), or across the legal dimension (Breach, Change of Control, On Signature…). A “catch all” trigger type called “Situation” allows for the specification of a a natural-language description of a situation.
There is likely an 80/20 rule to the specification of trigger events: they need to be semantically rich enough, and grounded in existing event streams, to capture meaningful semantics, without being SO detailed that they can no longer be easily operationalised.
Promises
We can use the simple data model below to capture the promises within a contract, relating them to the parties making/receiving the promises (promisor and promisee) as well as the natural language clauses that specify the promise, and the trigger condition for the promise, and whether the promise is currently active etc.
Rights
The abstract concept of a Right specialises Promise, and is then further specialised into some common types of Rights, such as Intellectual Property or Option To Renew. Legal ontologies (such as SALI) can be used to create these concepts.
Obligations
Obligation also specializes Promise, and introduces Payment Obligation (used when one party must make a payment to another) as well as Notification Obligation (when a party should notify the other party). Note that obligations include an obligation type that specify the relative weight of the obligation, such as mandatory, or best-effort.
Prohibitions
Finally Prohibition also specialises Promise — and is somewhat of a placeholder for further study and specialisation.
Summary
This post is not intended to be my definitive thoughts on this important subject, and there are clearly still many open questions. I hope you’ve found the references useful, and that this pragmatic foundation is useful for more research and development.
Innovation That Matters 
Leave a comment