How sensible contracts change authorized contracts

While a world without lawyers will most likely never materialize (to the chagrin of many parties), new technology in the form of smart contracts is changing the way legal matters are formulated. This can be seen in the increasing acceptance of key industrial applications at the OOC Oil & Gas Blockchain Consortium, a powerful network of 10 large oil and gas companies. In addition to the Construction Industry Institute of the University of Texas’s most recent Operating System 2.0 (OS2) initiative, a collaborative research and development project focused on capital projects, smart contracts powered by distributed ledger technology are shaping contracts of the future.

Whether it’s regulatory compliance, contract enforceability, cross-border financial transactions, material origins, document management, or other applications, smart contracts offer unparalleled functionality and the automation of contract terms. However, the “if-then-else” logic that smart contracts and their coding work with does not inherently work in step with the natural language of legal contracts. Because legal and contract organizations are typically far removed from business and operating systems, they can create contract terms that execution teams cannot follow or manage.

Smart contracts integrate with two other technologies, Industrial Internet of Things (IIoT) and Distributed Ledger Technology (DLT), to review, validate, capture and enforce agreed terms between multiple parties. A smart contract captures real, legally regulated events and gathers IIoT data for performance measurements, including information from sensors, meters, and other business processes. This data then informs the automated contract terms by sending results and associated evidence to the blocks.

A smart contract is a software program that automates the execution of contract terms. It only applies to the fulfillment of the executable contractual conditions. Smart contracts do not replace natural language contracts, but act as a program that connects to a natural language contract through an addendum that creates an inviolable link between the program and a natural language contract.

In theory, the process sounds great. However, there are some obstacles to overcome in its application. Here are some early lessons from steering the emerging process of aligning legal language with the terms and data necessary for intelligent codability of contracts.

Inaccurate data will not be charged

Contracts are often intentionally ambiguous to allow room for interpretation. Optimally vague contracts leave room for argument and allow contractors to use their data collection side to draw a case and ultimately financial consequences. This can lead to claims, disputes, exacerbated legal costs, project and operational delays, invoicing and payment delays, and the slow completion of a contract after the work is complete, which affects the larger supply chain and the delivery of the specified value through the contract.

In industrial sectors, field data collected through an IIoT platform from a variety of sources and placed in the blocks of a distributed ledger can eliminate this longstanding practice and associated litigation. To this end, a full and clear picture of business and operational practices is required for the parties involved when defining and agreeing terms to automate contracts.

In other words, contracts can no longer accommodate whims. For example, the time and place must be explicit. Confusion arises when a company traditionally collects business close data in local time but this is not reported for the counterparty and the counterparty measures data at the start of a business day in Coordinated Universal Time (UTC). Participants must agree on “specific dates”, which in this case contain the exact time zone to be used as well as the specific time and the significance for the terms of the contract and performance. Legal departments drafting contracts must consider such details in advance.

Create logic parameters

However, blockchain-backed contracts promoting real-time data recording capabilities should in reality be done near real-time. For example, one data feed from a shipping company collects metrics for reports every 15 minutes, 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, what is the compliance tolerance for the volume of water at a saltwater disposal site from an oil and gas well using a volume reading in the truck versus the sensor performance at the site? What kind of rounding will the smart contract have? Rounding down, rounding up, temporarily, bank rounds? These are the types of questions that need to be asked and elaborated for smart contract codification prior to translation. Smart contracts practically become data specifications.

Specificities inform logical parameters about data and incongruent measured values ​​cannot be automated.

Two different data sources cannot reach a consensus on a contractual term to determine payments. As noted above, location, time, and rounding decisions affect how contracts are translated into code. Legal contracts must contain provisions on parameters, including sources, tolerances, frequency, and timeframes of data collection methods.

Contradicting language

In practice, contracts become evergreen documents that are edited, appended, and cut / pasted for years when an original contract is applied to transactions after transactions over a period of time. Without exception, this results in terms that are either different or contradicting due to different idioms that are transmitted – usually by the procurement departments – during the life of a contract. Understandably, it is easier to modify an older contract that is “close enough” than to fabricate a completely new one. Problems arise, however, when an older contract that is used as a starting point contains irrelevant or inapplicable clauses that have been forgotten to remove. Smart contract code cannot be used to execute conflicting conditions.

This is a common problem for the billing language. If a company’s contract stipulates that it be paid on the fifth of each month by 12:00 UTC and the other party invoices twice a month, on the first and 15th of each month, it is evident that confusion (and dismay) with that discord abound. Smart contracts are essentially “stupid”. They do exactly what they are programmed to do and are unable to judge. It must be possible to encode the rules of engagement, in particular with regard to fee calculations and billing practices, from clear, non-contradicting contractual terms.

Anticipating data errors and gaps

IIoT data provides source information to inform the execution of a smart contract. Although the reliability and integrity of IIoT data is an order of magnitude better than the data entered by humans, there are always technological glitches and errors that lead to data gaps or errors.

The good news is that these occasions can be reasonably anticipated and the protocol for them can be incorporated into both natural language and smart contracts. With agreed terms for these events, a smart contract can be programmed to navigate through data tolerances and triggers that automatically detect when an error has occurred. It can then take the correct pre-defined action agreed in advance by both parties, resulting in no delay or downtime in the relationship.

The transition from risk-based to results-based thinking

Today’s contracts are stuck on paper to shape the world. Although many interactions between and within companies have been digitized, digitization is still about a risk-based approach to relationships. A “paper” contract – whether it is an actual printed copy or an electronic file – illustrates the commitment. It is the vehicle that codifies an agreement, a system designed to move the work forward as a stopgap measure and execution of services. But it’s inherently full of suspicion and bias, depending on which side of the contract you’re on. This mindset continues a paper contract economy that deals with negotiating risk and distributing the risk fairly between the parties.

Smart contracts will force a new methodology in the future, that of results-oriented thinking. By capturing digital information that records performance measurements, it is possible to write contracts that work optimally for autonomous systems and take paper workflows, human emotions, and inherent biases out of the equation. Risk reduction is moving to a new arena. Rather than compensation for human error, care is taken to create digital rules that can be executed autonomously. Tomorrow’s lawyers need new, valuable expertise that doesn’t focus on protecting clients from risk, but rather on creating efficient contracts that use digital environments to make measurements easier.

Moving to a results-based approach provides incentives for logistics to perform better. The recognition of causes for variability and errors and their systematic elimination leads to an input-result relationship, the core of an agile legal approach. Don’t be surprised if future law firms keep data scientists on their teams to leverage blockchain technology and take advantage of smart contracts for everyone.

Comments are closed.