The dividing line between a quick question and formal analysis is not the number of words or SQL lines. It is the impact of a wrong answer and the chance the work will be questioned or rerun. Low-impact, low-reuse exploration can stay Quick. Numbers used in weekly meetings, finance, customer communication, or period-over-period tracking should retain a Plan, SQL, validation, and Report.
Two questions are enough to route the work
| Unlikely to be questioned/rerun | Likely to be questioned/rerun | |
|---|---|---|
| Low impact if wrong | Quick: inspect columns or the first 20 rows | Preserve SQL: reusable exploration or self-service query |
| High impact if wrong | At least add validation checkpoints | Project: Plan → review → Execute → Report |
"Which values occur in status?" usually belongs top-left. "How many paid users did we have this week for the board deck?" belongs bottom-right even when it needs only one SQL line. Risk comes from use, not technical complexity.
Consider formal analysis when any condition applies:
- the number affects budgets, staffing, pricing, or customer commitments;
- the work needs cross-table JOINs, denominator definitions, or exception rules;
- the same definition will be rerun next week or month;
- someone else will take over, review, or cite the result;
- the conclusion needs limitations, not just a number.
Quick does not mean careless; Project does not mean bureaucracy
A sensible Quick deliverable can be just the question, query, and one definition note. Exploration should remain inexpensive; inspecting every schema does not need approval.
Project makes easy-to-lose decisions explicit: objective, denominator, grain, time window, join key, validation, and what the result cannot answer. Its purpose is to survive the second question, not to increase document length.
A useful upgrade signal is when chat fills with "Does user mean registered or paid?", "Do refunds count?", or "Can we split by market?" The problem has moved from value lookup to metric collaboration.
Lantide Data's two-track workflow
Lantide Data provides both Quick Analysis and Project Analysis. Quick fits column exploration, SQL syntax, and one-off validation. Project uses a Plan, comments, user Approve & Execute, formal SQL, and a Report. See the Quick vs Project guide.
The principle is to put governance cost where it is valuable: do not process every question, but do not leave formal numbers only in chat. People still own definitions and acceptable risk, and Lantide is not a multi-user BI monitoring system.
Conclusion
Before asking, label the error impact low/medium/high and rerun probability low/high. If either is elevated, preserve SQL and validation. If both are high, use formal analysis. Workflow should scale with risk, not question length.