Read time: ~6 minutes · Series: Business & Operations practice · Previous: How to review a Plan · Next: Report to HTML
The Report is out—what should you look at
Once Execute completes, the analyst delivers a Report. Your job isn't to nitpick the SQL syntax, but to judge: can this Report support the decision you're about to make, and does it honestly explain its limitations.
Four acceptance checks
| Check | What "good" looks like | What "not good" looks like |
|---|---|---|
| Concrete numbers | "1,623 orders, accounting for 1.63%" | "Attrition is fairly severe at a certain stage" |
| Traceable definitions | Stage / denominator are written in the Report | Only conclusions, no definitions |
| limitations | Clearly states what the data lacks and what the assumptions are | No limitations at all |
| Causal caution | Distinguishes correlation from causation | Writes "A causes B" outright |
Funnel-type analyses should also include the stage with the biggest drop-off and the counts / rates per stage (see USER_GUIDE §2.7).
Use Compare view to check against the Plan (recommended)
When accepting a Report, you can open the same project's Plan in Compare view and line it up side by side with the Report in the main window to compare definitions and numbers. Annotations inside Compare view are read-only, but you can use View changes to inspect the diff of Resolved annotations. For steps, see USER_GUIDE §11.10 and Analyst: the Plan flow.
If the Report was produced in collaboration with an external Agent, the minimum acceptance bar is still the same approved Plan, formal SQL evidence, concrete numbers, and limitations. Ask the analyst to use External MCP Activity to explain which artifacts were modified; a "done" in an external chat cannot replace this evidence. When you need to understand the connection and Activity boundaries, read External Agent Integration.
How to read limitations
limitations are not a way to dodge responsibility—they tell you what this number can't be used for. Common contents:
- Data excludes refunds, or some channels are delayed in landing
- The sample period is too short; the campaign period isn't comparable to normal days
- It's a correlation analysis and can't be treated as a causal conclusion
If the limitations conflict with your decision's risk (for example, you want to externally claim GMV, but the Report says refunds haven't been deducted), you should send it back and request a new Plan and re-run, rather than just rewording the Report.
Annotating a Report vs requesting a re-run
| Situation | Recommended approach |
|---|---|
| Wording, formatting, adding business context | Annotate on the Report and ask the Agent to revise the wording |
| The definition is wrong (denominator, stage, time window) | New Plan, re-Execute |
| The numbers lack a key dimension (e.g. not broken down by channel) | A new Plan, or a follow-up Plan in the same project |
One thing you can do right now
Open your most recent Report and find the limitations section first: if it's missing or too vague, annotate it and ask the analyst to add "what the data doesn't cover, and what the assumptions are."