Semantic code project

The Devil’s Advocate™ ISDA code project · Semantic code project: next steps Index — Click ᐅ to expand: 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:

definition [ label def term operator scope definition ]

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:

definition [ label ISDA 2002 Office def term Office operator means scope Master Agreement definition for: [howmany: each] Party: branch or office of Party]

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).

So far...

This remains a work in progress. That remains of this article, for the stout-hearted, continues on the discussion page, but be warned: it starts getting a bit tendentious. The rabbit hole I am descending may well be the wrong one, but — who knows? — maybe there is a wonderland down there.

See also

• ISDA code project