Skip to content
RAZOOM is in active development right now — join the early access list
RAZOOM

From an ambiguous problem to a reasoned outcome.

Four phases take a problem from framing to a Case outcome. The ten steps below show how that could work for one market-entry choice.

The Poland example illustrates the intended method. It is not output from a working RAZOOM system.

Conceptual illustration: should we expand into Poland? The question moves through four phases and ten steps. A stop check asks whether more reasoning would help; the proposed Case outcome is a pilot to measure customer acquisition cost. This is not output from a working RAZOOM system.

Four phases, ten steps.

Follow the conceptual question “Should we expand into Poland?” from the problem behind it to the evidence that would make a pilot worthwhile.
  1. Frame the problem

    1. 1

      Understand

      Identify the problem behind the question, the objective and any choice at stake.

      In the Poland exampleThe real question is whether Poland beats the next-best use of the same capital.

    2. 2

      Clarify

      Ask only what could change the conclusion. Everything else waits.

      In the Poland exampleWhat payback period is acceptable? Is entry via partner allowed?

    3. 3

      Formalize

      State objectives, constraints and criteria precisely enough to test.

      In the Poland exampleObjective: 24-month payback. Constraint: €1.2M ceiling. Criterion: risk-adjusted return.

  2. Structure the attack

    1. 4

      Decompose

      Break the problem into connected subproblems and map their dependencies.

      In the Poland exampleDemand, competition, unit economics, regulation, capacity, acquisition, pricing, risk, capital.

    2. 5

      Select Method

      Choose how each subproblem should be attacked — and by which kind of executor.

      In the Poland exampleUnit economics gets a model; capital risk gets a Monte Carlo simulation.

  3. Do the work

    1. 6

      Investigate

      Gather the evidence the critical unknowns require, kept apart from interpretation.

      In the Poland exampleCompetitor pricing, channel costs and licensing requirements, with sources.

    2. 7

      Calculate / Simulate / Experiment

      Run the formal methods — or define the measurement reality has to provide.

      In the Poland example10,000 simulated runs of cash position under uncertain acquisition cost.

    3. 8

      Challenge

      Attack assumptions, competing explanations and fragile links before concluding.

      In the Poland exampleThe conclusion collapses if acquisition cost exceeds €310. How confident are we?

  4. Conclude

    1. 9

      Synthesize

      Combine what survived into a conclusion with its confidence and conditions.

      In the Poland exampleExpansion is attractive only if acquisition cost holds below the threshold.

    2. 10

      Return outcome

      Produce a defensible answer — or the specific next action that would make one possible.

      In the Poland examplePilot first: a 90-day test in two cities to measure real acquisition cost.

See the full Poland example for the choice at stake, missing evidence and proposed next action.

What supports the process.

These eight internal functions support the four phases above. They are not another sequence of steps for the person asking the question.
Explore the eight internal functions
  1. Problem Diagnosis

    01

    What kind of problem is this?

    Classifies the problem — well-posed or ambiguous, calculable or judgemental, reversible or not — and checks whether the question asked is the question that matters.

    Produces: A problem model and, when needed, a reframed question.

  2. Information Value

    02

    Which missing facts are worth asking for?

    Estimates how much each unknown could move the Case outcome. Clarifying questions are asked only when the answer could change it.

    Produces: A short, ranked list of questions — often none.

  3. Dynamic Problem Graph

    03

    What depends on what?

    Decomposes the problem into subproblems with explicit dependencies. The graph is revised as evidence arrives instead of being fixed at the start.

    Produces: A graph of subproblems and the critical path through the problem.

  4. Method Selection

    04

    How should each part be attacked?

    Assigns each subproblem a method — reasoning, research, calculation, modeling, simulation, optimization, measurement or experiment — and an executor, local by default.

    Produces: An attack plan you can read before any work is done.

  5. Execution

    05

    What do the methods actually say?

    Runs the plan: local models for language work, deterministic tools for calculation, retrieval for evidence. Results are recorded with their inputs.

    Produces: Evidence, analyses and intermediate claims.

  6. Critic / Red Team

    06

    What would make this wrong?

    Independent critique attacks high-leverage assumptions, searches for competing explanations and protects competent dissent from being averaged away.

    Produces: Surviving claims, documented objections and fragility points.

  7. Synthesis

    07

    What can be concluded, and how confidently?

    Combines what survived into a conclusion with calibrated confidence and the conditions under which it holds.

    Produces: A supported conclusion or clear next step, traceable to its evidence.

  8. Stop Controller

    08

    Is more reasoning worth it?

    Decides when to stop: when the Case outcome is sufficiently supported for the stakes, when further reasoning cannot help, or when reality has to provide the next fact.

    Produces: A Case outcome from the types below — not necessarily an answer.

An answer is only one possible Case outcome.

When reality must answer the question, RAZOOM should stop reasoning and ask for evidence. These are the verdicts it is designed to return.
  • ConcludesAnswer

    The evidence supports a clear conclusion.

  • ConcludesConditional answer

    A conclusion that holds under stated conditions.

  • RedirectsWrong question

    The question asked would not resolve the real problem. Here is the better one.

  • RedirectsInsufficient information

    A defensible answer needs facts that are not available yet.

  • Asks realityMeasurement required

    The missing fact exists in the world and has to be measured.

  • Asks realityExperiment required

    The evidence does not exist yet. Here is the smallest test that would create it.

  • Asks realityPilot first

    Commit in a reversible, small way before committing fully.

  • Asks realityWait

    Deciding now destroys option value. Here is what to wait for.

  • ConcludesDecision depends on X

    The choice flips on one variable. Here is its threshold.

  • Requires a personFrontier escalation available — operator authorization required

    A frontier model might improve one specific step. Nothing is sent until an operator reviews and authorizes it.

Frontier escalation is never automatic. It is offered as an option, and nothing is sent until an operator reviews the request. How the Frontier Authorization Gate works

Bring us a problem that deserves this process.

Tell us about the problem and what evidence is missing. Your request helps us choose useful problems to test as we build RAZOOM.