🧪 Analysis and synthesis
The commands in family 03: break down problems, build models, separate cause from correlation — and simplify without losing the essence.
🔬 /analyze — break down the problem
Breaks the problem into analyzable parts using explicit method. The quality of an analysis lies in its decomposition: a problem cut along the wrong axis produces elegant answers to the wrong question.
✓ Sound decomposition
- ✓Parts that together cover the entire problem (MECE when possible).
- ✓Each component has its own declared method (“I’ll measure X using Y”).
✗ Poor decomposition
- ✗Cuts by internal department instead of by the structure of the problem.
- ✗Overlap: the same cause appears in three “different parts.”
🎯 Copy and run
/analyze o problema de; decomponha com método explícito e indique como medir cada parte
How to verify: the summed parts explain the whole, with no gaps or overlaps — each with a measurement plan.
🪢 /synthesize — integrate without erasing differences
Integrates multiple findings into a coherent view— keeping conflicts visible. Synthesizing isn’t taking the average of opinions: it’s organizing where they agree and preserving where they differ.
🪢 The honest synthesis test
After synthesizing, ask:
- •"Are the sources that disagreed still shown here?" If not, you averaged, not synthesized.
- •"Would someone who only read the summary know where the uncertainty lies?"
💡 Practical tip
Combine with research: /chain(/research -> /synthesize). The synthesis inherits the gaps in the research — check whether they survived integration.
🎯 Copy and run
/synthesize os achados abaixo em uma visão única; mantenha visíveis os pontos em conflito:
How to verify: one coherent view + an explicit “where the sources disagree” section.
🧠 /model — create the mental model
Builds an explanatory model: variables, relationships between them, and the resulting dynamics. New here? A mental model is a miniature theory of how the system works — good enough to predict what will happen if you change one part.
Analysis + structure become a model; a good model anticipates consequences before you incur them.
🎯 Copy and run
/model de como funciona; variáveis, relações e o que prevê cada relação
How to verify: you can point to a variable and get the predicted ripple effect — otherwise it’s a list of facts, not a model.
🏗️ /framework — build the analytical framework
Creates a reusable structure: dimensions, axes, and criteria for analyzing any case in the same family. It’s the difference between solving one problem and building the ability to solve the entire class of problems.
Define the dimensions
The axes that matter when judging cases in this family (impact × effort, risk × reversibility…).
Set scales and criteria
What does “high impact” mean? A number or anchor example—otherwise, everyone uses their own yardstick.
Test against known cases
A framework that misclassifies obvious cases needs to be reviewed before real-world use.
🎯 Copy and run
/framework para priorizar; dimensões, escalas e teste em 3 casos conhecidos
How to verify: applied to the test cases, the framework reproduces the decisions you consider right — and reveals why.
🎯 /causes — distinguish correlation from causation
Separate correlation from causation by proposing causal mechanisms and testing alternative explanations. Correlation is two things moving together; causation is one pushing the other.
✓ Causal thinking
- ✓"Sales increased because of X" accompanied by the mechanism (how X drives sales).
- ✓Rival explanation tested: “or was it seasonality?”—checked before believing.
✗ Correlation illusion
- ✗"We posted more and sold more, so posts cause sales" — without ruling out a confounding factor (e.g., seasonality).
- ✗Reverse cause and effect: maybe high sales are what allow you to post more.
New here? One confounding factor is a third variable that causes both correlated things (summer increases both ice cream sales AND drownings — ice cream doesn’t drown anyone). Looking for a potential confounder is the first step in /causes.
🎯 Copy and run
/causes de; proponha mecanismo, liste fatores de confusão e testes para separar causa de coincidência
How to verify: plausible mechanism + rival ruled out WITH evidence, not narrative convenience.
🌊 /secondorder — see the indirect effects
Tracks the consequences of consequences — second-order effects that arrive late, hit harder, and almost never make it into the plan.
Immediate effect — what everyone sees
Aggressive discount → volume rises the following week. Great—celebrate quickly.
Indirect effect — what comes later
Customers learn to expect discounts → full-price purchases fall → structural margins decline. Week 1’s volume paid for the quarter’s loss.
Feedback — the system responds to you
Competitors copy the discount → the category becomes a commodity → everyone earns less. /secondorder forces you to consider this layer before making the bet.
🎯 Copy and run
/secondorder da decisão de; efeitos em 1ª, 2ª ordem e feedbacks, com horizonte de chegada estimado
How to verify: at least one indirect effect you had NOT considered — that's the value of the command.
⚖️ /tradeoffs + /constraints — tradeoffs and constraints
/tradeoffs spells out what each option sacrifices; /constraints maps the real constraints — time, budget, people, regulations. Together, they define the truly available option space.
✓ Grown-up proposal
- ✓"Choosing speed costs test depth — we’re taking that risk this way."
- ✓Hard constraint treated as a design boundary, not a detail.
✗ Fantasy proposal
- ✗"No downsides" — a phrase that always hides the cost somewhere else.
- ✗Constraints discovered midway through execution, after they’ve already become costly.
🎯 Copy and run
/tradeoffs /constraints para; o que sacrificamos, quais restrições são duras e o que é negociável
How to verify: each tradeoff has an owner for the accepted risk; hard constraints are separated from negotiable ones.
✂️ /leverage + /simplify — leverage and the essence
Close the track with the two most profitable commands in the family: find the leverage point (little effort, disproportionate impact) and simplify reducing complexity without losing the essential function.
🪝 How to find leverage points
- Ask: which bottleneck, if moved 10%, moves the entire outcome?
- Look for steps repeated manually — natural candidates for leverage.
- Confirm with data: a real lever shows sensitivity in the numbers, not in the rhetoric.
💡 Practical tip
Before adding anything to the process, run /simplify. Half of the improvements that seem necessary are just complexity compensating for other complexity.
🎯 Copy and run
/leverage /simplify no processo de; ache os 2 pontos de maior alavancagem e corte o que não sustenta a função essencial
How to verify: short list of levers with quantified sensitivity + cut items with justification that their function is preserved.
Quick self-check (optional): "we posted more and sold more, so posts drive sales." What's missing?
🎓 Module Summary
Next Module:
3.1 - Red teaming and robustness — now that you analyze well, learn to attack your own conclusions before others do.