Verified against ChatGPT · 2026-08-08
Get a trustworthy first read on a new dataset before you build anything on top of it
Turns a raw data dump into a structured first-look summary — shape, likely grain, suspicious columns, and the three questions you should answer before trusting any number from it.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are a senior data analyst doing the first-look pass on a dataset someone just handed you, before any dashboard, report, or model gets built on top of it. Your job is not to describe the data politely — it's to tell me whether I can trust it yet.
DATASET DESCRIPTION
A weekly export from our billing system covering every invoice issued in the last 18 months, roughly 40,000 rows, pulled by an ops analyst who has since left.
COLUMNS AND SAMPLE VALUES
invoice_id (INV-2044, INV-2045...), customer_name (Acme Corp, acme corp, ACME CORPORATION), amount_due (1200.00, -450.00, 99999.99), status (paid, Paid, PAID, void)
INTENDED USE
Monthly revenue recognition dashboard for finance leadership, broken out by customer segment.
KNOWN CONTEXT
I've heard the billing system double-logs some invoices when a payment retry happens, but no one has confirmed how often.
What I need from you:
1. State the likely grain of this dataset in one sentence (one row per what, exactly) — if the columns given don't make the grain obvious, say so explicitly instead of guessing confidently, and name the one or two columns that would confirm it.
2. List every column that looks structurally suspicious: a numeric column with an implausible range, a date column with an inconsistent format, an ID column that isn't actually unique, a categorical column with near-duplicate values that are probably the same thing typed differently ("NY" vs "New York" vs "ny"). For each one, name the specific risk it poses to the intended use, not just that it "needs cleaning."
3. Identify what's missing that the intended use would need but this dataset doesn't obviously provide — a join key, a time dimension, a denominator for a rate you'd want to compute.
4. Write three yes/no questions I should get answered by whoever owns this data before I build anything on it — each one a question where a wrong assumed answer would silently produce a wrong number downstream, not a generic "what does this data represent" question.
WHAT NOT TO DO
Do not write a generic column-by-column data dictionary restating what each column obviously is — only surface columns and facts that actually change whether the data can be trusted. Do not invent row counts, date ranges, or specific values you weren't given; if a sample is too small to judge something, say that explicitly rather than extrapolating confidently from three rows.
OUTPUT FORMAT
- Grain statement (one sentence, plus a confidence flag: confirmed / probable / unconfirmed)
- Suspicious columns table: column | issue | downstream risk
- Missing-for-intended-use list
- Three yes/no questions for the data owner
- One line: is this dataset safe to build on now, or only after the questions above are answeredCustomize
Optional — swap in your own details for the highlighted parts above.
Why this works
The prompt deliberately reframes the task away from "summarize this dataset," which pulls GPT-5.1 toward a neutral, descriptive column dictionary that restates the obvious and gives false confidence, and toward "judge whether this is trustworthy," which activates a more skeptical evaluation frame where the model is rewarded for flagging problems rather than describing structure politely. Forcing an explicit grain statement with a confidence flag matters because grain ambiguity is the single most common silent cause of wrong aggregate numbers in BI work — a model asked to summarize data will often just assume a grain and move on, while one asked to state it with a confidence flag has to notice and admit when the columns given don't actually establish it. Requiring the downstream risk for each suspicious column, rather than a generic "needs cleaning" flag, forces specificity that prevents the model from padding the list with cosmetic nitpicks (a lowercase status value) that don't actually threaten the intended use, while missing a genuinely dangerous one (a status value like "void" that should be excluded from revenue but might not be). The explicit ban on inventing row counts or extrapolating from a small sample addresses a real failure mode: language models asked to analyze data they were only given a few sample rows of will often speak confidently about patterns across the whole dataset, and naming this restriction upfront produces appropriately hedged answers instead of fabricated precision.
What you get back
Grain: one row per invoice issued (probable — confirm invoice_id is truly unique, since duplicates from payment retries were mentioned as a known risk). Suspicious columns: customer_name (case/spacing inconsistency, e.g. 'Acme Corp' vs 'ACME CORPORATION' — will fragment a customer-segment rollup unless normalized); amount_due (contains a negative value and a value near 99999.99 that looks like a placeholder, not a real charge — both would distort a revenue sum). Missing: no explicit invoice date column was shown — confirm one exists before building a monthly view. Questions: (1) Does a duplicate invoice_id always mean a payment retry, or can it also mean a genuine duplicate charge? (2) Should void-status rows be excluded from revenue recognition entirely? (3) Is amount_due always in the same currency across all rows?
Verified against
ChatGPT GPT-5.1 · 2026-08-08
Changelog
- 2026-08-08 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
