Try dbt on CoreModels

Step 1 of 4

Import

CoreModels reads the manifest and the catalog of the jaffle_shop sample. You send no warehouse credentials.

import_vendor_project
  vendor:   dbt
  manifest: manifest.json   (jaffle_shop, dbt 1.4.1)
  catalog:  catalog.json

8

datasets added

39

columns governed

8

lineage edges added

47

nodes enriched

• customers · customer_id, first_name, last_name, first_order, most_recent_order, number_of_orders, total_order_amount
• orders · order_id, customer_id, order_date, status, amount, credit_card_amount, coupon_amount, bank_transfer_amount, gift_card_amount
• stg_customers · customer_id
• stg_orders · order_id, status
• stg_payments · payment_id, payment_method

One note from the import: model.jaffle_shop.customers.total_order_amount has no declared type in the sample. CoreModels stored it as String and kept the original in the vendor metadata.

Result: real output of import_vendor_project. The list of models and columns is read from the sample manifest.

Step 2 of 4

Drift audit

A teammate opens a pull request. It renames one column: stg_payments.payment_method becomes method. CoreModels audits the changed manifest against the governed model.

audit_vendor_project
  vendor:   dbt
  manifest: manifest.json   (pull request version)
  catalog:  catalog.json    (pull request version)

1

errors

2

warnings

6

info

Coverage · Info

field-unmapped on model.jaffle_shop.stg_payments.method

Field is not represented on the governed dataset (added since the last import).

Drift · Error

field-removed on model.jaffle_shop.stg_payments.payment_method

Field is governed in CoreModels but no longer exists on the estate dataset.

The same audit on the unchanged manifest reports 0 errors and no drift. An error count above 0 is the signal a CI check can fail on.

Result: real output of audit_vendor_project. Findings of the Drift and Coverage kinds are shown.

Step 3 of 4

What breaks

Which parts of the project depend on stg_payments.payment_method? Two sources answer this, and the labels below say which is which.

From CoreModels

Element 'payment_method': 2 vendor contract(s), 2 governed usage(s), 0 external binding(s).

• Used by type 'stg_payments'.
• Values come from vocabulary 'stg_payments payment_method values'.

Real output of analyze_concept_impact for this column. It covers the governed model and the dbt contracts that carry the column.

Read from the manifest

customers depends on stg_payments.

Its SQL does not name payment_method, so it keeps working.

orders depends on stg_payments. Its SQL names payment_method, so it breaks.

The accepted_values test on stg_payments.payment_method has no column to test.

Read from the jaffle_shop manifest: child_map of stg_payments, and a word search of each downstream model's SQL for the column name. Not computed by CoreModels.

Step 4 of 4

Contract

CoreModels writes the contract for the model from the governed definition. Your engineers review it like any other change to the repo.

Early access: in the product, we set it up with youmodels/coremodels_contracts.yml

# Generated by CoreModels — governed model contracts.
# Meaning changes belong in CoreModels; regenerate this file rather than editing it.
version: 2

models:
  - name: stg_payments
    config:
      contract:
        enforced: true
      materialized: view
    meta:
      coremodels:
        maps_to:
          - standard: "dbt"
            uri: "model.jaffle_shop.stg_payments"
    columns:
      - name: order_id
        description: "[dbt: model.jaffle_shop.stg_payments.order_id]"
        data_type: INT64
        meta:
          coremodels:
            maps_to:
              - standard: "dbt"
                uri: "model.jaffle_shop.stg_payments.order_id"
      - name: payment_method
        description: "[dbt: model.jaffle_shop.stg_payments.payment_method]"
        data_type: STRING
        data_tests:
          - accepted_values:
              values: ["credit_card", "coupon", "bank_transfer", "gift_card"]
        meta:
          coremodels:
            maps_to:
              - standard: "dbt"
                uri: "model.jaffle_shop.stg_payments.payment_method"
            vocabulary: "stg_payments payment_method values"
            vocabulary_maps_to:
              - standard: "dbt"
                uri: "model.jaffle_shop.stg_payments.payment_method#values"
      - name: amount
        description: "[dbt: model.jaffle_shop.stg_payments.amount]"
        data_type: FLOAT64
        meta:
          coremodels:
            maps_to:
              - standard: "dbt"
                uri: "model.jaffle_shop.stg_payments.amount"
      - name: payment_id
        description: "[dbt: model.jaffle_shop.stg_payments.payment_id]"
        data_type: INT64
        constraints:
          - type: not_null
        data_tests:
          - unique
          - not_null
        meta:
          coremodels:
            maps_to:
              - standard: "dbt"
                uri: "model.jaffle_shop.stg_payments.payment_id"

The contract keeps the governed name payment_method and sets enforced: true. dbt checks the columns of the model against it when the model builds.

Note from CoreModels: This model already has properties in 'models/staging/schema.yml'. Remove its block there, or dbt will report a duplicate patch for the generated 'models/coremodels_contracts.yml'.

Result: real output of generate_vendor_artifacts for stg_payments. CoreModels never writes to your repo.

Run these steps on your own project

Import your manifest, audit the next pull request, and see what breaks before it merges.

Start building

Every plan starts with a 14-day free trial; nothing is charged during the trial. By starting you agree to the Terms of Service and Privacy Policy. Payment is taken by Ariesnet, Inc. under Schematica.

Results from running CoreModels on the jaffle_shop sample, captured 2026-10-13. The sample is the public dbt Labs jaffle_shop project, as published in the test files of yu-iskw/dbt-artifacts-parser-ts. The Run buttons on these steps show saved results captured from CoreModels on the sample.