dbt Semantic Layer integration

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

Q: How does KPI Tree connect to the dbt Semantic Layer?

Two ways. A dbt Core connection reads semantic_manifest.json from your target directory, renders each metric as MetricFlow SQL with an in-process engine and runs it on the warehouse your models build into, with no dbt Cloud account. A dbt Cloud connection reads your catalogue through the Semantic Layer API with a read-only service token and can run the compiled SQL through dbt Cloud or on a linked warehouse. Both produce the same metrics, trees and ownership.

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

No. KPI Tree consumes your dbt definitions as an upstream source and never re-implements a calculation, so the number here is the number dbt gives every other tool. Your time goes into modelling how metrics drive each other and who owns them, not into re-entering definitions.

Q: What comes across from the semantic layer?

Every metric queryable at day grain, with its label, description, type, filters, measures, dimensions and entities. Simple, ratio, cumulative, derived and conversion metrics are all read. The aggregation is taken from the definition, inferred from the metric type and any non-additive dimension where the definition leaves it open, or pinned with meta.kpi_tree.aggregation in your YAML.

Q: What are dimension metrics?

For each metric you choose the dimensions that matter, and KPI Tree creates a child metric per distinct value automatically, so Revenue with a Region dimension gains Revenue (Region: EMEA), Revenue (Region: APAC) and so on, each with its own owner, baseline and nightly driver tests. The default limit is 15 values per dimension, adjustable between 2 and 200 at connection, dimension or metric level. On dbt Cloud the probe runs on a linked warehouse.

Q: Can I combine several dbt projects, or dbt with other sources, on one tree?

Yes. Each dbt project or environment is its own connection, and metrics from several of them sit on the same tree alongside metrics from Snowflake Semantic Views, Databricks Unity Catalog, SQL on a warehouse connection and spreadsheets. Each metric keeps its own calculation source while the tree carries the drivers, owners, targets and actions across them.

Q: What happens when my dbt project changes?

Each sync is compared with the previous one and the 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 are retired rather than deleted, with their history kept. Trees, ownership and action history are preserved. dbt Core syncs automatically on every upload; dbt Cloud syncs from the connection page or the API.

Q: What do the dbt artifacts add?

manifest.json brings model lineage and data model exploration in the app and over MCP. catalog.json adds every warehouse column with its real type. run_results.json records each model’s last build and works out how often each metric refreshes. sources.json adds source freshness on the metric itself. Post them from your build to the connection’s upload endpoint, from dbt Core or from a dbt Cloud job.

Q: 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 can be tracked as SQL metrics on the warehouse connection. dbt tests and exposures are not read, and lineage is kept at model level.

Q: Does it work with the dbt Fusion engine and the modernised YAML spec?

Yes. A dbt Core connection 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. A dbt Cloud connection only talks to the Semantic Layer API, so the engine behind the environment does not change the connection.

Connect the dbt Semantic Layer from dbt Core or dbt Cloud. KPI Tree imports every governed metric exactly as MetricFlow defines it, creates a child metric for every dimension value you care about, and never re-implements a calculation.Connect the dbt Semantic Layer from dbt Core or dbt Cloud. KPI Tree imports every governed metric exactly as MetricFlow defines it, creates a child metric for every dimension value you care about, and never re-implements a calculation. Above that it adds the layer the semantic layer 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

semantic_manifest.json

compiled from models/marts/metrics.yml

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

What the dbt Semantic Layer is, and where it stops.

A definition first, because the integration only makes sense against it.

The dbt Semantic Layer is a governed set of metric definitions, written as version-controlled YAML in your dbt project and compiled by MetricFlow, that tells every downstream tool exactly how each metric is calculated: which semantic model it comes from, which measure it aggregates, and over which dimensions and time grains it can be queried. It replaced the earlier dbt metrics layer, and dbt Cloud serves it through the Semantic Layer API, while a dbt Core project produces the same definitions as a semantic manifest.

It is the cleanest answer a business can have to "what is Revenue?". It is not designed to answer why Revenue fell, who owns the driver, or whether the fix worked. Those questions live in a layer above the semantic layer, and that is the layer this integration adds. The definitions stay in dbt. The causal tree, the owners and the verified outcomes live in KPI Tree, and Canopy hands all of it to your people and your agents.

Governed in dbt. Explained in KPI Tree. One semantic layer, the whole loop.

KPI Tree is a first-class consumer of the dbt Semantic Layer. From dbt Core it reads semantic_manifest.json and renders the SQL with an in-process MetricFlow engine. From dbt Cloud it reads the catalogue through the Semantic Layer API. Either way the SQL runs on the warehouse your models build into, with your definitions as the source of truth. Nothing is re-declared, re-mapped or copied into a second semantic layer.

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 defined, nothing re-declared

Metrics, dimensions, entities, measures, labels and descriptions come across from the dbt Semantic Layer intact. 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 query at day grain, on your warehouse or through dbt Cloud. Comparisons, rollups, breakdowns and the nightly correlation and causality sweep run in KPI Tree’s own engine, so no 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

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. 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

Every sync is compared with the last. New metrics appear, changed ones update in place, removed ones retire with their history kept. Ownership, trees and action history stay exactly where you left them.

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

dbt Core or dbt Cloud. Same sync, same layer above. Start where your project lives.

Both connections to the dbt Semantic Layer produce the same metrics, the same trees and the same ownership. The difference is where the definitions come from and where the SQL runs.

dbt Core

Your project compiles the manifest. KPI Tree renders the SQL with an in-process MetricFlow engine and runs it on your warehouse.

Definitions: semantic_manifest.json, uploaded from CI or by hand
SQL: Rendered in-process, run on your linked warehouse
Sync: Automatic on every upload
Needs: A linked warehouse connection. No dbt Cloud account.

The dbt Core integration

dbt Cloud

KPI Tree reads your catalogue through the Semantic Layer API and runs queries there, or on your own warehouse.

Definitions: Read live from the Semantic Layer API
SQL: Compiled by dbt Cloud, run there or on a linked warehouse
Sync: On demand from the connection page or the API
Needs: An Environment ID, a read-only service token and a host

The dbt Cloud integration

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

The semantic layer carries everything KPI Tree needs to query a metric. The optional dbt artifacts 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. KPI Tree probes their distinct values on your warehouse 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.

Five artifacts, one ZIP. The context behind every number.

Post the target directory from your build, dbt Core or dbt Cloud, 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

Required for a dbt Core connection, where it starts the sync. Read live through the API on dbt Cloud.

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 arrive through the upload endpoint from your own pipeline, up to 50 MB each. Tests and exposures are not read, and lineage is kept at model level.

The layer above

The dbt Semantic Layer governs the calculation. KPI Tree adds causation, ownership and proof.

Above your governed definitions sits one causal model of the business, with the org chart, the recorded context and the outcome of every action attached. People read it as a tree. Agents read the same graph over MCP.

Data warehouses

The numbers

Semantic layers

The definitions

Business apps over MCP

Launches, decisions, blockers

Org structure

Directory-synced

For humans

Answers, briefings and pushes

Read and write over MCP

Anthropic: 21% → ~95% with curated context

Canopy Agent Workflows the metrics start them, humans gate them

Canopy Agents four out of the box, any model, your keys

Canopy

The business context layer

Structural context The causal tree, the org chart

Temporal context What was true when, plan against actual

Behavioural context What people did, what worked

Operational context RACI, workflows, approvals

Strategic context Objectives, key results, initiatives

Map & Measure

Metric Trees

Business Models

Prove & Act

Root Cause

Ownership

Verified Impact

Strategy

Grounded in proven causality

Verified proof

Meta spend → Revenue, +£32k vs forecast, q < 0.01

Personalised Action Plans 31 experiments running

hypothesis → a real person’s plan → measure the change

Causation the test cascade

ADF p 0.02 → Granger p 0.003 → q < 0.05, 87 of 1,204 survive

Correlation

22,791 pairs tested nightly, NPS – Churn r 0.71

Data warehouses

The numbers

Semantic layers

The definitions

Business apps

Launches, decisions, blockers

Org structure

Directory-synced

Causal drivers, tested every night

Your dbt metrics become nodes on a tree. Every edge between them is re-tested nightly, from correlation through Granger causality with false-discovery control, so a driver carries a confidence level rather than a line someone drew.

Metric trees

RACI ownership, on every metric

Each metric gets Responsible, Accountable, Consulted and Informed assignments tied to real people in your directory. When it breaches its baseline the Accountable owner hears first, in Slack or by email, with escalation if nobody acts.

Conversion rate

Marketing · daily

Metric ownership

Verified impact, not self-reported

Actions are tracked against the metric they target and measured against a counterfactual forecast when the window closes. What held becomes a driver the model trusts. What did not is retracted.

Fix checkout flow

Verified · +£32k

Linked to Revenue · measured by the actuals pipeline

Pause underperforming ad sets

Measuring…

Verified impact

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

You already point an agent at your warehouse, or at the dbt Semantic Layer itself, 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.

Read-only by design. Your project, your warehouse and your data stay where they are.

SOC 2 Type II, continuously monitored

Controls independently examined for Security, Availability and Confidentiality and monitored every day, with CREST penetration testing and the Type II report in the Trust Center.

Continuous Monitoring

Controls Verified

CREST Penetration Testing

We never write to your dbt project, or to your warehouse

A dbt Core connection reads a manifest and runs SELECT statements with scoped, read-only credentials. A dbt Cloud connection carries the Semantic Layer Only and Metadata Only permission sets and nothing broader. No exposures are written back, no jobs are triggered and no models are touched.

Warehouse connection

Connected

Hostanalytics-prod.••••••.cloud

Service credential••••••••••••

TLS verifiedScoped service credentialsSecrets encrypted

Read-only access · credentials never leave the encrypted store

We do not store your data, calculations run in memory

Each metric's daily series is fetched with read-only credentials, computed on in KPI Tree's own encrypted in-memory engine and cached only briefly. Nothing is copied into a lake and nothing sits at rest.

Read-only credentialsSecrets encrypted with an HSMBring your own keySSO and SCIM through your directoryAudit logs to your SIEM

Common questions

What is the dbt Semantic Layer?

The dbt Semantic Layer is a governed set of metric definitions written as version-controlled YAML in a dbt project and compiled by MetricFlow. It tells every downstream tool how each metric is calculated, from which semantic model, over which dimensions and time grains. dbt Cloud serves it through the Semantic Layer API, and a dbt Core project produces the same definitions as a semantic manifest. It replaced the earlier dbt metrics layer.

How does KPI Tree connect to the dbt Semantic Layer?

Two ways. A dbt Core connection reads semantic_manifest.json from your target directory, renders each metric as MetricFlow SQL with an in-process engine and runs it on the warehouse your models build into, with no dbt Cloud account. A dbt Cloud connection reads your catalogue through the Semantic Layer API with a read-only service token and can run the compiled SQL through dbt Cloud or on a linked warehouse. Both produce the same metrics, trees and ownership.

Do I have to redefine my metrics in KPI Tree?

No. KPI Tree consumes your dbt definitions as an upstream source and never re-implements a calculation, so the number here is the number dbt gives every other tool. Your time goes into modelling how metrics drive each other and who owns them, not into re-entering definitions.

What comes across from the semantic layer?

Every metric queryable at day grain, with its label, description, type, filters, measures, dimensions and entities. Simple, ratio, cumulative, derived and conversion metrics are all read. The aggregation is taken from the definition, inferred from the metric type and any non-additive dimension where the definition leaves it open, or pinned with meta.kpi_tree.aggregation in your YAML.

What are dimension metrics?

For each metric you choose the dimensions that matter, and KPI Tree creates a child metric per distinct value automatically, so Revenue with a Region dimension gains Revenue (Region: EMEA), Revenue (Region: APAC) and so on, each with its own owner, baseline and nightly driver tests. The default limit is 15 values per dimension, adjustable between 2 and 200 at connection, dimension or metric level. On dbt Cloud the probe runs on a linked warehouse.

Can I combine several dbt projects, or dbt with other sources, on one tree?

Yes. Each dbt project or environment is its own connection, and metrics from several of them sit on the same tree alongside metrics from Snowflake Semantic Views, Databricks Unity Catalog, SQL on a warehouse connection and spreadsheets. Each metric keeps its own calculation source while the tree carries the drivers, owners, targets and actions across them.

What happens when my dbt project changes?

Each sync is compared with the previous one and the 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 are retired rather than deleted, with their history kept. Trees, ownership and action history are preserved. dbt Core syncs automatically on every upload; dbt Cloud syncs from the connection page or the API.

What do the dbt artifacts add?

manifest.json brings model lineage and data model exploration in the app and over MCP. catalog.json adds every warehouse column with its real type. run_results.json records each model’s last build and works out how often each metric refreshes. sources.json adds source freshness on the metric itself. Post them from your build to the connection’s upload endpoint, from dbt Core or from a dbt Cloud job.

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 can be tracked as SQL metrics on the warehouse connection. dbt tests and exposures are not read, and lineage is kept at model level.

Does it work with the dbt Fusion engine and the modernised YAML spec?

Yes. A dbt Core connection 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. A dbt Cloud connection only talks to the Semantic Layer API, so the engine behind the environment does not change the connection.

How do AI agents use it?

Through Canopy, KPI Tree’s business context layer, over MCP. An assistant such as Claude, ChatGPT, Gemini or Copilot can analyse a dbt metric with its drivers, owners and recorded context, explore the 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. The semantic layer tells the agent what the metric is. Canopy tells it why it moved and what to do.

Does KPI Tree write to my dbt project or my warehouse?

No. A dbt Core connection reads a manifest and runs SELECT statements with scoped, read-only credentials. A dbt Cloud connection carries the Semantic Layer Only and Metadata Only permission sets and nothing broader. Nothing is written back, no jobs are triggered and no models are touched.

Which dbt plans and versions are supported?

dbt Core 1.6 onwards for the manifest path, with no dbt Cloud account needed. For the API path, any dbt platform plan that includes the Semantic Layer API: Starter, Enterprise and Enterprise+. The Developer plan does not expose the API.

Related guides. Frameworks and metrics in depth.

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

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 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 Semantic Layer defines the metric. KPI Tree explains the movement, names the owner and proves the fix.

What the dbt Semantic Layer is, and where it stops.

Governed in dbt. Explained in KPI Tree. One semantic layer, the whole loop.

Every definition, as defined, nothing re-declared

One query per metric, everything else in memory

Dimension metrics, created automatically

Re-sync as a diff, trees and owners untouched

dbt Core or dbt Cloud. Same sync, same layer above. Start where your project lives.

dbt Core

dbt Cloud

What comes across from the dbt 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

Five artifacts, one ZIP. The context behind every number.

The dbt Semantic Layer governs the calculation. KPI Tree adds causation, ownership and proof.

Causal drivers, tested every night

RACI ownership, on every metric

Verified impact, not self-reported

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

Read-only by design. Your project, your warehouse and your data stay where they are.

SOC 2 Type II, continuously monitored

We never write to your dbt project, or to your warehouse

We do not store your data, calculations run in memory

Common questions

What is the dbt Semantic Layer?

How does KPI Tree connect to the dbt Semantic Layer?

Do I have to redefine my metrics in KPI Tree?

What comes across from the semantic layer?

What are dimension metrics?

Can I combine several dbt projects, or dbt with other sources, on one tree?

What happens when my dbt project changes?

What do the dbt artifacts add?

Are saved queries, exports, tests or exposures read?

Does it work with the dbt Fusion engine and the modernised YAML spec?

How do AI agents use it?

Does KPI Tree write to my dbt project or my warehouse?

Which dbt plans and versions are supported?

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 Core

dbt Cloud

Snowflake Semantic Views

Apache Ossie

You governed the definition. Now govern the decision.

Built by a team that's been in your shoes