Former IT Engineer Lawyer Explains the Similarities between Contract Review and Debugging

The core duty of a so-called “corporate legal advisor” is to check and revise contracts that the company enters into daily with clients and business partners. However, these checks and revisions can only be adequately performed by someone who is well-versed in both the law and the specific business field. Let’s explain why this is the case.

However, the following explanation may be difficult to understand for those who are not engineers or have programming experience. Monolith Law Office is a law firm led by a former IT engineer and experienced business manager. It is positioned as an article explaining contract checking and revision for managers with engineering or programming experience, from the perspective of a law firm led by a former IT engineer and business manager.

With this positioning in mind, checking and revising contracts is a task similar to the so-called “debugging”.

1. What is a “bug” in the first place?
2. What kind of work is “debugging”?
3. How does a contract define an algorithm?
4. What kind of work is contract revision?

Starting with what may be “obvious” to engineers, we will explain in the order listed above.

What are “Bugs” and “Debugging”?

A “Bug” is not a “PC Failure”

When we say “bug”, some people might imagine a scenario where smoke comes out of the machine while working on a PC and the screen displays something strange. However, a PC basically only operates as instructed. This is also true when a bug occurs. In other words, a “bug” is a phenomenon where:

• The PC is operating as instructed, but
• The operation is “unexpected behavior” for the user

.

Why does “unexpected behavior” occur?

For example, let’s consider the “wall-through” bug in a Mario-style action game.

Mario’s jump is a quadratic function. Acceleration, speed, coordinates. However, in a typical quadratic function, you can divide X infinitely finely, such as “What is Y when X=1.76582?”, but in a video game, you cannot divide time infinitely finely. This is because the screen only switches 30 times per second (for example). Therefore, in a sense, Mario is “warping” 30 times per second.

In this context, when we say “Mario jumps and bounces off a wall in the sky”, it means:

1. Mario was in the air a moment ago, but
2. The next moment, Mario’s coordinates are inside the wall

.

In such a case, we can judge that “Mario hit a wall in the sky while jumping”. Therefore, if we write a program in natural language that says:

If Mario’s coordinates are inside the wall, perform a bounce-back process (Note 1)

, we can realize the process of “Mario jumps and bounces off a wall in the sky”.

Note 1 seems correct as long as it is written as above. And indeed, this process is correct “under certain conditions”.

However, upon closer consideration, there could also be a situation like the one below (Note 2).

In this case, there is no moment when “Mario’s coordinates are inside the wall”, so the bounce-back process is not performed, and Mario ends up slipping through the wall.

This is an example of a “bug”. Even if a “wall-through bug” occurs for such reasons, it does not mean that the PC is broken. The PC is only behaving as instructed, and it is humans who evaluate that behavior as “unexpected” or “a bug”. And this “bug” occurs because the algorithm is not appropriate.

Considering whether “unexpected behavior will occur”

However, whether the above-mentioned “wall-through” will occur in the actual game play process is unclear just by thinking abstractly as above. Whether or not “wall-through” can occur depends on:

• How much jumping power (initial speed) does Mario have? Are there any items like jump power-ups?
• How thick is the wall at its thinnest?

It depends on these conditions. Depending on whether or not a situation like Note 2 can occur under these conditions, the program in Note 1 is not a problem if Note 2 cannot occur.

What kind of work is “Debugging”?

Therefore, in order to “debug”, i.e., find and fix bugs, the following processes are necessary:

1. Read and understand what kind of algorithm the program is (Note 1 is in natural language, but in reality, programs are written in a unique language, so reading itself is difficult)
2. Consider under what conditions the program operates (investigate the jumping power and thickness of the wall)
3. Consider whether any unexpected behavior will occur during this time

.

What Does Contract Review Entail?

Contract review is a process similar to this. A contract, to begin with, is a tool that regulates the rights and obligations of the parties involved, namely Party A and Party B, in anticipation of future events. It outlines how both parties should act as a result of these events. In this sense, it can be described as a ‘program that regulates the real world’. For instance,

In the event of a situation called ●●, Party A will compensate Party B with 1 million yen.

Contracts that establish such rules define the conditions and effects related to future events.

Therefore, the task of verifying whether there are any issues with this ‘program that regulates the real world’ and making corrections if there are, inevitably resembles ‘debugging’.

The Full Picture of the Algorithm is Not Described in the Contract

However, there is one point about “contracts” that is difficult to understand for those who are not legal professionals, but is extremely important. That point is that a contract only stipulates a “part” of the algorithm that governs the parties involved. In other words, just by reading the contract, you cannot fully understand the algorithm under which you and the other party are governed.

For example, when you buy a used CD at a store, the store and the customer do not enter into something like a “sales contract”, but if there is a scratch on the CD that makes it unplayable on a player, you would want to complain to the store, and you would expect the store to respond. This is not just a matter of “because it’s a service industry”, but theoretically,

1. Even without a contract, a sales contract is concluded
2. The Japanese Civil Code stipulates that the seller is liable for defects in the sale of specific goods such as used CDs
3. Therefore, the algorithm defined by the Civil Code is running between the store and the customer, and the store is liable for defects

This is the logic. And a “contract” is something that overwrites the algorithm defined by laws such as the Civil Code. For example, if there is a contract between the store and the customer that says “We do not accept any claims for defects in CDs after the fact”,

1. A sales contract is concluded
2. The Civil Code stipulates that the seller is liable for defects in the contract
3. However, according to the provisions of the contract, the principle of 2 is overwritten, and the store is not liable for defects

That’s how it works.

Contracts Overwrite the Principles of the Civil Code

This is also true for contracts concluded between companies, such as system development. For example, if a contract for a subcontracted system development is concluded between Party A and Party B,

1. The subcontract agreement is clearly established by the conclusion of the contract
2. In the case of a subcontract agreement, the contractor assumes a warranty liability according to the provisions of the Civil Code
3. If there is a provision for warranty liability in the contract, that provision overwrites the principle of the Civil Code in point 2. For example, if a warranty liability clause for a longer period than the Civil Code principle is provided, the stipulated period is valid

This means that even if there is no specific provision regarding warranty liability in the contract, warranty liability arises.

This is not limited to subcontracting or system development, but is a general theory regarding all contracts that a company enters into, such as stock transfers, fundraising through debt (money lending), employment, and stock issuance.

Therefore, just reading the contract does not allow you to grasp the full picture of the ‘algorithm’ that governs the relationship between the other party and your company. To grasp the full picture, you need to understand the ‘default algorithm’ defined by laws such as the Civil Code. This is because the contract merely overwrites this ‘default algorithm’.

You Can’t “Debug” Without Anticipating Future Events

Understanding an algorithm alone does not allow you to verify whether it will behave unexpectedly. This is similar to the case of “bugs” in games. Algorithms are abstract entities, and unless you anticipate what events may occur in the future, you cannot verify whether they will behave unexpectedly when such events occur.

This is a significant issue, especially in the case of new products such as apps or services, or new business schemes. When you launch a business with such products or schemes, it’s crucial to consider what could happen in the future. This can be difficult to anticipate without knowledge in the relevant field. Moreover, particularly in the case of inter-company contracts, both your company and the other party act under certain economic rationality. Therefore, a game-theoretical approach to business management is necessary to predict future events and the actions of the other party that may cause them.

Whether it’s “Unexpected” is Based on Management Judgment

Furthermore, just as it is humans, not PCs, who determine whether an event is a “bug”, whether a certain outcome brought about by a contract is “unexpected” is not purely a legal matter, but a matter of management judgment.

For example, there may be cases where an algorithm “in accordance with the principles of the Civil Code” is unacceptable for a certain business of a certain company. This is a different topic from the previous examples, but for instance, the Civil Code stipulates a default algorithm that “re-delegation by the trustee is a breach of contract” for quasi-mandate contracts. However, there may be cases where “for a certain company, a certain business is naturally expected to use subcontractors”. In such cases, it should be impossible to accept a contract that does not allow re-delegation, i.e.,

• Nothing is explicitly stated about the possibility of re-delegation (in this case, as mentioned above, the principles of the Civil Code apply)
• It is explicitly stated that re-delegation is not possible

Even if it is “in accordance with the principles of the Civil Code”, it should be impossible to accept such a contract.

Also, in management, there is always a risk of being held responsible if a certain event occurs. There is basically no such thing as a contract that poses no “risk” to the company. Whether or not to accept that risk is ultimately a management decision. It is the manager, not a consultant such as a legal advisor, who makes management decisions, but the consultant should present the necessary and sufficient information for the manager to make management decisions, such as

• Risks that do not need to be pointed out each time
• Risks that require a significant decision by the company to accept, and may require meetings, etc.

These must be pointed out with varying degrees of emphasis. Just like consultants in other fields, lawyers who check contracts also need a certain sense of “management” to set these “degrees of emphasis”.

Summary

As such, it can be said that the process of checking and revising contracts largely involves the following tasks:

1. Understanding how the principles of the Civil Code and other laws are overwritten by the contract, and what algorithm results from this
2. Considering what events could occur in the future under this algorithm
3. Checking whether any unexpected behavior occurs

And each of these tasks is:

1. A difficult task unless performed by someone who understands the law
2. A difficult task unless performed by someone who understands the content of the business, such as apps or web services, and the business scheme that the contract regulates
3. A difficult task unless performed by someone who has a certain understanding of the company or business content, and business sense

That’s why.

Checking and revising contracts is very “specialized” for these reasons.

Contract Creation and Review Services by Our Firm

At Monolis Law Firm, as a legal firm with strengths in IT, Internet, and business, we provide various services such as contract creation and review to our advisory and client companies.

If you are interested, please see the details below.