The lowly contract, a staple of business transactions everywhere, is about to get a major facelift. The typical role of a contract to date has been largely testimonial: an agreement is made between two parties (identified in painstaking detail) on page one, with stipulations about what is to be delivered at what cost, and the penalties that accrue if one or the other party fails to live up to their part of the agreement. Once the appropriate John Hancocks are signed, a process that usually involves multiple trips to Federal Express or similar courier services, the contracts end up in a drawer somewhere, likely never to see the light of day again. They are in general very boring even to lawyers unless of course one of those penalties is tripped, at which point they can get very exciting indeed.
What makes contracts so intriguing in a world of data is that they initiate and control the evolution of processes and that there is in fact typically a chain of contracts that occur over the lifespan of those processes. For instance, consider what it takes to get a movie to the screen. Typically, a studio will solicit bids from producers, often for more than one show at a time (what are typically called options).
The agreement is signed, and the producer will then set up separate contracts with directors, screenwriters, casting agents, location agents and so forth, who in turn are tasked with hiring the “talent” — the actors, artists, musicians, special effects houses, film houses. The list gets to be daunting quickly. Each of these, of course, is also contractual in nature, though the contracts may have been part of other longer-term contracts, such as an A-List actress agreeing to be available for three films.
Filming begins, the writing works great, the actors hit their marks perfectly every time, and a tape (or increasingly a high capacity drive) gets transferred to a production house, where the directors and film editors review the footage, select the relevant scenes, then pass these on the post-production team. Meanwhile, actors need to be fed; animals are taken care of, locations ascertained, music and sound effects added, studio space booked ... and all of these things also have contracts. The masters are prepared from the compiled footage, and eventually, a unified visual master is created.
While this is going on, the sales team has been talking with distributors, getting contracts for converting the native master into other languages, shooting additional scenes in order to ensure that local sensibilities are not offended, translations are produced and voiced over, often with a turnaround on the order of days or less. This means that over the course of a couple of years, one contract has morphed into hundreds. In the end, the film makes a gazillion dollars, and the contracts end up forgotten, taking up space in that giant warehouse at the end of first Raiders of the Lost Ark movie.
In the real world, things, in general, do not go quite the way they are expected to. A producer may end up with a lousy concept, or the script, which looked so good on the first read through, comes out flat when actually delivered. Actors die or get arrested, or just don't work out. The post-production graphics look like crap, production drags on for years, the wrong copy gets sent to a distributor (it happens more often than you'd think). At this point, the contracts come back out, the provisions get re-examined, and, depending upon arbitration conditions, redress is sought.
It is at this point that contracts and civil law intersect. When a provision was written, was it enforceable? Were there certain conditions beyond the power of the defendant that otherwise invalidated the contract? Was the expectation by the plaintiff excessive in comparison to what was actually delivered? Contract law can be very contentious because it frequently requires measuring intent and expectations, neither of which is always quantifiable.
Yet before it ever gets to court, the contract still serves a great number of purposes, not the least being the establishment (and assignment) of responsibility, remuneration and milestones. It frequently determines ownership, limits scope based upon location or other factors, and frequently indicates that other actions should be initiated in the case that a specific provision is met or voided. Semantically, a contract is considered a binding transaction — it binds the participants together in a common enterprise at specific places and times for specific objectives. These transactions are also considered “link-rich” in that they link together the various key entities that, including people, organizations, locations, intellectual property, localities and so forth. In many respects, the tree (or, more properly, graph) of these contracts forms the backbone that connects resources to products.
A smart contract is one in which every resource involved can be uniquely identified via some kind of conceptual identifier in a persistable machine-readable manner. Such resources can include entities, of course — this actor, this movie, this vehicle, this property and so forth — but it also can include specific statements or provisions within the contract itself. One way of thinking about this is that even with a generic (or template) provision, the provision for that contract only applies to those specific parties that signed the contract. For those familiar with programming, the distinction here is between a class (the template) and an instance (the template with names filled in).
This contract can be represented semantically as a semi-structured electronic document, typically an XML document, where every resource, every provision, and every constraint has a global identifier. The same document can also be represented using RDF, where the resources in question are then bound either directly or indirectly to the contract itself (which, not surprisingly, also has a unique global identifier).
What makes this smart contract so useful is that the various provisions of the contract can also be encoded as rules. When a given resource changes its state (some properties change values), the contract system can test the contract that contains that resource and see if one or more rules get tripped. Sometimes those rules are positive, such as a milestone was successfully met and approved by the client, while other rules are negative, such as a provider performing a product or service that did not meet the client's expectation.
From the standpoint of the smart contract, these are both just different rules that initiate secondary actions. The first signals to the accounting department to begin processing a payment, while the second signals to the legal department that it's time to bring out the lawyers.
Because this contract is data (and metadata), the actions that are invoked can be determined from the contract itself. This in turn significantly reduces the overall complexity of the application into parameterizing microservices calls. What's more, each transaction will also leave its own ghost markers in the system as global identifiers ... and these identifiers can then be recorded in a permanent ledger.
When the discussion around smart contracts arises, blockchain usually surfaces as being tied to smart contracts. This isn't necessarily required — you can build smart contracts without ever cracking open a blockchain API. However, what blockchain does do is provide a mechanism for permanently recording transaction identifiers and dates, as well as providing one mechanism to give a physical world entity a distinct global identifier.
In effect, what the blockchain does is to distribute the record of the transaction, putting it into several different blockchains when the transaction occurs. Should someone come into the database and change data (in effect, committing fraud) then the recorded transactions in the blockchain will no longer be in sync, and the transaction will consequently be flagged as potentially corrupted.
This is one of the reasons that there was originally such interest in blockchain by financial institutions; it provided a vehicle to reduce fraud. While larger financial institutions (which hold the bulk of the loans, liens and titles globally) have since developed their proprietary solutions in many cases, the idea that made blockchain so attractive initially remained - it made it much harder to claim a given resource was the resource specified in a smart contract if it wasn't.
One additional advantage that smart contracts provide comes in the above scenario. Contracts do not occur in a vacuum. They are typically part of a process, and can in fact even be used to drive processes, especially when combined with some form of business process management software and methodologies (BPM). This affects, well, everything.
For instance, in the movie studio example, a smart contract between a studio and a production house could establish global identifiers for the media being created, can notify studio production when the media has been produced or processed, can transfer the media to the appropriate network and can then hang suspended for an approval before creating a new master for a special effects, sound effects, music or other editing.
Beyond this, such smart contracts can be queried so that a director or executive can see, at a moment's glance, how far along a given process the product has reached, can see (and initiate) a review, and from this get a better handle on production numbers.
In order for this happen beyond the boundaries of one-off solutions, it will become necessary for the underlying models of smart contracts to become standardized. Beginning in 2016, the W3C sponsored a workshop on blockchain and smart contracts that is now moving towards broader standardization, including most notably the CommonAccord proposals. These proposals examine various facets of smart contracts, including the structural and semantic aspects, identity and signatory management, orchestration and the accounting or auditing (e.g., Blockchain) components. While various "smart contract" solutions abound, it is likely that the technology will really only take off once there is a clear consensus in business about which standards will dominate.
Smart Contracts, like so much of the interconnected web, are not necessarily novel ideas. There have been various attempts at building smart contracts since the 1980s.
However, the technology (and more importantly the standardization) of the various components have each been maturing at their own pace, and it's only been within the last few years that all of the key pieces have reached a level of maturity where inter-Enterprise smart contracts are feasible. As such, expect that smart contracts will quietly bubble up over the next decade, kind of like the way that fax machines reached a critical mass after years of being below the horizon.
Kurt Cagle is Managing Editor for Cognitive World, and is a contributing writer for Forbes, focusing on future technologies, science, enterprise data management, and technology ethics. He also runs his own consulting company, Semantical LLC, specializing on Smart Data, and is the author off more than twenty books on web technologies, search and data. He lives in Issaquah, WA with his wife, Cognitive World Editor Anne Cagle, daughters and cat (Bright Eyes).