Skip to main content

Coming from Great Expectations

Goal​

You already have Great Expectations (GX) ExpectationSuites and you want to run them here without rebuilding them by hand. This page shows you how to export a suite from GX and import it onto a data asset — where every expectation becomes a rule on that asset.

Measured Cloud is built on Great Expectations 1.x. A rule here is a thin 1:1 wrapper over a GX expectation_type + kwargs, so an exported suite maps in directly: known expectation types become editable rules, and everything else still runs exactly as GX would.

Prereqs​

  • A data asset to import onto. The imported expectations become that asset's rules.
  • Workspace editor role or higher (importing edits the asset's rules).
  • An exported GX ExpectationSuite as JSON (see below).

Export your suite from Great Expectations​

From your GX project, serialise the suite to a dict and write it out:

import json
import great_expectations as gx

context = gx.get_context()
suite = context.suites.get("my_suite")          # GX 1.x
# suite = context.get_expectation_suite("my_suite")  # GX 0.x

with open("my_suite.json", "w") as f:
    json.dump(suite.to_json_dict(), f, indent=2)

A GX 1.x export looks like this:

{
  "name": "orders",
  "expectations": [
    { "type": "expect_column_values_to_not_be_null", "kwargs": { "column": "id" } },
    { "type": "expect_table_row_count_to_be_between", "kwargs": { "min_value": 1, "max_value": 1000000 } }
  ]
}

The importer is liberal in what it accepts, so you rarely have to reshape the file:

  • GX 1.x and 0.x key names both work. Each expectation's type may be under type (GX 1.x) or expectation_type (GX 0.x); the suite name may be name (GX 1.x) or expectation_suite_name (GX 0.x).
  • A bare list of expectations works too. If all you have is the expectations array, paste just that — [ {"type": "...", "kwargs": {...}}, ... ].
  • Extra top-level keys (meta, ge_cloud_id, …) are ignored.

Import it in the UI​

  1. Open the data asset you want the rules on → the Rules card.
  2. Click Import from GX.
  3. Paste the suite JSON into the box, or upload the .json file.
  4. Click Import.

The summary tells you exactly what happened:

  • Imported — every expectation was imported (nothing is silently dropped).
  • Form-editable — how many opened as editable rules in the form-builder.
  • Runs as-is — any expectation type the form-builder doesn't model still runs; it's listed so you know which ones you can't edit in the form.

The rules view refreshes with the imported rules. From there you edit, add, or run them like any other rule.

Import onto an asset with no rules. If the asset already has rules, the import returns a conflict rather than overwriting your work. Clear the asset's rules first if you genuinely mean to replace them.

What maps to editable rules vs. runs read-only​

Every expectation you import becomes a rule on the asset — one storage channel, so nothing is stored twice and nothing gets dropped when you next edit the rules.

  • Every expectation in the form-builder gallery — the column/table expectations you'd otherwise author by hand — opens as a form-editable rule.
  • Anything else (a custom expectation, a plugin, a type we don't yet model in the form) is imported as a rule that still runs, kept read-only in the editor ("Unknown rule type … — kept as-is"). It's listed under Runs as-is so you know which ones you can't edit in the form, and it's re-saved verbatim whenever you edit the rest of the suite — so editing your imported rules never un-runs the ones the form can't open.

That's the "adopt easily" contract — import → runs, and every imported expectation keeps running through subsequent edits.

Custom SQL and custom expectations​

  • UnexpectedRowsExpectation (raw-SQL GX expectations) import as Custom SQL rules and run. The query is validated on import exactly like a hand-authored Custom SQL rule: it must be a read query (SELECT / WITH), must use the {batch} placeholder for the asset's table, and must pass the same SQL-safety checks (no statement chaining, comments, or privileged built-ins). A query that fails those checks is rejected on import (a 422) rather than stored — importing is never a way around the safety checks the editor enforces. GX's unexpected_rows_query is mapped onto the unexpected_rows_expectation rule's query kwarg, so the imported check is form-editable like any Custom SQL rule.
  • Custom expectation plugins (your own expectation classes) import as read-only rules and run only if the validation engine can resolve the class; the built-in gallery covers the standard library. First-class per-tenant custom-expectation plugins are a separate, planned capability — see Custom expectation plugins.

Do it from the API​

The same import is available on the REST API — handy for a one-off migration script:

curl -X POST \
  -H "Authorization: Bearer dqk_…" \
  -H "Content-Type: application/json" \
  -d "{\"data\": $(cat my_suite.json)}" \
  https://dq.example.com/api/v1/organizations/<org_id>/workspaces/<ws_id>/data-assets/<asset_id>/rule-suites/import

The response is {"data": {data_asset_id, suite_id, imported_count, editable_count, unknown_types}} (suite_id is deprecated and always null: the imported expectations become the asset's rules). The /rule-suites/import path keeps its name, but it is not part of the retired rule-suite alias and still writes. See the API reference for the full contract (accepted body shapes, the 409 when the asset already has rules, and the rate limit).

Keep your GX runtime on-prem (agent mode)​

If your data sits behind a firewall, you don't have to move it to import your suites. Point the import at an agent-mode data asset: you author (and import) the rules in the cloud, but the on-prem agent runs Great Expectations against your database and only reports pass/fail back. Your data — and your GX runtime — stay on your side of the wall. See Agent mode for the architecture.

Verify​

  • The Rules card shows the imported rules, and the summary's Imported count matches your suite's expectation count.
  • Click Run now (or the asset's run control) — you get a fresh ValidationResult with the expected pass/fail outcomes, proving the imported suite runs.
  • Any type listed under Runs as-is appears in the validation result even though it isn't editable in the form.