Sunday, March 10, 2013

Focus and Leverage Part 192

Categories of Legitimate Reservations (CLR’s)

 In this posting, we’re going to take a closer look at TOC’s Thinking Process tools.  No discussion about the TOC Thinking Processes would be complete, or accurate, without an in-depth discussion about the Categories of Legitimate Reservations, commonly referred to as the CLR’s.  In most discussions, the CLR’s are often ignored or glazed in briefness. However, the CLR’s are an extremely important component for using the TP, and conducting a successful analysis.

The concept behind the CLR’s is they provide the methods and tool to scrutinize the entities, entity statements and arrows between the entities themselves.  The CLR’s can apply to ALL entities  and tree within the TP stable.

Let’s begin with a short review of the TP.  The TP tools are based upon two different type of logic for construction and verbalization.  The first type of logic is Sufficiency Based and implies that the arrow between two entities is sufficient to cause the relationship of sufficiency between the two entities. In other words, it’s a cause-effect-cause relationship between entities.  From single cause statement can come many different effects statements, with a minimum of one effect.  What the arrow implies between two entities is that the entity at the base of the arrow is “sufficient” to cause, or have caused, the entity at the tip of the arrow.  The sufficiency arrow is read “if (the entity at the base of the arrow exists), then (it is sufficient to cause the entity at the tip of the arrow to also exist). The thinking tools associated with sufficiency include the Current Reality Tree (CRT), Future Reality Tress (FRT) and, the Transition Tree (TT).  The second type of logic is focused on Necessity.  In other words, you are looking for the “necessity” relationship between two entity statements.  In determining necessity the arrow between two entities is read “in order to have... (entity at the tip of the arrow), I must have…(the entity at the base of the arrow).  Necessity logic thinking includes the Pre-Requisite Tree (PRT) and the Conflict Diagram (CD).

The important take-away from the discussion above is the emphasis on the entities and arrows.  The arrows are the binding element that holds the trees together.  If we get the arrows and entities wrong, then there is high probability that the entire tree is wrong!  This is the important, and distinctive, aspect of the CLR’s to help determine if the tree is logical and correct.  The CLR’s are used to validate entity existence, causality existence, predicted effect existence, cause insufficiency, additional cause, tautology and to insulate the arrows for correctness and accuracy.

In logic we are dealing with the relationships between entities therefore; the basic relationship is defined as cause-effect-cause relationship.  This relationship is focused on the “causality” between the entities and is expressed with an arrow between them.  Scrutinizing entities and arrows on a tree can be frustrating and very time consuming but, also worth the effort.

Each of these seven CLR categories has a purpose, and the best of expression for each category should be applied to EVERY entity and arrow in a tree.  Let’s review the seven CLR’s for application and expected outcome for the use.


For an entity to be accurate and correct it must be expressed as a statement.  Making a statement does not mean that the entity statement is valid therefore; it must be scrutinized for its existence in reality.  If the entity does not exist in reality it cannot be used as an entity in a logic tree.

The primary focus of the entity existence reservation is to ask yourself “Does the entity, as stated, exist in reality?”  If it doesn’t, then clarify the wording in the statement to reflect what reality really is.  As an example:
                                   A                                         B
In the A example above it can easily be argued that the cause (base of the arrow) is NOT a statement.  If you try and read this arrow using sufficiency and the “If…, Then…) it makes no sense.  It should be replaced by a complete statement that reflects reality and solidifies the arrow between the two entities.  Example B provides such a statement.

It is worth noting that in a negative tree, each entity MUST be scrutinized to its existence in current reality.  In a positive tree (Future Reality Tree) when you are dealing with entities that do not or might not exist yet, then this category of the CLR is only valid for those entities in the tree which ARE NOT considered Actions.


Probably one of the most powerful reservation checks is causality existence.  This can be accomplished by reading the arrow between two entities.  Read the arrow by asking “If (cause)… Then (effect).”  Train yourself to read the words EXACTLY as they are written.  Avoid the tendency to add words, or leave words out of the statements.  If you add or delete words then it is only a partial statement and needs to be changed to reflect what is really is.

Causality existence reservations can occur when the “If…Then” statement appears acceptable to one person but, not to another person.  In other words, one sees the connection, but the other person does not.  This situation does not mean that the “cause” is not legitimate (valid), it just means that the cause must be validated.  This condition seems even more pronounced when it is associated from the existence of a “cause” that might not be verifiable.  If such is the case, how do you verify the existence of a “cause?”  The most practical step is to verbalize another “effect” that can come from the ventured “cause.”  The verbalization of an additional effect that comes from the cause is sufficient to verify causality existence.  By being able to show the existence of, minimum two, directly verifiable effects that come from the same cause, then the cause is verified. In the example it could be argued by person (a verbalized reservation) that the cause of “Sales are going down” is not “Customer markets have changed”, but rather something else (the A example).

                              A                                                        B
By being able to verify the existence of another “effect” (minimum two) stemming from the cause, the cause is verified.  The effect could be verified by an increase in sales alternative products within the current company, or perhaps from an increase in sales from a competitor.  However, this data may prove much harder to get and verify.

The predicted effect existence is used most often to invalidate a cause.  This can be accomplished by surfacing any additional causes (minimum one) that must be present in order for the cause to exist.  In other words, if the cause really does exist then, “What else would you expect to see?”  If your predicated effect does not exist, and it should exist but, doesn’t then, the cause is not really the cause. As an example, let’s walk through the following scenario.
                           A                                                      B 

In our example it states that “If the battery is dead (cause)…Then the car won’t start (effect)”. The Predicted Effect Existence challenges the assumption that the battery is dead. “If the battery is dead…then nothing electrical on the car should work”.  What we have listed are several other “electrical” components that should also NOT WORK if the battery is really dead.  If, in fact, these other electrical components DO NOT work then, is it highly probable the car battery is dead.  However, if any of these electrical components DO work, and work well then, it is highly probable that a dead battery is not the reason the car won’t start. The Predicted Effect Existence can quickly validate, or invalidate, a perceived cause.  If the stated “cause” is invalidated it swiftly points to the need to find another “cause” to achieve the “effect” of why the car won’t start.
In our next posting we'll cover the remaining Categories of Legitimate Reservation (CLR) and then begin taking a closer look at our Thinking Process Tools..

No comments: