Semantic code project: next steps

The design of organisations and products →Go uptown Index: Click ᐅ to expand: Design Tell me more Sign up for our newsletter — or just get in touch: for ½ a weekly 🍺 you get to consult JC. Ask about it here.

Thoughts following call on 3 March 2021

Levels of meaning/audience

There are at least three layers of meaning, which equate with audiences: (a) business: what practically is the deal I have to do; (b) litigation: how to avoid it by being so clear no one would take the point; (c) ease of systematic risk monitoring of legal terms, recognising this will increasingly be by means of machine/code.

These layers translate more or less to:

• The term sheet: these are the cocktail napkin terms; merchants assume the particular articulation of things that “go without saying” can be left to the legal layer.
• The legal layer: written in legal text (which may be more or less legalese) but which is designed to ensure that those things that ought to “go without saying” in fact do. To address an assertion made on the call which, on reflection, I would resist: it is never the objective “to convince a judge”: it is to put matters so clearly that no-one would need to refer the document to a judge. This is important, as “I am writing with litigation in mind” is, otherwise, a justification for writing in a legalistic way: I write this way because this is what a court would expect. This is a fallacy: First, a contract that comes before a court has already failed. A contract that is so clear that no-one in her right mind would litigate it will, if litigated, have the best likelihood of a positive outcome. Second, to write something in careful legalese for the benefit of a court sounds cute: as if you are writing a coded message that you hope a judge will understand, but that your counterparty will not. That is bad faith. A piece of paper is a poor risk management tool, except as far as it discourages vexatious or wilful interpretations.
• The code layer: The legal terms (be they term sheet or boilerplate terms) rendered in some kind of propositional or elementary form that reveals their fundamental logical structure.

Other work in this space

• Note the encyclopaedia of forms and precedents whereby you could call standardised templates very quickly. Could we borrow some of that?
• Note the work Ken Adams has done to codify the constituent parts of legal contracts.

Behavioural/incentive issues

User acceptance and “changing habits of a lifetime” are important behavioural points to overcome. However it strikes me that lawyers have forgotten the benefit of separating commercial terms from the legal layer: that is the basic architecture of the encyclopaedia of forms and precedents and for that matter, the ISDA master agreement: hardcode boilerplate; export key commercial terms and bespoke modifications.

Opensource vs IP

This project should be a free, open source, public utility. The the model should be open architecture, open-source, freeware. GitHub or MediaWiki, not ISDA. No-one should extract rent from boilerplate.

The information revolution has enabled our “drift to complicatedness” — with that a view has emerged that the resulting “legal technology” is somehow has intrinsic value, is proprietary and should be commercially protected. It is better to see good market-standard contractual terms as a common interface between market participants: a public utility that enables business to get done with minimal friction. No-one should try to own it or extract rent from it. Contract technology should not proprietary; rather contracts — agreements made out of contract technology — may be confidential. To confuse a contractual confidence with a proprietary right in intellectual property comprising the contract is to make a category error.

Ask

I think the ask at this stage is to identify the basic elemental building blocks of commercial contracts. It strikes me there are two ways of achieving this: firstly, to identify and parameterise a limited number of canonical contractual propositions: obligations, discretions, rights, definitions, conditions precedent, representations. The objective here is to see if there is a small, manageable number of basic propositions to which most contractual provisions can conform.

My hunch is that there is, and the apparently infinite complexity of legal drafting in fact subsists at a lower, syntactical level. For example, the “object” proposition is:

obligation [

label {{{label}}}

who {{{who}}}

operator {{{operator}}}

action {{{action}}}

how {{{how}}}

when {{{when}}}

condition {{{condition}}}]

And the difference between a complex obligation and a simple one comes in the articulation of each of the objects in side it. So, compare:

ISDA 2002	2002 Code
2(a)(i) Each party will make each payment or delivery specified in each Confirmation to be made by it, subject to the other provisions of this Agreement.	obligation [ label ISDA 2002 2(a)(i)1 ob who either Party operator must action pay or deliver how Per Confirmation when Per Confirmation condition Per Section 2(a)(iii)]edit
2(a)(ii) Payments under this Agreement will be made on the due date for value on that date in the place of the account specified in the relevant Confirmation or otherwise pursuant to this Agreement, in freely transferable funds and in the manner customary for payments in the required currency.	obligation [ label ISDA 2002 2(a)(ii)1 ob who Party A and Party B operator must action make [howmany: each] payment due by who under Agreement how for value in specified currency in freely transferable funds and in the place of the account described in Confirmation or Agreement when when due condition ]

I also suspect there are some standard form provisions that are worth rending as standard objects (rather than constructing them out of canonical forms) — basically “boilerplate” clauses which are semantically complex, but unitary in the context of a contract (for example, the Third Party Rights clause).

Goal

The theory is to start lawyers thinking about code in