Runs a structured exploratory data analysis on a new or suspect dataset - schema audit, target analysis, feature profiling, missingness patterns, and leakage checks - ending in a written decision log. Use when someone says "I just got this dataset, where do I start", "my model metrics look too good", "audit this data before we model it", or is debugging unexpected model behavior. Do NOT use for writing the transformation code itself - use pandas-expert instead; for ongoing production data monitoring use data-quality; for constructing model features after EDA use ml-feature-engineering; for answering a one-off business question from a database use sql-to-insights.
Click to play with sound.
---
name: EDA Playbook
description: Runs a structured exploratory data analysis on a new or suspect dataset - schema audit, target analysis, feature profiling, missingness patterns, and leakage checks - ending in a written decision log. Use when someone says "I just got this dataset, where do I start", "my model metrics look too good", "audit this data before we model it", or is debugging unexpected model behavior. Do NOT use for writing the transformation code itself - use pandas-expert instead; for ongoing production data monitoring use data-quality; for constructing model features after EDA use ml-feature-engineering; for answering a one-off business question from a database use sql-to-insights.
---
# EDA Playbook
Skipping EDA before modeling is the single most common source of silent failures in ML pipelines: leakage that makes offline metrics fictional, structural missingness treated as random, a target definition nobody actually agreed on. This playbook is a fixed-order audit that surfaces those problems while they cost hours instead of quarters - and its output is a decision log, not a pile of plots.
## Operating procedure
Run the sections in order: schema problems invalidate the target analysis, and the target definition must be pinned before any feature-target relationship means anything.
### Step 1: gather inputs
- The dataset, its supposed grain (one row = ?), and the expected row count. If the provider cannot state either, derive them and label the result a guess.
- The target column and its **written definition** - precisely what event, over what window, measured when. Ambiguity here cascades everywhere; do not proceed on a verbal shrug.
- What information will exist **at prediction time**. This single fact powers every leakage check later.
- Any known collection changes (new form fields, pipeline migrations) that could create structural breaks.
### Step 2: shape and schema audit
- Confirm row count is in the expected range; flag if off by orders of magnitude.
- Check every column dtype; coerce-or-drop mismatches before anything downstream (hand the coercion work to pandas-expert).
- List every column's null rate. Threshold: any column above 20% null gets an explicit handling decision in the log - no default treatment.… install to load the full skill