There are two main approaches to document automation. First, a Programmatic approach inserts If-Else-Then statements into a document to select different deal terms based on configuration options. Second, a Modular approach constructs an agreement from a hierarchy of standard and alternative sentences, clauses, and document sections.
At first blush, the approach of creating standard and a range of alternate provisions likely repeats much of the same core terms, thereby producing significant duplication of language. While this is true, the burden is borne by the computer. On the other hand, the approach of embedding If-Else-Then statements into lengthy documents becomes exceedingly challenging where the statements are nested inside one another, sometimes spanning many pages. This burden of complexity is borne by the human operator. As a programmer, I think of the programmatic approach as very brittle and highly susceptible to error.
This same rationale caused a shift many years ago in computer languages away from linear approaches—such as the C language—to modular, object-orientated programming in C++ and C#, widely used today.
Moreover, the modular approach most closely reflects the organizing structure of legal agreements. Contracts are organized in a consistent modular hierarchy. Each agreement has an explicit or implicit table of contents. Collectively, they organized upon similar building blocks. For this reason, ContractStandards proposes a Unified Contract Structure for organizing bi-lateral exchange agreements.
A modular hierarchy is an approach that allows us to handle highly complex systems, such as an organizing framework for all legal agreements. In his seminal work, The Architecture of Complexity, Herbert Simon demonstrates that hierarchy is the organizing theme for a science of complexity. His parable—written nearly 50 years ago—of the watchmakers is highly relevant to our current needs to address complexity, efficiency, but without sacrificing quality.
“There once was two watchmakers, named Hora and Tempus, who manufactured very fine watches. Both of them were highly regarded, and the phones in their workshops rang frequently. New customers were constantly calling them. However, Hora prospered while Tempus became poorer and poorer and finally lost his shop. What was the reason?
The watches the men made consisted of about 1000 parts each. Tempus had so constructed his that if he had one partially assembled and had to put it down—to answer the phone, say—it immediately fell to pieces and had to be reassembled from the elements. The better the customers liked his watches the more they phoned him and the more difficult it became for him to find enough uninterrupted time to finish a watch.
The watches Hora handled were no less complex than those of Tempus, but he had designed them so that he could put together sub-assemblies of about ten elements each. Ten of these subassemblies, again, could be put together into a larger subassembly and a system of ten of the latter constituted the whole watch. Hence, when Hora had to put down a partly assembled watch in order to answer the phone, he lost only a small part of his work, and he assembled his watches in only a fraction of the man-hours it took Tempus.”
Once the modular hierarchy is established, which allows selection of the core contract building blocks, a CAD system for law must then permit fine tuned configuration of deal terms tailored to client-specific needs. And, that will be the topic of the next blog post.
