Semantics in Business Systems: The Savvy Managers Guide (The Savvy Managers Guides)

Everything we've described up to now concerns the present or the past. But business is about the future. The future adds the dimension of committing to some described action. Most business is the making and executing of agreements and contracts. To realize that contracts are at their center steeped in semantics, we need go no further than the observation that most contracts require expensive legal talent to interpret.

You may feel that you are better served to leave your agreements semantically ambiguous and trust that your lawyers will allow you to interpret them the way you would like them to be interpreted later. But that is a game for people who would rather make their money reinterpreting what they believe was intended when an agreement was entered into, rather than for business people who really had an intention.

Contracts Are the Last Bastion of Intentional Obfuscation

There are 880,000 lawyers in the United States, representing at least a $100 billion industry.^[4] One of the most lucrative things they do is draft, interpret, and litigate contracts. If contracts were easy to draft and easy to interpret, they would also be easy to litigate in those fewer cases when they would go to court.

There are tens of billions of dollars at stake to make sure the contracts remain complex. Contracts are not only so complex that a computer couldn't interpret them, but so complex that a layperson also couldn't interpret them.

"It's difficult to get a man to understand something when his salary depends on his not understanding it."

—Upton Sinclair

It Is Possible to Have Unambiguous Contracts

It is possible to have unambiguous contracts, even about fairly complex topics. We were involved with a pharmaceutical company once on a deal that would have been worth nearly a million dollars to us. They were quite interested in our intellectual property, and had their team of lawyers draft a contract. (Pharmaceutical companies have many highly paid intellectual property lawyers.) They drafted a 30-page document that was structured like a COBOL program before structured programming was invented: Any paragraph in the document could, and did, override provisions or change definitions elsewhere in the contract. Despite 30 pages of text, most of the essential elements of the agreement were still vague.

We did a semantic analysis on the contract. The discussion that follows is based largely on that review. It is presented here for two reasons:

1. To show that even the most complex areas of business can be rationally and systematically understood semantically, to great benefit to the participants (assuming they want to understand the agreements into which they are entering).

2. To begin a discussion, which is taken up later in the book, about the potential for having software agents create, negotiate, and abide by contracts without having to involve humans (let alone lawyers).

What Is a Contract?

The classic definition of a contract requires that to be enforceable, a contract must have four things:

1. Mutual assent—There is evidence that both parties agreed to the contract. Usually this is accomplished by reducing the contract to writing, but it's not always necessary.

2. Legality—The subject matter is legal (you can't make a contract to kill someone).

3. Capacity—The parties are of age of majority, not insane, and so on.

4. Consideration—Each party had some sort of economic incentive to participate in the contract (this is why there are often contracts where the consideration is a few dollars).

If you dig a bit deeper, you'll find some semantics behind these considerations, and if you look at particular types of contracts, you'll see more, as we discuss next. Figure 2.1 is a highly simplified semantic representation of a sales contract.

Figure 2.1: A highly simplified semantic representation of a sales contract.

Frequently, we would label the lines between the concepts, but in this case we can discuss it without labels. Most real estate, personal property, and intellectual property contracts that I have examined have a structure very similar to this. At their heart they contain the following elements:

• Parties—All contracts have parties (most have two parties), and the first part of most contracts identifies the parties. Semantically we're interested in what a party is (there are several types, including individuals, married couples, and corporations, as well as ad hoc groups that come together just for the contract) This is generally pretty straightforward, but there are some complexities regarding whether the maker of the contract can bind the parties, and whether the parties have the capacity to contract. There may be an agent contracting on behalf of a party, and this must be spelled out. (There are some three-party contracts, but typically not in property transfer.)

• Jurisdiction—Contracts have jurisdictions, either explicit or implicit. Jurisdictions are legal contrivances that establish some of the semantics of the contract, as well as set up procedures for dealing with disagreements or violations of the terms of the contract. This also establishes whether the transfer is taxable, and if so, the contract must specify who bears this.

• Property/subject—Most contracts deal with something, and in most cases that something, the subject, concerns products or services. Sometimes the subject is the item to be exchanged, but sometimes the description of product or service is a contingency regarding the entire contract. As mentioned previously, the subject must be legal. But we are more concerned with what the subject is. Is it a piece of real estate, a widget to be purchased, or what? Usually the subject is property, which might be personal property, real property (land and buildings), or intellectual property (songs, movies, software, trade secrets, etc.).

• Rights—It's apparent that intellectual property contracts deal with what rights in the intellectual property are conveyed with the contract. For instance, a recording contract may indicate that the rights to the songs in the subject have been transferred to one of the parties to the contract. We talk about taking possession in real estate contracts, but really you just acquire rights to the property in question—perhaps the right to occupy or the right to drill for oil.

• Transfer—The lawyers call it conversion, but it basically means some physical good or right was transferred from one party to another.

• Encumbrances—If a right has restrictions, we call these encumbrances on the right. For instance, your land may have encumbrances for easements. Your employment contract may restrict what you can do while working for your employer and for a period of time afterward (called noncompetes and the like, but they are really encumbrances on you).

• Warranties and obligations—Most contracts deal with the future, and some obligation that is placed on each party. For instance, in a purchase contract the seller is obligated to deliver the goods and the purchaser is obligated to pay.

• Contingent events and remedies—Either of the parties may fail to execute on their obligation. Contracts often specify what remedy the other party has in that case. In the absence of specific remedies, generally the jurisdiction provides default remedies.

Other types of contracts (service contracts for consulting or employment, etc.) are scarcely different in structure, except that the property is a promise to deliver a service over some time period in the future. Typically the warranties concern noncompetes, confidentiality, and so on. An insurance contract substitutes indemnity for transfer and concerns itself with which set of circumstances are recoverable and for how much.

Contracts that Even a Computer Could Understand

It may sound a bit strange, but in the not too distant future we are going to need to have contracts that can be interpreted by software programs. A product by Business Integrity shows how this type of technology can be used to generate contracts.^[5] The IntellX product saves the parameters and generates a traditional text contract. It doesn't take a huge leap to imagine applications interpreting the contract based on the parameters in the model. It is going to be far easier if these contracts are structured in a highly regular fashion, similar to the way the contract in Figure 2.1 is structured.

How Semantic Clarity Can Overcome Even Intentional Obfuscation

Contracts are complex, at least in part because the legal industry, by its very nature, tends to create agreements that require additional interpretation. Semantics in general, and in the future, semantically inspired tools and applications, force the composer of the contract to structure the content of the contract in a way that removes ambiguity. The way this process works is primarily through forced choice selections. If a contract concerns the transfer of rights in a program, exactly what rights are being transferred (select one from a limited list of choices)? Through this process, whether you do it by hand or with a tool, you arrive at an agreement with a small fraction of the ambiguity of a normal contract.

^[4]2000 Statistical Abstract of the United States, Section 12, "Labor Force, Employment and Earnings," p. 18.

^[5]IntellX—Document Assembly Software. Available at http://www.business-integrity.com/IntellX.html.