Apache Ossie integration
Your Ossie document defines the metric. KPI Tree explains the movement, names the owner and proves the fix.
Post an Apache Ossie document, the Open Semantic Interchange format, to a KPI Tree connection.Post an Apache Ossie document, the Open Semantic Interchange format, to a KPI Tree connection. Every dataset, dimension, relationship and metric in it becomes a tracked metric that runs on the warehouse you link, exactly as defined. Above the interchange it adds the layer no semantic standard carries: which metrics drive which, with statistical confidence, who is accountable when one moves, and whether the last action worked.
sales.osi.yaml
Apache Ossie · version 0.1.1
version: 0.1.1
semantic_model:
- name: orders
datasets:
- name: fct_orders
source: analytics.marts.fct_orders
primary_key: [order_id]
fields:
- name: order_date
dimension: { is_time: true }
metrics:
- name: revenue
expression: SUM(order_total)
Revenue
Imported from OSI£1.28m
Month to date · vs £1.51m last month
Rollup
sum · day, week, month, quarter
Primary driver
Conversion rate · lag 3d
Accountable
Last action
Checkout rollback · verified
What Apache Ossie is, and where it stops.
Apache Ossie, incubating, is the open standard that began as the Open Semantic Interchange: a vendor-neutral YAML and JSON format for a semantic model, with datasets, fields, dimensions, time flags, relationships, metrics, multi-dialect expressions and AI context. Snowflake, dbt Labs and Salesforce founded it in 2025, more than fifty organisations take part, and version 0.1.1 is the released spec. Snowflake exports a Semantic View to Ossie YAML with one system function, dbt Core 1.12 writes an Ossie document beside every semantic manifest, and converters exist for Databricks metric views, Sigma, Omni and Tableau.
It settles what a metric is, wherever it was defined. It does not say why the metric fell, who owns the driver, or whether the fix worked, and the spec carries no owners, targets, causal links or verified outcomes. Those live in a layer above the interchange, and that is the layer this integration adds. The definition stays in the Ossie document and the tool that produced it. 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.
Defined anywhere. Explained in KPI Tree. One document, the whole loop.
An Ossie document is the most portable definition of a metric there is: the same file Snowflake exports from a Semantic View and dbt writes at parse time. KPI Tree reads it as written and runs each metric as one query on the warehouse you link, with the document as the source of truth. Where the standard leaves a rollup unsaid, KPI Tree infers one and says so, so nothing is silently assumed.
What the interchange 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. The interchange 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 interchanged, nothing re-declared
Datasets, fields, dimensions, time dimensions, relationships and metrics come across from the document with their descriptions. Expressions in the ANSI SQL or Snowflake dialect render as they are written.
Choose metrics to sync
4 of 5 selectedRevenue
dimensions: region, channel
Orders
dimensions: region, channel, plan
Average order value
dimensions: region
Active customers
dimensions: plan
Cumulative bookings
dimensions: none
Aggregation read from each definition. Nothing re-declared.
One query per metric, everything else in memory
Each metric is one MetricFlow-rendered query at day grain on the warehouse you link. 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 total0 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 changes to the document.
Revenue
Create Dimension Metrics · ondimensions: region, channel · 5 child metrics created
Each child has its own owner, baseline and nightly driver tests. No YAML changes.
Re-post as a diff, trees and owners untouched
Every document you post 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:1442
Found
3
Created
38
Updated
1
Archived
0
Skipped
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. Export the document, post it, link a warehouse.
Export an Ossie document from where your semantics live
- Snowflake: one system function, YAML out
- dbt Core 1.12: osi_document.json beside semantic_manifest.json
- Converters for Databricks, Sigma, Omni and Tableau in the Apache repo
-- Snowflake: a Semantic View as Ossie YAML
SELECT SYSTEM$READ_OSSIE_YAML_FROM_SEMANTIC_VIEW('analytics.marts.sales_sv');
-- dbt Core 1.12: written at parse time, no extra step
dbt parse
target/semantic_manifest.json
target/osi_document.json
Post it to your connection
- YAML or JSON, up to 50 MB
- One scoped API key, no other credentials
- Sync starts automatically on every post
curl -X POST \
-H "Authorization: Bearer $KPITREE_API_KEY" \
-F "spec=@target/osi_document.json" \
"https://acme.kpitree.co/api/connections/$CONNECTION_ID/semantic_layer/osi/artifacts"
-- 202 Accepted · converted to a MetricFlow manifest · sync started
The metrics run on your warehouse
- One query per metric, on the warehouse you already run
- Read-only credentials, nothing written back
- Inferred rollups marked so you can change them
Warehouse connection
ConnectedRead-only access · credentials never leave the encrypted store
What comes across from an Ossie document. And what the interchange leaves for KPI Tree to infer.
Datasets, fields and relationships the model
Metrics ANSI SQL and Snowflake dialects
Rollups inferred, then yours
Ask an agent the same question twice. Once on the semantic layer, once on Canopy above it.
An Ossie document already gives every tool in your stack the same governed number, and an agent on any of them comes back with it. 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 interchange, whichever platform it runs on, 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.
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.
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?
CanopyHad some of the contextAugust 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.
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.
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.
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.
- 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.
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.
Or connect the source directly. dbt, Snowflake Semantic Views and Unity Catalog metric views each have a native path.
If your definitions live in dbt, in a Snowflake Semantic View or in a Unity Catalog metric view, the native integrations read them without an export step and keep the source doing the maths. The Ossie path is for everything else, and for definitions that move between tools.
Common questions
What is Apache Ossie, and how does it relate to the Open Semantic Interchange?
They are the same standard. The Open Semantic Interchange, OSI, was founded by Snowflake, dbt Labs and Salesforce in 2025 as a vendor-neutral YAML and JSON format for semantic models, and it entered the Apache Incubator in 2026 under the name Apache Ossie. Version 0.1.1 is the released spec and the one KPI Tree reads.
Which tools produce an Ossie document today?
Snowflake exports any Semantic View to Ossie YAML with SYSTEM$READ_OSSIE_YAML_FROM_SEMANTIC_VIEW. dbt Core 1.12 writes osi_document.json into the target directory at parse time. Strategy Mosaic and Honeydew export natively. Databricks metric views, Sigma, Omni, Salesforce and Tableau models convert with the tools in the Apache Ossie repository.
How does KPI Tree read an Ossie document?
Post the document to your connection and every dataset, dimension, relationship and metric in it becomes a tracked metric, exactly as defined. Each metric runs as one query at day grain on the warehouse you link, under read-only credentials, and the sync reports what it created, updated and skipped.
How do I set up an Ossie connection?
Create an Ossie connection in the wizard, link the warehouse the definitions run on, and post the document to the connection’s upload endpoint with an API key scoped to semantic layer uploads, from a terminal or from the last step of your pipeline. Every post starts a sync.
What comes across, and what has to be inferred?
Datasets with their keys and fields, dimensions and time dimensions, relationships, metrics, descriptions and AI context come across from the document. The standard carries no rollup rule, so KPI Tree infers one from each metric’s expression, marks it in the app and the sync report, and never overwrites a rollup you set by hand.
Which expression dialects are supported?
Expressions in the ANSI SQL or Snowflake dialect render as written. A metric that only carries another dialect, or that has no day-level time dimension, is reported as skipped rather than guessed at.
Which warehouses can the metrics run on?
Snowflake, BigQuery, Databricks, Redshift and PostgreSQL. The linked connection should point at the database the document’s datasets resolve in.
Does KPI Tree export Ossie?
Not at present. KPI Tree imports Ossie documents; it does not write them. If you need a definition to travel, export it from the tool that owns it and post it here.
Should I use Ossie or a native integration?
If your definitions live in dbt, in a Snowflake Semantic View or in a Unity Catalog metric view, use the native integration: it reads the source without an export step and keeps the source doing the maths. The Ossie path is for definitions that live elsewhere, or that move between tools.
What happens when the document changes?
Post it again. Each sync is compared with the previous one and the report lists what was created, updated, retired and skipped. Trees, ownership, action history and any rollup you set by hand are preserved.
Related guides. Frameworks and metrics in depth.
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.
How to build a metric tree
A step-by-step metric tree and KPI tree template from North Star to daily levers
dbt semantic layer and metric trees: how they fit together
dbt is the plumbing, the metric tree is the application above it
Related integrations. More sources that work with KPI Tree.
You made the definition portable. Now make the decision accountable.
Post an Ossie document and see your own metrics as a causal tree with named owners and verified actions, in a demo on your data.
The guide
Semantic layer vs business context layer: what a definition settles, and what it cannot.
Read the guide
