One of the more challenging aspects of digitising contracts (making then computable) is understanding how to assemble a contract from a reusable set of clauses. There is inherent tension between the notion of a clause as an atomic reusable snippet of text, and the assumptions that a clause makes about its host contract, or the other clauses that must be present in the contract.

In this article I dive deeper into what assembling contracts from clauses means in terms of semantics, and sketch out some Concerto data models to capture those semantics.

To illustrate and make concrete the issues I am going to use a real employment contract, available on the SEC website.

Contract Definitions

First, let’s take a look at the preamble of the contract and section 1 (a) and 1 (b). These sections define the Duties and Scope of Employment, sections that are likely mandatory in all employment agreements. Later we will see some sections (clauses) that are likely optional, in as far as they are likely not applicable to all employees.

To aid analysis I have coloured the different definitions within the contract.

Just like software developers, lawyers need to define and declare their “variables”. Here we see that the contract author has named some definitions and supplied some values:

  • Agreement — When the contract author needs to refer to this agreement itself, they can use the “Agreement” definition. Note that in Object-Oriented-Programming we’d refer to the “this” pointer.
  • Effective Date — defined as a constant value, January 6th, 2004.
  • Executive — defined as the human name, John O’Keefe.
  • Company — defined as Verdisys, Inc.
  • Employment — defined as Executive Vice President and Chief Financial Office

It is likely that these five definitions are required and present in all Employee Agreements (though not agreements of other types…). Semantically we’ve defined an Employment Agreement concept, and associated properties with it, perhaps resulting in a model, something like this:

namespace agreement@1.0.0
abstract concept Party identified by name {
   o String name
}

concept Person extends Party {}
concept Company extends Party {}

abstract concept Agreement {
   o DateTime effectiveDate
}

namespace employment@1.0.0
import agreement@1.0.0.{Agreement,Person}
concept Employee extends Person {}
concept Executive extends Employee {}
scalar Employment extends String

concept ExecutiveEmploymentAgreement extends Agreement {
   o Executive executive
   o Company company
   o Employment employment 
}

There are a few things to note with the model above:

  1. An abstract concepts of a Party is defined, which is specialized into either a Person, or a Company.
  2. An abstract concept of an Agreement is defined, with an Effective Date
  3. We have chosen NOT to specify that an Agreement has parties, because the nature/types of those parties will vary, based on the type of the Agreement. For this executive employment agreement there must be two parties, one of which is a Company, while the other is an Executive. This is debatable, but it does simplify the modelling.
  4. In the employment namespace
    • Two new types of Party are defined: Employee and Executive
    • The Executive Employment Agreement concept is defined, a specialised type of Agreement

This simple model covers the five definitions required by the executive employment agreement.

Clause References

Let’s move on to section 2 (a) of the contract, which defines the salary:

Clause 2(a) defines a salary that increase in the second and third years, but only if the agreement is renewed pursuant to section 4(a):

So, there is a semantic link (a dependency) between Clause 2(a) and Clause 4(a). Clause 2(a) should not be usable in an agreement that does not define a Term clause. The model below introduces an abstract Clause: an identifiable element of a contract, defined by some text. Don’t get too hung up on these details — this is a simplification.

Here is basic model:

namespace clause@1.0.0
abstract concept Clause identified by id {
   o String id
   o String text // text for the clause
}

namespace employment@1.0.0
scalar CalculatedValue extends String
abstract concept Term extends Clause {}
concept WrittenNoticeRenewableTerm extends Term {
   o CalculatedValue expire // agreement.expirationDate + n years
   o Duration autoRenewPeriod // 1 year
   o Duration noticePeriod // 60 days
}

concept ThreeYearIncreasingSalary extends Clause {
   o MonetaryAmount firstYearGrossAnnualSalary
   o MonetaryAmount secondYearGrossAnnualSalary
   o MonetaryAmount thirdYearGrossAnnualSalary
   --> Term term
}

The employment namespace defines three specialised Clauses: Term, WrittenNoticeRenewableTerm and ThreeYearIncreasingSalary, with ThreeYearIncreasingSalary dependent on a clause that specialises the abstract Term concept.

Calculated Values

The expire property of the WrittenNoticeRenewableTerm clause is very interesting, as it references the Effective Date definition of the Agreement concept. The expire property has a definite value once the agreement is signed, but that value is only knowable once the Effective Date of the contract is defined. Over the course of the lifespan of the employment contract the VALUE of the expire property will change, incrementing by one year, for as long as no written notice of non-renewal has been received. The expire property is therefore a calculated value, and the expire property does not store a constant or literal value, but instead stores an expression used to calculate the value. The details of the expression language are omitted here for brevity.

It is important to note that the WrittenNoticeRenewableTerm concept is a computable representation of the semantics of the clause (how to update the value, based on the text of the contract) — not the CURRENT VALUE of the renewal — that can only be calculated by combining the computable representation of the clause with information about the state of the world (current date, and whether the written notification of termination was received, and when it was received). It’s important not to conflate these two aspects: HOW to update the value (defined in the contract) and the CURRENT VALUE (defined by events that have occurred / not-occurred in the real-world).

Optional Clauses

Let us now move onto Section 2(b) and 2(c) of the agreement. These two clauses might be considered optional in this type of agreement, in as far as not all employees are eligible for bonuses or stock options.

Let’s continue to refine our sample employment model, defining concepts for Bonus and Options clauses:

namespace employment@1.0.0

concept Bonus extends Clause {
   --> Executive executive // this might be implicit, from agreement
   o MonetaryAmount signOnBonus
   o Double baseCompensationPercentage
}

concept Options extends Clause {
   --> Executive executive // these might be implicit, from agreement
   --> Company company
   --> ExecutiveEmploymentAgreement agreement 
   o Integer initialShareOption
   o Period vestingPeriod
}

We can then extend our definition of ExecutiveEmploymentAgreement, specifying the clauses that are required, or optional within this type of agreement:

concept ExecutiveEmploymentAgreement extends Agreement {
   // preamble and clause 1(a)
   o Executive executive
   o Company company
   o Employment employment
   o ThreeYearIncreasingSalary salary // clause 2(a)
   o Bonus bonus optional // clause 2(b)
   o Options options optional // clause 2(c)
   o Term term // clause 4(a)
}

Summary

Our simple ExecutiveEmploymentAgreement concept has started to capture the semantics of this type of agreement. We’ve been able to express the required and optional characteristics and also captured the dependencies between clauses; it’s impossible to add a ThreeYearIncreasingSalary clause to the agreement without it having a relationship to a Term clause.

We now have the structured data to ask and answer a wide-variety of questions about a repository of agreements:

  1. How many agreements do I have of type ExecutiveEmploymentAgreement?
  2. How many of those have a bonus clause, but no options clause?
  3. Do we have ExecutiveEmploymentAgreement where the autoRenewPeriod of the WrittenNoticeRenewableTerm is greater than 2 years?
  4. Which ExecutiveEmploymentAgreements have a bonus with a baseCompensationPercentage less than 20%?
    • Show the clause text for each…
  5. …