We continue our discussion with Mark Oblad on his work within the contracts, smart contracts, and blockchain space in the second of a five-part weekly series. Not all types of contractual relationships have been reduced to fill-in-the-blank documents as discussed in Part I of this series.
Shutterstock
Mary: How should contracts be created or built?
Mark: While the direction given to many young startups is that, in the words of Chris Dixon, a veteran entrepreneur and general partner at the venture capital firm Andreessen Horowitz, “… your deal terms should be plain vanilla. Etc. These things are time tested and you are far more likely to screw things up than create value by tinkering with them,” other transactions place significant weight on unique terms underscored by significant dollar magnitudes. There may be no choice here but to piece together a transaction document for something that may never have been seen before: Find a starting point somewhere for the deal point—maybe an old transaction, maybe a contracts database, maybe a contracts-clause database; drop the clause into the document; clean up the style; and look for and correct defined terms and references to the parties of the agreements.
Mary: Can you give some examples of solutions?
Mark: Two applications developed by Paper Software, Turner for Mac and Contract Tools for Word on Windows PCs, are designed to import and manipulate contracts in various formats (e.g., DOCX, EDGAR HTML, PDF, RTF and TXT) in an editor environment. The tools offer a broad functionality, such as web-like navigation, navigation history, term auto-completion and enhanced search, and their ability to automatically detect structure, catalogue defined terms, flag misuses and alter formatting enable the user to more efficiently build an internally coherent and consistent document. The result can then be exported as a native Word document as well as or other relevant formats.
Other approaches of constructing contracts involve breaking contracts into modular pieces, and providing workflows for piecing together a custom agreement. In this broad category, Common.Form and CommonAccord aim to build repositories of interchangeable contract clauses, and provide compiler tools to build a coherent contract.
Mary: Do later stage or more mature industries have standard or templated contracts?
Mark: Industries may slowly move together to agree on some common terms. And, once there is agreement on the terms, the forms can follow. Over time, the form may get rewritten so many times that transaction-specific data moves its way to the first page of the document or to a schedule of “riders”, while the language of the contract is generalized to reference the data and to cover as many situations as possible. Software developers in a similar fashion improve their applications to make the code more flexible and to cover as many likely situations as possible by refactoring the code and creating a well-documented API (application program interface) to allow systems to “talk” to each other.
This maturing process may be driven by an industry coalition, such as the ISDA (International Swaps and Derivatives Association) with respect to the ISDA Master Agreement, or an intermediary seeking to reduce friction and increase transaction flow, such as securities exchanges. In the venture industry, Fenwick’s well-known Series Seeddocuments, while purposely eliminating more complicated market terms, have come a long way towards reducing the need for inline changes by moving inputs to the front page.
Mary: How does the automation work?
Mark: The process of completing an automated document typically involves entering the contract’s data into some form, which from the very start is a structured format. This set of data is only part of the information in and surrounding the contract that is interesting to the various users.
For example, when a company is sold to another, the purchasing company runs like a background and in-depth check or “diligence” process which includes reviewing all of the target company’s contracts. In addition to understanding the amounts of the target company’s rights and obligations—the kind of information that may be structured during contract drafting—the purchasing company is particularly interested in clauses in a contract that may not have been part of the automated variables and thus not structured initially. Typically, such sections would include:
- indemnity clauses (language about which party bears the costs of improbable risks);
- termination clauses (language that may allow one party of the contract to terminate the contract in circumstances such as selling the company); and
- non-compete and non-solicit obligations (language limiting the target company, and by extension, the purchasing company, from conducting some businesses).
Capturing this type of data typically is done manually, but automated tools such as eBrevia (https://ebrevia.com/) and kira (https://kirasystems.com/), have been making progress with the help of natural language processing, machine learning and alternative intelligence generally, to efficiently gather the information from archives of executed contracts.
Mary: How much does the user need to know to use this type of automation software?
Mark: Probabilistic tools like these typically provide users with a cafeteria-style menu of types of unstructured data the software can extract, however the concept is formulated and wherever it is buried in the document. For example, if the user selects “Change of Control,” the software would identify the concept expressed directly as “change of control” or in other language such as “assignment by operation of law” or “sale of all or substantially all of the company’s assets.” Having in advance the menu of concepts that would be needed later, one wonders why the original templates of the contract shouldn’t address the points within the contract in structured format from the start. Perhaps inline tagging or embedded diligence metadata in the template could increase the probability of correct answers.
Other relevant data includes the activity of the contracting parties and events occurring after the contract is in place.
- Who signed, with what authority, at what time, along with corroborating information on identity (user account information, IP address, the versions of the user’s browser and operating system, the content of a drawn signature, etc.);
- Intent to be bound (language used to direct the user to authenticate a document, language consenting to the process, evidence of the contract being displayed and reviewed, etc.)—this set of data is the expertise of electronic signature solutions such as HelloSign.
- Further, knowing about the lapse of time and occurrence of other events during the life of the contract are often necessary to understand the legal effect of the agreement.
Contract life cycle platforms, such as Ironclad and Concordfocus on keeping track of deadlines and workflows for managing a body of contracts within an organization.
In an ideal world, everything becomes data and is interconnected in a system smart enough to guide the user, without legal expertise, through the processes or forms to achieve their legal goal. Thank you again to Mark Oblad, of JW Player, for this information and you can see the people that helped Mark here. Next up, we sidestep contracts to talk about the open source movement in Part III. #onwards.
[“Source-forbes”]
){kind=link}
){kind=link}