Define: metric, period, entity
Break down: baseline and drivers
Execute: staged queries
Check: grain and reconciliation
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