While a world free of lawyers will most likely never come to fruition (to many parties’ chagrin), new technology in the form of smart contracts is changing how legal matters are drafted. Evidenced by increased adoption for major industrial applications with the OOC Oil & Gas Blockchain Consortium, a powerful network of 10 major oil and gas players; alongside the Construction Industry Institute at The University of Texas’ recent Operating System 2.0 (OS2) initiative, a collaborative research and development project focused on capital projects, smart contracts backed by distributed ledger technology are giving shape to contracts of the future.
Whether regulatory compliance, contractual enforceability, cross-border financial transactions, material provenance, document management or other applications, smart contracts lend unprecedented functionality and the automation of contract terms. However, the ‘if-then-else’ style logic that smart contracts and their coding operate on does not innately function in lockstep with the natural language of legal contracts. Since legal and contracts organizations are usually far removed from business and operational systems, they can draft contractual terms and conditions that execution teams are unable to follow or administer.
Smart contracts integrate with two other technologies, Industrial Internet of Things (IIoT) and Distributed Ledger Technology (DLT) to verify, validate, capture, and enforce agreed-upon terms between multiple parties. A smart contract takes real-world, legally governed events and collects IIoT data for performance measurements including information from sensors, meters, and other business processes. This data then informs the automated terms of a contract by posting results and accompanying proof to the blocks.
A smart contract is a software program that automates the execution of contract terms. It applies to only the performance of executable terms of a contract. Smart contracts do not replace natural language contracts but instead function as a program that connects to a natural language contract through an addendum that establishes an inviolable link between the program and a natural language contract.
In theory, the process sounds great. But in application, there are a few obstacles to overcome. Here are several early lessons learned from navigating the emergent process of aligning legal language with terms and data necessary for smart contract codeability.
Imprecise Data Does Not Compute
Contracts are often intentionally ambiguous to leave room for the benefit of interpretation. Optimally vague contracts allow space for argument and in doing so, enable contract participants the opportunity to leverage their side of data collection to make a case and, ultimately, financial consequence. This can lead to claims, disputes, exacerbated legal expenses, project and operational delays, invoicing and payment delays, and the slow close out of a contract after work is completed, all of which impact the greater supply chain and the delivery of the value stipulated by the contract.
In industrial sectors, field data captured through an IIoT platform from a wide array of sources and posted to the blocks of a distributed ledger can render this long-standing practice and its corresponding litigious contention obsolete. To do so, a comprehensive and clear picture of the business and operational practices for involved parties is necessary when defining and agreeing on terms in order to automate contracts.
In other words, contracts will no longer be able to accommodate vagaries. For example, location and time need to be explicit. If one company traditionally collects data at the close of business operations in local time, but this isn’t specified to the counterparty, and the counterparty measures data at the start of a business day in Coordinated Universal Time (UTC), confusion ensues. Participants need to agree on “specific data,” which in this case includes the exact time zone to be used along with the specific time and what that means for contractual terms and fulfillment. Legal departments drafting contracts need to consider details like this in advance.
Creating Logic Parameters
Blockchain-backed contracts tout real-time data recording capabilities, but in actuality, should say near real-time instead. For example, a data feed from one trucking company clocks readings every 15 minutes for reports while another runs reports at the end of each day. What data source will these companies use for their contract? And what are the tolerances?
For example, regarding the volume of water at a saltwater disposal site from an oil and gas production well, when using a reading of volume in the truck versus the sensor output at the site, what is the match tolerance? Furthermore, what type of rounding will the smart contract act on? Rounding down, up, intermittent, bankers’ rounding? These are the types of questions that must be asked and hammered out prior to translation for smart contract codification. Smart contracts become, in effect, data specifications.
Specificities inform logic parameters around data and incongruent readings can’t be automated.
Two disparate data sources can’t generate consensus for a contractual condition to dictate payments. As listed above, location, time, and rounding decisions impact how contracts translate into code. Legal contracts must contain terms on parameters including sources, tolerances, frequency and time frames of data capture methods among others.
Contradictory Language
In practice, contracts become evergreen documents that get edited, appended, and cut/pasted over years as an original contract gets applied to transaction after transaction over periods of time. This invariably results in terms and conditions that are either disparate or contradictory due to legacy verbiage that carries over—typically by procurement departments—through a contract’s lifetime. Understandably, it’s easier to modify an older contract that’s “close enough” than it is to fabricate a completely new one. Problems arise, however, when an older contract used as a starting point has irrelevant or inapplicable clauses that have been forgotten to be removed. The code of a smart contract cannot be made to execute contradictory terms.
For billing language, this is a common issue. If one company’s contract specifies to be paid on the fifth of each month by 12:00 UTC and the counterparty invoices twice a month, on the first and 15th of a month, it’s obvious that confusion (and dismay) will abound with this discord. Smart contracts are essentially “dumb.” They execute exactly what they are programmed to execute and are incapable of judgment. Rules of engagement, particularly those regarding fee calculations and billing practices, must be able to be encoded from clear, non-conflicted contract terms.
Anticipating Data Glitches and Gaps
IIoT data provides source information to inform the execution of a smart contract. Although IIoT data’s reliability and integrity are an order of magnitude better than human-entered data, there will always be technology glitches and failures that result in data gaps or errors.
The good news is that these occasions can be reasonably anticipated and protocol for them can be incorporated into both natural language and smart contracts. With agreed-upon terms for these events, a smart contract can be programmed to navigate data tolerances and triggers that automatically recognize when a glitch or failure has occurred. It can then execute the correct predefined action, agreed upon upfront by both parties resulting in zero delays or downtime to the relationship.
The Move from Risk-Based to Outcome-Based Thinking
Today’s contracts are stuck in a paper-based way of framing up the world. Although many interactions between and within companies have been digitized, digitization still revolves around a risk-based approach to relationships. A “paper” contract—whether an actual printed copy or an electronic file—illustrates commitment; it is the vehicle that codifies an agreement, a system meant to move work forward as a stopgap to measure and execute services against. But it is inherently rife with distrust and bias depending on what side of the contract you are operating on. This way of thinking perpetuates a paper contract economy concerned with negotiating risk and how risk gets equitably shared between parties.
In the future, smart contracts will force a new methodology, that of outcome-based thinking. By capturing digital information that records performance measurements, it’s possible to write contracts that operate optimally for autonomous systems, taking paper workflows, human emotions, and inherent biases out of the equation. Risk mitigation moves to a new arena. Instead of indemnification due to human error, attention will go toward creating digital rules that can be autonomously executed. The lawyers of tomorrow will need a new valued skillset focused not on how to protect clients from risk, but how to construct efficient contracts that leverage digital environments to facilitate the measurement execution of contracts.
Moving to an outcome-based approach incentivizes logistics to perform better. Identifying causes of variability and error then systematically eliminating them generates an input to outcome relationship, the crux of an agile legal approach. Don’t be surprised when law firms of the future retain data scientists on their teams to leverage blockchain technology and harness the benefits of smart contracts for all.
