Semantic code project: next steps

The design of organisations and products Go Premium Making legal contracts a better experience Index — Click ᐅ to expand: Design Comments? Questions? Suggestions? Requests? Insults? We’d love to 📧 hear from you. Sign up for our newsletter.

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 termsheet 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.
• Note the work Ken Adams has done to codify the constituent parts of legal contracts.

Ask

I think 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 which most contractual provisions can conform to. 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 [[:template:{{{label}}} ob|{{{label}}} ob]] 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) General Conditions
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. Where settlement is by delivery (that is, other than by payment), such delivery will be made for receipt on the due date in the manner customary for the relevant obligation unless otherwise specified in the relevant Confirmation or elsewhere in this Agreement.	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 ] obligation [ label ISDA 2002 2(a)(ii)2 ob who Party A or Party B operator must action make [howmany: each] delivery due by who under Agreement how for receipt when When due condition ] edit