## TL;DR
Your first GX suite should be tiny: 5 to 8 expectations on your most important table, checking the things that would page you if they broke (keys not null, IDs unique, row counts sane, values in range). Scaffold it with the CLI, add expectations in a notebook or Python script, then run it on a schedule via a checkpoint. A small suite that runs daily beats a 200-expectation suite nobody maintains.

## The query
```
great expectations first suite setup
```

## Use this when
- you have one critical table and zero data quality checks on it
- you want failing-data alerts before downstream consumers notice
- a data agent needs a contract to validate its own outputs against

## Not for
- replacing dbt tests if your stack is already dbt-native (use dbt tests there)
- full data profiling or one-off exploration (use the profiler for that, then keep only what matters)
- real-time streaming validation (GX checkpoints are batch-oriented)

## Steps
1. Install and initialize. `pip install great_expectations`, then `great_expectations init` in your project directory to create the `gx/` config folder.
Expected output: `gx/great_expectations.yml` exists and `great_expectations suite list` runs without errors.

2. Connect your data. Add a datasource for your warehouse or files (the docs have per-backend snippets; Postgres and file-based CSV are the simplest starts).
Expected output: `great_expectations datasource list` shows your new datasource.

3. Create the suite and add expectations that catch real breakage. Start with these five on the key table: `expect_column_values_to_not_be_null` on the primary key, `expect_column_values_to_be_unique` on it, `expect_table_row_count_to_be_between` with a sane band, `expect_column_values_to_be_between` on the main metric, `expect_column_values_to_be_in_set` on the status column.
Expected output: `suite.json` contains your expectations and reads like a plain-English contract.

4. Build a checkpoint that runs the suite against the table. A checkpoint is just the runnable wrapper: which suite, which data, where results go.
Expected output: `great_expectations checkpoint run my_checkpoint` prints a validation result with success true or false.

5. Schedule the checkpoint (cron, Airflow, whatever you already run) and point the action list at your alerting channel so failures notify a human.
Expected output: a deliberately broken expectation (e.g. a wrong row-count band) produces a failing validation and an alert, proving the loop works end to end.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_3cmwtUjSZ0zlatYzOq9mlw