Semantic code project: next steps
|
The design of organisations and products
|
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:
- 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 |
|---|---|
obligation [
| |
|
obligation [
|
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