What this prompt does
This prompt asks the model to specify a Great Expectations test suite tight enough to drop straight into CI, not a vague checklist. You provide [table], [warehouse], [primary_key], and [freshness], and it returns a JSON expectation suite covering schema, nulls, uniqueness, value ranges, foreign keys, regex patterns, and drift -- each expectation annotated with what it protects against.
The structure works because it maps each common data-quality failure to a specific expectation. [primary_key] drives the uniqueness checks and the foreign-key existence tests against parent tables. [freshness] anchors the row-count-vs-prior-run guard and the distribution-drift expectation, so the suite knows what "recent" means. [table] and [warehouse] ground the schema and type checks in the real columns. By demanding a one-line note per expectation, the prompt produces a suite a reviewer can reason about instead of a wall of opaque rules, which is what keeps the checks maintained over time rather than ignored.
When to use it
- A table feeds something a customer sees and you want quality gates before it ships.
- You need schema, null, uniqueness, and range checks generated as a real GE suite.
- You want foreign-key existence checks against parent tables written for you.
- You need a row-count-vs-prior-run guard to catch partial or doubled loads.
- You want distribution-drift detection tied to a freshness window.
- You're wiring data quality into CI and need JSON you can commit, not a checklist.
- You want regex pattern checks on formatted string columns to catch malformed values.
Example output
You get the JSON expectation suite -- schema and type checks, non-null expectations on business-critical columns, uniqueness on the primary key and natural keys, value-range and allowed-set rules, foreign-key checks, regex patterns, and a drift expectation -- with a one-line doc note beside each explaining what it guards against. It's structured to drop into a Great Expectations checkpoint and run in CI without you having to hand-author each rule from scratch.
Pro tips
- Name the real
[primary_key](order_id) so the uniqueness and FK checks key on the right column. - Set
[freshness]to your actual load cadence (last 24 hours) so the row-count guard and drift check use a sensible window. - Make
[table]and[warehouse]specific so the schema and type expectations match what's really deployed. - Wire the suite into CI so a bad load fails loud instead of leaking downstream into a dashboard nobody re-checks.
- Ask the model to flag which columns are business-critical so non-null checks land where they matter, not on every field.
- Tune allowed-set and range expectations to your data; over-tight ranges cause false alarms that erode trust in the suite.
- Add regex pattern checks on string columns that follow a known format so malformed values fail the suite early.
