Future Reality Tree (FRT) §

Pattern: A named solution to a recurring problem.

A sufficiency-logic map that tests whether a proposed injection will replace today’s undesirable effects with desirable effects, without creating worse side effects.

Also known as: FRT; future-reality branch when the scope is narrow.

Reasoning mode: sufficiency-based logic. Arrows read if A, then B; multi-in-edge defaults to OR.

The Future Reality Tree turns a promising TOC solution into a testable hypothesis. An Evaporating Cloud may produce an injection that appears to dissolve a conflict, but the FRT asks what that injection will cause in the system. It traces the expected effects until most original undesirable effects have desirable replacements and any new negative branches have been trimmed.

Understand This First §

Context §

The FRT sits in the middle of the Thinking Processes sequence. The Current Reality Tree answers what to change? by showing how the current system produces its undesirable effects. The Evaporating Cloud begins to what to change? by surfacing an assumption and proposing an injection. The FRT completes that answer by testing whether the injection is sufficient to create the desired future.

The tool uses sufficiency logic. Its arrows read if A, then B. That puts the FRT on the same logic side as the CRT and the Transition Tree, and on the opposite side from the necessity-based Cloud and Prerequisite Tree. The distinction matters because the FRT is not asking whether an entity is necessary for an objective. It is asking whether an injection, combined with existing facts and supporting injections, is enough to cause the desired effects.

An FRT normally follows a CRT and Cloud, but it can test any consequential decision before implementation. Scheinkopf treats it as a general tool for predicting an idea’s web of consequences. The TOCICO Dictionary gives the certification-grade formulation: an FRT links proposed injections to desirable effects and identifies new UDEs the injections may create. The Negative Branch Reservation process then prevents those UDEs before launch.

Problem §

A team can leave a Cloud session with a solution that feels right. The conflict has been reframed, a false assumption named, and an injection proposed. The temptation is to treat that plausible injection as verified.

The injection may remove the original conflict yet fail the system. It can solve one undesirable effect while leaving others untouched, create a side effect that later erodes the benefit, or depend on conditions nobody has stated. The organization needs to model the future state before committing money, attention, and implementation capacity.

Forces §

Solution §

Build a sufficiency-based tree from one or more injections to the desirable effects that should replace the CRT’s UDEs. State each injection as an entity to be introduced and each desirable effect in present tense, as if the future state already exists. Connect injections, current facts, supporting assumptions, and intermediate effects with if-then arrows.

The original construction method starts with an injection and builds upward. A later method rotates an Evaporating Cloud 90 degrees clockwise, then uses its assumptions and injections as the tree’s base. Either method follows four moves.

First, list the intended benefits. When the FRT follows a CRT, these are often the opposites of selected UDEs. “Customers complain about late orders” becomes “Customers receive orders when promised.” “Teller turnover is high” becomes “Teller turnover is stable enough to protect service quality.” A desirable effect is an observable future entity, not a slogan.

Second, connect the injection to the desirable effects through sufficiency logic. Each arrow must read cleanly as an if-then claim. If the injection is insufficient by itself, add the missing current fact or supporting injection. The tree then shows the full set of conditions behind the solution.

Third, run the Categories of Legitimate Reservations. Clarity, entity existence, causality existence, cause insufficiency, additional cause, cause-effect reversal, predicted effect, and tautology all apply to the FRT’s sufficiency arrows. The most common reservation is cause insufficiency: “This injection doesn’t cause that desirable effect unless something else also changes.” A secondary injection or current-reality entity usually repairs the gap.

Fourth, identify and trim negative branches. A negative branch is a predicted undesirable effect caused by the injection or a supporting change. The Negative Branch Reservation process traces where the branch turns negative, then adds or modifies an injection to prevent the bad effect. If a major branch cannot be trimmed, reconsider the primary injection.

A small FRT has this shape. In the bank case, fewer service errors and shorter wait times are jointly required for customer retention. Neither is enough alone, so their convergence uses an AND-junctor instead of the sufficiency default. Every other node has one incoming edge.

flowchart BT
    I1["Injection: Entry pay is raised using hiring-and-training savings"] --> M1["New hires stay long enough to become proficient"]
    F1["Existing turnover cost is recovered"] --> I1
    M1 --> DE1["Service errors fall"]
    M1 --> DE2["Customer wait time falls"]
    DE1 --> AndGoal(("AND"))
    DE2 --> AndGoal
    AndGoal --> Goal["Customer retention improves"]
    I1 --> NB1["Potential negative branch: budget pressure shifts to other branches"]
    T1["Trimming injection: pay change is paired with turnover-cost reporting"] --> NB2["Budget pressure is reviewed against recovered cost"]

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

The example compresses Scheinkopf’s bank case. The injection is specific: use money consumed by turnover, hiring, and initial training to raise entry pay. The desirable effects are service stability and customer retention. Budget pressure elsewhere is the possible negative branch. Turnover-cost reporting is the trimming injection that keeps the pay change tied to recovered cost. The AND-junctor makes the dependency explicit: fewer errors won’t retain customers if waits stay long, and shorter waits won’t retain them if errors remain high.

A second, smaller FRT isolates that joint sufficient cause: two desirable effects converge through an AND-junctor onto customer retention.

flowchart BT
    DEa["Desired effect: service errors fall"] --> AndGoal2(("AND"))
    DEb["Desired effect: customer wait time falls"] --> AndGoal2
    AndGoal2 --> Goalb["Customer retention improves"]

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

The diagrams show the convention. Bare arrows mean either cause is sufficient; an explicit AND-junctor means both effects must exist together.

How It Plays Out §

In Scheinkopf’s bank case, the CRT traced teller turnover, customer complaints, service errors, and attrition to a pay-structure policy. The Cloud framed the conflict: the bank needed stable entry-level employment to protect service while staying inside a fixed compensation budget. The injection shifted money from hiring and initial training into entry pay and retention.

The FRT tested whether that injection could replace the UDEs. Higher entry pay reduces turnover. Lower turnover cuts hiring and basic-training load. Experienced employees then spend more time serving customers and coaching new tellers who stay. Errors, slow service, and forgotten customer names fall. The tree shows both why the injection should close the visible symptoms and where it needs support.

In production or project work, the same tool tests solutions that may create second-order failures. A DBR team might move green-buffer orders to an equivalent resource when the routed resource is busy. Flow improves, but frequent moves can weaken quality records, cost traceability, and routing discipline. A routing-update rule, capability matrix, or daily review of off-routing moves can trim that branch. Without the FRT/NBR pass, the team may improve flow while damaging control.

A software organization using TOC on release flow faces the same problem. The injection might let teams bypass a weekly release board for low-risk changes. The desirable effects are shorter cycle time, fewer stale approvals, and more capacity for high-risk review. The negative branch includes drifting risk labels, uneven release quality, and hidden security exceptions. The FRT requires the conditions that make the bypass safe: a clear risk taxonomy, automated regression checks, exception logging, and periodic audits. Without them, the injection is not ready.

Consequences §

Benefits. The FRT gives a proposed solution a causal spine. It connects injections to desirable effects, exposes the secondary injections they need, and gives skeptics a disciplined place to raise reservations before implementation. It also keeps the change sequence honest: a CRT diagnosis is not a solution, and a Cloud injection is not proof.

Liabilities. A full FRT takes patience after a productive Cloud session. If every local decision requires a multi-page tree, people will stop using it. Scope should follow consequence: use a full tree for a strategic, cross-functional, expensive, or politically risky injection; use a future-reality branch for a narrow question. A tidy FRT can still be wrong when its starting UDEs are thin, its desirable effects are aspirations rather than observable entities, or only supporters raise the negative branches.

The FRT stops before implementation planning. It identifies injections and tests the future state; it doesn’t sequence obstacles, assign owners, or produce an action plan. That work belongs to the Prerequisite Tree, Transition Tree, and, at organizational scale, the Strategy and Tactics Tree. Treating an FRT as a project plan skips the obstacles the next tool is meant to expose.

Related Articles §

Sources §