ANALYTICS & REPORTING

Dataset fitness check before analysis

Use when a dataset has arrived and you need to know what it can support before analysing it.

dataset-fitness-check.md

Download .md

You are checking whether a dataset can support an analysis before anyone runs it. You are not doing the analysis.

The analysis planned: {{PLANNED_ANALYSIS}}
Dataset description, including row count, date range and columns: {{DATASET_DESCRIPTION}}
A sample of rows: {{SAMPLE_ROWS}}
How the data was collected: {{COLLECTION_METHOD}}

Output:
1. A verdict line: fit for {{PLANNED_ANALYSIS}}, fit with caveats, or not fit. One of those three, first, before any detail.
2. A check table: Check | Result | Evidence from {{SAMPLE_ROWS}} or {{DATASET_DESCRIPTION}} | Effect on the analysis. Cover grain, duplicate rows, missing values by column, date coverage and gaps, placeholder values such as zero or unknown, outliers, any change in collection part way through the period, and survivorship.
3. Columns that cannot be used at all, and why.
4. The minimum cleaning steps, in order, each with what it removes or changes and roughly how many rows that affects.
5. Questions about {{COLLECTION_METHOD}} that must be answered before the result can be trusted.

Rules:
- Do not clean anything silently. Every exclusion is a listed step someone else could repeat.
- If the date range in {{DATASET_DESCRIPTION}} is shorter than the comparison the analysis needs, say that first and say what is missing.
- Where the sample is too small to judge a check, mark it unverified rather than passing it.

Fill in before running

Replace each placeholder with your own detail. The more specific you are, the less the model invents.

{{PLANNED_ANALYSIS}}
{{DATASET_DESCRIPTION}}
{{SAMPLE_ROWS}}
{{COLLECTION_METHOD}}

Getting a better result

Send a sample of at least a few hundred rows spread across the period, not the first hundred.
Ask who generated the extract and when; regenerated exports rarely match the first one.
Keep the cleaning steps as code, since the analysis will be re-run and the steps will be forgotten.

Questions about this prompt

When do I use this rather than starting the analysis?

When a dataset has arrived from elsewhere and you do not know how it was made. An hour here is cheaper than presenting a result and then discovering the collection method changed part way through the period. The verdict comes first and is one of fit, fit with caveats, or not fit.

What do I need in front of me?

The analysis you intend to run, the dataset description with row count, date range and columns, a sample of rows, and how the data was collected. Send a few hundred rows spread across the period rather than the first hundred, or the checks on gaps and mid period changes have nothing to look at.

What comes back?

The verdict line, then a check table covering grain, duplicates, missing values by column, date coverage, placeholder values, outliers, collection changes and survivorship, each with its evidence and effect. Then unusable columns, ordered cleaning steps with the rows affected, and questions about collection. The cleaning steps are what you keep.

What is the mistake that costs me here?

Cleaning as you go instead of writing the steps down. Every exclusion has to be repeatable by somebody else, and the analysis gets re-run long after you have forgotten what you dropped, so keep the steps as code. Treat unverified checks as unverified too: a sample too small to judge is not a pass.