A playbook is different from a tutorial. A tutorial teaches you to do a thing once. A playbook tells a team which move to make in which situation, who owns it, and what order the moves run in. When several people across an agency are using language models to read client data, the difference between ad hoc prompting and a real playbook is the difference between occasional embarrassment and dependable output.
This is the operating playbook for table and chart interpretation. It is organized as a set of plays, each with a trigger that tells you when to run it, the steps inside it, and the role that owns the outcome. You will not run every play on every dataset. You select plays based on the shape of the data and the stakes of the decision.
The plays assume you already understand the basic technique. If you do not, start with Reading Tables and Charts With AI: A Practical Q&A and come back. Here we focus on sequencing and ownership.
Play One: Intake and Normalize
Trigger
Any time raw data arrives, before a single prompt is written.
The Moves
- Convert the source into clean, delimited text with explicit headers
- Strip merged cells, footnotes, and decorative formatting
- Record units and currency in each header so nothing is inferred
- Note which rows are subtotals or aggregates
Owner
Whoever receives the data owns normalization. This step is unglamorous and skippable under deadline pressure, which is exactly why it needs a named owner. Most downstream errors trace back to a table that was never cleaned.
Play Two: Frame the Question
Trigger
Once the data is normalized and before any analysis prompt.
The Moves
Write the question so it names the exact cells and the exact operation. Replace "what is the trend" with "what is the percentage change in the Net Revenue row from the first to the last period." Specificity here is not pedantry; it is the lever that removes ambiguity from the model's parse.
For exploratory work where you do not yet know the question, run a separate discovery prompt first, then frame a precise question for the figure you actually need.
Play Three: Extract Before You Interpret
Trigger
Whenever a conclusion will rest on specific numbers.
The Moves
Ask the model to pull the relevant figures and list them, with the cells they came from, before doing any analysis. Confirm those figures against the source. Only then ask for interpretation. Splitting extraction from interpretation prevents a wrong number from flowing invisibly into a confident conclusion, which is the single most common failure in this work.
Play Four: Compute Deterministically
Trigger
Any arithmetic that will be quoted.
The Moves
- Have the model show its calculation steps explicitly, or
- Have the model call a calculation or code tool so the math runs deterministically
- Never accept a quoted number produced as a free-form guess
Owner
The analyst running the prompt owns this. The discipline of showing work is what makes errors visible, and it pairs directly with the verification habits in A Repeatable Process for Extracting Insight From Tables.
Play Five: Handle Charts Deliberately
Trigger
When the source is a chart image rather than a table.
The Moves
Decide first whether you need exact values or just the shape of the trend. For shape and direction, the model's image reading is fine. For exact figures, do not read them off the image; locate the underlying data and run the table plays on it instead. Mixing these up is how estimated numbers end up presented as precise ones.
Play Six: Verify and Sign Off
Trigger
Before anything reaches a client or a decision.
The Moves
- Spot-check a sample of cells against the source
- Reproduce any quoted arithmetic independently
- Confirm trends are described in the direction the data supports
- Have a second person sign off on high-stakes figures
Owner
A reviewer separate from the person who ran the prompt. Self-review misses the errors you were primed not to see.
Play Seven: Template and Hand Off
Trigger
Once a type of analysis recurs.
The Moves
Capture the working prompt, the input format, and the verification checklist as a reusable template. A templated play lets a new team member produce the same quality without rediscovering it. This is where a playbook turns into institutional capability rather than individual skill.
Sequencing the Plays
The plays run in order for a fresh dataset: normalize, frame, extract, compute, handle charts as needed, verify, then template. For recurring work you start from the template and still run verification every time. The order is not arbitrary; each play depends on the one before it being done properly. Skipping normalization undermines framing, and skipping extraction undermines computation.
For a sense of how these plays will shift as models improve, see When Models Stop Needing Your Cleaned-Up Spreadsheets.
Choosing Which Plays to Run
You do not run all seven plays on every dataset. The skill of the playbook is selecting the right subset for the situation, and that selection comes down to two questions: how messy is the data, and how high are the stakes.
Reading the Data
- Clean, well-structured data lets you go light on normalization but never on framing or verification
- Messy exports, screenshots, or PDFs demand a full normalization pass before anything else
- Charts trigger the chart-handling play and a decision about whether you need exact values
Reading the Stakes
A throwaway internal question can skip the second reviewer and the templating play. A figure headed into a client deck or a board memo runs every verification step and gets a second pair of eyes. Matching the rigor to the consequence keeps the playbook fast where speed is fine and careful where it counts.
The mistake to avoid is treating low-stakes habits as acceptable on high-stakes work. The cost of a quiet error does not scale down just because you were in a hurry, so the verification and sign-off plays stay mandatory whenever the output will drive a decision.
Where Teams Slip
Even with the plays defined, predictable things go wrong, and knowing them lets you reinforce the weak spots.
- Normalization gets skipped under deadline pressure, so errors enter at the source
- Extraction and interpretation get bundled, hiding a wrong figure inside a good conclusion
- Verification becomes a rubber stamp rather than a real check against the source
- Templates go stale after a model upgrade and carry outdated caution
The corrective in every case is the same: make the skippable step owned and explicit rather than dependent on someone remembering. A playbook works precisely because it removes reliance on memory and good intentions.
Frequently Asked Questions
Do I really need separate owners for each play?
For a solo practitioner the owners collapse into you, but the roles still matter as distinct hats. The reason to name owners on a team is that the skippable steps, normalization and verification, are precisely the ones that get dropped when nobody is accountable for them.
Which play prevents the most errors?
Extract before you interpret. Most damaging mistakes are not wild hallucinations; they are a wrong figure that flowed into a correct-sounding conclusion. Forcing extraction into its own step, with cells listed, catches those before they propagate.
How do I run this without slowing everything down?
Template the recurring analyses so most of the framing and verification is pre-built. The first pass through a new data type is slow; after that, the playbook is fast because the structure is reusable.
What if the data is too large for one prompt?
Add a filtering or summarization step to the intake play, reducing the data to the rows that matter before framing the question. A focused subset is read more accurately than a full dump, even when the full dataset fits the context window.
Can non-analysts run this playbook?
Yes, which is part of the point. Clear plays with explicit steps let people without deep data backgrounds produce reliable output, provided verification and sign-off stay in place for high-stakes figures.
How often should the templates be revisited?
Whenever the model changes or the data format shifts. A template that assumed a weaker model may be overly cautious for a stronger one, and a template built for last quarter's report layout breaks when the layout changes.
Key Takeaways
- A playbook assigns each move a trigger, steps, and an owner so quality does not depend on memory
- Normalize data first; most downstream errors trace to an uncleaned table
- Extract figures before interpreting them so a wrong number cannot hide in a good conclusion
- Compute deterministically through shown work or tool calls for anything you will quote
- Verification by a second person and reusable templates turn individual skill into team capability