Apache-2.0 GX Core Python library for data quality Expectations, validation definitions, checkpoints, Data Docs, metadata stores, and pipeline quality checks.
Open the source and read safety notes before installing.
Source-backed facts for citing this resource, derived directly from the registry — also available as plain text for AI assistants.
Decision playbook
Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.
0
78
—
No baseline selected
No major trust-signal divergence detected in the current selection.
Confirm ownership and provenance before trusting install instructions.
Source link availableRequired
Open the canonical repository and verify ownership.
Source provenance statusRequired
Marked as source-backed.
Metadata reviewed
Registry metadata indicates a reviewed listing.
Validate risk disclosures before installation or API wiring.
Safety notes presentRequired
Review the listed safety guidance before running commands.
Privacy notes presentRequired
Review data handling notes before connecting accounts or secrets.
Trust level risk gateRequired
Trust level does not block evaluation.
Check package metadata and artifact integrity signals.
Install payload available
Install or copy payload is available for review.
Package verification flag
No package verification flag provided.
Checksum metadata
No checksum provided for downloaded artifact.
Use compare context to validate trade-offs before adoption.
Compare tray has multiple entries
Add at least one more entry to compare trust differences.
Baseline comparison available
No baseline peer selected yet.
Diverging trust signals identified
No major trust-signal divergence found.
Setup at a glance
Copy-ready — paste the snippet to get started.
Adoption plan
Current risk score 16/100. Use staged verification before broader rollout.
Validate source and review signals before any execution.
Confirm source provenanceRequired
Source URL/provenance metadata is present.
Confirm metadata review state
Listing has review metadata.
Verify install payload
Install/config payload exists and can be inspected.
Confirm safety, privacy, and package integrity signals.
Review safety notesRequired
Safety notes are present.
Review privacy notesRequired
Privacy notes are present.
Verify package integrity metadata
No package verification/checksum metadata.
Adopt in controlled steps based on the selected plan.
Run in isolated sandbox firstRequired
Use a constrained sandbox and observe behavior across multiple tasks.
Roll out graduallyRequired
Roll out to a small cohort before wider usage.
Set monitoring and fallback
Define rollback path and monitor errors after adoption.
Evidence readiness
Required evidence gates are covered (5/6 signals complete).
Source repository/provenance is listed.
Required in this preset
Review metadata is present.
Required in this preset
Safety notes are present.
Required in this preset
Privacy notes are present.
Optional in this preset
Package integrity metadata is missing.
Optional in this preset
Install payload is available.
Required in this preset
Required evidence gates are covered for this preset.
Decision timeline
5/6 steps complete with no blocking gaps for this preset.
triage
Source/provenance metadata is available.
triage
Review metadata is available.
verify
Safety notes are available.
verify
Privacy notes are available.
verify
Package integrity metadata is missing.
rollout
Install payload is available.
No required blockers for this timeline preset.
Prerequisite readiness
5 prerequisites to line up before setup. Have accounts and credentials ready first.
Safety & privacy surface
6 safety and 5 privacy notes across 8 risk areas. Review closely: credentials & tokens, permissions & scopes, network access.
Disclosure: editorial
## Editorial notes
Great Expectations is useful when Claude-adjacent teams need source-controlled data quality checks for pipelines, warehouses, files, notebooks, batch jobs, analytics handoffs, feature data, and evaluation datasets. It gives agents and developers a shared vocabulary for data quality Expectations, repeatable validation definitions, checkable results, generated Data Docs, and automation hooks that can fit into CI, orchestration, and data review workflows.
This entry covers the open-source GX Core library. It is distinct from dbt Core, DuckDB, Polars, Apache Airflow, and Dagster. dbt Core transforms warehouse data. DuckDB and Polars query or transform tabular data. Airflow schedules DAGs. Dagster orchestrates assets. Great Expectations focuses on declaring, running, storing, documenting, and responding to data quality validations.
## Source notes
- The official repository README describes GX Core as a package for data teams built around Expectations, which are expressive and extensible unit tests for data.
- The README says GX Core can automatically generate documentation for validation results and recommends installing `great_expectations` in a Python virtual environment.
- The README says GX Core supports Python 3.10 through 3.13 and points users to the compatibility reference for supported data sources and integrations.
- The compatibility reference lists supported GX Core integrations and data sources such as Amazon S3, Azure Blob Storage, BigQuery, Databricks SQL, Microsoft SQL Server, pandas, PostgreSQL, Snowflake, Spark, and SQLite, and says Windows is not currently supported.
- The introduction docs describe using the GX Core Python library and sample data to create a data validation workflow.
- The connect-to-data docs describe connecting to SQL databases, filesystem data, pandas DataFrames, and Spark DataFrames, then organizing data into Batches for validation.
- The run-validations docs describe validating Expectations against data, associating Batch Definitions with Expectation Suites through Validation Definitions, running Validation Definitions, and retrieving unexpected rows.
- The trigger-actions docs describe Checkpoints that automate responses to Validation Results, including alerts, Data Docs updates, and custom Actions.
- The credentials docs say credentials, tokens, and connection strings should be stored outside version control using environment variables, uncommitted config files, or supported cloud secrets managers.
- The Data Docs docs say Data Docs translate Expectations, Validation Results, and other metadata into human-readable static web pages that can be built manually or updated by Checkpoint Actions.
- The metadata-store docs say Stores persist project metadata including Expectation Suite configurations, Validation Definitions, Checkpoints, Validation Results, and Suite Parameters.
- The analytics docs say Great Expectations tracks analytics events by default and describes disabling collection with `GX_ANALYTICS_ENABLED` or `analytics_enabled`.
- The repository is `great-expectations/great_expectations`, is Apache-2.0 licensed, and is active.
## Duplicate check
Checked current `content/tools/`, `content/mcp/`, agents, hooks, rules, skills, commands, guides, collections, open pull requests, live issue state, and repository-wide content for `Great Expectations`, `GX Core`, `great_expectations`, `great-expectations`, `github.com/great-expectations/great_expectations`, `docs.greatexpectations.io`, and `greatexpectations.io`. Existing mentions appear only inside a data pipeline engineering agent and a data engineering collection; no dedicated Great Expectations tools entry, source URL duplicate, target file, issue duplicate, or open duplicate PR was found.
## Disclosure
Editorial listing. No paid placement or affiliate link is used. GX Core is Apache-2.0 open-source software; GX Cloud, data warehouses, cloud storage, databases, notebooks, orchestrators, notification services, secrets managers, and downstream documentation hosts may have separate licenses, billing, terms, privacy obligations, and access controls.Great Expectations is useful when Claude-adjacent teams need source-controlled data quality checks for pipelines, warehouses, files, notebooks, batch jobs, analytics handoffs, feature data, and evaluation datasets. It gives agents and developers a shared vocabulary for data quality Expectations, repeatable validation definitions, checkable results, generated Data Docs, and automation hooks that can fit into CI, orchestration, and data review workflows.
This entry covers the open-source GX Core library. It is distinct from dbt Core, DuckDB, Polars, Apache Airflow, and Dagster. dbt Core transforms warehouse data. DuckDB and Polars query or transform tabular data. Airflow schedules DAGs. Dagster orchestrates assets. Great Expectations focuses on declaring, running, storing, documenting, and responding to data quality validations.
great_expectations in a Python virtual environment.GX_ANALYTICS_ENABLED or analytics_enabled.great-expectations/great_expectations, is Apache-2.0 licensed, and is active.Checked current content/tools/, content/mcp/, agents, hooks, rules, skills, commands, guides, collections, open pull requests, live issue state, and repository-wide content for Great Expectations, GX Core, great_expectations, great-expectations, github.com/great-expectations/great_expectations, docs.greatexpectations.io, and greatexpectations.io. Existing mentions appear only inside a data pipeline engineering agent and a data engineering collection; no dedicated Great Expectations tools entry, source URL duplicate, target file, issue duplicate, or open duplicate PR was found.
Editorial listing. No paid placement or affiliate link is used. GX Core is Apache-2.0 open-source software; GX Cloud, data warehouses, cloud storage, databases, notebooks, orchestrators, notification services, secrets managers, and downstream documentation hosts may have separate licenses, billing, terms, privacy obligations, and access controls.
Show that Great Expectations is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.
[](https://heyclau.de/entry/tools/great-expectations)Great Expectations side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.
| Field | Apache-2.0 GX Core Python library for data quality Expectations, validation definitions, checkpoints, Data Docs, metadata stores, and pipeline quality checks. Open dossier | Apache-2.0 dbt engine for transforming warehouse data with SQL models, Jinja, YAML configs, tests, documentation, lineage, metadata, and build artifacts. Open dossier | MIT-licensed embedded analytical SQL database for local OLAP workloads, data files, notebooks, Python and R clients, extensions, and single-file analytics workflows. Open dossier | Apache-2.0 Python workflow orchestration framework for resilient data pipelines with flows, tasks, deployments, schedules, retries, caching, workers, work pools, and observability. Open dossier |
|---|---|---|---|---|
| Next steps | ||||
| Trust | ||||
| Review status | ReviewedMaintainer reviewed | ReviewedMaintainer reviewed | ReviewedMaintainer reviewed | ReviewedMaintainer reviewed |
| Package trust | Package not verified | Package not verified | Package not verified | Package not verified |
| Source provenance | Source-backed | Source-backed | Source-backed | Source-backed |
| Submitter | oktofeesh1 | oktofeesh1 | oktofeesh1 | oktofeesh1 |
| Install risk | Review first | Review first | Review first | Review first |
| Notes | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ |
| Brand | ||||
| Category | tools | tools | tools | tools |
| Source | Source-backed | Source-backed | Source-backed | Source-backed |
| Author | Great Expectations | dbt Labs | DuckDB Foundation | Prefect |
| Added | 2026-06-04 | 2026-06-04 | 2026-06-04 | 2026-06-04 |
| Platforms | ||||
| Harness | ||||
| Source repo | — | — | — | — |
| Safety notes | ✓GX Core validations can query databases, scan files, evaluate DataFrames, and compute metrics over real datasets, so production runs should use scoped credentials, tested queries, and bounded resources. Checkpoints can trigger Actions such as updating Data Docs, sending notifications, or running custom logic based on Validation Results; notification endpoints and custom Actions should be reviewed before automation. Data Docs generate static human-readable documentation from Expectations, Validation Results, and metadata, so hosted sites and generated folders need access controls before they include sensitive details. Result formats and unexpected-row retrieval can expose row-level failures or sample values; teams should tune result verbosity before publishing results to logs, tickets, chat, or docs sites. Custom Expectations, custom Actions, SQL-based custom Expectations, and orchestration integrations run team-provided code or queries and should be treated as trusted project code. GX Core compatibility depends on Python, data source, integration, and optional dependency support, so upgrades should be tested against the compatibility reference and existing validation suites. | ✓dbt runs transformation SQL against a data platform and can create, replace, or mutate warehouse objects, so development and production targets should be separated and permissioned carefully. The current `dbt-labs/dbt-core` README warns that `main` hosts dbt Core v2.0 alpha, that behavior, APIs, and on-disk formats may change, and that dbt Core v1 development has moved to `1.latest`. Version, adapter, package, and artifact compatibility should be pinned and tested before upgrading shared projects or production jobs. Model tests, contracts, lineage, and documentation improve confidence, but they do not replace data review, access controls, warehouse governance, freshness checks, or incident response. Threads, full refreshes, incremental logic, and CI jobs can consume warehouse budget or lock shared resources; teams should set concurrency, timeout, and rollback expectations before broad automation. Profile files and environment variables can contain sensitive warehouse credentials, so `profiles.yml` should stay out of git, logs, generated docs, screenshots, and shared support artifacts. | ✓DuckDB SQL should be treated like executable code because queries can read and write files, access network resources through extensions, load extensions, consume system resources, and mutate attached databases. Applications that accept user-controlled SQL, file paths, table names, filter expressions, or data-source settings need sandboxing and allowlists rather than passing those values directly into DuckDB operations. Extensions run with the same privileges as the DuckDB process, and community extensions should only be installed from trusted sources after reviewing their maintenance and distribution path. Statements such as `ATTACH`, `COPY`, `EXPORT DATABASE`, `CREATE SECRET`, `INSERT`, `UPDATE`, and `DELETE` can change local files, databases, or connected services when permissions allow it. Analytical queries can use substantial CPU, memory, temporary disk, and object-store bandwidth, so shared automations should configure memory, thread, timeout, temp-directory, and retry expectations. Persistent database files and write-ahead logs need backups, file permissions, and recovery procedures before DuckDB is used for durable or production-adjacent analytical state. | ✓Prefect flows and tasks run arbitrary Python code and can query databases, mutate files, call APIs, launch subprocesses, provision infrastructure, and trigger downstream jobs, so workflows should be treated as trusted production code. Retries, schedules, event triggers, deployment runs, backfills, and automations can repeat side effects unless tasks are idempotent and external writes are guarded. Work pools and workers can start subprocesses, containers, Kubernetes jobs, or cloud jobs; base job templates, queue limits, worker permissions, and infrastructure credentials should be scoped tightly. Flow and task timeouts help prevent unintentional long-running work, but teams still need resource limits, cancellation behavior, and cleanup policies for jobs that touch external systems. Blocks can store credentials and typed configuration for external services; SecretStr fields are encrypted and hidden by default in the UI, but credentials still need rotation, least privilege, and environment separation. Logging can capture custom logs, print statements, subprocess output, thread output, task parameters, and exception details; secrets and sensitive rows should not be printed or attached to artifacts. Self-hosted Prefect servers should use authentication, reverse proxy controls, CSRF protection, CORS policy, and secure custom-header handling before being exposed beyond a trusted network. Prefect Cloud, webhooks, automations, notifications, and external integrations can trigger or observe workflow activity and should be reviewed for permissions, rate limits, and incident response behavior. |
| Privacy notes | ✓GX Core workflows can process source data, schemas, table names, file paths, SQL queries, Batch metadata, Expectation Suites, Validation Results, Checkpoints, Actions, Data Docs, and generated stores. The credentials docs say tokens and connection strings should be stored securely outside version control, using environment variables, uncommitted config files, or supported secrets managers. File Data Context Stores can persist Expectation Suites, Validation Definitions, Checkpoints, Validation Results, and Suite Parameters in project folders or configured backends. Data Docs are static web pages generated from Expectations, Validation Results, and metadata; publishing them can disclose validation outcomes, column names, dataset structure, and failing examples. GX Core tracks analytics events by default, including feature usage, operating system, and Python version, and the docs describe disabling collection with `GX_ANALYTICS_ENABLED` or `analytics_enabled`. | ✓dbt workflows can process SQL models, Jinja macros, YAML configs, sources, tests, seeds, snapshots, metrics, exposures, connection profiles, warehouse relation names, logs, and generated artifacts. Command output and `logs/dbt.log` can include invocation arguments, runtime context, thread names, node metadata, warehouse relation identifiers, errors, and other debugging details. dbt artifacts are written to the project's `target/` directory by default and may include manifests, run results, catalogs, source freshness output, semantic manifests, invocation IDs, adapter types, project metadata, and selected environment metadata. The artifacts docs say environment variables prefixed with `DBT_ENV_CUSTOM_ENV_` can be included in artifact metadata, so teams should avoid placing secrets in those variables. The usage-stats docs say dbt telemetry is enabled by default and does not track credentials, raw model contents, or model names; dbt Core users can opt out by setting `send_anonymous_usage_stats` to false or `DO_NOT_TRACK=1`. | ✓DuckDB workflows can process local files, database files, notebooks, query text, table names, column names, object-store paths, data-frame contents, connection strings, secrets, extensions, and generated result sets. The files-created docs describe global files such as `~/.duckdb_history`, extension directories, and stored persistent secrets, so users should avoid typing credentials or sensitive data into ad hoc SQL history. Persistent secrets are stored under DuckDB's configured secret directory, and `duckdb_secrets()` redacts sensitive fields by default; enabling unredacted secret output is unsafe with untrusted SQL. On-disk databases can create database files, write-ahead logs, and temporary directories next to the database file or working directory, depending on connection mode and configuration. HTTP, S3, and other external-data workflows can expose object-store identifiers, paths, credentials, request metadata, and result data to the connected service and any configured logs or monitoring. | ✓Prefect workflows can process flow parameters, task inputs and outputs, cached results, state history, run metadata, logs, artifacts, events, schedules, deployments, work-pool data, block documents, and infrastructure job variables. Logs and captured print statements can disclose SQL queries, file paths, data samples, credentials, API responses, exception traces, and environment details if workflow code does not redact them. Blocks, variables, settings, profiles, and environment variables can contain cloud credentials, database credentials, Docker registry credentials, Git credentials, Slack webhooks, Snowflake credentials, and other integration secrets. Prefect server or Prefect Cloud stores orchestration metadata used for monitoring, retries, states, automations, alerts, and dashboards; teams should review retention, access controls, workspace boundaries, and export requirements. Workers running in local, Docker, Kubernetes, serverless, or managed infrastructure may expose environment variables, mounted files, network metadata, container images, and cloud identity details to the execution environment. Automations, webhooks, notifications, and integrations can forward run metadata, event payloads, failure details, and parameters to chat tools, incident systems, APIs, or downstream services. |
| Prerequisites |
|
|
|
|
| Install | — | — | — | — |
| Config | — | — | — | — |
| Citations | ||||
| Claim | Unclaimed | Unclaimed | Unclaimed | Unclaimed |
Transform warehouse data with SQL models, tests, docs, lineage, and artifacts.
Run embedded analytical SQL over local files, data frames, and DuckDB databases.
Source-backed guides for putting this to work.
Loading live community signals…
A short, calm digest of reviewed Claude resources. Unsubscribe any time.