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: if worst came to worst what would a court say about this (c) risk monitoring, increasingly my 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 articulate with sufficient clarity those things that ought to “go without saying” in fact do. Here the objective is not “to convince a judge” so much as put quotidian matters beyond doubt so that there is no point referring them to a judge. 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

I think it is vital to recognise that this project should be a free, open source, public utility. The “drift to complicatedness” the information revolution has enabled has been accompanied by a view that legal technology in itself is proprietary when in fact it is better regarded as a common API between market participants. Contract technology should not proprietary, that is to say; rather contracts — agreements made out of contract technology — may be confidential. To confuse a contractual confidence with a proprietary right in intellectual property is to make a category error. No-one should extract rent from boilerplate.

Therefore the model should be open architecture, open-source, freeware. GitHub or MediaWiki, not ISDA.

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