Read time: ~8 minutes · Role: Business / Operations · Next: Work through the reading path below article by article, or ask an analyst to share results as a Project
.lantide(with an annotatable Plan) or an HTML Report (for reading in the weekly meeting).
You've probably run into this scenario
On Friday, ops says in the group chat "the campaign conversion rate is 12%." On Monday, business asks: "Is the denominator orders placed or orders paid? Do cancellations count?" The analyst digs through the chat history—only a summary, no definition document you've personally confirmed.
You're not here to learn SQL, nor to press Approve & Execute for the analyst (the button that approves the Plan and formally kicks off the data pull). What you need is: before a number goes public, to be able to state on the Plan "I agree with this calculation"; and after the Report is out, to judge "can this number be taken to a meeting."
What Lantide Data is (Business / Operations view)
In one sentence: a local analysis tool that analysts use, but with definitions and conclusions written into an annotatable Plan / Report—not trapped in AI chat bubbles or Slack screenshots.
Whether the analyst uses Lantide's built-in Agent or a controlled external Agent doesn't change how you accept the work: what you review is the same Plan, Report, limitations, and traceable evidence—not a completion claim made in an external chat.
| What you're used to | How Lantide does it |
|---|---|
| Nodding "let's calculate it this way" in the group chat | Annotate on the Plan, with changes bound to the original text |
| Reading the analyst's verbal summary in the weekly meeting | Attach a Report or HTML Report (with numbers and limitations) |
| "The AI says it's 12%" | Probe the denominator and stage definitions in the Plan |
| Pushing for "just give me a number first" | Align on the definition before Execute; formal numbers come from an Executed Report |
Plan = how this analysis should be calculated (the definition contract).
Execute = the analyst (or a designated owner) pressing the button, meaning "this version of the Plan is cleared for a formal data pull"—you shouldn't press it for the analyst, unless you are the analysis owner.
Report = a deliverable with concrete numbers and limitations, exportable to HTML to attach to the weekly meeting.
What you do in the flow
sequenceDiagram
participant Biz as Business or Operations
participant Analyst as Analyst
participant Agent as Agent
Analyst->>Agent: Explore and draft the Plan
Analyst-->>Biz: Please review the Plan
Biz->>Analyst: Annotate definitions on the Plan
Analyst->>Agent: Resolve and revise
Note over Analyst,Agent: No formal data pull before Execute
Analyst->>Agent: Press Execute
Agent-->>Analyst: Produce the Report
Analyst-->>Biz: Deliver the Report
Biz->>Biz: Cite it in the weekly meeting or make a decision
Note over Analyst,Biz: An HTML Report can be produced to attach to the meeting
The moments you should most be involved in:
- Plan review (before Execute) — confirm whether the denominator, time window, and funnel stages match your business understanding
- Report acceptance (after Execute) — do the numbers answer your question; are the limitations honest
- (Optional) HTML report — once the Report content is OK, you can Generate it yourself (when you have project permissions) or ask the analyst; then Open / Export it for the weekly meeting (see Report to HTML)
If you were only invited to "hear the results," at minimum read the stage definitions and limitations sections of the Report.
Division of labor with PMs and analysts
| Role | What you care about |
|---|---|
| Analyst | Write the Plan, press Execute, produce the Report |
| PM / decision-maker | Whether to push the tool, how the pilot runs, team rules |
| You (Business / Operations) | Whether this definition is right, whether this number can go to a meeting; optionally: produce the HTML meeting version yourself or ask the analyst |
If you're also the PM, both paths are worth reading; if you were just pulled in to review numbers, this article + the 2 onboarding articles are enough to get started.
Cases where you may not need to go deep on your own
- Teams that never chase definitions and only want one-off charts
- You expect to install the database and migrate the workspace yourself → see Platform Admin (Data Engineering) introduction
- You want to write SQL and run analyses yourself → see Analyst introduction
Suggested reading path (onboarding → practice → advanced)
Onboarding: build a mental model (~12 minutes)
| # | Article | Overview | Status |
|---|---|---|---|
| 1 | Why sign off on the Plan instead of nodding in Slack | Why verbal consensus gets missed; annotations bound to the original text | Available |
| 2 | Quick exploration vs formal numbers | Which numbers can't go into the weekly meeting or finance | Available |
Practice: aligning with daily work (~26 minutes)
| # | Article | Overview | Status |
|---|---|---|---|
| 3 | How to review a Plan (no SQL needed) | Denominator, time window, stage, assumptions list | Available |
| 4 | How to accept a Report | Numbers, limitations, when to ask for a re-run | Available |
| 5 | Turn a Report into an HTML report | Principles, Generate yourself or ask the analyst, export and fine-tune | Available |
| 6 | Annotating a Plan: what to write, what not to do | Concrete definition changes vs vague number-chasing | Available |
| — | Follow along | Ask an analyst to share a project: annotate the Plan + read the Report + open or export an HTML version | Available |
Advanced: dividing labor with other tools (~12 minutes)
| # | Article | Overview | Status |
|---|---|---|---|
| 7 | Dividing labor with BI dashboards and weekly-meeting decks | Adhoc sign-off vs daily monitoring | Available |
| 8 | Common anti-patterns | Verbally changing definitions, rushing Execute, taking Quick screenshots to meetings | Available |
Design depth (optional)
| Resource | When to read |
|---|---|
| USER_GUIDE §2.5–2.7 | To see what the Plan / Report look like in the product |
| USER_GUIDE §10 | Step-by-step HTML generation, export, and fine-tuning |
| PM: The quality bar | When the team wants to set a unified standard for "meeting-ready numbers" |
Trial checklist
- Finish this article + the 2 onboarding articles
- Ask an analyst to open a project and walk you through a Plan in the Planning state
- In Plan Visual mode, select a passage and leave one annotation (e.g. changing the denominator definition)
- Read an Executed Report and confirm it has concrete numbers and limitations
- (Optional) After accepting the Report: Generate the HTML yourself or ask the analyst, Open to check limitations, then Export for the weekly meeting
- Confirm you haven't—and don't need to—press Execute for the analyst
- (If using an external Agent) Ask the analyst to show the affected artifacts and External MCP Activity, rather than just forwarding an external chat summary
Other roles
- Analyst introduction — daily analysis and Execute
- Product Manager introduction — adoption and pilot rollout
- Platform Admin (Data Engineering) introduction — connections and workspace migration
- Learn Hub