Airbus lost a quarter to misaligned revenue metrics: here is the playbook that prevents it

The problem is not that your teams lack data. The problem is that your VPVPA clear statement of the benefits your product delivers, the problems it solves and why customers should choose you over alternatives.View full definition → of Sales, your CFO, and your Head of Product are each opening a dashboard Monday morning, looking at the same business, and reading three different numbers. At Airbus, internal audits have documented how decentralized reporting units maintained divergent definitions of delivered revenue across programs, creating reconciliation cycles that consumed analyst bandwidth for weeks per quarter. This is not an Airbus-specific failure. It is the default state of any organization that built its BIBITechnologies and processes that turn raw data into actionable insights via reporting, dashboards and analysis, so teams can decide based on facts rather than intuition.View full definition → stack incrementally, team by team, tool by tool.

The semantic layersemantic layerA shared business definitions layer that sits between raw data and reports, so everyone uses the same numbers for revenue, churn or margin.View full definition → is the architectural answer: a centralized, governed translation layer that sits between your raw data and your consumption tools, and defines metrics once so every tool, team, and AI agentAI agentSoftware that pursues a goal on its own: it plans steps, uses tools and takes actions with limited human input.View full definition → reads the same definition. The urgency is higher in 2026 because AI assistants now query these definitions directly. A confused semantic layer no longer just misleads a human analyst; it poisons the context a language model uses to answer an executive's question.

Five steps to build a governed semantic layer

Step 1: audit every metric definition in your BI stack

Before writing a single definition, inventory what exists. Pull every dashboard from Tableau, Power BI, Looker, and any embedded analytics your product team runs. List every metric that appears in more than one place. For each one, document the SQLSQLSales Qualified Lead: a prospect the sales team has validated as ready for direct outreach and a proposal, having passed clear qualification criteria.View full definition → or calculation behind it, the team that owns it, and the last date it was reviewed. In most organizations with more than 50 dashboards, you will find between eight and twenty distinct definitions of "active customer" alone. This inventory is your mandate document: it shows leadership the cost of the status quo.

Step 2: govern revenue, customer count and one KPIKPIKey Performance Indicator, a measurable value that shows how effectively you're achieving a specific objective, tracked over time against a target.View full definition → first

Do not try to govern everything at once. Pick the three metrics where misalignment causes the most visible business pain, typically revenue recognition, customer count, and one domain-specific KPI (churn ratechurn rateChurn rate is the percentage of customers or revenue lost over a period. It measures how fast a business loses its existing customer base.View full definition →, on-time delivery, net promoter scorenet promoter scoreNet Promoter Score (NPS) measures customer loyalty by asking how likely customers are to recommend a brand, then subtracting detractors from promoters.View full definition →). Define these three in exhaustive written prose before touching any tooling. Who is included, who is excluded, over what time window, with what currency conversion, adjusted for what returns. Get sign-off from finance, commercial, and product leadership in a single document. This alignment artifact matters more than the technology.

Step 3: choose between dbt and embedded semantic layers

Your options split into two categories. Embedded layers (Looker's LookML, Cube.dev, AtScale) sit inside or alongside your BI stack and expose governed metrics to consuming tools via APIs. Transformation-layer approaches push definitions upstream into your dbt models, wheremetric definitions live as versioned, tested SQL objects that feed any downstream tool. dbt Labs (a vendor with commercial interests in this space) announced dbt v2 and dbt Charts at their 2026 Summit, positioningpositioningThe mental space you want your brand to occupy in your target customer's mind relative to alternatives.View full definition → the transformation layer as the primary place where business meaning gets encoded, not just data shape. Worth reading, but cross-reference with independent assessments before committing budget.

For most enterprises already running Snowflake or Databricks, the practical path in 2026 is a combination: dbt defines and tests the metric logic upstream, Cube.dev or a native BI semantic layer exposes it to tools. This avoids locking your definitions inside any single BI vendor.

Step 4: enforce metric definitions with data contractsdata contractsA formal agreement between the team that produces data and the teams that use it, defining structure, meaning, quality and who is accountable when it breaks.View full definition →

A metric definition written in a YAML file does nothing if the upstream table it reads from can change without notice.Data contracts between producing and consuming teams are what make the semantic layer durable. A contract specifies that the `orders` table will always contain an `order_status` field with a defined set of values, and that any change requires a version bump and downstream notification. Without contracts, your beautifully governed metric breaks silently when a source team renames a column.

Step 5: monitor semantic layer usage and publish metric health

Once your semantic layer is live, instrument which metric definitions are being queried, which teams still bypass it by writing ad-hoc SQL, and where calculation errors surface in production. Publish a monthly "metric health" report to data leadership. Make the semantic layer the path of least resistance: if accessing a governed metric is faster and easier than writing custom SQL, adoption follows without mandates.

What kills semantic layer programs?

The most common failure is "shadow metrics": a team finds the governed definition inconvenient for their use case and builds a private calculation in a notebook or a spreadsheet. This happens when metric owners define metrics without consulting the teams who will use them. The fix is co-authorship, not governance-by-decree. Bring the consuming teams into the definition process before publishing anything.

A second failure is over-engineering the first version. Organizations spend six months building a complete semantic ontology and ship nothing. A semantic layer with three well-governed metrics that finance and sales both trust is worth more than a comprehensive taxonomy no one uses.

Tooling fragmentation is the third trap. If your semantic layer only covers Looker but not the Jupyter notebooks your data science team runs, or the embedded analytics in your product, you have governed a fraction of consumption. MapMapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition → all data consumers before choosing your implementation path.

Finally, do not ignore AI agentsAI agentsAgentic AI refers to AI systems that pursue goals autonomously by planning, taking actions through tools, and adapting based on results, with minimal step-by-step human direction.View full definition → as a consumer class. As LLMLLMA Large Language Model is an AI system trained on vast text data to predict and generate language, enabling tasks like writing, summarizing, and answering questions.View full definition →-based tools query your data catalogdata catalogA centralized inventory of an organization's data assets, enriched with metadata, that helps people find, understand, and trust the data they need.View full definition → and metric definitions directly, an ambiguous or undocumented metric definition becomes a source of confidently wrong AI output. Document the business logic in plain language inside the metric definition itself, not just the SQL.

Quick wins for metric alignment this week

• Pull all dashboards that show "revenue" or "active users" and write down the SQL behind each one. Count distinct definitions. Share that count with your CDO or CTO.
• Schedule a 90-minute session with finance, commercial, and product to agree on one metric definition. One. Write it in prose and circulate for sign-off.
• If you run dbt, add a `metrics:` block to one existing model and wire it to your BI layer as a proof of concept.
• Identify one upstream table that your most-used metric reads from and ask its owner whether a change notification process exists. If not, draft a one-page contract template.
• Check whether your AI assistant tools (Copilot, Gemini for Workspace, or any embedded LLM) have access to your data catalog. If they do, review what metric definitions they are reading.

A semantic layer is only as strong as the organizational process behind it. The technology choices matter less than getting finance, commercial, and product to co-sign a single definition and then making that definition the one true source for every tool that touches the number.