Semantic code project
|
The Devil’s Advocate™ 
|
It’s all very well complaining, as reform-minded lawyers are inclined to, that legalese is absurd, does no-one any good, and that it must, surely, dawn on the world’s professional wordsmiths at some time soon that whole-hearted surrender to plain English will assure them of an exponential explosion in productivity and profitability. The case of plain English is the legal eagle’s efficient market hypothesis: it should work, but doesn’t: where clean lines and abrupt cadences should, logically, lighten our load, textual profligacy jabs a defiant finger in the eye of the right-thinking logician who believes he maps the territory of our hearts. The facts tell a different story: he doesn’t.
For we lawyers are inured to speaking in a certain way. It is our dialect; we have learned it since the cradle: it is who we are. With it, we graduated and earned our place at the bar. As we matured it became an overwhelming competence signal: it how we demonstrate our place in the pecking order. All that notwithstanding, it is difficult turning legalese into plain English. It doesn’t come naturally to lawyers, and not one of those reg tech entrepreneurs has managed a machine that can do it. (No one has even tried, as far as I can tell).
On the other hand, you have visionary types who talk of legal language as if it is some kind of object-oriented code. This seems a better aspiration — at some remove, legal language is a kind of code: it is a set of operating rules within which components in a system are programmed to interact. Good contracts have many of the features of code, being exact, unambiguous, not needing qualitative evaluation; devoid of metaphor and limited in the use of tense. As the information revolution continues we should expect contracts and code to come together: Lawrence Lessig would say at some point they will converge: code is law.
In this semantic code project, rather than starting with the porridge we are left with at the end of the drafting process, we ask whether the better thing is not to start at the beginning: if we build legal statements from their elements, and even negotiate that way, by reference to propositions rather than sentences, we at least discipline ourselves to articulate legal relationships in neat code. If you are so minded, you can then extrapolate this into language as flowery as you like — the Fish principle is simple algorithm. But — who knows? — if the number of basic propositions is limited, and lawyers get used to handling this “machine code”, we might deprive windy legal language of its very reason for being.
Theory
In a commercial legal agreement, there are a limited number of basic legal propositions, all of which have common components, which are standard building blocks of a legal contract. These are things like “definition”, “right”, “obligation”, “condition”, “warranty”, and the proposition needs a “label” to identify it and position it in the contractual framework. My hunch is that say twenty of these “canonical proposition” types could be used to fully describe the legal content of most commercial contracts.
For example, a “definition” is a fairly straightforward proposition: there is a “term”, “definition”, “operator” and “scope”. So the definition proposition template might look like this:
|
In a contract there will be multiple “definition” propositions, and each will have its own label and variables from which you could construct basic legal semantic text. For example, take the ISDA definition of Office:
|
“Office” means a branch or office of a party, which may be such party’s head or home office. |
You could, we suggest, render that as follows:
|
Note that “which may be such party’s head or home office” is a non-restrictive elaboration — it is flannel, basically — it adds no information that is not conveyed by the expression “a branch or office of a party” so it can be omitted from the propositional variable. (This will frighten some of the horses I should think).
Speculation
The rest of this article is a hastily-drawn sketch. It may provide food for thought, and may just be nonsense.
Create (or select) a standard proposition
Select a standard proposition. A “definition” can be represented as:
|
Standard proposition templates will be prefaced with a “c-” and you can find a complete list of the formats here:
| Canonical propositional forms: Completed propositions: |
Why are there t-versions and c-versions of each standard proposition?
You call templates using the “c-” templates. These designate:
- (a) what type of standard proposition it is (is it a right, obligation definition, condition precedent, etc): you do this by the “c-type” template —“c” for “call” — you select (e.g. “c-obligation”)
- (b) where to find the static data inputs to populate this particular proposition — this will be a taxonomised address for a particular agreement (e.g. “ISDA 2002 2(a)(iii)”). This is where the “t-” templates come in handy: you need to put your proposition variables into a followable, but still fairly convoluted code environment, which you can access by “{{subst:}}ing” the relevant “t-type” template — “t” for “template standard proposition” — and just dropping the variables into the relevant spaces.
- (c) what format to output the proposition. For example “pr” will output it as in JCML[1]; “se” will out put as minimalistic semantic English.
The idea is to take an existing template standard proposition and “{{subst:}}” it into a new structure at the correctly taxonomised address, and then populate it. If there isn’t an existing standard proposition to fit, create a new one — but try to avoid this: the name of the game is to have as few “canonical” propositions as possible.
The form of template standard proposition should be:
|
Name: t-[NAME]<noinclude>{{c|Template propositions}}</noinclude> |
Where:
- Change [NAME] and {VAR1}, {VAR2} and {VAR3} to suit your proposition. Note ALL ARE CASE SENSITIVE. Suggest using only lowercase. Bear in mind the command calling the template also has to be case-correct.
- “Label” above is fixed text and will help in correctly taxonomising. Don’t change this. Also leave <noinclude>{{c|Template propositions}}</noinclude> as is — this adds the template to the correct category and helps you to find it later.
The form of template call — this simply extracts the relevant data from the taxonomised address, but doesn’t do anything with it (the “format” parameter designates that), is as follows:
|
{{{{{format}}} [NAME] |
Create a corresponding proposition in your agreement schema
You should have an agreement schema (a structured skeleton of the agreement in question. This has a unique taxonomised template name following this format: [Code] [Agreement] [Edition Year] [Clause reference]. For example, Section 1(a) of the 2002 ISDA is {{Code 2002 ISDA 1(a)}}
Create the new template (e.g. {{Code 2002 ISDA 1(a)}}) and call the template proposition using the “c-” template operator. For example, to: if you want to put an “application” operator in {{Code ISDA 2002 1(a)}} template, insert: {{c-application|ISDA 2002 1(a)1}} there. Note the 1: this is to distinguish between different instances of “application” that appear in clause 1(a), so not necessary if only one, but good practice.
If there is not an existing container, this should prompt you for a bunch of inputs which are not there yet (eg {{{label}}}, {{{action}}} etc).
Render
You choose your rendering by the parameter “format” in the “c-” template.
- pr means “proposition”: this is the inputs into the proposition listed as they are.
- se means “semantic”: This is the inputs into the proposition constructed into minimal English
- std means “standard” legal English: so idiomatic, but not legalese, but not so spartan so as not to be fun.
- pomp means “pompous” and we have had a bit of fun with this.
Structure challenges
The whole agreement needs to have a nested code/subroutine structure. The labels will help address parts. It will be more rigorously nested than the numbering schema of a word doc. The preliminary, interpretation, definitions and overriding principles by which all rights and obligations are construed are the outermost layer. Any nested layer inherits all the outer conditions and terms. Deal with carve-outs and carve ins by "undoing" prevailing conditions. So conditions are "on" or "off". As each proposition has an address label and is an object in the system, this is manageable.
To do
Devise a proposition labelling taxonomy, that can neatly (and predictably) cover: proposition type, agreement type, location and clause reference
See also
References
- ↑ Jolly Contrarian Markup Languange of course.