--- slug: core-problem type: concept summary: "The convergence point in current reality that accounts for the most significant UDEs: the target a Current Reality Tree identifies before the rest of the Thinking Processes design a change." created: 2026-06-07 updated: 2026-06-07 related: current-reality-tree: relation: produced-by note: "A Current Reality Tree identifies the core problem by tracing current UDEs through sufficiency logic until the causes converge on one to three governing entities." undesirable-effect: relation: produces note: "A core problem is defined by the UDEs it causes; UDEs are the visible symptoms, while the core problem is the deeper current-reality entity the tree finds." inherent-simplicity: relation: depends-on note: "The search for a core problem rests on Inherent Simplicity: many visible effects usually trace to a small number of governing causes." evaporating-cloud: relation: used-by note: "In the Snowflake Method, the core problem identified by the CRT is verbalized as a conflict and worked through an Evaporating Cloud." future-reality-tree: relation: informs note: "The Future Reality Tree tests whether an injection aimed at the core problem will replace the original UDEs with desirable effects." categories-legitimate-reservations: relation: tested-by note: "The Categories of Legitimate Reservations test whether the tree's convergence on a core problem is logically defensible rather than merely plausible." assumption: relation: related note: "A core problem may be an erroneous assumption that holds a policy, measurement, conflict, or behavior pattern in place." policy-constraint: relation: related note: "Many TOC case diagnoses converge on a policy, measurement, or paradigm constraint as the core problem behind the visible UDEs." --- # Core Problem [TOC Fundamentals (TOCFC)](learning-tracks.md#toc-fundamentals): [prev: Current Reality Tree (CRT)](current-reality-tree.md) -> Core Problem -> [next: Injection](injection.md) [Thinking Processes (TP Practitioner)](learning-tracks.md#thinking-processes): [prev: Goal Tree (IO Map)](goal-tree.md) -> Core Problem -> [next: Conditional Reality Tree](conditional-reality-tree.md) > **Concept:** Vocabulary that names a phenomenon. *The selected part of current reality that accounts for the most significant undesirable effects in the system being studied.* *Also known as: core driver when the emphasis is on the deeper causal source; core conflict when the problem is expressed as an Evaporating Cloud.* The core problem is what a Thinking Process diagnosis is trying to find. A plant, hospital, bank, project office, or software organization can list many things that are going wrong. TOC asks whether those visible problems are mostly effects of one to three causes deeper in the system. The core problem is that deeper cause, chosen because changing it would remove most of the important undesirable effects rather than treating the symptoms one at a time. ## Context The concept sits between the [Undesirable Effect](undesirable-effect.md) and the [Current Reality Tree](current-reality-tree.md). UDEs are the symptoms the practitioner can see. The CRT is the sufficiency-logic diagram that traces those symptoms downward through cause and effect. The core problem is the convergence point the CRT is trying to expose. The term matters because it keeps the first Thinking Process question honest. *What to change?* does not mean "which complaint is loudest?" or "which resource is easiest to fix?" It means: which entity in current reality is responsible for enough of the important UDEs that changing it gives the rest of the toolset a focused target? The core problem is then handed forward. In the Snowflake Method, the practitioner verbalizes it as a conflict through the [Evaporating Cloud](evaporating-cloud.md). The injection chosen against that conflict is tested in a [Future Reality Tree](future-reality-tree.md), then sequenced through the Prerequisite Tree and Transition Tree. A weak core-problem statement therefore contaminates the whole sequence. The later tools can be logically tidy and still solve the wrong thing. ## What It Is A core problem is a current-reality entity that directly causes most of the significant UDEs in the system under study. The *TOCICO Dictionary* gives the working rule as one to three core problems accounting for more than 70 percent of the UDEs, but the same entry warns that the number is a guideline. Not all UDEs are equally important, and the UDE list never captures the whole system. The test is not arithmetic alone. It is whether the entity explains the effects that matter enough to justify the change effort. The concept has several legitimate forms. A core problem can be a **fact or condition in current reality**: a local-efficiency measure is used as the prime operations measure, a release rule ignores constraint state, or a pay structure cannot hold experienced tellers. In this form the core problem appears as an entity near the base of a CRT. It can be a **conflict**: the D and D-prime opposition in a core conflict cloud, such as "use local efficiencies as a prime measure" versus "do not use local efficiencies as a prime measure." In the Three-Cloud Method, three specific clouds are generalized into a core conflict that becomes the base of the CRT. It can be an **erroneous assumption**: the belief that an idle resource is always waste, that every department must be locally efficient, or that a budget pool cannot be changed even when turnover consumes it. The assumption often sits below the visible policy and explains why the policy persists. The Dictionary also describes four connected levels: erroneous assumptions produce policies; policies install measurements; measurements produce behaviors. A core problem can be stated at any of those levels, but the level chosen changes what the organization can actually do next. A team with authority over a measurement may not have authority over the executive assumption beneath it. A practitioner who names the assumption but cannot change it may need an intermediate objective before the solution can move. ## How It Is Measured or Recognized A core problem is recognized by convergence under scrutiny. The first sign is ancestry: the candidate entity is a cause-and-effect ancestor of most of the important UDEs at the top of the CRT. If removing that entity in the team's imagination does not remove the UDEs, it isn't the core problem, no matter how central it looks. The second sign is importance. A candidate that explains 70 percent of trivial UDEs and none of the serious ones is not the right focus. Dettmer's Goal Tree work is blunt about this failure: old-style UDE collection could produce huge trees and broad core-problem statements that felt impressive but weren't actionable. The revised discipline asks whether the UDEs are tied to the goal and critical success factors, not merely whether many complaints can be connected. The third sign is changeability. The Dictionary allows the person conducting the study to choose among possible core drivers based on authority and stamina. That is not a license to pick a convenient cause. It is a recognition that two causes can both explain the UDEs, while only one sits within the decision-maker's sphere. A core problem the team cannot influence may be true and still not be the right working target for this team. The fourth sign is auditability. The [Categories of Legitimate Reservations](categories-legitimate-reservations.md) must survive the convergence claim. Each entity has to exist; each arrow has to hold; cause-insufficiency and additional-cause reservations have to be answered. A core problem selected before the Level II and Level III reservations are closed is a hunch drawn in a box. > **⚠️ Warning:** Do not treat "root cause" and "core problem" as synonyms. A root cause is any lowest-level cause in a reality branch. It becomes a core problem only when it accounts for the majority of the significant UDEs and is selected as the focus for change. A CRT can have several root causes and still only one working core problem, or it can require several critical root causes because forcing one grand cause would be dishonest. ## Why It Matters The core problem gives the Thinking Processes their focusing power. Without it, the organization is left with a list of UDEs and a dozen improvement projects. With it, the practitioner can ask whether one policy, one measurement frame, one assumption, or one conflict is producing enough of the damage that the rest of the work should aim there first. The concept also protects TOC from two opposite errors. The first is symptom treatment: solving late orders, overtime, rework, and complaints one at a time because each is visible. The second is false compression: forcing every problem into one grand cause because the field expects convergence. The first error wastes focus. The second creates a brittle diagnosis. A good core-problem statement sits between them: narrow enough to act on, broad enough to explain the effects. For certification-track readers, the distinction is practical. The CRT answers *what to change?* only if the candidate can explain why the chosen entity is the core problem, not just an upstream cause. The Cloud that follows should verbalize the core problem as a conflict or expose the assumption beneath it. The FRT should then test whether the injection removes the UDEs that made the entity core in the first place. If those handoffs don't line up, the diagrams are connected by labels rather than by logic. For implementation, the term sets the boundary between diagnosis and politics. A core problem is usually not a machine that can be bought around. It is often a rule, measure, assumption, or conflict that people have been rewarded for preserving. Naming it changes the conversation from "which symptom should we fix?" to "which part of current reality must stop being true?" ## Common Misunderstanding **"The core problem is the worst UDE."** It isn't. The worst UDE may be the most painful symptom at the top of the tree. The core problem is the cause lower in the tree that produces that symptom and many others. **"The lowest cause is automatically the core problem."** Not necessarily. A low-level cause can explain one branch while another low-level cause explains another. It becomes core only when the convergence and importance tests hold. **"Every CRT must end in one core problem."** The Dictionary says one to three core problems are normal, and Dettmer argues that later-generation CRT work may need several critical root causes rather than one over-broad statement. If the logic does not honestly converge, don't force it. **"A core conflict and a core problem are identical."** They can be two expressions of the same underlying structure, but they are not the same diagram object. A core problem may be a fact, policy, measurement, behavior, assumption, or conflict. A core conflict is the cloud form: the opposing prerequisites whose assumptions keep the system stuck. **"The core problem is objective once the tree is drawn."** The tree constrains the choice, but judgment remains. UDE selection, importance weighting, authority boundaries, and stamina all affect which core driver becomes the working core problem. That judgment is acceptable only when the logic is explicit and peer-reviewable. ## Sources - Cox, *TOCICO Dictionary of Theory of Constraints Terms* (2nd ed., 2012), entries "core problem," "root cause," "core conflict," "current reality tree," and "undesirable effect." The certification-grade definitions this entry cross-checks against, including the 70 percent guideline, the three manifestations of a core problem, and the distinction between root cause and core problem. 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 contemporary source for the Thinking Processes as an integrated answer to the change-question sequence, with the CRT identifying what needs to change and the EC, FRT, PRT, and TT carrying the target forward. - 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 the Snowflake Method, the Three-Cloud Method, the bank example, and the instruction to test whether one cause is responsible for most of the UDEs before naming it core. - Dettmer, "The Logical Thinking Process and the Goal Tree" (local TOC paper extraction, 2007 lineage). The source for the critique of over-broad UDE lists and soft core-problem statements, and for the later discipline of accepting several critical root causes when one actionable convergence point would be false. - Schragenheim and Updegrove, "The Fundamental Structure of the Theory of Constraints" (TOCICO, 2024). The contemporary reformulation that frames the first change question as diagnosing the flawed assumption or core problem preventing better system performance. --- - [Next: Evaporating Cloud (Conflict Resolution Diagram)](evaporating-cloud.md) - [Previous: Current Reality Tree (CRT)](current-reality-tree.md)