Exploratory Data Analyst

The first hour with a new dataset determines whether the next month builds on rock or sand. This skill runs a disciplined exploratory pass — provenance, structure, quality, distributions, relationships — with the analyst's cardinal rule intact: look at actual rows early and often, because summaries are where data problems hide.

When to use this skill

• A new dataset, export, or table arrives and decisions will be built on it
• Before any modeling, dashboarding, or metric definition on unfamiliar data
• A familiar dataset starts producing surprising numbers and needs a health check
• Someone hands you conclusions plus the underlying data, and you want to trust but verify

Workflow

1. Interrogate provenance first: who or what produced this, over what period, with which filters already applied — and what does one row represent? "One row = one order" versus "one row = one order line" changes every count downstream. Write the grain down before anything else.
2. Look at twenty raw rows — top, bottom, and a random sample — before any aggregate. You are hunting the things summaries hide: header rows inside the data, placeholder values (0, -1, 1900-01-01, "N/A", empty string), truncated text, two formats sharing one column.
3. Profile the structure: row and column counts, types as stored versus types as intended — numbers as text, dates as strings, IDs as floats — and file size sanity against expectation.
4. Audit quality column by column: missingness rate and its pattern (random, or concentrated in one segment or time range?), cardinality (constants, near-constants, IDs that are almost but not quite unique), duplicates at the declared grain, and ranges against physical reality — negative ages, future dates, orders totaling zero.
5. Examine distributions one variable at a time: for numerics, min/max/median/p95/p99 and a histogram — note skew, spikes at round numbers, clumps at caps and defaults; for categoricals, the top values and the size of the tail; for dates, coverage and gaps.
6. Probe relationships with a purpose. Correlations and cross-tabs only for pairs that matter to the question at hand; before believing any joined number, check key relationships across tables — orphaned foreign keys, unexpected fan-out on the join.
7. Slice by time if time exists. Most datasets contain regime changes — a schema migration, a tracking change, a business pivot — visible as level shifts. A dataset that looks fine pooled can be two incompatible datasets stapled together.
8. Write the findings memo as you go, not from memory afterwards: each finding with its evidence (the query or the count), a severity, and the implication for the intended use.

Output format

## EDA memo: <dataset> — <date>

Grain: one row = <entity>. Period: <range>. Source: <system, known filters>.
Size: <rows> x <cols>.

### Trustworthy for
<the questions this data can support as-is>

### Findings
| # | Finding | Evidence | Severity | Implication |

### Do not use for
<questions this data cannot answer, and why>

### Open questions for the data owner

The "do not use for" section is the memo's most valuable paragraph. Never omit it.

Guardrails

• No modeling, forecasting, or causal claims during EDA — this pass is what earns the right to do those things later
• Never clean silently while exploring; log every filter or fix applied, or the findings describe a dataset that no longer exists
• Distrust perfectly clean data — zero missing values in a human-entered field is itself a finding
• Statistical significance has no place in an EDA memo; a hundred implicit comparisons were just run
• If the grain cannot be established, stop: everything downstream is arithmetic on an unknown unit

Sixty-second sanity checklist

• Row count within 2x of expectation
• One known real-world fact reproduced from the raw data
• The declared primary key is actually unique
• Dates fall inside the claimed period
• The metric everyone quotes, recomputed from raw, matches the number they quote