// On this page
I’ve written elsewhere about why I structure AI queries in stages rather than asking a single direct question. This piece is the practical companion: the actual prompts, in order, with annotations on what I’m trying to achieve and what goes wrong when you skip steps.
These are not prompts to copy verbatim. They’re templates. The company name, the specific question, the framing of the situation — all of that gets filled in with real information. What matters is the structure.
Before you start
The single most important thing you can do before running any of this is write down, in one sentence, what you believe about the company. Not a question. A belief.
“I think the market is underpricing the recovery in margins because it’s extrapolating last year’s cost pressures.”
Write that down. Keep it visible. The point of the exercise that follows is to stress-test that belief, not to produce a new one. If you don’t start with a clear statement of what you think, the model will generate something that sounds like a view and you’ll mistake it for yours.
Stage 1: The role
You are a cautious equity analyst reviewing a position on behalf of a sceptical investment committee.
Your job is not to be helpful or encouraging. Your job is to produce the most rigorous assessment
you can, with explicit flags wherever the evidence is thin or the reasoning involves assumptions
you cannot verify. The company under review is [COMPANY NAME]. The current situation is: [TWO OR
THREE SENTENCES OF CONTEXT].
Before you do anything else, confirm your understanding of what I've told you and flag any
ambiguities in my framing.Why this matters: The default mode for these models is helpful and agreeable. That’s useful for many things. It’s actively counterproductive for investment analysis, where what you need is friction, not agreement. Establishing the role before the analysis begins shifts the register of everything that follows.
The instruction to confirm understanding and flag ambiguities is not courtesy — it’s the first test. A model in the right mode will often push back on your framing here. That’s exactly what you want.
Stage 2: The filter
Before forming any view on this position, I want you to separate what we actually know from
what we're inferring. Please produce two lists:
LIST A — Observable facts: things that are verifiable from published sources (filings,
announcements, audited accounts, market data). Do not include anything that requires
interpretation to establish.
LIST B — Assumptions and inferences: things that appear in the investment case but depend
on interpretations, management forecasts, analyst projections, or extrapolations from
the observable data.
If you're uncertain which list something belongs on, put it in List B and note the uncertainty.Why this matters: This is the step most people skip, and it’s the most valuable one. The output often reveals that what looked like a well-constructed thesis is built on two facts and four assumptions presented as facts. That’s not a reason to abandon the thesis — assumptions can be reasonable — but it’s essential to know which parts of your case are load-bearing and which are speculation dressed as evidence.
It also prevents the model from blending facts and inferences in its subsequent outputs. If you skip this step, you get prose that mixes the two seamlessly, which feels like analysis but makes it very hard to know where the risk actually lies.
Stage 3: The risk frame
Now I want you to focus specifically on the downside. Please address three things:
1. INVALIDATION: What would need to be true for the investment thesis to be completely wrong?
Not just weaker — wrong. What observable evidence would tell you the core assumption has failed?
2. TIMING: What is the realistic range of time over which the thesis could play out, and what
are the costs — financial and opportunity — of being right but early?
3. KNOWN UNKNOWNS: What are the most important things we don't know that bear on this decision,
and how long before we're likely to have better information?Why this matters: The question “what are the risks” produces a generic list. Every analyst knows what the risks are in a general sense — the question is which risks are specific and material to this situation, right now.
The invalidation question is the most important. If you can’t answer clearly what would make you wrong, you don’t have a thesis — you have a preference. And a model that can’t answer it clearly is telling you something useful about how much of the case rests on faith rather than evidence.
Stage 4: The verdict
Given everything above — the facts, the assumptions, the downside case — I want you to produce
a single practical recommendation. The format should be:
ACTION: [One sentence. What you would do with the position.]
CONFIDENCE: [A number from 1 to 100, where 50 is genuinely uncertain.]
PRIMARY DRIVER: [The single most important factor driving the recommendation.]
WHAT WOULD CHANGE THIS: [The single most important new information that would shift the recommendation.]Why this matters: A verdict without a confidence level is almost useless for decision-making. The difference between “add to the position at 65/100 confidence, primarily on the margin recovery thesis” and “add to the position at 52/100 confidence, primarily because I can’t find a strong reason not to” is everything. The second one is often what you get if you don’t force the model to be explicit.
The “what would change this” question is borrowed from good forecasting practice. A recommendation that nothing could shift is a belief, not an analysis.
What the sequence produces
Done properly, this takes twenty minutes. What you get at the end is not a decision — that remains yours — but a structured map of what you know, what you’re assuming, where the downside is concentrated, and what confidence level is actually warranted.
The output will usually be less flattering to your existing view than a direct question would produce. That’s the point. The goal is not to feel better about the position. The goal is to make a better decision about it.
One practical note: I run this sequence as a single conversation rather than as separate queries. Each stage builds on the previous one, and the model’s earlier commitments — to the role, to the fact/assumption distinction — shape what it produces in the later stages. Resetting the conversation between stages loses that context and typically produces worse output.
What it doesn’t do
This framework does not make the model reliable on factual questions. It will sometimes get numbers wrong, mis-state facts from memory, or confidently cite something that doesn’t exist. The List A / List B exercise at Stage 2 is partly designed to surface this — if something appears in List A but you can’t verify it from a primary source, treat it as List B.
The framework is a structure for thinking, not a source of facts. The facts still have to come from somewhere you trust.