Skip to main content
The armor migrate-from great-expectations command ships today as a deliberate stub. This page documents what exists, why it is a stub, and how to migrate manually in the meantime. If you want this adapter prioritized, open a support ticket with a representative copy of your GE project layout. The adapter is demand-gated on verifying the modern GE config surface against a real project.

​
Current state

Running the command returns an ODCS skeleton with zero mapped items and a single warning: 
$ armor migrate-from great-expectations ./great_expectations/
great-expectations -> ODCS (./great_expectations/): mapped 0, warnings 1 (...).
Nothing mapped — refusing to emit an empty contract.
The command exits non-zero on purpose so a pipe like migrate-from great-expectations ... | contract apply -f - fails cleanly instead of feeding an empty document into your live asset.

​
Why a stub

Great Expectations went through a significant config-surface change with its v1 release. Fluent Datasources moved away from the purely file-based great_expectations.yml tree that earlier versions relied on. A naive file-walker (like the dbt adapter) would map the pre-v1 layout correctly but ship silently-wrong output against a modern project, which is worse than no adapter. The concrete work to turn this into a real adapter, once demand pulls it forward:
  1. Inventory a modern GE v1 project’s on-disk layout. Fluent Datasources do not necessarily leave JSON expectation suites under expectations/ the way pre-v1 projects did.
  2. Decide between scanning the on-disk tree or calling the GE Python API to enumerate the Data Context’s suites. The API is more reliable across releases but adds a great_expectations runtime dependency. The file scan is zero-dep but brittle.
  3. Map the subset of GE expectations that correspond 1:1 to AnomalyArmor validity rules. The obvious candidates:
    • expect_column_values_to_not_be_null -> not_null
    • expect_column_values_to_be_in_set -> allowed_values
    • expect_column_values_to_match_regex -> regex_match
  4. Warn on every GE expectation without a native AA equivalent. The adapter will not try to emulate them via custom SQL automatically, that is a larger design call that belongs in a follow-up.

​
Manual migration today

For now the migration path is manual. It is straightforward if your expectation coverage is small.
  1. For every table you monitor in GE, identify the underlying AnomalyArmor asset. Use armor assets list if you need to look up the asset UUID.
  2. Export the current AnomalyArmor config for that asset as a starting template: 
    armor contract pull --asset <asset-uuid> -o orders.yaml
  3. Open orders.yaml and add a customProperties.anomalyarmor.validity entry for each expectation you want to port. The Data Contracts guide documents the validity-rule shape.
  4. Validate and apply: 
    armor contract validate -f orders.yaml
armor contract plan --asset <asset-uuid> -f orders.yaml
armor contract apply --asset <asset-uuid> -f orders.yaml
For expectations that do not have a native AA equivalent (range checks, referential checks, custom evaluators), author them as custom SQL checks in AnomalyArmor rather than trying to force them through the validity rule shape.

​
See also