dbt Variables

This guide describes Tuva Core v1.0.0. Set Tuva vars under the vars: key in the consuming connector/root project's dbt_project.yml. Tuva Core keeps a small set of package-level vars for domain enablement, data asset storage, schema naming, runtime metadata, and local synthetic-data validation.

The most complete commented example lives in integration_tests/dbt_project.yml. That project sets development defaults for synthetic builds; the Tuva Core root package keeps optional model families disabled and configures data asset storage and tuva_last_run.

Core boolean switches must be native, unquoted YAML true or false. This applies to the domain and Data Quality switches below, parity_enabled, and use_coderx_enterprise. Strings such as "false" are rejected. A direct env_var() returns a string; environment-driven jobs must generate typed YAML or JSON before invoking dbt. For example, dbt build --vars '{"claims_enabled": true, "clinical_enabled": false}' supplies native booleans.

Installing a standalone package enables its models. Retired tuva_marts_enabled, tuva_core_enabled, and package-level enablement switches do not control the 1.0 package graph. Use each package's documented configuration after installing its Git tag alongside Core in the root project.

Domain Enablement

These vars enable the major Tuva Core domains. They default to false in the package when omitted. integration_tests/dbt_project.yml enables claims, clinical, and provider attribution so local builds exercise the full Core path, while keeping the optional data quality models disabled.

Variable	Package Default	integration_tests Default	Description
claims_enabled	false	true	Enables payer/claims input layer, normalization, claims preprocessing, and claims-derived core tables.
clinical_enabled	false	true	Enables provider/clinical input layer, normalization, and clinical-derived core tables.
provider_attribution_enabled	false	true	Enables provider attribution input and claims preprocessing attribution. Requires claims_enabled.
data_quality_enabled	false	false	Enables queryable Structural and Logical Data Quality results.
enable_data_quality_failure_keys	false	false	Enables optional logical failure key output. Requires data_quality_enabled: true and at least one enabled claims or clinical domain.

Parity

parity_enabled defaults to false. With claims enabled, it builds opt-in metric outputs for comparisons against an immutable prior version. It is separate from Data Quality and does not itself execute a baseline or decide whether an upgrade passes. See the 1.0 upgrade validation steps.

Runtime And Schema

Variable	Default	Description
tuva_last_run	Current UTC dbt run_started_at	Populates the tuva_last_run column in Tuva Core output models.
tuva_schema_prefix	unset	Prefixes Tuva output schemas, for example dev_core, dev_input_layer, and dev_data_quality.
provider_attribution_as_of_date	unset	Optional YYYY-MM-DD override for provider attribution current-state calculations.
passthrough	{}	Global column-extension mapping. Its only accepted keys are prefix (default x_) and strip (default false); unknown keys fail compilation. See the guide for supported table pairs and validation rules.

Medication Terminology

Variable	Default	Description
use_coderx_enterprise	false	Selects the shared CodeRx interface. false uses the package's CodeRx Open assets. true makes every CodeRx consumer read user-managed packages, drugs, and classes relations from the target database's coderx schema.

Set use_coderx_enterprise: true only after all three Enterprise relations are available. The switch applies consistently to pharmacy normalization, medication enrichment, Data Quality, and dependent packages; unmatched values do not fall back to the bundled Open assets.

vars:
  use_coderx_enterprise: true

Seed Loading

Tuva Core resolves one complete data-asset snapshot from tuva-core/<data-asset-version>/, such as tuva-core/1.0.0/. The package code version and data-asset version are intentionally independent. Tuva Core sets a tested default, and maintainers coordinate the two versions when either one changes. Use dbt build on a fresh installation so seeds, models, unit tests, and data tests run in dependency order. dbt run does not load seeds or execute tests.

Variable	Default	Description
tuva_core_data_asset_version	1.0.0	Complete Tuva Core data-asset snapshot loaded from tuva-core/<version>/. Do not use separate terminology, value-set, provider-data, or synthetic-data versions.
custom_bucket_name	tuva-public-resources	Default public bucket for versioned Tuva seed artifacts.
tuva_seed_fabric_storage_root	https://tuvapublicresources.blob.core.windows.net	Microsoft Fabric storage endpoint used by seed loading macros.

The public snapshot also contains _manifest.json and _release.json, but dbt does not read either file. The loader uses only the configured bucket and versioned path.

Synthetic Data

These settings describe the Core integration_tests project. They are not needed in a normal project that maps its own source data to the Input Layer.

Variable	Default	Description
synthetic_data_size	small in integration_tests, large in seed path fallback	Selects the small or large synthetic input payload.

The 1.0 integration project always maps the package synthetic seeds; it has no use_synthetic_data switch. A connector for real data supplies its own Input Layer mappings.

Diagnostics

When selected, metadata.tuva_invocations is a one-row table for the invocation that built it. Normal table builds replace the prior row. It records the package version, root project, target, adapter, command, run_started_at, and tuva_last_run; it does not contain completion time, run status, or an append-only history. Use dbt artifacts and your orchestrator for execution history and success/failure status.

Maintainer-Only Settings

The commented integration project also inventories loader endpoints, Logical Data Quality chunking, and internal unit-test overrides. Those are implementation and validation settings, not routine connector configuration. Do not set _extension_columns_override or other internal test hooks in a normal project. See the warehouse guide for adapter-specific guidance.

Example Core Config

vars:
  claims_enabled: true
  clinical_enabled: true
  provider_attribution_enabled: true
  data_quality_enabled: true

For local development with package synthetic data, use the commented defaults in integration_tests/dbt_project.yml.