--- title: "Playground" slug: "playground" type: page locale: en-US canonical: "https://www.coremodels.io/playground" updatedAt: "2026-10-23T10:44:32Z" --- # Playground ## Try dbt on CoreModels Four steps on a public sample project. You need no account. Each step shows what CoreModels returned when we ran it. 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 you`models/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](/start) Every plan starts with a 14-day free trial; nothing is charged during the trial. By starting you agree to the [Terms of Service](/legal/terms) and [Privacy Policy](/legal/privacy). 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](https://raw.githubusercontent.com/yu-iskw/dbt-artifacts-parser-ts/main/packages/dbt-artifacts-parser/resources/manifest/v8/jaffle_shop/manifest.json). The Run buttons on these steps show saved results captured from CoreModels on the sample.