File-to-chart analysis checklist for ChatGPT

Goal

Turn a raw file upload into a chart and a decision memo without letting the model bluff past bad columns, missing values, or bad math.

Why the order matters

Upload a file and ask "what are the trends?" and you'll get an answer in twenty seconds. It will be articulate, it will have a chart, and you will have no way to tell whether it silently dropped 4,000 rows that failed date parsing, treated "N/A" as a category, double-counted because of a duplicated key, or computed a percentage over a denominator that isn't what you meant.

Most bad analysis happens before the chart, not in it. The chart is where you notice, if you're lucky. This checklist front-loads the noticing to where it's cheap.

Checklist

1. Schema audit first

Inspect the uploaded file and list every sheet or table, the columns, inferred types, missing-value counts per column, duplicate-key risks, row count, and anything ambiguous. Do not analyze trends yet.

Read the row count against what you expected. A mismatch here explains more downstream weirdness than anything else you'll check.

Watch for: numeric columns typed as text (currency symbols, thousands separators), dates in mixed formats, and categorical columns with near-duplicate values (UK / U.K. / United Kingdom).

2. Ask the cleaning questions

Before calculating anything, tell me which columns or rows need decisions from me: missing values, outliers, date parsing, category normalization, or join assumptions. For each, give the options and say which you'd default to.

The point is to make the judgement calls yours. Dropping nulls versus treating them as zero is a decision that changes the answer, and it should not be made silently by a tool.

3. Lock the metric definitions

Define the exact metrics you'll calculate: numerator, denominator, grain, time window, and treatment of nulls. Stop and wait for confirmation.

This is the highest-value step. "Conversion rate" has at least four reasonable definitions and they give different numbers. Writing it out as numerator-over-denominator makes the disagreement visible before it's buried in a chart.

Also settle the grain — one row per what? — because a grain mismatch is the single most common cause of a plausible, confidently-presented, entirely wrong number.

4. Show the intermediate table

Produce the intermediate grouped table you're using for the final chart. Include totals and row counts per group so I can inspect the math.

Check that the totals reconcile with the raw row count from step 1. If 12,000 rows became 9,400, find out where 2,600 went before you look at a single chart.

Small groups matter too: a 100% conversion rate on n=3 will dominate a bar chart and mean nothing.

5. Propose the chart, then justify it

Recommend the best chart for this question, explain why it fits the data shape, and name one misleading chart type you're deliberately avoiding and why.

The "avoided" clause is worth the line. It surfaces the reasoning — pie charts for more than five categories, dual axes implying a correlation, a truncated y-axis making a 2% change look like a cliff.

Ask for the axis ranges explicitly, and insist that a bar chart's axis starts at zero.

6. Spot-check the math

Pick three rows at random and show the arithmetic behind the final values, step by step. If a value depends on an assumption, call it out.

Actually check one yourself against the source file. It takes a minute and it's the only thing that converts "the analysis looks right" into "I checked".

7. Ask what it isn't showing

What does this chart NOT show? What would someone wrongly conclude from it? What's the strongest alternative explanation for the pattern?

Every chart is a selection. This question is where survivorship bias, seasonality, and composition effects — where the aggregate moves because the mix changed, not the rates — get caught.

8. Write the memo

Write a short memo: what the chart shows, what it does not show, the strongest caveat, the confidence level, and the next question I should ask.

Rules

• No trend claims before the schema audit is complete.
• No percentages without the raw counts nearby.
• No executive summary until the intermediate table has been inspected.
• Every number in the memo traces to a row in the intermediate table.
• If the model writes code to do the analysis, read the code. It's the actual analysis; the prose is a description of it, and the two can disagree.

Traps worth naming explicitly

• Silent row loss. Failed date parses and type coercions drop rows quietly. Always reconcile counts.
• Duplicate keys inflating a join. If a join can produce more rows than its left side, every downstream sum is wrong.
• Timezone drift. Grouping UTC timestamps by "day" is not the same as your business day, and the difference lands entirely in the boundary buckets.
• Aggregating an average. The mean of per-group means is not the overall mean unless the groups are equal size.
• Outliers included or excluded without saying. Either is defensible; doing it silently isn't.
• Correlation stated as cause. Ask for the alternative explanation, every time.

Failure modes

• It analyzes before auditing. Restate the stop. If it persists, upload the file in a fresh chat with the audit prompt as the first message.
• Numbers change between turns. It re-derived them differently. Pin the intermediate table and require every later number to come from it.
• The chart looks great and the data is thin. Ask for n per group on the chart itself.
• It "cleans" data without telling you. Ask explicitly: "list every row or value you excluded, modified, or coerced, and why."