---
slug: transition-tree
type: pattern
summary: "A sufficiency-logic action map that sequences the steps from the present condition to a chosen objective, with the need, condition, and rationale for each step visible."
created: 2026-05-21
updated: 2026-05-22
related:
  prerequisite-tree:
    relation: depends-on
    note: "The PRT supplies the intermediate objectives and obstacles that the Transition Tree turns into action-level steps."
  future-reality-tree:
    relation: downstream-of
    note: "The FRT tests the injection and desired future before the Transition Tree plans the detailed action path."
  sufficient-cause:
    relation: depends-on
    note: "The Transition Tree is a sufficiency-logic tool: every action-plus-condition cluster has to be enough to create the next stated reality."
  categories-legitimate-reservations:
    relation: tested-by
    note: "The CLR tests whether each action, need, condition, and working assumption can carry the causal load the tree assigns to it."
  six-layers-resistance:
    relation: implements
    note: "The Transition Tree addresses the implementation-detail layer by making the why behind each step visible before action begins."
  strategy-tactics-tree:
    relation: complements
    note: "The S&T Tree often absorbs Transition Tree logic when implementation has to be synchronized across levels and functions."
  critical-chain:
    relation: complements
    note: "Critical Chain can schedule and protect project work after the Transition Tree has clarified which actions should happen and why."
---

# Transition Tree (TT)

[TOC Fundamentals (TOCFC)](learning-tracks.md#toc-fundamentals): [prev: Prerequisite Tree (PRT)](prerequisite-tree.md) -> Transition Tree (TT) -> [next: Categories of Legitimate Reservations (CLR)](categories-legitimate-reservations.md)
[Thinking Processes (TP Practitioner)](learning-tracks.md#thinking-processes): [prev: Intermediate Objective (IO)](intermediate-objective.md) -> Transition Tree (TT) -> [next: Strategy and Tactics Tree (S&T Tree)](strategy-tactics-tree.md)

> **Pattern:** A named solution to a recurring problem.

*A sufficiency-logic action map that sequences the exact steps needed to move from the present condition to a chosen objective, with the need, condition, and rationale for each step visible.*

*Also known as: TT; TRT; transition map.*

**Reasoning mode:** [sufficiency-based logic](sufficient-cause.md) — arrows read *if A, then B*; multi-in-edge defaults to OR.

A [Prerequisite Tree](prerequisite-tree.md) can tell the team which intermediate objectives must exist before an injection can be implemented. It still doesn't tell anyone what to do next. The Transition Tree starts when the question becomes practical: what action comes first, what condition makes that action appropriate, what need does it satisfy, and what new reality should exist after the action is taken?

## Understand This First

- [Prerequisite Tree](prerequisite-tree.md) — the obstacle-and-intermediate-objective map the TT usually expands.
- [Sufficient Cause](sufficient-cause.md) — the if-then logic used by every action step.
- [Categories of Legitimate Reservations](categories-legitimate-reservations.md) — the scrutiny protocol for action, condition, and rationale claims.

## Context

The Transition Tree sits at the end of the classical Thinking Processes sequence. The [Current Reality Tree](current-reality-tree.md) answers *what to change?* The [Evaporating Cloud](evaporating-cloud.md) and [Future Reality Tree](future-reality-tree.md) answer *to what to change?* The PRT begins *how to cause the change?* by identifying obstacles and intermediate objectives. The TT carries that answer down to action.

The tool uses sufficiency logic. Its arrows read *if these conditions and this action exist, then this next reality should exist*. That places it on the same logic side as the CRT and FRT, and on the opposite side from the necessity-based Cloud and PRT. The PRT says a condition is required. The TT says this action, taken under these conditions for this need, is enough to create the next condition.

Scheinkopf's Handbook chapter treats the TT as the tool for action sequences that need deliberate choreography: buy-in meetings, sales meetings, supplier negotiations, policy-change launches, and other moments where a generic project plan leaves too much unsaid. The TOCICO Dictionary makes the same boundary explicit. A TT is not merely a schedule. It is a step-by-step implementation plan with the rationale for each step on the page.

## Problem

Implementation plans often answer *who* and *when* while leaving *why* implicit. A task list says "train supervisors," "change release rule," "hold customer meeting," or "update the measure." It may even assign dates and owners. But it usually doesn't show why that action is needed now, what condition has to be present before it is safe, what new condition the action should create, or what to do if reality doesn't match the plan.

That missing logic matters because implementation rarely follows the exact script. Conditions change. A buyer raises a different objection. A manager discovers that the required data isn't available. A policy owner agrees with the solution but rejects the first action. When the rationale is hidden, people either follow the old plan blindly or improvise without a shared logic. The TT gives them a map they can test while acting.

## Forces

- **The PRT stops at conditions.** Intermediate objectives are states to achieve, not the actions that create them.
- **The obvious first action may be premature.** A step that is useful later can be harmful before the necessary condition exists.
- **Sequence is causal, not clerical.** The reason one action comes before another is that it creates the condition that makes the next action appropriate.
- **People need the why when reality changes.** A detailed instruction without its rationale breaks as soon as the situation differs from the plan.
- **Action can create negative branches.** A step can be logically sufficient for the next condition and still cause a side effect that has to be prevented.

## Solution

Build a TT from the objective backward into the actions required to make it real. The objective may be an injection from an FRT, an intermediate objective from a PRT, or another clearly stated implementation target. Write the objective as an entity: the desired condition exists. Then draft the action spine from the current condition toward that objective.

For each action, state four things. First, name the need for the action: what is missing or blocked that makes action necessary? Second, state the appropriate condition for taking the action: the team has the ability to act, and the action will not create serious negative effects. Third, name the action itself. Fourth, state the working assumption that explains why this action satisfies the need and creates the next condition.

The basic action logic looks like this. The current diagram is a linear single-in-edge chain, so the sufficiency default (multi-in-edge = OR) is vacuously satisfied — the question of joint sufficiency does not arise at any node:

```mermaid
flowchart BT
    S0["Present condition"] --> N1["Need for first action is clear"]
    N1 --> A1["Action 1 is taken"]
    A1 --> S1["Condition for action 2 exists"]
    S1 --> N2["Need for next action is clear"]
    N2 --> A2["Action 2 is taken"]
    A2 --> Goal["Objective exists"]
    W1["Working assumption explains why action 1 creates the next condition"] -. "scrutinizes" .- A1
    W2["Working assumption explains why action 2 completes the objective"] -. "scrutinizes" .- A2
```

The classical Transition Tree teaching, going back to Goldratt's original TP lectures, pairs *Need* and *Action* as jointly required to produce the next *Condition*: the action is sufficient only when the need that warrants it is present. The linear diagram above is a simplification that hides the joint structure inside the sequence. A small companion diagram makes the joint structure explicit using an AND-junctor, with one Working-Assumption dashed scrutiny edge attached so the rationale is visible:

```mermaid
flowchart BT
    NeedA["Need: customer's reliability gap is acknowledged"] --> AndCond(("AND"))
    ActA["Action: present the reliability offer against the acknowledged gap"] --> AndCond
    AndCond --> NextC["Next condition: customer evaluates the offer against named criteria"]
    Wa["Working assumption: an offer landed without the need is heard as another supplier claim"] -. "scrutinizes" .- ActA

    classDef andjunctor fill:#A6894B,stroke:#3a2f1a,color:#fff,stroke-width:1.5px;
    class AndCond andjunctor;
```

The first diagram is the article's primary illustration — the action spine in the form practitioners most often draw it, with the joint structure absorbed into the sequence. The second diagram isolates the Need+Action AND-junctor that the field's classical TT lectures use to show the joint structure explicitly: action without the recognized need produces a different next condition (often hostility or confusion) than the same action taken when the need is acknowledged. The two together model the convention: bare arrows where the chain is genuinely linear and each link's sufficiency is captured by the working assumption, an explicit AND-junctor where the modeler wants to show that the action's effect depends jointly on the need being present.

Run the [Categories of Legitimate Reservations](categories-legitimate-reservations.md) on each cluster. Clarity and entity existence apply to the need, condition, action, and working assumption. Causality existence, cause insufficiency, additional cause, cause-effect reversal, and predicted-effect checks apply to the if-then links. If the action is not enough, add the missing condition or change the action. If the action creates a negative branch, modify it or add a prior action that prevents the branch.

If no action comes to mind, the tree is telling you something useful. The PRT stopped too high. Go back and break the obstacle into smaller intermediate objectives until the team reaches a condition where the first action is obvious enough to test.

## How It Plays Out

Scheinkopf's main Handbook example puts the TT inside a market-constraint setting. A company with a decisive competitive edge in due-date reliability has to change its sales meeting. If the salesperson opens by presenting the offer, the buyer hears another supplier claim and starts searching for the catch. The TT sequences a different meeting. First establish the damage created by unreliable suppliers. Then agree on the criteria any real solution must meet. Then present the reliability offer as the answer to those criteria.

The point isn't scripting patter. The point is causal order. The buyer has to recognize the damage before the criteria matter. The criteria have to exist before the offer can be seen as the natural solution. Each action creates the condition that makes the next action appropriate. If the buyer doesn't agree that the damage exists, the salesperson doesn't race ahead to the offer; the need for the next action is not present yet.

A DBR implementation shows the same structure in operations. Suppose the PRT says "release authority is tied to buffer status" is an intermediate objective. The TT may start with the present condition that planners release jobs by work-order date. The first action gathers a clean list of jobs whose release would change under the buffer rule. The next condition is that planners can see the difference between old and new release decisions. The next action runs a one-week shadow release board. Only after supervisors and planners have seen the exception pattern does the final action move release authority to the buffer rule.

Without the TT, the implementation plan might simply say "switch release rule on Monday." That may be brave, but it isn't a TOC implementation plan. The TT exposes why each action is needed, what it should create, and where the team should stop if the conditions are not yet safe.

## Consequences

**Benefits.** The TT turns implementation from a task list into a causal experiment. It shows why each action belongs in the sequence, what condition should appear after the action, and how the team will know when the next action is warranted. That makes delegation cleaner: people don't just receive tasks; they receive the logic that lets them adapt.

It also makes buy-in work more concrete. The six layers of resistance distinguish agreement on the solution from agreement on implementation details. The TT works at that detail layer. It gives affected managers, salespeople, planners, or operators a way to challenge the plan before execution rather than after the first surprise.

**Liabilities.** A TT is overkill for simple actions. If the next step is obvious, low-risk, and reversible, a checklist may be enough. Use a TT when the action sequence is risky, politically exposed, dependent on buyer or manager response, or likely to be reused as a training artifact.

The second liability is false precision. A diagram can look exact while its assumptions remain weak. The working assumption beside each action has to be stated plainly enough for another practitioner to challenge. If the tree hides weak assumptions under tidy boxes, it gives the action plan more authority than it has earned.

The third liability is scale confusion. For a bounded action sequence, the TT is useful. For a whole-company change, the [Strategy and Tactics Tree](strategy-tactics-tree.md) often becomes the better communication artifact. Scheinkopf notes that S&T work can absorb PRT and TT elements without requiring complete standalone trees. The discipline remains the same: actions need reasons, conditions, and predicted effects.

## Sources

- Cox, *TOCICO Dictionary of Theory of Constraints Terms* (2nd ed., 2012), entries "transition tree," "sufficiency-based logic," "logical and connector," "intermediate objective," "how to cause the change," and "thinking processes." The certification-grade vocabulary for the TT's purpose, structure, two construction approaches, and relationship to the PRT.
- Cox and Schleier, [*Theory of Constraints Handbook*](https://openlibrary.org/works/OL18346923W) (2010), Ch. 23 (Mabin and Davies, "The TOC Thinking Processes: Their Nature and Use"). The chapter places the TT in the full Thinking Processes sequence, identifies it as a sufficiency-based implementation tool, and explains its role in collective buy-in.
- Cox and Schleier, [*Theory of Constraints Handbook*](https://openlibrary.org/works/OL18346923W) (2010), Ch. 25 (Scheinkopf, "Thinking Processes Including S&T Trees"). The working construction source for this entry: action spine, need entity, appropriate-condition check, working assumption, negative-branch review, and the reliability-selling TT example.
- Scheinkopf, [*Thinking for a Change: Putting the TOC Thinking Processes to Use*](https://openlibrary.org/works/OL8923068W) (1999). The book-length Thinking Processes curriculum behind the Handbook treatment; useful for the earlier TT format and the distinction between action-level sufficiency and prerequisite necessity.
- Goldratt, [*It's Not Luck*](https://openlibrary.org/works/OL2463053W) (1994). The narrative source for the CRT-to-Cloud-to-FRT-to-PRT-to-TT implementation sequence as practiced by Alex Rogo and the UniCo division teams.

---

- [Next: Strategy and Tactics Tree (S&T Tree)](strategy-tactics-tree.md)
- [Previous: Prerequisite Tree (PRT)](prerequisite-tree.md)