Evaporating Cloud (EC)

A conflict-resolution tool using necessary-condition logic, flowing left-to-right from Common Objective to Conflict. Multiple necessary inputs are implicitly AND; OR is explicit.

Node types

• CommonObjective — the shared objective valid for both sides (default: green)
• Need — a perceived need that must be met (default: blue)
• Want — a perceived want derived from a need (default: orange)
• Conflict — the conflict as mutually exclusive wants (lightning-bolt icon, no text)
• OrJunctor — alternative necessary inputs, any one of which suffices (icon: OR circle)
• Assumption — an underlying assumption behind the conflict (default: purple)
• Solution — the solution that breaks the conflict (default: teal)

Edge types — necessary-condition relationships flowing left-to-right from the shared objective through needs and wants to the conflict.

• From the objective: objective_to_need, objective_to_or
• From a need: need_to_want, need_to_or, need_to_assumption, need_to_solution
• From a want: want_to_conflict, want_to_or, want_to_assumption
• From the conflict: conflict_to_or, conflict_to_assumption
• From an OrJunctor: or_to_want, or_to_conflict, or_to_or

A conflict resolution graph showing how assumptions behind a conflict can be surfaced and resolved:

vgraph projectConflict: EC "Project Delivery vs Quality" {
    // The shared objective both sides agree on
    node obj: CommonObjective "Deliver a successful software product";

    // The two competing needs
    node needA: Need "Meet the market window deadline";
    node needB: Need "Ensure product quality and reliability";

    // The specific wants derived from each need
    node wantA: Want "Release with current feature set now";
    node wantB: Want "Extend timeline for thorough testing";

    // The conflict between the two wants
    node conf: Conflict;

    // Assumptions underlying the conflict
    node assA: Assumption "Testing always requires calendar time";
    node assB: Assumption "Features cannot be descoped";
    node assC: Assumption "Quality requires full manual testing";

    // Solution that breaks the conflict
    node sol: Solution "Implement automated testing pipeline";

    // Objective requires both needs (necessary condition)
    edge obj -> needA: objective_to_need;
    edge obj -> needB: objective_to_need;

    // Needs lead to wants
    edge needA -> wantA: need_to_want;
    edge needB -> wantB: need_to_want;

    // Wants create the conflict
    edge wantA -> conf: want_to_conflict;
    edge wantB -> conf: want_to_conflict;

    // Assumptions exposed
    edge needA -> assA: need_to_assumption;
    edge needB -> assC: need_to_assumption;
    edge conf -> assB: conflict_to_assumption;

    // Solution resolves by breaking assumption
    edge needB -> sol: need_to_solution;
}

Note: EC graphs flow left-to-right, with the Common Objective on the far left and the Conflict on the far right. The two branches represent competing Needs and Wants that create the conflict. Assumptions are surfaced on each edge to identify which assumption can be challenged. The Solution breaks the conflict by invalidating one or more assumptions. EC uses necessary condition logic — "In order to [Objective] we must provide [Need]". The Conflict node has no text label; it is rendered as a lightning bolt icon.