Academy
7. Knowing the Limits and Going Further
Recognise what the engine cannot do — missing columns, structure sampling on very large datasets, complex modelling — and know when to escalate to a mission or use Intelligence alerts.
The natural-language query engine is powerful, but it has clear boundaries you should understand.
-
No invented columns. The engine answers questions the data can answer. If a column doesn't exist in your dataset — say you ask for "profit margin" but only have revenue and cost columns without a margin field — the engine won't fabricate data. It may derive a calculation if the math is obvious, but it will never hallucinate a column that isn't there.
-
Structure sampling on large datasets. To understand your data's shape (column names, types, sample values), the model reads a sample — not every row. The good news: the actual computation still runs on all rows. The risk: if your data has irregular patterns that don't appear in the sample, the engine may misunderstand a column's purpose or type.
-
Complex modelling hits a wall. Multi-step statistical models, predictive analytics, or iterative transformations go beyond what a single query can handle. The engine executes one code block per question; it isn't designed for workflows that need several dependent steps.
How do you spot these limits in practice? Watch for these signals in the engine's response:
• "Column not found" or assumption statements. The engine states its assumptions in the answer when a column name is ambiguous or missing. If it picks the wrong column, correct it and re-ask.
• Unexpected results on very large files. If the structure sample didn't capture an edge case, the generated code may misinterpret a column. Always review the generated code and the result table — both are visible for every query — to confirm the logic matches your intent.
• Overly simplified answers to complex questions. If you ask for a regression, a forecast, or a multi-join pipeline and the answer feels shallow, the engine likely reduced your question to what it could do in one pass. That's your cue to escalate.
When a query hits these limits, you have two escalation paths:
1. Missions. Complex modelling — anything requiring iteration over several steps, multi-stage transformations, or advanced analytics — is better handled as a mission. In a mission, @oupi can work through multiple dependent steps, refining code and results progressively rather than answering in a single shot.
2. Intelligence alerts. If your goal is ongoing monitoring rather than a one-off question, set up Intelligence alerts. The Intelligence module watches your data continuously and raises alerts on notable changes and anomalies. Instead of repeatedly querying "did anything change?", let the platform tell you, with a dedicated dashboard summarising what moved and why it matters.
Before escalating, try breaking your complex question into smaller, single-purpose queries. Ask one thing at a time — "total revenue by region for Q2", then "top 10 customers by margin in 2025" — and chain the insights yourself. You'll often get what you need without a full mission.
Clean column headers in your source file dramatically reduce misunderstandings. If the engine keeps misinterpreting a field, rename the column in a transformation (the original dataset stays intact) and re-query.
Go to your Intelligence dashboard and review any active alerts. If you have none yet, open a dataset you query often and enable Intelligence monitoring on it. Observe the alerts dashboard to see what the platform flags automatically — this is your alternative to repetitive manual queries.
The query engine won't invent missing columns, may sample structure on large datasets (though computation covers all rows), and isn't built for multi-step modelling. When you hit these walls: review the visible code and result table to confirm what happened, try splitting complex questions into simpler ones, escalate to a mission for iterative analytics, and set up Intelligence alerts for ongoing monitoring instead of repeated queries.