Lesson 4.3: Analysis and data work with a model
Learn to use an assistant for analysis without being misled by its arithmetic: describe your data, ask for the method first, verify sums and test formulas.
By the end of this lesson you will be able to choose the safest way to work with numbers in an assistant, describe a data set so the model reads it correctly, ask for the method before the result, verify the arithmetic, catch the commonest statistical trap in business reporting, and get spreadsheet formulas that you can test. You will work through a regional sales table and see why the average of four growth rates is not the growth of the total, and you will check whether a table is small enough to paste in. You should have read Lessons 2.2, 2.4 and 3.1, since analysis combines grounding in supplied data, checking output and asking for visible working. You do not need to be a statistician, though the Data Science course in this library goes deeper into the methods mentioned here.
Numbers are where assistants are most useful and most dangerous at once. They can explain a method, write a formula, spot a pattern in a small table and draft the commentary on a result. They can also add up a column wrongly, mix units or apply the wrong statistical idea, and they will present the wrong figure in the same fluent, confident tone as the right one. Lesson 2.4 explained why. This lesson shows how to get the benefit and keep the control.
What assistants do well and badly with data
Does well · Does badly or unreliablyExplaining a method or a term · Exact arithmetic over many numbers, without running code
Suggesting how to approach a question · Remembering every row of a long pasted table
Writing formulas, SQL and scripts · Knowing what your column names really mean
Spotting an obvious pattern in a small table · Statistical judgement where hidden traps apply
Drafting commentary on results you supply · Noticing data-quality problems it was not told about
Suggesting charts and chart code · Choosing the right chart for a fair comparison without guidance
The practical lesson is a division of labour. Let the assistant propose the approach, write the formula and explain the result. Let a calculator, a spreadsheet or code run by a tool do the computation. And keep the judgement about whether the result makes sense for yourself.
Four ways to work, from riskiest to safest
1. Paste raw numbers and ask for an answer. Quick for tiny tables, and the weakest on accuracy for anything with more than a handful of figures. Use only for rough orientation.
2. Paste the data and ask for the working. Better, because errors become visible. Still, the arithmetic is done by a text predictor, so recompute anything that matters.
3. Use a tool feature that runs code. Some assistants can write and run a program on an uploaded file and return the result. The arithmetic is then exact, because a computer did it, though the program itself may be wrong. Ask to see the code, and ask for the row counts and totals it used, so you can check the steps.
4. Ask for the formula, query or script, and run it yourself. The safest and most repeatable. The assistant writes =SUMIFS(...) or a SQL query, you run it on your own data, and you check the output against a few rows you can do by hand.
For anything that will inform a decision, prefer ways 3 and 4. For anything in front of a client or regulator, run it yourself and keep the working.
Describe the data before you ask
A model cannot see your spreadsheet's meaning, only its text. Give it a short data description, in the way Lesson 2.2 recommended, before the numbers.
text
Data description:
- Table: monthly collections by branch, April to September 2026.
- Columns: branch (text), month (MMM-YY), due (Rs lakh, amount due that
month), collected (Rs lakh, amount collected that month).
- Collection rate = collected divided by due.
- Known issues: Pune branch data for June is missing and shown as blank.
- Do not treat blanks as zero.
Four items matter most: the grain (what one row is), the columns with units, the definitions of any measure, and known problems. They are the same things you looked for in Lesson 1.1 and Lesson 1.2 of the Data Science course, and for the same reason: a model that does not know the blank means "missing" will happily treat it as zero.
Two further cautions apply to what you paste. Privacy: remove names, account numbers and anything else the analysis does not need, or aggregate first, for example by branch instead of by customer. Size: a long table may not fit, or may be silently truncated. Estimate it before you paste. A table of 500 rows by 8 columns, at about 4 tokens a cell, is 16,000 tokens, which exceeds an 8,000-token window by a factor of two, and would leave no space for the question or the answer.
Ask for the method first
A habit that prevents most analysis errors is to separate the plan from the calculation.
1. State the question and the decision it informs.
2. Ask for the method, with no numbers: "Describe the steps you would take to answer this, and the assumptions each depends on. Do not calculate yet."
3. Review the method. Is it the right measure? Are the groups comparable? Does it match how your organisation defines the figure?
4. Run the calculation, with the working shown, or ask for a formula you run yourself.
5. Sanity-check the result against something you know.
6. Ask for an interpretation that includes limitations.
The second step is the one most often skipped, and it is where the worst errors are caught, since a wrong method produces a wrong number however accurate the arithmetic.
Predict first: a table gives sales in the first and second quarters for four regions, with growth for each region. Your manager asks for "the average growth across regions". Are there two sensible answers, and which would you report? Decide before reading on.
There are two answers, and they differ. One is the simple average of the four regions' growth rates. The other is the growth of the total. They are equal only if every region is the same size, and the second is usually what the manager means.
A worked example: the regional sales table
Here is the table, in rupees lakh.
Region · Q1 · Q2 · GrowthNorth · 120 · 132 · 10.0%
South · 95 · 90 · −5.3%
East · 80 · 96 · 20.0%
West · 105 · 105 · 0.0%
Total · 400 · 423 · 5.75%
North grew by (132 − 120) ÷ 120 = 10 per cent. South fell by (90 − 95) ÷ 95 = −5.26 per cent. East grew by (96 − 80) ÷ 80 = 20 per cent. West was flat. The simple average of the four rates is (10 − 5.26 + 20 + 0) ÷ 4 = 6.18 per cent. The total grew from 400 to 423, which is 23 ÷ 400 = 5.75 per cent. The two figures differ because the regions have different sizes: East grew fastest but is small, so it pulls the simple average up more than it moves the total.
An assistant asked for "average growth" without guidance may well report 6.18 per cent and call it the answer. This is the average-of-averages trap from Lesson 1.3 of the Data Science course, and it is a fine example of why you ask for the method first. A better prompt names the measure.
text
Using the table below (Rs lakh), calculate: (a) each region's growth from Q1 to
Q2; (b) the growth of the total; and (c) the simple average of the four growth
rates. Show each calculation. Then explain in two sentences why (b) and (c)
differ, and say which one I should report as "overall growth".
Table: [PASTE]
Verifying the arithmetic
Whenever numbers come back, run a short check.
Do the parts add to the total? If the table has a total row, add the column.
Are the units consistent? Lakh against crore, thousands against units, per cent against decimals.
Is the order of magnitude plausible? A growth rate of 400 per cent in a stable business is a red flag.
Recompute one or two figures independently, in a spreadsheet or by hand.
Check the denominator. A rate is a count divided by something. Ask what that something was.
Re-ask in a different way. If the same question put differently gives a different figure, one of them is wrong.
If a tool ran code, ask it for the row count and the sum it used, and check them against your own count of the file. A mismatch usually means rows were dropped or a column was read as text.
Spreadsheet help
One of the safest and most useful jobs for an assistant is writing formulas. The key is to describe the layout exactly, because the model cannot see your sheet.
text
In my sheet, row 1 has headers. Column A is Region, column B is Q1 sales, column
C is Q2 sales. Data runs from row 2 to row 5. Write a formula for D2 that gives
growth from Q1 to Q2 as a percentage, and another formula for the growth of the
total in D6. Explain each formula in one line, and show the value each should
give for my numbers: B2=120, C2=132.
The reply might offer =(C2-B2)/B2 for the regions and =(SUM(C2:C5)-SUM(B2:B5))/SUM(B2:B5) for the total. The last line of the prompt, asking for the expected value for a sample row, gives you a built-in test: type the formula, and see whether D2 shows 10 per cent. Always test a formula on a row you can do by hand before copying it down a thousand rows. The same approach works for lookups, conditional sums, pivot-style summaries and date arithmetic.
Asking for interpretation, with limits
Once the numbers are right, an assistant can draft the commentary. Guard against over-reach with a few instructions.
Stay within the data: "Describe what the figures show. Do not explain causes unless the data supports them."
Ask for the sample size and uncertainty: "State how many records each figure rests on and whether the difference could plausibly be chance."
Ask for alternative explanations: "Give two other explanations for this pattern that the data cannot rule out."
Mark correlation: "Do not use causal language for relationships found in this data."
Ask the sceptical question: "What would a sceptical statistician ask about this analysis?"
These instructions turn commentary from a story into a set of claims with their limits, which is what a reader deciding something needs. The Data Science course covers the underlying ideas, such as confidence intervals in Lesson 2.3 and correlation versus causation in Lesson 2.4.
Charts and visual analysis
Assistants can suggest which chart fits a question and write the code or the steps to draw it. Use that, and apply the rules of honest charting from Lesson 1.4 of the Data Science course: bars start at zero, the time window is justified, groups of different size are compared as rates, and the title states the finding. A prompt that supplies the question and the data description and asks "which chart would show this fairly, and what would be misleading?" often gives a useful answer.
If you upload an image of a chart and ask what it shows, treat the reading as a first look. Models can misread axes, mix up series or miss a truncated scale, so check the figures it quotes against the chart itself, and ask it to point out anything about the chart that could mislead a reader. That last question is a good one to put to your own charts too.
Keeping a trail
Analysis done in a chat disappears into a scroll. Three small habits make it reproducible, which matters the moment someone asks how you got a number.
Save the final prompt and the data description beside the output, with the date. Next quarter you will want to rerun the same analysis, and you will not remember what you asked.
Record the checks you made, such as "total recomputed in the spreadsheet: matches" or "formula tested on rows 2 and 9".
Note the version of the data, such as the file name and extract date, because a figure that cannot be tied to a file cannot be defended.
A one-page note holding the question, the method, the figures, the checks and the limits is far more valuable than a polished chart with no history. It also protects you: if a figure is later challenged, you can show where it came from and what you did to test it.
More worked examples
Example 1: coding free-text survey answers. A team has 200 open-ended survey comments. They ask the assistant to propose a set of themes from a sample of 30 comments, then to assign each of the 200 to one theme, quoting the words that justified it. They check 25 assignments at random, find 3 wrong, and refine the theme definitions with two examples. The theme counts become a chart. They report the counts with the note that assignments were checked on a sample, not individually.
Example 2: KPI commentary. An analyst pastes the monthly KPI table and asks for a short commentary. The first draft says "collections improved due to the new reminder process", a cause nobody supplied. She adds the instruction "no causes unless stated in the data", and the commentary now describes the movement and lists "possible causes to investigate" separately, labelled as untested.
Example 3: a formula that looked right. A manager asks for a formula to count customers overdue by more than 7 days. The assistant supplies one, and the test row, which has exactly 7 days overdue, returns "overdue". The formula used a "greater than or equal" test. The boundary row caught the error, and a corrected formula fixed it. Test the edges: the exact threshold, a blank, a zero and the largest value.
Common mistakes
Accepting arithmetic from a text predictor. Prefer code, a spreadsheet or your own recomputation.
Pasting data with no description. State the grain, units, definitions and known issues.
Pasting too much. Check that the table fits, or summarise it first.
Skipping the method step. A wrong method gives a wrong number, however neat the sum.
Averaging averages. Weight by size, or compute from totals.
Letting commentary invent causes. Ask for what the data shows, and label causes as hypotheses.
Copying a formula down without testing it. Test one row you can do by hand, including edge cases.
Pasting personal data. Remove identifiers or aggregate before sharing.
Key takeaways
Assistants explain methods and write formulas well, and compute long arithmetic unreliably. Divide the work: the model proposes, a calculator or code computes, you judge.
Prefer tools that run code or formulas you run yourself over raw arithmetic in text, and ask to see the code and the row counts.
Describe the data first: the grain, columns with units, definitions and known issues. Remove personal data and check the table fits the window.
Ask for the method before the calculation, review it, then compute and sanity-check.
The simple average of four growth rates, 6.18 per cent in the example, can differ from the growth of the total, 5.75 per cent, because the regions differ in size.
Test every formula on a row you can do by hand and on edge cases. Ask commentary to stay within the data and state its limits.
Check yourself
1. Why is a formula you run yourself safer than asking for the answer in text?
A spreadsheet computes exactly and repeatably, and you can test it on known rows. Text predictors can make arithmetic errors.
2. What four things belong in a data description?
The grain, the columns with units, the definitions of measures, and known issues such as blanks.
3. Region A goes from 200 to 220 and Region B from 50 to 60. What are the simple average of growth rates and the growth of the total?
A is 10%, B is 20%, so the average is 15%. The total goes from 250 to 280, which is 12%.
4. A table has 300 rows, 10 columns and 4 tokens a cell. How many tokens is it?
300 × 10 × 4 = 12,000 tokens.
5. How would you test a formula for "more than 7 days overdue"?
Use a row with exactly 7 days, one with 8, one with 6 and a blank, and check each result.
Try this
You need an assistant and about fifty minutes.
1. Choose a small table from your work with at least four groups and two periods. Write the data description with the four items.
2. Ask the assistant for the method before any calculation: what you would compute for "overall growth" and the assumptions. Review it.
3. Ask for the calculation with the working shown. Recompute the total growth and the simple average of the group growth rates in a spreadsheet. Note any difference from the assistant's figures.
4. Use the table-fit simulator to see how large a table you can paste. Try pasting a summary table instead of raw rows.
5. Ask for a spreadsheet formula for one measure, with a test value. Test it on a row you can do by hand and on an edge case.
6. Ask for commentary with the five guard instructions: stay within the data, sample size, alternatives, no causal language and the sceptical question.
7. Fill in this table.
Check · Assistant's figure · Your figure · Match?Growth of the total · · ·
Simple average of rates · · ·
Sum of the parts · · ·
A formula test row · · ·
A good result is a verified analysis, with the method named, the figures recomputed, the formula tested at its edges, and commentary that states what the data does and does not show. In the final lesson of this module, we apply the same habits to planning, operations and code.
Tags: Prompt Engineering Data analysis Spreadsheets Verification Intermediate