Read time: ~5 minutes · Series: Business & Ops practice · Previous: Report to HTML · Next: vs BI and meetings
Good vs bad annotations
| Bad | Good |
|---|---|
| "Run it again" | "Denominator = paid orders; exclude status=cancelled" |
| "Numbers wrong" | "Window should be 5/20–6/20, exclude warmup" |
| "Different from last time" | "Stage2 = paid, not order-created" |
| "Execute now" | "Execute after the three points above are confirmed" |
Annotations must be actionable: analyst or Agent knows which Plan sentence to change and how.
How to (summary)
- Open project Plan, Visual mode
- Select sentence or table to change
- Add annotation with your change
- Analyst Resolves; Agent patches only annotated sections
After Resolve:
- View changes for before/after on resolved annotations
- Archive when done tracking (history kept in sidecar)
- Anchor outdated after big body edits—analyst Re-anchor by re-selecting text (business users usually annotate only)
Full steps: USER_GUIDE §11.7.
Two things not to do
- Press Execute for the analyst without reading Plan—accountability stays with analysis owner
- Skip Plan and demand Report—fast short-term, expensive metric disputes later
If only time for Quick exploration, ask analyst to label informal numbers—don't put them in sign-off flow.
Slack, meetings, and Plan
- Meeting: align decisions and priorities
- Plan annotations: write resolutions into metric contract
- Slack: notify "Plan updated—see section 3"—cannot replace Plan annotations
One thing to do now
Practice template: "Change [quote] to [your definition], because [one line of business context]." Use on next Plan review.