From an ambiguous problem to a reasoned outcome.
The Poland example illustrates the intended method. It is not output from a working RAZOOM system.
Four phases, ten steps.
Frame the problem
- 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
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
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.
- 1
Structure the attack
- 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.
- 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.
- 4
Do the work
- 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.
- 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.
- 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?
- 6
Conclude
- 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.
- 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.
- 9
See the full Poland example for the choice at stake, missing evidence and proposed next action.
What supports the process.
Explore the eight internal functions
Problem Diagnosis
01What 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.
Information Value
02Which 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.
Dynamic Problem Graph
03What 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.
Method Selection
04How 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.
Execution
05What 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.
Critic / Red Team
06What 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.
Synthesis
07What 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.
Stop Controller
08Is 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.
- 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.


