Complex question plan
01

Define: metric, period, entity

02

Break down: baseline and drivers

03

Execute: staged queries

04

Check: grain and reconciliation

05

Explain: evidence and limits

Make the plan inspectable before making the answer fluent

A question about declining regional profit bundles metric definition, geography, comparison period, revenue, and cost.

One opaque query can hide a wrong assumption behind a plausible number, so expose the dependencies first.

Decompose by analytical dependency

Resolve profit, organization, and time before calculating the change; only then segment by product, channel, or expense.

Each step should declare input, filter, output grain, and upstream dependency to prevent accidental multiplication across joins.

Validate intermediate evidence in two ways

Technical checks cover keys, row counts, nulls, reconciliation, and scope. Business checks cover definitions, comparability, events, and data cutoff.

When a check fails, repair the failing stage instead of merely regenerating the narrative.

Insert approval where consequence is high

Finance definitions, cross-domain joins, sensitive detail, and expensive scans justify showing the plan and scope before execution.

Routine summaries may run automatically, but their plan and evidence still need a durable trace.

Accept with compound questions and injected faults

Test cross-metric and cross-source questions while introducing missing tables, late data, bad joins, and competing definitions.

AskTable.ai can be assessed for conversational analysis; plan display, staged execution, caching, and approval behavior require deployment-specific verification.

Write an analysis contract before generating queries

Translate the question into a decision object, governed metric, comparison window, allowed dimensions, evidence grain, and explicit inference limits. “Why did East-region profit fall?” is underspecified until profit type, region assignment, and comparison period are known. Mark every assumption as user-confirmed, identity default, semantic contract, or system inference.

Only low-risk inferences with strong evidence should execute automatically. Finance definitions, cross-organization scope, and causal claims deserve confirmation. A syntactically valid query can still answer the wrong question, so contract validation precedes SQL validation.

Represent dependencies as a plan graph

Build baseline and current comparable totals, verify the conserved difference, then decompose by product, channel, customer, or cost. Each node records inputs, filters, grain, outputs, row count, uniqueness, nulls, and totals. Cacheable intermediate results make replay and targeted repair possible.

Decompose by independent checks, not sentence fragments. Product and channel views may overlap and cannot be added as complete causes. Label mutually exclusive decompositions, cross-dimensional views, and residuals so the narrative does not double-count evidence.

Attach technical and business invariants to every step

Technical invariants cover keys, row counts, join multiplication, nulls, and date scope. Business invariants cover accounting equations, roll-up conservation, comparable stores, and cutoff. Stop when an invariant fails instead of producing an explanation from corrupted intermediates.

EXPLAIN can reveal scan and join behavior but does not prove business correctness; plausible totals do not prove technical validity. Link definitions, lineage, SQL, parameters, and intermediate evidence under one request ID.

Separate arithmetic contribution, association, and causality

A profit bridge can arithmetically attribute changes to price, volume, mix, and cost, but it does not prove why those inputs changed. Promotion and demand may share seasonality; channel mix and product mix may move together.

A model should frame causal language as a hypothesis unless design, temporal ordering, controls, and alternative explanations support it. An analytics agent can narrow investigation, but fluent certainty is not causal identification.

Accept through fault injection and replay

Test late refunds, missing dimensions, metric-version changes, mismatched comparison populations, cross-domain joins, and database timeouts. The system should stop at the failing node, name the invariant, retain valid work, and offer a recovery path. Changing a definition should invalidate every dependent node.

AskTable.ai may be assessed as the conversational analysis entry point. Plan display, node caching, human approval, replay, and invariant checks require deployment-specific verification, possibly across warehouse and observability systems. This article does not promise automated causal analysis or universal multi-step planning.

Public references

Ready to help your team start?

Talk through a real scenario and see how AskTable.ai can fit your business.

Book a demo