Your dbt Core semantic layer defines the metric. KPI Tree explains the movement, names the owner and proves the fix.

No. KPI Tree reads semantic_manifest.json from your dbt Core project and renders the metric SQL itself with an in-process MetricFlow engine, so there is no dbt Cloud account, Semantic Layer API or service token in the path. If you later move to dbt Cloud, the dbt Cloud integration connects through the Semantic Layer API instead.

dbt Core 1.6 onwards, which is when MetricFlow and the semantic manifest arrived. KPI Tree reads both manifest shapes: the measures-based spec from dbt Core 1.6 to 1.11 and the modernised spec from 1.12 onwards, where simple metrics replace measures. The manifest is what MetricFlow itself reads, so the connection follows your project through the spec migration.

On your own warehouse. A dbt Core connection holds definitions and never executes anything itself. KPI Tree renders each metric as MetricFlow SQL in the dialect of the linked warehouse and runs one aggregation query per metric at day grain. Period comparisons, weekly and monthly rollups, dimension breakdowns and the nightly correlation and causality tests are all computed in KPI Tree’s own in-memory engine from those results.

Snowflake, BigQuery, Databricks, Redshift and PostgreSQL. The linked connection should point at the database and schema your dbt models build into. Azure SQL and Google Sheets connections cannot be linked to a dbt Core connection.

Four ways, shown as tabs in the connection wizard: upload the file or a ZIP of the target directory in the browser, post it with curl, run the Python script the wizard provides, or commit the GitHub Actions workflow it generates. The workflow runs dbt build on every push to main and posts the artifacts with an API key scoped to semantic layer uploads. Every upload starts a sync automatically. Artifacts and ZIPs can be up to 50 MB each.

Each upload is compared with the previous one and the sync report lists what was created, updated, retired and skipped. New metrics appear, edited definitions update in place, and metrics removed from the project or deselected for sync are retired rather than deleted, with their history and recorded context kept. Trees, ownership and action history are preserved. A metric whose name changes in dbt is treated as a new metric.

Simple, ratio, cumulative, derived and conversion metrics, as long as the metric can be queried at day grain. Metrics defined only at weekly or coarser grains are listed as skipped in the sync report rather than guessed at. Every other grain, from week to quarter, is computed by KPI Tree from the daily series.

It reads the aggregation from the definition first: sum, count, average, min and max map straight from the measure, a ratio or cumulative metric rolls up as its last value, and a non-additive dimension marks a stock that takes its first or last value. Where the definition leaves it open, the metric type and name decide, and the sync report says which rollups were declared and which were inferred. To settle it yourself, add meta.kpi_tree.aggregation to the metric or measure in your YAML and the derivation never overrides it.

Yes. The Metrics tab lists every metric in the manifest and you choose the dimensions for each one. KPI Tree probes the distinct values of a chosen dimension on your warehouse and creates a child metric per value, so Revenue with a Region dimension gains a node for each region with its own owner and tracking. The default limit is 15 values per dimension, adjustable between 2 and 200 at connection, dimension or metric level, and any dimension above its limit is skipped with the reason shown in the sync report.

manifest.json brings model lineage, so every metric can be traced to the models and sources that produce it, in the app and over MCP. catalog.json adds every warehouse column with its real data type. run_results.json records each model’s last build status and timing and works out how often each metric’s data refreshes. sources.json adds source freshness, so a metric whose upstream source has gone stale says so on the metric itself. Only semantic_manifest.json is required.

Not at present. KPI Tree syncs the metrics themselves and you choose dimensions per metric, so saved queries are not imported. Exports land as tables in your warehouse, and an export table can be tracked as a SQL metric on the warehouse connection. dbt tests and exposures are not read, and lineage is kept at model level rather than column level.

No. The connection reads a manifest and runs SELECT statements with scoped, read-only credentials. Nothing is written back to the project, no jobs are triggered and no models are touched.

The dbt Semantic Layer is the successor to the dbt metrics layer. It keeps the idea of metrics defined once in YAML and adds semantic models, entities and MetricFlow, which compiles the SQL. KPI Tree reads the semantic manifest MetricFlow produces, so it works with the current spec rather than the retired metrics package.

Yes. Each dbt project is its own connection with its own manifest, and metrics from several projects sit on the same tree with their own calculation sources. The tree carries the drivers, owners, targets and actions across them.

Yes. Metrics from several dbt projects, from Snowflake Semantic Views or Databricks Unity Catalog, from SQL on a warehouse connection and from spreadsheets all sit on the same tree. Each keeps its own calculation source while the tree carries the drivers, owners, targets and actions across them.

Through Canopy, KPI Tree’s business context layer, over MCP. An assistant such as Claude, ChatGPT, Gemini or Copilot can analyse a metric with its drivers, owners and recorded context, explore the dbt data model behind it, see the last build and source freshness, and, with editor access, run read-only queries on the linked warehouse to test an explanation.

Use this one if you run dbt Core without dbt Cloud, or if you want the SQL to run on your own warehouse with no dbt Cloud usage. If you have a dbt platform plan with the Semantic Layer, the dbt Cloud integration reads your catalogue live through the Semantic Layer API with no uploads.