AI

Investigations

Give Chartizer a question and it investigates — running its own queries, gathering evidence, and presenting what it found as charts.

An investigation is the difference between a chart and an answer. You pose a question in plain language; Chartizer plans an approach, works through your connected data with its own tools, checks what it finds, and comes back with a written finding backed by charts and the exact queries behind them.

Where Ask your data answers a single question with a single chart, an investigation keeps going: it follows what it finds, rules out explanations, and reports.

The loop

Plan

Chartizer restates your question as something answerable, identifies which datasets could speak to it, and lays out the steps it intends to take. The plan is visible before anything runs.

Gather

It works through the plan with its tools — profiling fields, running aggregate queries, joining and segmenting metrics by dimension. Each step and its result is recorded.

Verify

Findings are checked before they are reported: does the row count support the claim, does the pattern hold when the window shifts, is there a simpler explanation such as a partial period or an upstream sync gap?

Present

You get a written finding, the charts that show it, and the evidence trail behind every claim.

What it can use

Every tool is read-only and runs as you — an investigation can never reach data you could not open yourself.

Tool What it does
Catalogue search Finds datasets and fields relevant to the question, by name, description, and field name
Schema inspection Reads field names, types, nullability, and existing mappings
Field profiling Distributions, null rates, cardinality, min/max, outliers
Query Aggregate, filter, group, and bucket over a dataset
Time comparison Period over period, same period last year, moving windows
Anomaly detection Spikes, drops, and changepoints in a series
Segmentation Splits a metric by dimension to find where a change concentrates
Chart building Produces a chart bound to the dataset, not a static image
Data-quality check Flags unmatched records, sync gaps, and schema drift affecting the answer

Read-only, always

No tool writes. Connectors have no write path at all, so an investigation cannot modify a source, a dataset, or a mapping — only read, compute, and chart. Accepting a mapping suggestion remains a human action.

Evidence

Every claim in a finding carries what produced it. Expand any statement to see:

  • the datasets used, and their last sync time,
  • the query that was run, in full,
  • the row counts behind the number,
  • any caveat the check raised — a partial period, a high null rate, unmatched records.
Text
Finding · Revenue fell 18% in the EU region in July

  evidence
    dataset      Orders (MySQL) · synced 12 Aug 09:02
    query        sum(total) by month where region = 'EU'
    rows         48,201 → 39,514
    caveat       Orders has 124 unmatched records on `dealer_id`;
                 excluded from the dealer split below.

  charts
    Monthly revenue, EU, last 13 months          (line)
    Revenue by dealer, July vs June              (grouped bar)

Read the caveats before the conclusion

The caveat line is where investigations earn their keep. “Revenue fell 18%” and “revenue fell 18%, but one source stopped syncing on the 14th” are very different findings.

A worked example

Text
› Why did dealer signups drop last month?

Chartizer plans, then works:

  1. Catalogue search finds Dealers, Signups, and Leads 2026.
  2. Field profiling on Signups.created_at confirms coverage through yesterday — no sync gap.
  3. Query buckets signups by week; the drop starts in week 27, not gradually.
  4. Segmentation by source_channel concentrates the drop in one channel.
  5. Join to Leads 2026 on the mapped email field shows lead volume held steady.
  6. Data-quality check notes 18 unmatched records — too few to explain the gap.
  7. Anomaly detection dates the changepoint to 3 July.

The finding: leads kept arriving, but conversion from one channel collapsed on 3 July — with a weekly line chart, a channel breakdown, and the queries behind both.

It tells you what it could not determine

An investigation does not manufacture a cause. If the data cannot distinguish between two explanations, it says so and names what would settle it — usually a field or a source that is not connected yet.

Following up

Investigations keep context, so you can push on any part of the finding:

Text
› why did that channel drop?
› was it the same in other regions?
› show me the affected dealers
› save the weekly chart to Internal

Save to project turns any chart from the finding into a normal chart, bound to its dataset and refreshing with it — no AI involved from then on. The written finding can be saved alongside it as a text tile on a dashboard.

What makes an investigation work well

Helps Why
A stated definition “Active dealer means ordered in 90 days” removes the biggest source of wrong answers
A time range “Last month vs the month before” beats “recently”
Tidy unmatched counts Large unmatched counts weaken every joined claim

It cannot know your business rules

“Churn”, “active”, “qualified” mean whatever your company decided. Say the rule in the question, or encode it once as a dataset the investigation can reach.

Permissions and privacy

  • Investigations run as you. Datasets you cannot open are invisible — not named, not hinted at.
  • Row-level rules apply to every query an investigation runs.
  • Restricted datasets need an access request first.
  • What is sent to the model, what is retained, and how to restrict both is covered in Data handling.
  • Investigations can be disabled team-wide under Settings → AI.

Check the query before acting on a surprising finding

A confident write-up with the wrong date column looks exactly like a correct one. The evidence trail exists so you can check — for anything that will drive a decision, read the query.