The quarterly review starts and three numbers for revenue arrive with it. Finance shows one figure, sales shows a second, and the board pack carries a third. Everyone in the room is looking at a dashboard, every dashboard is fed from the same warehouse, and the first twenty minutes disappear into an argument about whose number is real.

The instinct is to blame data quality, but the data is usually fine. What forked is the definition. Each tool computed revenue its own way, and each way was defensible. This post is about that failure mode, the semantic metrics layer that removes it, and the governance that keeps the definitions from forking again.

Why the numbers fork

A dashboard is not a window onto the data. It is a small program, and inside that program lives a definition: which tables to read, which rows to exclude, how to treat time. Build three dashboards in three tools and you have written three programs. Nobody decided to fork the definition of revenue. It forked because the definition lived inside the tools instead of in one place the tools share.

  • Revenue: does it include refunds, credit notes, and cancelled orders? Gross or net of discounts? Recognized on the booking date, the invoice date, or the cash date?
  • Churn: measured over thirty days or ninety? Do paused accounts count? Is a downgrade churn or contraction?
  • Coverage: coverage of which denominator exactly? Active customers this month, contracted customers this year, or every account ever created?
  • Currency and calendar: which exchange rate, fixed or daily? Fiscal year or Gregorian? The same transactions land in different quarters under different calendars.
  • Copies: the extract someone pulled into a spreadsheet last year still computes the old definition, and it still circulates.

None of these choices is wrong on its own. Each is a reasonable local decision made by a competent analyst under a deadline. The problem is that the choices were made independently, encoded invisibly, and shipped to executives under the same word: revenue.

Define the metric once, compute it everywhere

A semantic metrics layer moves the definitions out of the tools and into the platform. In the 0plus lakehouse the layer sits above the governed tables and below every consumer. A metric is a named, versioned, owned object: its source tables, its expression, its grain, its filters, and its time semantics, written once. Dashboards, scheduled reports, exports, and the chat interface all ask the layer for net revenue. Nobody re-derives it.

This matters most in a conversational interface. When someone asks about churn in Arabic or in English, the question resolves to the same metric object, computed by the same engine, inside the same perimeter. The answer carries its lineage, so the trail runs from the reply through the metric version down to the certified tables beneath it. Two people asking in two languages get one number and one trail.

metric: net_revenue
owner: finance
version: 3
source: finance.invoices
expression: SUM(amount) - SUM(refund_amount)
time: invoice_date
grain: [month, region, product_line]
labels:
  en: net revenue
  ar: صافي الإيرادات

Governing a metric change

Definitions are not frozen. Finance will legitimately change what counts as net revenue when the refund policy changes. The danger was never change, it is silent change: the analyst who edits a dashboard filter on a Thursday and quietly moves the company's reported revenue. A metrics layer makes the definition a governed artifact, so changing it works like changing a schema, not like editing a chart.

What a governed change looks like

The metric owner proposes a new version with a written rationale. Lineage answers the impact question mechanically: which dashboards, reports, and saved questions consume this metric, and who owns them. The approval lands in the audit log with who signed, when, and the diff between version two and version three. Downstream consumers inherit the new version together on the effective date, and time travel in the lakehouse can still reproduce last quarter's board pack under the definition that was in force then.

A metric definition is a policy, not a formula. Write it down once, version it like code, and let every screen in the company inherit the same change on the same day.

What changes in the meeting room

Because 0plus runs inside your perimeter with zero egress to public AI, the metrics layer can cover everything, including the finance tables nobody would let near a hosted model. The definitions, the computations, and the audit trail all live inside walls you control, and that is verifiable at the network layer.

And because the platform is Arabic first, a metric carries its Arabic and English names as one object. Net revenue and صافي الإيرادات are not two labels drifting apart in two BI tools. They are the same definition, so a bilingual executive team stops translating numbers across the table.

The next quarterly review still opens with a revenue number. But when someone questions it, the response is no longer a duel between dashboards. It is one definition, one version history, and one trail from the figure on the screen to the tables that produced it. Disagreement turns into a five minute diagnosis, and the meeting moves on to what the number means.