dbt models & semantic layer
When a repository syncs, Zingle AI builds a rich catalog from your dbt project. This catalog is what makes the agents context-aware - they don't guess at your schema, they read it.
Models & columns
For every dbt model, Zingle AI stores:
- Its name, path, materialization, and description.
- Its columns, with dual provenance - a column can be discovered in the dbt manifest (declared in YAML), in the warehouse (present in the physical table), or both. This lets the UI show you where a column is defined versus where it actually exists.
- Its lineage - upstream and downstream dependencies, rendered as an interactive graph in the Data Explorer.
Semantic layer
If your project uses dbt's semantic layer, Zingle AI syncs the full definition:
| Object | Description |
|---|---|
| Semantic model | A semantic wrapper over a dbt model. |
| Entity | Join keys / grains (primary, foreign, unique). |
| Dimension | Attributes you slice by (categorical, time). |
| Measure | Aggregatable quantities. |
| Metric | Named, reusable calculations built from measures. |
Zingle's agents use the semantic layer to reason in business terms (metrics and dimensions) rather than requiring only raw table structures.
How agents use the catalog
- The Build agent looks up existing models to avoid duplication and to write changes consistent with your project's conventions.
- Refactor and Optimize analyze the whole model graph to find merge candidates, duplicates, layering violations, and optimization opportunities.
Explore all of this visually in the Data Explorer.