A practical guide for practitioners, analysts, and professionals working with difficult problems
This guide explains how to the RESOLVE in practice — whether you are working alone, with a team, or using AI as an analytical partner. It covers when to use RESOLVE, how to move through each stage, common mistakes to avoid, and how to work with AI systems effectively within the process.
A reference version is available as a PDF download at the end of this page
What is RESOLVE
RESOLVE is a reasoning method (framework) for tackling complex, contested, ambiguous, or consequential problems. Probelms where a fast, confident first answer is likely to be wrong, or at least incomplete. It provides a seven-stage spine that disciplines the reasoning process from first framing through to review and adaptation.
It is not a checklist. It is not a promise of better outputs from better prompting. It is a scaffold for doing harder thinking more rigorously.
RESOLVE is the flagship method within the Better Thinking reasoning ecosystem. It sits above a set of reasoning tools — analytical engines used within specific stages — and operates within a broader framework of structured human–AI reasoning.
The seven stages
Stage R
Reality — Clarify what is happening and how the issue is framed
Before any analysis begins, check whether the problem as stated is actually the problem that needs solving. Assumptions should be made visible and the working framing used in later stages stated explicitly. For complex or contested issues, a framing scan surfaces alternative ways of seeing the problem before progression.
Stage E
End state — Define what “better” looks like and how success will be recognised
Vague aspirations produce vague interventions. Success must be defined in observable or testable terms, with a declared time horizon and identified constraints. This stage separates what must be true from what would be nice.
Stage S
System — Understand causes, structures, constraints, and leverage points
Surface symptoms and root causes are not the same thing. This stage maps the causal structure of the problem — what is actually driving it, what constraints are structural versus assumed, and where genuine leverage exists. Material claims are distinguished by confidence level: evidence-supported, mechanism-based, exploratory, or unresolved.
Stage O
Options — Expand possible pathways before narrowing choices
Premature convergence on a single solution is one of the most common reasoning failures. This stage requires genuine option expansion — including cross-domain and unconventional pathways — before any filtering begins. The goal is to widen the field, not confirm the first idea.
Stage L
Logic — Evaluate trade-offs and select transparently
Selection criteria must be declared. Trade-offs must be made explicit rather than obscured. The decision-making authority is identified. AI and analytical tools may inform this stage, but they do not constitute decision authority. Ethical, legal, and long-term implications are considered before selection.
Stage V
Value delivery — Implement with ownership, alignment, and feedback
A good decision without a viable implementation path is just a plan. This stage establishes clear ownership and accountability, anticipates behavioural and cultural barriers, and builds in feedback capture from the outset.
Stage E
Evolve — Review outcomes, adapt, scale, or stop
RESOLVE is iterative. New evidence, changed circumstances, or better understanding at any stage can and should trigger a return to earlier stages. The final stage formalises what was learned and what should change as a result.
Δ Movement
What changed?
Every RESOLVE run ends with an explicit statement of what shifted — not a summary of what was found, but what materially changed in understanding, leverage, or direction as a result of running the process.
This is how RESOLVE avoids the trap of structured analysis that produces no real movement — where a rigorous-looking process ends in the same place it started.
When to use
RESOLVE is most valuable where one or more of the following is true:
- The problem is genuinely complex — multiple causes, competing interests, uncertain evidence
- The framing is contested — different people describe the problem differently, or the problem keeps shifting
- The stakes are significant — the cost of a poor decision is high, or hard to reverse
- Previous attempts have stalled — the problem has resisted straightforward approaches
- The first answer feels too easy — confidence is high but the reasoning behind it is thin
It is less necessary where problems are well-defined, evidence is clear, and the path forward is genuinely straightforward. RESOLVE is a discipline for difficulty, not a bureaucratic requirement for every decision.
RESOLVE does not guarantee a correct answer. It improves how the problem is structured and analysed.
What RESOLVE is not
RESOLVE is not a decision-maker. It improves the reasoning process, but it does not own the judgment, the responsibility, or the final decision. Those remain with the people accountable for the outcome.
RESOLVE is not a universal one-shot answer engine. Better prompting can improve many first-pass outputs. RESOLVE is for the harder cases — where the issue is complex, contested, ambiguous, or consequential, and where disciplined iteration produces materially better results than fast first answers.
RESOLVE is not a replacement for domain expertise. Its strongest results emerge when a knowledgeable human is active inside the process — correcting framing drift, challenging weak assumptions, adding grounded judgment, and deciding what is actually workable.
Good practice for reliable results
- Use fresh chats for important runs (avoid context carryover)
- Keep inputs clean and structured
- Use 3–5 contrasting framings
- Limit facts to the most relevant
- Run a second pass only when neededCompare outputs if testing robustness.
When to stop
Stop when:
- the problem is clearly framed
- root drivers are understood
- trade-offs are explicit
- a bounded decision direction is reached
- Do not continue adding input once clarity stops improving.
Using AI as a reasoning partner, not a reasoning replacement
AI systems can provide significant value within a RESOLVE process — particularly in Stage S (evidence gathering, system mapping), Stage O (option generation, cross-domain search), and Stage L (criteria comparison, stress-testing). Used well, they accelerate the parts of the process that benefit from breadth and speed.
The critical discipline is maintaining your own judgment throughout. AI outputs within RESOLVE should be treated as analytical inputs, not conclusions. The following practices help:
Use AI for breadth, not verdict. Ask AI to generate framings, surface evidence, propose options, identify precedents. Do not ask it to decide.
Challenge AI outputs actively. If an AI-generated framing or option seems immediately right, ask it to argue the opposite. Ask it what it might have missed. Ask it what evidence would change its analysis.
Stay in the loop at every stage. The strongest RESOLVE results emerge when a knowledgeable human is active and critical throughout — correcting drift, adding domain judgment, and maintaining responsibility for the final direction.
State your working framing explicitly. When working with AI across a RESOLVE process, always state the working framing at the start of each stage. AI systems do not carry context reliably across sessions; restating the framing is not redundant, it is good practice.
Different AI tools may vary in wording, emphasis, or level of detail. When working well, the underlying reasoning, trade-offs, and conclusions should remain broadly similar.
Using RESOLVE without AI
RESOLVE can be run in a room with a team just as effectively as with AI. Work through the stages together, using a whiteboard or shared document to capture thinking. The structure keeps discussion focused, surfaces different perspectives, and helps the group move from problem to decision without getting stuck in debate or jumping to premature solutions.
What goes wrong — and how to avoid it
Skipping Stage R. The most common and most costly mistake. Moving straight to analysis or solution without checking the framing means all subsequent work may be addressing the wrong problem. Even five minutes on Stage R changes the quality of what follows.
Treating the first framing as fixed. The framing that arrives with the problem is usually someone else’s framing — shaped by their interests, their experience, or the way the problem was first noticed. It deserves scrutiny, not deference.
Confusing diagnosis with prescription. Identifying the cause of a problem is not the same as identifying the solution. Stage S and Stage O are deliberately separated for this reason.
Narrowing too early in Stage O. The temptation to converge on a preferred option before the option space has been genuinely explored is strong. Resist it. Options dismissed before they are properly understood are frequently the ones worth examining most carefully.
Using RESOLVE as a post-hoc justification. Running through the stages after a decision has already been made produces the appearance of structured reasoning without its substance. If you are using RESOLVE, use it to reason, not to document.
RESOLVE’s reasoning tools
RESOLVE draws on a set of reasoning tools — analytical engines invoked at specific stages to deepen or sharpen the analysis. These are not separate products. They are part of how RESOLVE works.
- HYP — Hypothesis generation. Used in Stage R to surface multiple plausible explanations before deeper analysis begins.
- ANSYS — System analysis. Used in Stage S to map causal structures, incentives, and leverage points.
- EVID — Evidence validation. Used in Stage S when the quality or reliability of evidence materially affects the analysis.
- IDX — Structured divergence. Used in Stage O as the primary tool for widening the option space before filtering begins.
- EXP — Exploratory expansion. Used in Stage O to test mechanisms, check cross-domain candidates, and stress-test shortlisted options.
- SYN — Cross-domain synthesis. Used in Stage O when recombination across fields could open new intervention pathways.
- SOL — Solution evaluation. Used in Stage L to compare options against declared criteria, constraints, and trade-offs.
- ENS — Ensemble stress-test. Used in Stage L to pressure-test conclusions through multiple analytical perspectives before selection.
Using advanced mode with your own tools
In advanced mode, you can integrate your own tools (e.g. SCAMPER, IDEATE, OODA) into the RESOLVE process. Apply them at the stages where they are most useful—for example, ideation tools in Options or decision frameworks in Logic—to sharpen thinking without overcomplicating the analysis.