The language of the law . . . (Part II)

I’d like to take my “contracts as computer programs” idea (see post below) in another direction. Before doing so, hats off to Ron Friedmann of Prism Legal Consulting who, after looking at my earlier post, spoke much more felicitously of “contracts as code” and discussed yet another extension of the idea with the suggestions that contracts might merit coding with XML tags (take a look at http://www.prismlegal.com/wordpress/index.php?m=200401#post-127).

Alright, contracts as code it is, then. With this idea in mind, recall that, before actually writing the code for an application, a programmer might “outline” the program’s steps using a flow chart to picture all of the “if, then this, else that” meanderings of the program’s logic. Well, I’m not a flow-charting maven myself, nor do I presume to know how to code in any more than a very rudimentary way, but I have at times dealt with the hairiest of contract provisions. These are the clauses with so many internal conditions, dependencies, branches and the like that even the tried-and-true method of merely block-indenting the various dependent clauses and exception-like-provisos leave the drafting lawyers, let alone another lawyer or the client, reaching for the Advil bottle after several attempts at parsing the provision at hand.

Suppose that lawyers mustered enough gumption to learn the rudiments not of programming, but of using flow-charting tools – Microsoft Visio perhaps or some of its less expensive and complicated cousins. Maybe the lawyer will find that, by diagramming each of the clause’s very own “if, this, then yes, do that” internal structure, the meaning will become much more readily apparent, glitches in the logic will stand out more clearly and lay people will finally catch on to how the provision does or doesn’t work.

Case in point, a good ten years or so ago, a more junior lawyer in my then firm and I were asked by a non-US client to explain how a complicated contract provision worked. We started preparing our explanation in standard English prose, all the time mindful that we were not only going to have to hurdle the difficulties that the clause itself presented, but we were also going to have to get over the English-as-a-second language obstacle. Together, we hit upon the idea of using a flow-chart (nothing itself too sophisticated, no legend necessary to decipher the meaning of the use of circles vs. the use of parallelograms). We sent off our fax (little email in those days) and, voila, the client got it right away and readily understood a problem with the language’s logic that we pointed out in the briefest of text that accompanied the faxed chart. Who knows, maybe the client would have gotten the point if we had made our presentation in the “standard” way, but she herself enthusiastically endorsed the flow-chart approach (“one picture is worth, . . .” and all that).

I’ve tried to use this flow-chart approach when it comes to my own drafting and, all too frequently, I catch myself all balled up in a logical bind as I draft in English first, flow chart second and gnash my teeth at my gaffe third. And, yes, when disciplined enough, I even diagram first, and draft in English second.

Oh for a set of flow-charting tools developed just for complex commercial contract drafting. Had it been four years ago, I’d end this post with “Business model, anyone?”

Comments

[Andrew Davis]

Great blog. If too many lawyers start embracing your ideas, the thesis of your blog could be in jeopardy (here's hoping, anyway!!).

As for flow-charting tools developed for contract drafting, I once came across something called Mustor (www.mustor.com). I never pursued it, so I don't know the first thing about it. But I think it purports to tackle the issues that you describe above.

[John Small]

Interesting discussion. I'm starting
to study logic in earnest and particularly
modal logic which I believe will have a huge
impact not only on AI, RDBMS's, but law in
particular. I was looking in the search engine
to see what I could find regarding logic and law and thus found your blog. Right on!

[Tom O'Brien]

Do any of you have practical tips for which of visio's templates works best for flow-charting??

[Jon Molnar]

Regarding Tom's question about which visio templates work best for flowcharting the simple block symbols will work fine. You only really need blocks to identify topics (issues) and diamonds for decision points (If This/Then, Else or Yes/No). Arrowos or lines will connect the boxes and diamonds to give you flow.

To save money you don't even have to buy Visio to flowchart. Bring up the drawing toolbar in Word and use Textboxes to create essentially the same simple chart. Visio is just cleaner at connecting the objects.

To the point about using graphics, to clarify the issues. I spent two years in the UK on a project. During the first year the British/American meetings would take on the average of 4 to 5 hours and many times neither party felt that the meetings really accomplished anything. In the second year, we adopted the practice of creating a graphic to define the scope of the meeting. All attendees had to agree to that the graphic represented the intended scope of the meeting. If the graphic did meet everyone's expectation it was revised until all agreed. Then the meeting proceeded. This practice resulted in cutting our meetings down to 1 to 2 hours and the productivity increased 100%.

You might want to spend a some time looking at what the software world has come up with in dealing with programming logic tools. The Uniform Modeling Language (UML) is a set of graphic symbols that are used to define processes and logic to be applied in developing software solutions. The UML can be used to work just about anything that requires logic. The process of understanding how to use UML may be helpful to you to understand how to graphically portray your text logic problems.

BTW: A company Rational has developed a set of applications that are design to use UML and can take a project from conception (specs) to final testing but it is pricey. However, you can use UML symbols in any graphic application.

[Tract Owner]

I found this blog while searching for a technique to "Flow Chart legal clauses". Although I have not found the "techniques", I have, at least, found someone who has gone through the same process.

As the owner of a tract in a sub-division, I and the other "Owners" are bound by a set of "Declarations and Restriction", and Owner Association "By-Laws". We (owners) are at the point where we feel we need to/should take responsibility for the Association from the Developer. However the developer, being reluctant to hand-over control of the Association, quotes a clause in the "Restrictions" that he says supports his retention of control.

The clause reads as follows:

"Notwithstanding any contrary provision contained herein, until such Bylaws are enacted or the Developer has conveyed to third parties 65% of the acreage or platted lots, whichever shall last occur, Developer shall appoint the Directors and Directors need not be members of the Association. The Association shall have the powers and duties specified in the Articles and Bylaws of the Homeowners Association."

The By-laws were initially enacted by the Developer at the time when tracts were made available for sale. And, recently an Owners Meeting was held during which the owners themselves elected all Officers and Directors in accordance with the By-laws.

Over 65% of the Tracts have been sold/ (conveyed to third parties). Whether or not 65% of the Acreage has been sold/ (conveyed to third parties) is up for interpretation.

However, when I read the "Clause" I see two (2) "OR" statements and that is what has me confused and thinking that I need to Flow Chart this clause.

I can, in my way of thinking, interpret the clause as follows:
1. Are the Bylaws are enacted - Yes or No
2. If no - Developer retains control
3. If yes –
4. OR have 65% of Tracts OR Acreage been sold/Conveyed - Yes or No
5. If no - developer retains control
6. If yes - Owners take-over responsibility

It seems to me that the second "Or" statement refers to the conveyance of either 65% of the Tracts or Acreage and that compound Statement is the last of two statements (the first being the By-Laws statement) which determine "whichever shall last occur"

This is still confusing, even after having struggled to put my thoughts on paper. Can any of you help me to understand this clause and help to put it in pictorial/Flow-Chart format.

Your help would be greatly appreciated.