Define the metric once, or argue about it forever

Two dashboards sat side by side on the conference room screen, and they disagreed. Sales showed $4.18M in revenue for the quarter. Finance showed $3.91M. Same word, same quarter, two numbers, and a room that had cleared its morning to make a decision now spent it arguing over which one was real.

Neither was wrong. Sales counted revenue the day a contract was signed. Finance counted it the day the invoice cleared. Both rules were reasonable, both were buried in a query somewhere, and the two queries had never been compared. The metric had two meanings because it had been defined twice, by two people who never spoke.

A number is only as trustworthy as the least careful query that ever computed it.

The cleanest fix is also the most disciplined one. Take every metric the business runs on and define it exactly once, in a single governed place that sits between the warehouse and every tool that reads from it. This is the semantic layer. One definition of revenue: which table it comes from, the filter that decides whether a row counts, the moment it is recognized, the grain it rolls up to. Every dashboard, every BI tool, every ad-hoc question resolves "revenue" through that one definition instead of writing its own.

The discipline is what makes it work. A metric definition gets treated like code. Moving "recognize on invoice" to "recognize on signature" becomes a reviewed change with a name on it, not a quiet edit in someone's private query at 11pm. One decision, in one place, that everyone downstream inherits automatically.

This is where the method earns its keep, on a problem most stacks never see coming. Slice revenue by something that lives on a related table with many rows per record, the line items inside an order, and an ordinary query multiplies that order's revenue across every line and sums it several times. A $3.91M quarter quietly reports as $5.2M, and no one notices until it is on a slide.

The right approach solves this at the definition, not in each query. The layer knows every metric's unique key and removes the duplicates before it sums, so slicing by any dimension can no longer inflate the total.

You do not fix double-counting with care. You fix it once, in the definition, or you rediscover it forever.

The same design is what makes natural-language analytics survivable. Point a language model straight at the warehouse and let it write SQL, and it will invent its own definition of revenue and state it with total confidence, a fourth number nobody can trace.

The correct way to wire AI into analytics is to put the semantic layer between the model and the data. The model is only allowed to ask for metrics and dimensions that already exist; it picks from defined building blocks, and the layer compiles that choice into the same governed query a human dashboard would run. It cannot redefine revenue, because it never touches the definition.

Self-serve analytics is not letting everyone write queries. It is letting everyone reach the same trusted answer through a different door.

We built exactly this for an analytics product that was losing a standing Monday meeting to reconciliation, and the meeting simply stopped happening, not because the data got cleaner but because the disagreement had nowhere left to begin.

Define the metric once and you change the question the whole company is allowed to ask: not "whose number is right," but "what do we do about it." That is the difference between data you argue over and data you act on.

TensorLabs builds the semantic-layer and AI-query infrastructure behind that kind of single-source-oftruth analytics.