dbt Cloud integration

Your dbt Cloud Semantic Layer defines the metric. KPI Tree explains the movement, names the owner and proves the fix.

Q: Which dbt plans support this integration?

Any dbt platform plan that includes the Semantic Layer API: Starter, Enterprise and Enterprise+. The Developer plan does not expose the API. If you run dbt Core without dbt Cloud, use the dbt Core integration, which needs no dbt Cloud account at all.

Q: What permissions does the service token need?

The Semantic Layer Only and Metadata Only permission sets, both of which are read-only. Create the token in dbt Cloud under account settings, note the Environment ID of the environment your Semantic Layer is configured on, and paste both into the connection wizard. The token is encrypted at rest and never leaves the connection.

Q: Does it work with regional or single-tenant dbt Cloud instances?

Yes. The host is a field in the wizard. It defaults to the multi-tenant endpoint and can be set to the EMEA or AU region, or to the semantic layer host of a single-tenant instance.

Q: Do I have to redefine my metrics in KPI Tree?

No. KPI Tree reads your definitions through the Semantic Layer API and asks dbt Cloud to compile the SQL, so the number here is the number dbt gives every other tool. There is no second semantic layer to keep in sync. Your time goes into modelling how metrics drive each other and who owns them, not into re-entering definitions.

Q: How does KPI Tree query the Semantic Layer, and what does it cost in dbt Cloud?

It uses the Semantic Layer GraphQL API to list metrics and to compile or run one query per metric at day grain, with results returned as Apache Arrow. dbt counts each compiled or run query as a queried metric. To keep that usage down, link a warehouse connection and KPI Tree runs the compiled SQL on your own infrastructure instead, while definitions still come from dbt Cloud on every sync.

Q: How often does the catalogue sync?

On demand. Press Sync on the connection page after your project changes, or call the sync endpoint from the last step of the dbt Cloud job that builds your project so the catalogue refreshes with every deployment. Each sync runs as a background job, compares the catalogue with the previous run and reports what was created, updated, retired and skipped. Trees, ownership and action history are preserved.

Q: What are dimension metrics, and why do they need a linked warehouse?

With dimension metrics on, KPI Tree probes the distinct values of each dimension you chose for a metric and creates a child metric per value, so Signups with a Plan dimension gains a node for each plan with its own owner and tracking. The probe runs on your warehouse, so a linked warehouse connection is required. 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.

Q: How does KPI Tree decide whether to sum or take the last value across a week or a month?

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.

Q: Which metric types come across?

Simple, ratio, cumulative, derived and conversion metrics, as long as the metric is queryable at day grain. Metrics offered 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.

Q: Can I add dbt artifacts to a dbt Cloud connection?

Yes. Post manifest.json, catalog.json, run_results.json and sources.json from your job’s target directory to the connection’s upload endpoint, ideally as the last step of the job that builds them. They add model lineage and data model exploration, warehouse column types, build history with each metric’s refresh cadence, and source freshness on the metric itself. KPI Tree does not fetch artifacts from dbt Cloud on its own.

Paste an Environment ID and a read-only service token.Paste an Environment ID and a read-only service token. KPI Tree reads your whole metric catalogue through the dbt Semantic Layer API, keeps every definition as dbt compiles it, never re-implements a calculation, and creates a child metric for every dimension value you care about. Above that it adds the layer dbt never carried: which metrics drive which, with statistical confidence, who is accountable when one moves, and whether the last action worked.

Book a demo⌘B See how it connects

models/marts/metrics.yml

served by the Semantic Layer API

metrics:

- name: revenue

label: Revenue

type: simple

type_params:

measure: order_total # agg: sum

filter: {{ Dimension('order__status') }} = 'complete'

dimensions: region, channelgrain: dayentity: order

Synced as written · diff applied nightly

Revenue

Synced from dbt

£1.28m

Month to date · vs £1.51m last month

15%

Aggregation

sum · day, week, month, quarter

Primary driver

Conversion rate · lag 3d

Accountable

Sarah Chen

Last action

Checkout rollback · verified

Governed in dbt Cloud. Explained in KPI Tree. One token, the whole loop.

The dbt Semantic Layer is where a metric stops being a matter of opinion: one definition, compiled by MetricFlow, served to every tool through one API. KPI Tree is one of those tools. It lists your metrics with their dimensions, grains and aggregation through the Semantic Layer API and asks dbt Cloud to compile the SQL, so the number here is the number dbt gives everyone else. Link the warehouse your project builds into and that compiled SQL runs there instead, which keeps your Queried Metrics usage down.

What the dbt Semantic Layer does not know is why Revenue fell, who owns Conversion, or whether Monday's release moved it. That is the layer KPI Tree adds: a causal metric tree re-tested every night, RACI ownership on every node, action plans measured against a forecast, and Canopy, the business context layer that hands all of it to your people and to the agents they already use over MCP. Your dbt project stays the single source of truth for how a metric is calculated. KPI Tree becomes the source of truth for what to do about it.

Every definition, as compiled, nothing re-declared

Names, labels, descriptions, dimensions, queryable grains and measures come across through the Semantic Layer API. Sum, average, first and last are read from each definition, so weekly and monthly rollups behave the way your YAML says.

Choose metrics to sync

4 of 5 selected

Revenue

dimensions: region, channel

sum

Orders

dimensions: region, channel, plan

count

Average order value

dimensions: region

ratio

Active customers

dimensions: plan

count distinct

Cumulative bookings

dimensions: none

cumulative

Aggregation read from each definition. Nothing re-declared.

One query per metric, everything else in memory

Each metric is one compiled query at day grain, through dbt Cloud or on your own warehouse. Comparisons, rollups, breakdowns and the nightly causality sweep run in KPI Tree’s engine, so neither bill grows with the tree.

Warehouse queries · last sync

4 total

Revenue1 query · 1.8s · 412 rows

Orders1 query · 1.2s · 412 rows

Average order value1 query · 1.6s · 412 rows

Active customers1 query · 2.3s · 412 rows

0 warehouse queries for

period comparisons, weekly and monthly rollups, dimension breakdowns, nightly correlation and causality tests. All computed in memory from those four results.

Dimension metrics, created automatically

Link a warehouse, switch on Create Dimension Metrics, and every dimension you chose becomes a child metric per value: Revenue (Region: EMEA), Revenue (Region: APAC), and so on. Each child gets its own owner, baseline and nightly driver tests, so you see which region moved and who owns it. No YAML changes.

Revenue

Create Dimension Metrics · on

dimensions: region, channel · 5 child metrics created

Revenue (Region: EMEA)£612k4%

Revenue (Region: APAC)£318k21%

Revenue (Region: UK)£350k2%

Revenue (Channel: Web)£880k1%

Revenue (Channel: App)£400k9%

Each child has its own owner, baseline and nightly driver tests. No YAML changes.

Re-sync as a diff, trees and owners untouched

Press Sync, or call the API, and the catalogue is compared with the last run: created, updated, retired and skipped, with the reason for every skipped dimension. Ownership, trees and action history stay where they were.

Sync summary

Completed 06:14

Found

Created

Updated

Archived

Skipped

Dimension metrics created118

customer__customer_id skipped: 48,211 values, above the 50 value limit

Trees, owners and action history preserved · gross_margin renamed in place

Connected in three steps. A token, an environment, a sync.

A dbt Cloud connection holds a read-only service token and reads your dbt Semantic Layer catalogue live. Nothing is uploaded to start, and nothing is written back.

Create a read-only service token

In dbt Cloud, create a service token with the Semantic Layer Only and Metadata Only permission sets. Both are read-only. Note the Environment ID of the environment your Semantic Layer is configured on, and the host if you are not on the default multi-tenant endpoint.

Semantic Layer Only and Metadata Only, nothing broader
Any host: the default endpoint, the EMEA or AU region, or a single-tenant instance
The token is encrypted at rest and never leaves the connection

dbt Cloud Semantic Layer

Connected

Environment ID218 407

Service tokendbtc_••••••••••••

Hostsemantic-layer.cloud.getdbt.com

Direct executionoptionalSnowflake · analytics_prod

Semantic Layer OnlyMetadata OnlyRead-only

Never writes to your project, jobs or environments.

Sync the catalogue

Save the connection and press Sync. KPI Tree lists every metric in the environment with its dimensions and grains, reads the aggregation from each definition, and reports what it created, updated, retired and skipped. Choose which metrics and dimensions to keep on the Metrics tab and sync again whenever your project changes.

Runs as a background job, so large catalogues complete reliably
Selective sync: pick metrics and dimensions one at a time
Re-run from the connection page, or from your own pipeline through the API

Sync summary

Completed 06:14

Found

Created

Updated

Archived

Skipped

Dimension metrics created118

customer__customer_id skipped: 48,211 values, above the 50 value limit

Trees, owners and action history preserved · gross_margin renamed in place

Optionally, run the SQL on your own warehouse

Link the Snowflake, BigQuery, Databricks, Redshift or PostgreSQL connection your project builds into and KPI Tree runs the SQL dbt Cloud compiles directly there. Definitions still come from the Semantic Layer on every sync. Only the data path moves, and dimension breakdowns become available.

Cuts dbt Cloud Queried Metrics usage
Required for dimension metrics
Governance unchanged: dbt still owns the definition

dbt Cloud Semantic Layer

Connected

Direct execution

analytics_prod · marts

DefinitionsSemantic Layer API · env 218 407

Last syncSync button · 06:14 · 42 metrics

Queries run on

What comes across from the dbt Cloud Semantic Layer. And what stays exactly where it is.

The Semantic Layer API carries everything KPI Tree needs to query a metric. The optional artifacts from your job add the context that explains a change. Nothing is written back to your project.

Metrics simple, ratio, cumulative, derived, conversion

Every dbt Semantic Layer metric with a day-level time dimension, with its label, description, type and filters. Metrics defined only at coarser grains are reported as skipped rather than guessed at, and a conversion metric can carry a declared rollup so nothing is assumed.

Dimensions and entities child metrics created for you

Pick the dimensions that matter for each metric. With a linked warehouse, KPI Tree probes their distinct values and creates a child metric per value automatically, within a cardinality limit you set by connection, by dimension or by metric. Entities come across too, so an assistant can follow the joins.

Aggregation and rollups read, inferred, or declared

Sum, count, average, min and max map straight from the measure. Stocks and flows are inferred from the metric type and any non-additive dimension, and you can pin the answer in your YAML with meta.kpi_tree.aggregation so the derivation never second-guesses it.

Bring the artifacts too. The context behind every number.

Post the target directory from your dbt Cloud job to the same connection and every metric gains its own lineage, column context, build history and freshness. An assistant can then check whether a movement is a business change or a stale source before anyone acts on it.

semantic_manifest.json

Metric definitions

optional

Read live through the API on every sync. Include it in the ZIP to keep the artifacts in step.

manifest.json

Model lineage

optional

Models, seeds and sources with their dependencies. Unlocks data model exploration in the app and over MCP.

catalog.json

Column context

optional

Every warehouse column with its real data type, merged over the descriptions you wrote.

run_results.json

Build history

optional

Last build status and timing on every model, and each metric’s refresh cadence worked out from your run history.

sources.json

Source freshness

optional

Freshness status and loaded-at times, so stale upstream data shows on the metric itself.

Artifacts are posted from your job through the upload endpoint, up to 50 MB each. KPI Tree does not fetch them from dbt Cloud on its own, so add the upload as the last step of the job that builds them.

Ask an agent the same question twice. Once on the dbt Semantic Layer, once on Canopy above it.

A dbt Cloud team usually already has an agent on the Semantic Layer API or the dbt MCP server, and it comes back with a governed number. The fair question is what Canopy adds. The pair below shows the shape of the difference, and the benchmark beneath it measures it on eight real business questions.

The semantic layer alone

A correct number, and a dead end.

Every consumer of the dbt Semantic Layer, dbt’s own MCP server included, gets the same governed figure. None of them gets the cause, the owner or the follow-up, so the question goes back to the data team.

Why is revenue down this month?

Revenue is £1.28m month to date, 15% below last month. The metric is defined as the sum of order_total where status is complete.

I do not have information about what caused the change or who is responsible. Would you like me to break it down by region?

Canopy on top of dbt

The driver, the owner, the build check and the next step.

Canopy reads the causal tree, the RACI, the build history from your dbt artifacts and the open tasks, so the first answer is the one people act on.

Why is revenue down this month?

Conversion rate is the driver, down 23%, Granger-causal at a three day lag. Traffic and order value are flat. The drop starts the day after Monday's checkout release.

The data is sound: fct_orders built at 06:12 and every source passed freshness. Sarah Chen is Accountable and a rollback task is already open. Shall I attach this analysis to it?

driver · q < 0.05owner · Sarah Chenbuild · freshtask · open

Canopy, the business context layer

We measured it. Eight business questions toOpus 5, three ways in: Snowflake over MCP, raw SQLSnowflake Cortex Analyst, a governed semantic modelCanopy withSnowflake Semantic Views

One shared dataset, the same model, the same questions. The Cortex Analyst arm is the closest stand-in for an agent on the dbt Semantic Layer or the dbt MCP server: governed definitions and correct numbers, but no causal model, no owners and no record of what was tried. All three arms say what moved. Only the Canopy arm says why, who owns it and what is already being done, first time, without a week of follow-up questions.

What happened in the business in August that explains the numbers?

Claude

Nothing actually "happened" in August — August is the seasonal trough, and the margin damage was done back in April. Here's what the data shows (DEMO_DATA.PUBLIC.FCT_DAILY_METRICS, 4 London sites).

August 2026 vs August 2025

	Aug 2025	Aug 2026	Δ
Orders	51,215	52,198	+1.9%
Revenue	£368,141	£378,622	+2.8%
AOV	£7.19	£7.25	+0.8%
COGS % of revenue	36.8%	36.8%	flat
Staff cost	£69,397	£72,534	+4.5%
Staff hours	4,631	4,631	identical
Business rates (net)	£10,239	£16,954	+65.6%
EBITDA	£114,656	£111,352	−2.9%
EBITDA margin	31.1%	29.4%	−1.7pp

Trading was slightly better than last August. EBITDA still fell. The bridge:

Revenue +£10,481
COGS −£3,864
Staff −£3,137
Business rates −£6,715
Waste +£453, delivery commission −£161, card fees −£279, energy −£82
Net −£3,304

The two things that actually changed, both on 1 April 2026

1. Business rates relief ended. FCT_RATES_DAILY.RELIEF_RATE goes 0.40 → 0.00 on 2026-04-01. Gross rates are unchanged (~£17k/month); the relief line just went to zero. That's ~£6.7k/month, ~£80k annualised, straight off EBITDA.

2. A pay rise. Average hourly rate stepped from £13.92 (March) to £14.38 (April) and has held ~£14.40–14.55 since — +4.4% YoY. Headcount is unchanged at 28 and August hours are identical to last August, so this is pure rate inflation, not overspend on rotas. Employer NI ticked up in line (8.70% → 8.77% of wages).

The low absolute numbers are seasonality, not decline

Revenue fell from £521.9k in May to £364.5k in July and £378.6k in August. That happens every year in this data — these are commuter-belt sites (Canary Wharf, Liverpool Street, Paddington, Shoreditch) and July/August is the holiday trough:

2024: Jun £226k → Jul £198k → Aug £222k
2025: Jun £431k → Jul £350k → Aug £368k
2026: Jun £445k → Jul £365k → Aug £379k

Because rates, energy and most of the staff cost are fixed, the trough compresses margin every summer. The difference in 2026 is that ~£10k/month of new fixed cost landed before the trough, so the summer margin floor dropped from 31.1% to 29.4%.

What I ruled out

Waste — down YoY (£5,157 → £4,704), improved across every reason code.
Channel mix — eat-inredacted value split and delivery commission rates are flat YoY; no shift toward commission-heavy channels.
A specific incident — daily orders across all five weeks of August sit in a tight 2,020–2,073 band on weekdays. No outage, no closure, no spike.
Site-specific problems — all four locations moved together (Canary Wharf weakest at 27.3% EBITDA, Shoreditch strongest at 31.7%; same shape everywhere).

One caveat: the table contains dated rows running through February 2027. I treated August 2026 as the last actual month and ignored anything after it — worth confirming that's right, since the forward rows would flatter any trend line drawn through them.

The lever, if you want the margin back, is the £6.7k/month rates step — that's 2× the wage impact and it's not going to unwind on its own.

14tool calls14Snowflake queries

Judge: fabricated, 0 of 9 specifics · 334k tokens of context read

Claude

The short version

August was a good month. The alarming numbers on the dashboard right now are September-to-date, not August — the health report's "EBITDA -21.8% MoM" is 1–9 Sep vs 1–9 Aug. Read on the full month, August looks like this:

	Aug 2026	Jul 2026	Aug 2025
Revenue	£378,621.99	£364,535.26(+3.9%)	£368,140.79(+2.8%)
EBITDA	£111,351.63	£99,888.10(+11.5%)	£114,655.61(-2.9%)
Gross margin %	60.2	59.7	68.5
COGS %	39.8	40.3	31.5
Labour cost %	22.1	23.5	14.5

The finding: August sold more than last August and earned less. Revenue was up £10,481.20 year on year, yet EBITDA was down £3,303.98. That is not a demand problem — it is entirely a cost-structure problem. COGS is running 8.3 points higher than last August and labour 7.6 points higher.

I'm quoting those as percentage points rather than converting to a cash bridge: the margin metrics aggregate daily rates and don't reconcile cleanly against the P&L lines, so a pounds figure would be spurious.

What Canopy records as the why

KPI Tree's Canopy business context layer explains both halves of that.

Why August beat July:

The King's Head kitchen refit finished ahead of schedule, so the venue reopened a full week early and caught the bank holiday trade that had been written off.
The Sunday roast menu relaunched across all London venues with sharing boards and a fixed-price family option.
At Shoreditch, moving quiz night from Tuesday to Thursday lifted revenue per labour hour — Thursdays were dead and the kitchen was already staffed.

Why the year-on-year margin is gone:

Menu re-costing came back showing produce inflation at about 9%, steeper than budgeted, with beef and dairy the worst offenders.
The draught supplier raised keg prices 6%, affecting every venue on the same contract.
Leadership chose to re-engineer the menu rather than raise prices — protecting the headline price going into a soft quarter, but absorbing the inflation into margin. August is what that decision costs.

Two other recorded items shape the read: the area manager is on leave through the bank holiday fortnight (cover split between two senior venue managers, until 22 Sep), and the new till system is blocked on payment provider approval, so the faster table-ordering flow is still switched off at the pilot sites.

Which venues

All four venues beat July. Against last August, only one is ahead:

Canary Wharf £24,832.15 — +3.9% (+£934.15) — the only venue up
Liverpool Street £26,658.84 — -3.9% (-£1,085.55)
Paddington £26,977.50 — -4.4% (-£1,241.53)
Shoreditch £32,883.14 — -5.5% (-£1,911.05)

Canary Wharf being the outlier lines up with the recorded decision to hold its staffing flat through the quarter despite the labour cost target, on the grounds that the lunch trade is too volatile to cut cover. On these numbers that call is paying.

What's already in flight

Both funded initiatives are aimed squarely at this and both are working month-on-month:

Menu engineering programme (Rachel Morrison, £45,000 budget, £18,500 spent, 33% progress) targets COGS % down — COGS fell 40.3 → 39.8 July to August.
Rota optimisation rollout (Michael Patel, £30,000 budget, £12,000 spent, 33% progress) targets labour cost % down — labour fell 23.5 → 22.1. Canopy confirms it went live at the pilot venue with demand-based templates.

So the levers are moving in the right direction; they just haven't clawed back the year-on-year gap yet. Two departmental objectives sit on this — "Reduce labour cost percentage to below 28%" (Oliver Blackwood) is at risk, and "Improve gross margin to 68% across all venues" (Thomas Williams) is nominally on track at 34% outcome progress but only 16.7% execution progress.

One thing August does not explain. The quarterly EBITDA goal of £950,000 (Thomas Williams and Oliver Blackwood, due 30 Sep) stands at £239,950.11 — that is July £99,888.10 + August £111,351.63 + Sep 1–9 £28,710.38, and it reconciles exactly. With 21 days left and August's best-in-quarter month at £111,351.63, that target cannot be reached. Q3-to-date is 44.3% below the same span of Q2 (£430,770.18), so Q2 ran at roughly £143k/month against Q3's ~£105k. That gap is seasonal or structural and predates August; it is not caused by anything in the August numbers.

What to do

Take the keg and produce increases to the P&L, not just the menu. Rachel Morrison owns COGS % and the menu engineering programme. The decision to re-engineer rather than re-price was made before produce inflation came back at 9% — that's a materially different input than when the call was made, and it's Thomas Williams' and Oliver Blackwood's decision to revisit as EBITDA owners.
The one check that settles it: whether the draught contract is open to renegotiation or a second supplier. Every venue is on the same contract, so it's a single conversation with a group-wide 6% effect. Nobody in Canopy is recorded as owning that — Rachel Morrison is the right person to open it.
Unblock the till rollout. The payment provider approval is holding the faster table-ordering flow off the pilot sites. That is a phone call to the provider, not an analysis, and it's the one recorded blocker with no owner attached.
Reset the £950k quarterly target. It is arithmetically unreachable and it is currently making a company objective read as on-track at 29.3%. Thomas Williams and Oliver Blackwood are Responsible.
Look again on 1 October, when September closes and gives a clean full-month read on whether the two initiatives keep pulling COGS and labour down.

What would change this conclusion: if the August revenue lift was mostly the King's Head reopening early rather than the Sunday roast relaunch, then the underlying like-for-like trade is flatter than +2.8% and the cost story is worse than it looks. I can't separate those — there's no King's Head metric in the tree; the EBITDA search returned only Canary Wharf, Shoreditch, Liverpool Street and Paddington. That's a measurement gap worth closing.

Two things I can do on your say-so: Canopy has a pointer saying the full autumn menu push context — promo dates and first-wave venues — is in the #marketing channel, and I can pull that thread in. I can also record the "revenue up, EBITDA down year on year, cost-driven" finding against EBITDA so it's there next month. Both need your go-ahead — ingesting reads the whole channel and can adopt the Slack workspace as a context source.

22tool calls0Snowflake queries

Judge: partial, 9 of 10 specifics · 520k tokens of context read

CanopyHad some of the context

Claude

The short version

	Aug 2026	Jul 2026	Aug 2025
Revenue	£378,621.99	£364,535.26(+3.9%)	£368,140.79(+2.8%)
EBITDA	£111,351.63	£99,888.10(+11.5%)	£114,655.61(-2.9%)
Gross margin %	60.2	59.7	68.5
COGS %	39.8	40.3	31.5
Labour cost %	22.1	23.5	14.5

What Canopy records as the why

KPI Tree's Canopy business context layer explains both halves of that.

Why August beat July:

The King's Head kitchen refit finished ahead of schedule, so the venue reopened a full week early and caught the bank holiday trade that had been written off.
The Sunday roast menu relaunched across all London venues with sharing boards and a fixed-price family option.
At Shoreditch, moving quiz night from Tuesday to Thursday lifted revenue per labour hour — Thursdays were dead and the kitchen was already staffed.

Why the year-on-year margin is gone:

Menu re-costing came back showing produce inflation at about 9%, steeper than budgeted, with beef and dairy the worst offenders.
The draught supplier raised keg prices 6%, affecting every venue on the same contract.
Leadership chose to re-engineer the menu rather than raise prices — protecting the headline price going into a soft quarter, but absorbing the inflation into margin. August is what that decision costs.

Which venues

All four venues beat July. Against last August, only one is ahead:

Canary Wharf £24,832.15 — +3.9% (+£934.15) — the only venue up
Liverpool Street £26,658.84 — -3.9% (-£1,085.55)
Paddington £26,977.50 — -4.4% (-£1,241.53)
Shoreditch £32,883.14 — -5.5% (-£1,911.05)

What's already in flight

Both funded initiatives are aimed squarely at this and both are working month-on-month:

Menu engineering programme (Rachel Morrison, £45,000 budget, £18,500 spent, 33% progress) targets COGS % down — COGS fell 40.3 → 39.8 July to August.
Rota optimisation rollout (Michael Patel, £30,000 budget, £12,000 spent, 33% progress) targets labour cost % down — labour fell 23.5 → 22.1. Canopy confirms it went live at the pilot venue with demand-based templates.

What to do

Take the keg and produce increases to the P&L, not just the menu. Rachel Morrison owns COGS % and the menu engineering programme. The decision to re-engineer rather than re-price was made before produce inflation came back at 9% — that's a materially different input than when the call was made, and it's Thomas Williams' and Oliver Blackwood's decision to revisit as EBITDA owners.
The one check that settles it: whether the draught contract is open to renegotiation or a second supplier. Every venue is on the same contract, so it's a single conversation with a group-wide 6% effect. Nobody in Canopy is recorded as owning that — Rachel Morrison is the right person to open it.
Unblock the till rollout. The payment provider approval is holding the faster table-ordering flow off the pilot sites. That is a phone call to the provider, not an analysis, and it's the one recorded blocker with no owner attached.
Reset the £950k quarterly target. It is arithmetically unreachable and it is currently making a company objective read as on-track at 29.3%. Thomas Williams and Oliver Blackwood are Responsible.
Look again on 1 October, when September closes and gives a clean full-month read on whether the two initiatives keep pulling COGS and labour down.

22tool calls0Snowflake queries

Judge: partial, 9 of 10 specifics · 520k tokens of context read

Each surface is judged on whether its answer drew on the business context recorded for this question. The judge saw the answers unlabelled, and saying plainly that the data is not there counts in a surface's favour. The judge's own term and specifics count sit under each answer.

One question, asked verbatim, one run per surface against the same dataset. Answers are unedited, and each panel carries the tool-call and warehouse-query counts of that run.

Part of the dbt Semantic Layer integration. One connection for dbt Cloud, one for dbt Core, the same layer above.

The dbt Semantic Layer integration The dbt Core integration

The hub page covers what the dbt Semantic Layer is, what KPI Tree adds above it, the benchmark and the security posture. The dbt Core page covers the manifest path with no dbt Cloud account.

Common questions

Which dbt plans support this integration?

Any dbt platform plan that includes the Semantic Layer API: Starter, Enterprise and Enterprise+. The Developer plan does not expose the API. If you run dbt Core without dbt Cloud, use the dbt Core integration, which needs no dbt Cloud account at all.

What permissions does the service token need?

The Semantic Layer Only and Metadata Only permission sets, both of which are read-only. Create the token in dbt Cloud under account settings, note the Environment ID of the environment your Semantic Layer is configured on, and paste both into the connection wizard. The token is encrypted at rest and never leaves the connection.

Does it work with regional or single-tenant dbt Cloud instances?

Yes. The host is a field in the wizard. It defaults to the multi-tenant endpoint and can be set to the EMEA or AU region, or to the semantic layer host of a single-tenant instance.

Do I have to redefine my metrics in KPI Tree?

No. KPI Tree reads your definitions through the Semantic Layer API and asks dbt Cloud to compile the SQL, so the number here is the number dbt gives every other tool. There is no second semantic layer to keep in sync. Your time goes into modelling how metrics drive each other and who owns them, not into re-entering definitions.

How does KPI Tree query the Semantic Layer, and what does it cost in dbt Cloud?

It uses the Semantic Layer GraphQL API to list metrics and to compile or run one query per metric at day grain, with results returned as Apache Arrow. dbt counts each compiled or run query as a queried metric. To keep that usage down, link a warehouse connection and KPI Tree runs the compiled SQL on your own infrastructure instead, while definitions still come from dbt Cloud on every sync.

How often does the catalogue sync?

On demand. Press Sync on the connection page after your project changes, or call the sync endpoint from the last step of the dbt Cloud job that builds your project so the catalogue refreshes with every deployment. Each sync runs as a background job, compares the catalogue with the previous run and reports what was created, updated, retired and skipped. Trees, ownership and action history are preserved.

What are dimension metrics, and why do they need a linked warehouse?

With dimension metrics on, KPI Tree probes the distinct values of each dimension you chose for a metric and creates a child metric per value, so Signups with a Plan dimension gains a node for each plan with its own owner and tracking. The probe runs on your warehouse, so a linked warehouse connection is required. 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.

How does KPI Tree decide whether to sum or take the last value across a week or a month?

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.

Which metric types come across?

Simple, ratio, cumulative, derived and conversion metrics, as long as the metric is queryable at day grain. Metrics offered 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.

Can I add dbt artifacts to a dbt Cloud connection?

Yes. Post manifest.json, catalog.json, run_results.json and sources.json from your job’s target directory to the connection’s upload endpoint, ideally as the last step of the job that builds them. They add model lineage and data model exploration, warehouse column types, build history with each metric’s refresh cadence, and source freshness on the metric itself. KPI Tree does not fetch artifacts from dbt Cloud on its own.

Are saved queries, exports, tests or exposures read?

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 from an uploaded manifest is kept at model level.

Does it work with the dbt Fusion engine?

KPI Tree only talks to the Semantic Layer API, so the engine behind your environment does not change the connection. Metrics defined under the modernised YAML spec that Fusion and dbt Core 1.12 use are read the same way as metrics defined under the earlier spec.

Does KPI Tree write to my dbt project?

No. The service token carries the Semantic Layer Only and Metadata Only permission sets and nothing broader. Nothing is written back to the project, no jobs are triggered and no models or environments are touched.

Is this the dbt metrics layer?

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 it through the Semantic Layer API, so it works with the current spec rather than the retired metrics package.

Can I combine several dbt environments or projects on one tree?

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

Can dbt metrics share a tree with metrics from other sources?

Yes. Metrics from several dbt environments, 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.

Should I use this or the dbt Core integration?

Use this one if you have a dbt platform plan with the Semantic Layer and want the catalogue read live with no uploads. Use the dbt Core integration if you run dbt Core without dbt Cloud, or if you want every query to run on your own warehouse with no dbt Cloud usage at all.

Related guides. Frameworks and metrics in depth.

Deep dives into the frameworks and metrics that work with dbt Cloud.

dbt semantic layer and metric trees: how they fit together

dbt is the plumbing, the metric tree is the application above it

Read guide

Semantic layer vs business context layer

A semantic layer settles what a metric is. It cannot settle how metrics drive each other, who owns them, or what happens when one moves.

Read guide

How to build a metric tree

A step-by-step metric tree and KPI tree template from North Star to daily levers

Read guide

Related integrations. More sources that work with KPI Tree.

You governed the definition. Now govern the decision.

Connect your dbt Cloud Semantic Layer and see your own metrics as a causal tree with named owners and verified actions, in a demo on your data.

Book a demo⌘B See pricing

The guide

dbt semantic layer and metric trees: how the two layers fit together, and where each one stops.

Read the guide

Your dbt Cloud Semantic Layer defines the metric. KPI Tree explains the movement, names the owner and proves the fix.

Governed in dbt Cloud. Explained in KPI Tree. One token, the whole loop.

Every definition, as compiled, nothing re-declared

One query per metric, everything else in memory

Dimension metrics, created automatically

Re-sync as a diff, trees and owners untouched

Connected in three steps. A token, an environment, a sync.

Create a read-only service token

Sync the catalogue

Optionally, run the SQL on your own warehouse

What comes across from the dbt Cloud Semantic Layer. And what stays exactly where it is.

Metrics simple, ratio, cumulative, derived, conversion

Dimensions and entities child metrics created for you

Aggregation and rollups read, inferred, or declared

Bring the artifacts too. The context behind every number.

Ask an agent the same question twice. Once on the dbt Semantic Layer, once on Canopy above it.

A correct number, and a dead end.

The driver, the owner, the build check and the next step.

We measured it. Eight business questions toOpus 5, three ways in: Snowflake over MCP, raw SQLSnowflake Cortex Analyst, a governed semantic modelCanopy withSnowflake Semantic Views

Part of the dbt Semantic Layer integration. One connection for dbt Cloud, one for dbt Core, the same layer above.

Common questions

Which dbt plans support this integration?

What permissions does the service token need?

Does it work with regional or single-tenant dbt Cloud instances?

Do I have to redefine my metrics in KPI Tree?

How does KPI Tree query the Semantic Layer, and what does it cost in dbt Cloud?

How often does the catalogue sync?

What are dimension metrics, and why do they need a linked warehouse?

How does KPI Tree decide whether to sum or take the last value across a week or a month?

Which metric types come across?

Can I add dbt artifacts to a dbt Cloud connection?

Are saved queries, exports, tests or exposures read?

Does it work with the dbt Fusion engine?

Does KPI Tree write to my dbt project?

Is this the dbt metrics layer?

Can I combine several dbt environments or projects on one tree?

Can dbt metrics share a tree with metrics from other sources?

Should I use this or the dbt Core integration?

Related guides. Frameworks and metrics in depth.

dbt semantic layer and metric trees: how they fit together

Semantic layer vs business context layer

How to build a metric tree

Related integrations. More sources that work with KPI Tree.

dbt Semantic Layer

dbt Core

Snowflake

Databricks

You governed the definition. Now govern the decision.

Built by a team that's been in your shoes