Evaporating Cloud (Conflict Resolution Diagram) §

Pattern: A named solution to a recurring problem.

A five-box necessity-logic diagram that turns an apparent conflict into testable assumptions, then finds the injection that lets both requirements be met without compromise.

Also known as: EC; Cloud; Conflict Cloud; Conflict Resolution Diagram (CRD).

Reasoning mode: necessity-based logic — arrows read in order to A, we must have B; multi-in-edge defaults to AND.

The Evaporating Cloud starts where ordinary problem solving stalls: two actions look mutually exclusive, and both sides can explain why their action is necessary. TOC treats that moment as a diagnostic signal, not a call to split the difference. If the system is internally consistent, the contradiction isn’t in reality. It is in an assumption under one of the arrows. Surface that assumption, test it, and the conflict can disappear rather than be negotiated down.

Context §

The Evaporating Cloud belongs in the Thinking Processes sequence immediately after the Current Reality Tree. The CRT answers what to change? by finding the core problem behind a set of undesirable effects. The EC answers the next question: to what to change? It translates the core problem into a conflict, exposes the assumptions that make the conflict appear unavoidable, and proposes the first injection the Future Reality Tree will test.

The tool uses Necessary Cause, not sufficiency logic. Its arrows read in order to A, we must have B. They do not read if B, then A. That distinction is not cosmetic. A cloud works by challenging the assumption under a necessary-condition arrow. If the practitioner reads the cloud as a cause-and-effect tree, the assumption layer disappears and the diagram collapses into a compromise chart.

The EC has two standard placements in the larger method. In the Snowflake Method, a CRT first converges on a core problem, and the cloud then verbalizes that problem as a conflict. In the Three-Cloud Method, the practitioner builds clouds for three diverse undesirable effects, generalizes them into a core conflict cloud, and then uses that generic cloud as the base for the CRT. The field uses both. Dettmer is more cautious about the Three-Cloud shortcut; Scheinkopf and the TOC Handbook treat it as a useful, teachable route when the UDEs are chosen carefully.

Problem §

Most organizational conflicts are argued at the level of actions. The plant manager wants to keep green orders on their assigned routings. The flow-improvement team wants to move them to any equivalent resource with capacity. The branch manager wants to raise entry-level teller pay. The budget rule says the hiring, training, and salary pool cannot grow. Each action has a reason. Each reason appears tied to a real requirement. The conflict persists because the parties keep defending the action instead of testing the assumption that made the action look necessary.

Compromise rarely fixes that structure. It gives each side less than it says it needs, leaves the assumption intact, and lets the conflict return in a new form. Domination is worse: one side wins the action while the other requirement remains unmet, so the system pays later through delay, turnover, poor service, expediting, or political resistance. The practitioner needs a way to preserve both legitimate requirements while attacking the false necessity that made the two actions appear incompatible.

Forces §

Solution §

Build the five-box cloud and read it as necessity logic. Box A is the shared objective. Boxes B and C are the two requirements that must both be met for A. Boxes D and D-prime are the two prerequisites, wants, actions, or policies that appear necessary for B and C but cannot coexist.

The first discipline is wording. D and D-prime must be mutually exclusive as written. B and C must be real requirements, not disguised versions of D and D-prime. A must be a shared objective both sides would accept. A weak cloud usually fails here: the practitioner has written two positions, not two requirements tied to a common objective.

The second discipline is verbalization. Read every arrow aloud:

The word after because is the working surface of the cloud. It is the assumption under the arrow. Some assumptions are valid facts of the system; others are obsolete policies, measurement habits, authority limits, or inherited beliefs. The cloud evaporates when the practitioner finds an assumption that is false, too broad, no longer necessary, or replaceable by a new condition.

The third discipline is injection design. An injection is a state, condition, or action that invalidates one or more assumptions while preserving both requirements. A good injection lets the practitioner say one of five things: A can be achieved without B, A can be achieved without C, B can be achieved without D, C can be achieved without D-prime, or D and D-prime can coexist after all. Most working injections attack the B-D or C-D-prime arrows, because those are where local policy and operating habit most often masquerade as necessity.

The five-box shape is small enough to draw in a meeting, but it is strict enough that weak conflicts show themselves quickly. The convergence at A reads as the necessity default — every named upstream condition is required — without an explicit junctor:

flowchart LR
    D["D: Take action one"] --> B["B: Meet requirement one"]
    D2["D-prime: Take action two"] --> C["C: Meet requirement two"]
    B --> A["A: Achieve the shared objective"]
    C --> A
    D -. "cannot coexist with" .- D2

The cloud’s rare override case is the OR-junctor, used when the diagram models alternative ways to satisfy a single need — when the practitioner has two competing prerequisites either of which would meet the same requirement. A small companion cloud shows the construct in isolation: a B requirement that could be satisfied by either of two alternative D-prerequisites converges through an OR-junctor:

flowchart LR
    Dx["D: Take action one"] --> OrAlt(("OR"))
    Dxp["D-prime-alt: Take a second action that also satisfies B"] --> OrAlt
    OrAlt --> Bx["B: Meet requirement one"]

    classDef orjunctor fill:#A6894B,stroke:#3a2f1a,color:#fff,stroke-width:1.5px;
    class OrAlt orjunctor;

The first diagram is the cloud in its standard form — the default-AND reading at A says both B and C are required, no junctor needed. The second diagram isolates the OR-junctor that appears only when the practitioner is modeling alternative satisfiers under one of the necessity arrows. The two together model the convention: bare arrows where the necessity default says every named upstream condition is required, an explicit OR-junctor where the modeler intends any one of the named upstream conditions is enough on its own. The OR-junctor is the rare construct in necessity diagrams — most working clouds do not need it — but the construct is part of the field’s vocabulary and appears in the practitioner literature when a cloud’s resolution involves substituting one prerequisite for another.

Run the Categories of Legitimate Reservations at the level they fit. Clarity and entity existence apply to every box. The full sufficiency-side CLR does not apply cleanly to the cloud’s necessity arrows; those arrows are tested by surfacing and challenging their assumptions. Once an injection is chosen, move the work into the Future Reality Tree and Negative Branch Reservation process. The cloud finds the opening. It doesn’t prove the whole future state.

How It Plays Out §

Scheinkopf’s TOC Handbook chapter gives a production example from a heavy-steel make-to-order operation. Orders were waiting for heat treat, but the sharper diagnosis was that green orders were waiting for the specific quench tank named in their routing even when equivalent tanks were idle at nearby plants. The conflict was not “use the routing” versus “break the routing” in the abstract. One side needed to process orders according to routings so cost and quality would be protected. The other needed to maximize flow so orders would not age into expediting later. The invalid assumption was that the named tank in the routing was the only capable, cost-effective resource. Once the team found that assumption false, the injection was straightforward: if the routed resource was busy and an equivalent resource was available, move the order to the equivalent resource regardless of its buffer color, then update routings over time so equivalent resources were no longer exceptions.

The bank case in the same chapter shows the cloud after a CRT has already converged. The CRT surfaced a pay-structure problem behind teller turnover, customer complaints, and poor service. The cloud framed the conflict around staying within the compensation budget while creating stable employment and better service. The assumption that made the conflict look locked was that the total hiring, training, and salary pool could not grow. Nobody at the bank could increase that pool, but the branch manager could shift money inside it. The injection moved money from hiring and initial training into entry-level pay. The mechanism was not a moral appeal to “value employees.” It was a structural move: reduce turnover, reduce the hiring-and-training load that turnover creates, and use the recovered money to hold the pay structure in place.

The generic cost-world versus throughput-world conflict works the same way. A cost-world manager wants every resource busy to protect local efficiency. A throughput-world practitioner wants non-constraints subordinated to the system constraint, even when that leaves visible idle time. The shared objective is better system performance. The two requirements are cost control and throughput protection. The false assumption is that local resource efficiency is the route to global cost control in a constrained system. Once that assumption is exposed, the injection is not “accept inefficiency.” It is a measurement change: protect cost through T, I, and OE at the system level, while allowing protective capacity at non-constraints. That is why the cloud sits close to Cost-World vs. Throughput-World Thinking, Subordination, and Throughput Accounting.

Consequences §

Benefits. The cloud preserves both sides’ legitimate requirements before it challenges either side’s action, so the conversation moves from advocacy to diagnosis. It gives the practitioner a compact way to expose the policy, measurement, or belief holding a policy constraint in place. It also produces an injection in a form the rest of the Thinking Processes can use: the FRT can test it, the PRT can map its obstacles, and the Transition Tree can sequence the actions. In routine use, the cloud is the TP tool managers can carry into day-to-day conflict without building a full CRT first.

Liabilities. A cloud is easy to draw badly. If B and C are not true requirements, the diagram becomes a dressed-up negotiation. If A is not genuinely shared, the conflict may be a values dispute rather than a TOC cloud; Mycue and Schragenheim’s government work names this risk when democratic stakeholders do not agree on the public-value objective. If the practitioner stops at the first plausible injection, the cloud can create a clever idea whose negative branches have not been tested. And if the organization treats the injection as a compromise, not as an assumption-breaking move, the old assumption quietly reinstalls itself after the meeting.

Related Articles §

Sources §