Modularity in contracts: boilerplate and information flow.

• Author: Smith, Henry E.
• Position: Boilerplate: Foundations of Market Contracts Symposium

TABLE OF CONTENTS INTRODUCTION I. MODULARITY IN CONTRACT A. Modularity and Complexity B. Modular Boilerplate 1. Splitting or Decomposition 2. Substitution 3. Augmentation 4. Exclusion 5. Inversion 6. Porting II. A MODEL OF MODULARITY IN CONTRACT BOILERPLATE A. Formalism and Context-Dependence B. An Information-Theoretic Model of Boilerplate III. FURTHER APPLICATIONS A. Nonmodularity in Legal Realism B. Comparative Contracts and the Seams in the Web of Law CONCLUSION INTRODUCTION

Contractual boilerplate is a little like property. Such a statement might seem like a category mistake. After all, contractual boilerplate language is part of contracts, which, unlike property, are freely customizable by the parties. Contracts create rights between those parties, not against the world at large. Nor do people who devise new boilerplate terms usually have intellectual property in the provisions themselves.

I will argue that, in an interesting and overlooked way, boilerplate is the first way station on the road from contract to property. In particular, boilerplate, like all legal communication, is the result of striking a trade-off between communicating intensively in a narrow sphere or communicating in a more stripped-down formal way in a wider variety of contexts. (1) Contract and property form something close to corner solutions here. Contracting parties are allowed to be as idiosyncratic as they like, but the idiosyncrasies apply simply to their own dealings--usually not to those of third parties. (2) At the other end of the spectrum, property law deals in simple stable signals with a wide currency, but the rules of property eschew a lot of contextual detail. This makes property rights easy to adapt to many contexts and allows those whose expertise is minimal to avoid running afoul of these in rem rights. The simplicity of property rights also helps potential purchasers to inform themselves about the rights in the process of acquiring them. (3)

Boilerplate language in contracts is somewhere in the middle of this spectrum running from information-rich contract rights limited to a particular deal to simple standardized property rights availing against "the world." Once this aspect of boilerplate is understood, an information-cost theory of property can shed light on how boilerplate is--and is not--used in contracts. By definition boilerplate is meant to be used in more than one contract, and boilerplate is more self-contained and less specific to a particular contract than might be expected from contract theory. (4) Boilerplate is highly standardized, and when courts interpret boilerplate they treat it as intentionally standardized and not harboring unusual meanings. In other words, some portability of boilerplate is achieved at the price of tailoring such provisions to particular contexts.

In striking this trade-off between tailoring and portability, boilerplate takes advantage of modularity. In general, modularity is a device to deal with complexity by decomposing a complex system into pieces (modules), in which communications (or other interdependencies) are intense within the module but sparse and standardized across modules. Two elements are more likely to be in the same module if they are part of a dense web of connections, whereas they are more likely to be part of separate modules if they are weakly connected in this sense. Modularity is thus a matter of degree. For example, in a computer program, an initial version might have some kind of a print function embedded in various parts of the program. Instead, one can create a print module that can be called upon by other parts of the program in standardized ways. When revisions are being made to the print module or to the rest of the program the interdependencies (which I will also call "interactions") are much easier to foresee. If a better print module comes along it can be substituted for the existing one, or the success of the print module at hand can lead to its adoption in a wide variety of other programs. With the rise of object-oriented programming this style of software design has gained widespread use.

Modularity carries with it characteristic costs and benefits. Modularity is beneficial in that it makes complexity manageable. It also allows multiple people to work on a larger problem, often in very specialized ways, without incurring the costs of intense communication. Finally, modularity allows a system to manage uncertainty; because each module can function and develop in relative isolation, these processes can occur without the need to resolve uncertainty elsewhere in the system. In this sense modularity is said to create options. Without modularity, keeping the options for certain decisions open would be prohibitively costly. Modularity achieves these benefits by interrupting information flow, through what is often called "information hiding"; only certain kinds of information can be passed from module to module, reducing the need to know what's going on in the other black boxes. As long as the design rules built into the interface are obeyed, changes will not have costly ramifications elsewhere.

Although modularity is increasingly employed in areas ranging from biological evolution to organizational design, some of the most dramatic examples of the power of modularity and much of our understanding of its implications come from the realm of computer hardware and software. A key turning point in computer design came with the IBM System/360, introduced in 1964, which was the first truly modular computer design. (5) Nonmodular design that had prevailed before the mid-1960s had become much too cumbersome. Similarly in software, the rise of the UNIX operating system began a similar harnessing of modularity, and more recently the role of modularity in open-source software like Linux is well-known. (6) Most relevantly for our purposes, the development of object-oriented programming (with the rise of languages like Smalltalk, Java, and C++) allowed all sorts of computer programs to be more thoroughly modular. (7) When programs become very complex, breaking a problem down by modules rather than by flow chart can be key to managing complexity and allowing for flexibility in evolution. In this Article, I will draw an analogy between writing contracts and writing computer programs.

The role of modularity in boilerplate has been largely overlooked in law and economics, for reasons having their roots deep in the Coasean tradition. As Tom Merrill and I have argued elsewhere, Coase assumed a hyperrealist view of property which bears little relation to the traditional notion of property as a right to exclude from a thing, good against the world. (8) Instead, Coase, like the legal realists before him, tended to emphasize use-rights, which in Coase's case would be the product of enlightened judges making economically informed decisions about resource conflicts where parties cannot bargain to the efficient result themselves. (9) One would naturally expect such solutions to be finely tailored, and they would have little reason to track traditional exclusion rights. In a moment of extreme candor in the course of his discussion of spectrum rights, Coase even expresses his view that the concept of property "tends to obscure the question that is being decided" (10) and that "whether we have the right to shoot over another man's land has been thought of as depending on who owns the airspace over the land. It would be simpler to discuss what we should be allowed to do with a gun." (11)

The importance of modularity has been easy to overlook in traditional law and economics. First, the lumpy character of entitlements and their ability to encapsulate and hide information does not figure in theories at all. Instead, in law and economics more information is usually considered better. Exceptions to the more-is-better approach, such as the potential for information overload, are not generally considered problems in the theory of entitlements anyway. (12) Second, traditional law and economics would not be very compatible with modularity because legal concepts and formalism implement the principle of modularity, but law and economics inherits the anticonceptualism and antiformalism of the legal realists. I argue that formalism properly understood is simply one way of striking the inevitable informational trade-off between intense communication in a narrow range of contexts and more standardized--formal--ways of communicating more widely. Finally, law and economics, even behavioral law and economics, does not emphasize the benefits of modularity for human comprehension and innovation, even though pioneering behavioral economist Herbert Simon considered the very notion of bounded rationality to imply a strong trend towards modularity in human problem solving and institution building. (13) As has proved true in cognitive science, a complex phenomenon can be more amenable to study if the phenomenon itself is modular, as most cognitive scientists now consider the human mind to be. (14) Likewise, computer programmers are well aware that human minds deal with complexity much better if problems are broken down in a modular way. For this reason alone, modularity makes for good programming style. Furthermore, evolution--even evolution not directed by a central intelligence--often gravitates towards modular systems because of their ability to adapt to new conditions. (15) If so, the evolution of contract law and of privately circulating forms of boilerplate can be explained as the product of a similar evolutionary logic.

In the next Part, I will introduce the notion of modularity and demonstrate that it plays a pervasive role in managing contractual complexity, particularly through its use in boilerplate provisions. In Part II, the Article turns to a simple model of modularity in which such formal devices reflect a trade-off between the information-intensiveness and...