---
slug: current-reality-tree
type: pattern
summary: "A cause-and-effect map connecting a system's undesirable effects to the few core problems behind most of them; the Thinking Process tool for what to change."
created: 2026-05-21
updated: 2026-07-01
related:
  necessary-cause:
    relation: contrasts-with
    note: "The CRT is the canonical sufficiency-based diagnostic; the contrast with the necessity-based Evaporating Cloud is the cleanest place in the TP curriculum to teach the two-logic-types distinction."
  evaporating-cloud:
    relation: produces
    note: "A core problem identified in the CRT is verbalized as a conflict and resolved with an Evaporating Cloud; the CRT-then-EC sequence is the spine of the traditional Snowflake Method."
  future-reality-tree:
    relation: enables
    note: "The injection chosen against the CRT's core problem is tested in a Future Reality Tree, which verifies that the proposed change eliminates the UDEs without introducing new ones."
  prerequisite-tree:
    relation: enables
    note: "Once the injection is verified, the Prerequisite Tree maps the obstacles to implementing it; the CRT supplies the destination the PRT then plots a route to."
  transition-tree:
    relation: enables
    note: "The Transition Tree sequences the actions that close out the PRT's intermediate objectives; the chain CRT → EC → FRT → PRT → TT carries the diagnosis through to implementation."
  strategy-tactics-tree:
    relation: related
    note: "The S&T Tree is the organizational-scale partner to the CRT-led TP sequence; the CRT diagnoses what to change, the S&T Tree carries the change across management levels."
  categories-legitimate-reservations:
    relation: enforces
    note: "The CLR is the audit protocol every CRT arrow must pass; entity-existence and causality-existence reservations apply to every entity and arrow, and the sufficiency-side reservations (cause insufficiency, additional cause, cause-effect reversal, predicted-effect existence, tautology) apply because the CRT's arrows are sufficiency arrows."
  conditional-reality-tree:
    relation: refined-by
    note: "Youssef and Mabin's 2024 Conditional Reality Tree extends the CRT's binary logic to situations where the same cause produces different effects under different contextual conditions; the entry sits downstream of the CRT in the field's current state."
  inherent-simplicity:
    relation: depends-on
    note: "Goldratt's expectation that a small set of root causes explains the majority of a system's UDEs is the inherent-simplicity premise the CRT relies on; without that premise, the convergence the CRT looks for would not be available."
  five-focusing-steps:
    relation: complements
    note: "The CRT is the diagnostic tool of choice when the constraint is a policy or paradigm rather than a physical resource; it answers Step 1's identification question for cases the floor-walk cannot reach."
  policy-constraint:
    relation: detects
    note: "The CRT is particularly suited to surfacing policy constraints; the diagnostic move that lets a CRT converge on a written rule rather than a machine is the conversion the entry pays attention to."
  local-optimization:
    relation: detects
    note: "A well-built CRT often converges on a local-efficiency policy as the root cause of seemingly unrelated UDEs across functions; the diagnosis is one of the patterns the body of knowledge uses the CRT to find."
---

# Current Reality Tree (CRT)

[TOC Fundamentals (TOCFC)](learning-tracks.md#toc-fundamentals): [prev: Evaporating Cloud (Conflict Resolution Diagram)](evaporating-cloud.md) -> Current Reality Tree (CRT) -> [next: Core Problem](core-problem.md)

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

*A cause-and-effect map of an organization's undesirable effects that converges on the small set of core problems responsible for most of them; the TOC tool for answering "what to change?"*

*Also known as: CRT; current-reality diagram.*

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

The CRT turns a list of complaints into a diagnosis. A team can list a dozen things wrong with the business by lunchtime. If each complaint becomes its own project, the organization spreads effort across symptoms and leaves the system unchanged. The CRT tests a sharper claim: most visible undesirable effects may trace to one or two policies, measurements, or paradigms. If the claim holds, the practitioner has found what to change. If it does not, the diagram shows where the diagnosis is still thin.

## Context

The CRT belongs at the head of the Thinking Processes sequence because the downstream tools answer different questions. The CRT answers *what to change?* The [Evaporating Cloud](evaporating-cloud.md) asks *to what to change?* The [Future Reality Tree](future-reality-tree.md) tests whether the proposed change will work. The [Prerequisite Tree](prerequisite-tree.md) and [Transition Tree](transition-tree.md) plan how to cause it. The CRT establishes the target the rest of the sequence will work on.

The tool rests on [Inherent Simplicity](inherent-simplicity.md): the premise that a small number of root causes hold a complex system in its current state. It also rests on the [Necessary Cause](necessary-cause.md) distinction by staying firmly on the sufficiency side. A CRT arrow reads *if A, then B*, not *in order to A, we must have B*. Conflating those two readings is exactly the kind of construction error the [Categories of Legitimate Reservations](categories-legitimate-reservations.md) are meant to catch.

The CRT complements the [Five Focusing Steps](five-focusing-steps.md) when Step 1 cannot be answered by walking the floor. A physical bottleneck leaves inventory piles and idle downstream stations. A [policy constraint](policy-constraint.md) or paradigm constraint often leaves only symptoms: missed due dates, local fights, chronic expediting, or customers leaving. The CRT gives the practitioner a way to trace those symptoms back to the rule or belief that produces them.

## Problem

A working organization produces a steady stream of complaints: due dates missed, customers lost, employees quitting, departments fighting, projects stalled, errors recurring, costs rising. Each complaint is real. Each one suggests its own remedy. A team that treats them as independent runs many improvement projects, each defensible on its own, and still sees the complaints return next quarter.

The change that would dissolve most of the complaints is harder to see because the connections are not on any chart. The order-entry team sees one face of the problem. The planner sees another. Customer service sees a third. The situation needs a representation that lays the visible UDEs out together, traces them through cause and effect, and converges on the small set of policies or paradigms producing the pattern.

## Forces

- **Symptoms multiply faster than causes.** A complex system may produce many UDEs from a few root causes, but the practitioner first sees the UDEs.
- **Causal claims are easy to assert and hard to test.** "Engineering is slow because morale is low" may sound plausible. The CLR asks whether the arrow actually holds.
- **No single function owns the picture.** Order entry knows when orders are late; planning knows when materials are short; the floor knows when the constraint is starved.
- **A non-convergent diagnosis wastes the sequence after it.** A CRT that names six unrelated problems sends the [EC](evaporating-cloud.md), [FRT](future-reality-tree.md), [PRT](prerequisite-tree.md), and [TT](transition-tree.md) into six change paths.
- **The team must trust the tree.** A polished CRT presented after the fact rarely moves people. A rougher CRT the team helped build often does.

## Solution

Build a sufficiency-based logic diagram that connects the organization's undesirable effects (UDEs) to a small set of root causes, then test the convergence. A working CRT has one to three entities near the bottom that account for most UDEs at the top. Those entities are the **core problems**. They are the answer to *what to change?*

The diagram can be built bottom-up and read either way. Each arrow says: if the entity at the tail exists, then the entity at the head exists. Chained arrows trace from a policy or paradigm through intermediate effects to the visible UDEs. The deliverable is not the picture itself. It is the convergence that shows which root entity deserves the system's attention.

Two construction approaches are in standard use, both documented in the *TOC Handbook* and the *TOCICO Dictionary*. The **Snowflake Method** lists six to twelve UDEs, connects them to immediate causes, and grows the diagram until it converges. The final tree places UDEs across the top and one or two core problems at the bottom. Dettmer is the canonical exposition; the *TOC Handbook* Ch. 25, by Scheinkopf, gives the worked bank example.

The **Three-Cloud Method**, Goldratt's later approach, starts with three seemingly unrelated UDEs. The practitioner builds an [Evaporating Cloud](evaporating-cloud.md) for each, synthesizes them into a **core conflict cloud**, and uses that cloud as the base of the CRT. It is often faster to learn and run. Dettmer argues that it can converge prematurely; the *TOCICO Dictionary* records both positions.

Whichever route is used, every entity and arrow must pass the CLR. Level I asks whether each entity is clearly stated. Level II asks whether the entity exists and whether the causal claim is real. Level III applies the sufficiency reservations: cause insufficiency, additional cause, cause-effect reversal, predicted-effect existence, and tautology. A CRT whose arrows have not passed Level III has not earned its diagnostic claim.

## How It Plays Out

A multi-branch bank used a CRT in the late 1990s, the case Scheinkopf walks through in *TOC Handbook* Ch. 25. The branch manager, head cashier, and human-resources director listed nine UDEs: high teller turnover, vacancies filled by inexperienced hires, customer complaints, customer attrition, lost revenue, slow service, transaction errors, forgotten names, and a small hiring-and-training budget. The tree converged on one root entity: *the bank is unable to maintain an adequate pay structure to provide stable employment*. That entity traced back to an inherited budget rule and measurement system. The CRT did not produce the change; it produced the target the [Evaporating Cloud](evaporating-cloud.md) and [Future Reality Tree](future-reality-tree.md) then worked on.

A police department used a CRT against chronic 911 response-time trouble, one of the public-service applications surveyed in Kim and colleagues' 2008 literature review. The converging cause was not dispatch capacity, patrol-vehicle availability, or officer staffing. It was a policy requiring two-officer responses to a call category that volume data showed could safely be handled by one officer about three-quarters of the time. The CRT traced response-time, officer-shortage, citizen-complaint, and morale UDEs to the same two-officer rule. Replacing the rule with a volume-tiered dispatch policy resolved most of the visible problem set within a quarter.

A small worked CRT, read from the bottom up, shows the default sufficiency form. Each cause can independently produce a downstream effect, so no junctor is needed:

```mermaid
flowchart BT
    Core1[Local-efficiency measurement on every workstation] --> Mid1[Stations push work whether the constraint can absorb it or not]
    Core2[Release policy ignores constraint state] --> Mid1
    Mid1 --> Mid2[Inventory accumulates ahead of the constraint]
    Mid1 --> Mid3[Constraint frequently works on rush jobs out of sequence]
    Mid2 --> UDE1[Lead times have lengthened]
    Mid3 --> UDE2[Due-date performance has fallen]
    Mid3 --> UDE3[Expediting consumes a senior planner's day]
    Mid2 --> UDE4[Working capital is locked in WIP]
```

The four UDEs at the top look like four problems. The tree's claim is narrower: two policies at the bottom produce the visible pattern through the middle effects. In default sufficiency mode, either bottom policy can feed the push behavior. That is the ordinary CRT reading unless the diagram says otherwise.

A second, smaller CRT shows the override case. Here the modeler intends joint sufficient cause: neither policy alone is enough, and both must exist together before stations push work beyond what the constraint can absorb.

```mermaid
flowchart BT
    Core1b[Local-efficiency measurement on every workstation] --> AndPush2(("AND"))
    Core2b[Release policy ignores constraint state] --> AndPush2
    AndPush2 --> Mid1b[Stations push work whether the constraint can absorb it or not]

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

Together, the diagrams model the convention used across the Thinking Processes entries. Bare arrows in a sufficiency diagram mean *any one named cause may be enough*. An explicit AND-junctor means *the causes are required together*. The junctor is not decoration. It changes the claim the diagram is making.

> **⚠️ Warning:** A CRT whose convergence depends on an entity nobody on the team can change is not yet useful for that team. Dettmer's intermediate-objectives map and the three-cloud approach handle this differently. Dettmer reframes the analysis around the team's actual sphere; the three-cloud method accepts the convergence and escalates. Either response is better than pretending the team can change a constraint it cannot.

## Consequences

**Benefits.** The team leaves with a shared map and an agreed focus point. The convergence concentrates the rest of the TP work, and the implementation budget, on one or two policy targets instead of the whole symptom list. The diagram is also auditable: the CLR gives later reviewers a protocol for challenging any entity or arrow. Most important, the CRT can surface policy and paradigm constraints the floor-walk diagnostic of the [Five Focusing Steps](five-focusing-steps.md) cannot reach. The bank's pay structure and the police department's two-officer rule were constraint types no inventory pile-up would have revealed.

**Liabilities.** A CRT is expensive to build well. The literature's construction times range from a half-day for a small focused tree to multi-day sessions for an organization-wide CRT, and most teams underestimate the second-pass discipline the CLR demands. A biased UDE set can also force false convergence: every UDE chosen from one function, or by one person, will make the diagram look more certain than the system warrants. Dettmer's critique of the three-cloud approach belongs here too. The method can converge prematurely on a core conflict the Snowflake Method would have refined.

A CRT is also not a [Future Reality Tree](future-reality-tree.md). Confusing them leads teams to implement against the diagnosis without testing whether the proposed change eliminates the UDEs or creates new ones. Finally, the construction process is part of the deliverable. A logically perfect CRT that the team did not help build may fail where a rougher but jointly built tree succeeds.

## Sources

- Cox, *TOCICO Dictionary of Theory of Constraints Terms* (2nd ed., 2012), entries "current reality tree," "core problem," "core conflict," "undesirable effect," "sufficiency-based logic," "categories of legitimate reservation," "three-cloud approach." The certification-grade definitions every claim in the entry cross-checks against; the Dictionary records both the snowflake and three-cloud approaches and the field's reservations about each. Distributed through TOCICO membership; no Open Library record.
- 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 literature review that anchors the entry's claims about CRT use across functional domains, the prevalence of the tool relative to the EC, and the methodological developments since 2000 (the Communications CRT, the Generic Evaporating Cloud, the Current Reality Branch, the integration of System Dynamics diagrams). The same chapter names the CRT as the answer to *what to change?* in Goldratt's three-question change sequence.
- Cox and Schleier, [*Theory of Constraints Handbook*](https://openlibrary.org/works/OL18346923W) (2010), Ch. 25 (Scheinkopf, "Thinking Processes Including S&T Trees"). The canonical worked CRT in the contemporary literature, including the multi-branch bank example the "How It Plays Out" section draws on and the step-by-step snowflake and three-cloud construction protocols. Scheinkopf's framing — necessity-based logic answers *what do we need?* and sufficiency-based logic answers *what will happen?* — is the operational orienting question the field uses to choose between the CRT and the EC.
- Dettmer, [*Goldratt's Theory of Constraints: A Systems Approach to Continuous Improvement*](https://openlibrary.org/works/OL1827619W) (1997). The canonical CRT-construction exposition outside the Handbook; Dettmer's verbalization conventions ("if A then B" for sufficiency arrows, "in order to A we must have B" for necessity arrows) are the practitioner-level prose conventions most TP trainings inherit. Dettmer is also the principal advocate for the snowflake approach over the three-cloud method when the analysis is strategic rather than tactical.
- Scheinkopf, [*Thinking for a Change: Putting the TOC Thinking Processes to Use*](https://openlibrary.org/works/OL8923068W) (1999). The chapter-length CRT treatment whose construction protocol the *TOC Handbook* Ch. 25 condenses; the Communications CRT (CCRT) variant that strips the diagram down for managerial buy-in originates here.
- Goldratt, [*It's Not Luck*](https://openlibrary.org/works/OL2463053W) (1994). The narrative source for the snowflake-then-cloud-then-FRT-then-PRT-then-TT sequence as the operational form of the Thinking Processes. The Alex Rogo / UniCo divisions thread dramatizes a CRT-led diagnosis arriving at a policy-level core problem (the corporate measurement system rewarding the wrong divisional behavior) before the Evaporating Cloud and the Future Reality Tree are reached. The novel is the canonical onboarding artifact for the TP toolset.

---

- [Next: Core Problem](core-problem.md)
- [Previous: Goal Tree (IO Map)](goal-tree.md)