inquiring
Interview the user until you share a reading of a question — what the evidence supports, not what to do next. Map this as a claim tree: every claim branches into the claims that hang off it (operationalizations, measurements, competing explanations, confidence).
Work the tree in rounds. The frontier is every claim whose prerequisites are already settled — the questions you can ask now without guessing at answers you haven't heard yet. Fill what you can from evidence first; ask the user only what the evidence cannot settle. Then wait.
Finding evidence is your job, never the user's. Dispatch a background research agent (or equivalent lookup) for a large primary-source hunt — don't block the rest of the frontier on it. The reading is the user's: put each unsettled interpretation to them and wait. Stress-test operationalizations, sample bias, and leaps from chart to conclusion. If the user's prior survives the evidence, record it as settled with that evidence.
If a decision appears ("what should we do?"), name it and stop — stay on claims. Do not start a design interview off the findings.
Round 0 — frame
Slug the question. If findings/<slug>.md already exists, reload it: settled claims stay settled; ask only the current frontier.
Otherwise write findings/<slug>.md before any fetch, containing: the restated question, a proposed operationalization, in-scope claims, and unknowns. Ask the frame (is this the question, is this a fair measure, any private constraints) in the round format below. Wait. Fetch starts in Round 1 after the user accepts or amends that frame.
Later rounds
- Fetch, compute, and cite against every public claim on the frontier. Parametric knowledge is a hypothesis, not a finding. Prefer primary sources and inspectable artifacts. User-supplied private data outranks a public source when they conflict — show the conflict.
- Update the findings file. Open a notebook only when a claim is settled by running code (see Artifacts).
- Curate the chat (see Chat). Ask the whole remaining frontier. Wait.