Beyond the Semantic Layer

How analytics systems fail, why the semantic layer was inevitable, and why it is not enough

Lorenzo Bradanini and Lorenzo Tettamanti

Jan 12, 2026

The day I realized data was not the problem

There is a particular kind of frustration that only appears once a data system is, by all reasonable standards, successful.

The pipelines run.
The warehouse scales.
The dashboards load.
The executives nod.

The incident reports stop.
The on-call pager stays quiet.
The architecture diagrams finally look clean.

And yet, something feels deeply wrong.

Not loudly wrong. Nothing is on fire. No red alerts. No missing data. The system does what it is supposed to do.

It produces numbers, charts, trends. It answers questions: at least the ones it was designed to answer.

The discomfort is quieter than that. Harder to name.

I remember the moment clearly. I was reading yet another thoughtful, well-written deep dive on the semantic layer.

It explained metrics, dimensions, abstractions, self-serve analytics.

It talked about centralizing logic, eliminating ambiguity, empowering business users. I nodded along. Everything made sense. The arguments were sound. The tooling was impressive.

This was, by any standard, good work.

Eight hours later, I closed my laptop with an uncomfortable realization I couldn’t quite shake:

If all of this is so well understood,
why does analytics still feel so brittle?

Not broken. Brittle.

The kind of brittle where nothing fails outright, but everything feels slightly unstable. Where confidence depends on context. Where every number comes with a mental footnote. Where trust is provisional.

A single new question could fracture consensus.
A small change in definition could invalidate months of careful work.
Two dashboards could disagree without either being wrong; and without anyone being able to explain, cleanly, why.

Everyone involved was competent.
Everyone followed best practices.
And yet, the system could not absorb change without stress.

That was the moment the problem stopped feeling to be just technical.

This essay is my own attempt to sit with that discomfort and follow it all the way down.

Not to criticize tools.
Not to promote frameworks.
Not to propose yet another layer for its own sake.

But to understand what analytics systems are actually missing,
and why the hardest problems only seem to appear after everything is supposedly working.

The illusion of maturity

For most of the history of data engineering, scale was the enemy.

Could we ingest fast enough?
Could we store cheaply enough?
Could we query quickly enough?

These were clear, honest problems. They had benchmarks. They had roadmaps. They had satisfying answers, usually involving more cores and a larger bill.

And, eventually, we won.

Cloud storage removed scarcity.
Columnar warehouses removed fear.
Distributed systems removed ceilings.

We learned how to move data around at impressive speeds, how to store absurd volumes of it, and how to scan it so fast that no one even pretends to count rows anymore.

We casually talk about terabytes the way people once talked about megabytes, which should probably concern someone.

By almost any technical measure, the modern data stack worked. And yet, the promised land never quite arrived.

Not because the systems failed, everything was green, but because once scale stopped being the problem, something else quietly took its place.

Meaning.

The remaining problems were no longer about throughput or latency. They were about understanding. About interpretation. About agreement.

The kind of problems that don’t show up in monitoring dashboards and cannot be solved by adding another node.

Because at its core, analytics is not really about numbers.

It is about translation.

From events to facts.
From facts to metrics.
From metrics to decisions.

Each step looks straightforward on a slide deck. Each one feels like it should be automatable. And each one, in practice, smuggles in a handful of assumptions while no one is looking.

An event becomes a fact once we decide it matters.
A fact becomes a metric once we decide how to aggregate it.
A metric becomes a decision once someone decides to trust it; often after asking who built the dashboard.

Every translation introduces interpretation, and it reflects a precise point of view.

And interpretation, left unmanaged, drifts.

Slowly. Politely. With good intentions.

Definitions evolve. Exceptions accumulate. A metric that once meant something precise becomes a rough suggestion.

The system still answers questions: it just answers them with a quiet asterisk.

Scale used to hide this. When data was scarce, ambiguity was tolerable. When queries were expensive, people didn’t ask follow-ups. When dashboards were rare, contradictions stayed invisible.

But once analytics became cheap, fast, and everywhere, meaning became the bottleneck.

And that’s when a data system that looks mature on paper starts to feel oddly fragile in practice: like a very impressive machine held together by shared assumptions and a mutual agreement not to ask that question.

When precision isn’t enough

SQL is one of the most successful languages ever designed.

It scales from hobby projects to trillion-row warehouses, and entire careers are built on fluency. And yet, it answers how, not why.

SELECT SUM(amount)
FROM transactions
WHERE status = 'settled'

Syntactically, this is flawless. The query planner understands it, the optimizer executes it efficiently. Semantically? Empty.

What does “settled” mean? Settled with the customer, accounting, or the bank?
Why are refunds excluded, because they were reversed later, or because someone copied this query from last quarter?
Which FX rate applies; spot, month-end, or the one that makes finance look good?

The database does not know. SQL executes logic; it cannot encode meaning, context, or assumptions.

Every analytical query carries this hidden cognitive tax: is this table canonical? Is this join correct? Is this filter business-approved?

Multiply that across dozens of analysts, hundreds of dashboards, and ad-hoc queries running before meetings, and what looks like efficiency is really entropy: quietly accumulating semantic drift.

The semantic layer emerged as an honest response. Metrics became objects. Dimensions became curated. Business logic was centralized. Joins, filters, and aggregations were standardized.

Dashboards could finally speak a common language. This was progress.

But notice what it does not stabilize: assumptions, temporal validity, domain disagreement. The layer freezes a moment in time while the business continues to evolve.

Products change, markets shift, regulations update: and suddenly a once-“canonical” metric feels negotiable.

Because metrics are not facts. Invoices, payments, FX rates: those are facts.

Metrics are interpretations: stories we tell about those facts, often encoded as SQL transformations, dbt models, or metrics-layer objects. And like all stories, they are context-dependent and time-sensitive.

Meaning, it turns out, does not live in the warehouse. It lives in analyst intuition, tribal knowledge, and half-maintained documentation. The warehouse stores raw events.

The semantic layer stores calculated objects. But understanding, what the numbers actually signify, lives elsewhere.

And until we make that explicit, even the most precise analytics system will remain impressively brittle.

The Cognitive Data Interface

Ask a large language model to answer a business question, and you get a revelation: it guesses.

It guesses joins. Should it join orders to payments or transactions? Which key is canonical?
It guesses metrics. Does “net revenue” include refunds? Discounts? FX conversions?
It guesses intent. Is the user asking for last quarter’s revenue, or a forecast-adjusted figure?

This is not because LLMs are careless or sloppy. It is because we never encoded meaning explicitly.

All the rules, edge cases, and assumptions that analysts carry in their heads are invisible to machines. SQL queries, dbt models, and metrics layers are only partially helpful: they are brittle shells without context.

Humans quietly compensate for ambiguity. Analysts know that settled = completed minus refunded, even if that logic is scattered across Slack threads, meeting notes, and half-written docs.

Machines do not. AI exposes these cracks, forcing us to formalize what we never bothered to codify.

AI did not create the problem, it exposed it

This is an important distinction. AI did not invent ambiguity. It only surfaced what was already there.

Every analytical system has been silently drifting under layers of human assumptions. Analysts and dashboards absorb ambiguity without complaint; machines cannot.

AI does not “understand” business rules: it follows logic. If the logic is incomplete, inconsistent, or implicit, the AI will guess, and those guesses highlight exactly where meaning was never formalized.

From metrics to knowledge

The semantic layer asks a reasonable question:

How do we define metrics once, so that dashboards, analysts, and AI agree?

But a deeper question is far more consequential:

How does an organization know what it knows?

This is not a data engineering problem in the classical sense. It is epistemic. It is about encoding the logic, context, and history of decisions in a way that both humans and machines can consume reliably.

Without this, every query, model, and dashboard remains an approximation, and AI only makes those approximations painfully visible.

Definition of the Cognitive Data Interface (CDI)

The Cognitive Data Interface (CDI) is an architectural layer designed to make organizational knowledge explicit, versioned, and machine-actionable. It is built around four core principles:

Separates facts from interpretations
Facts are immutable raw events, e.g., (order_id, amount, currency, event_ts); interpretations are calculated metrics, e.g., RecognizedRevenue, which depends on facts plus business logic.
Versions meaning over time
Metrics and definitions are not static. Each calculation carries temporal metadata so that historical analyses can reproduce what was believed at the time.
Encodes domain knowledge explicitly
Business rules, edge cases, assumptions, and constraints are captured as executable objects rather than scattered in documentation or analyst intuition.
Serves humans and machines equally
Dashboards, analysts, and AI agents query the CDI through the same interface, ensuring consistency across all consumers.

The CDI treats meaning as first-class, executable infrastructure, not documentation. It’s the bridge between raw data and trusted insight, humans and AI alike.

Facts vs. Assertions

Consider this concrete example:

Facts (raw events):

order_id | amount | currency | event_ts
--------------------------------------
1001     | 100    | USD      | 2026-01-01
1002     | 200    | EUR      | 2026-01-02

Assertions (interpretations):

RecognizedRevenue :=
  SUM(amount)
  WHERE status = 'completed'
  USING fx_rate_at(event_ts)

Facts persist: they are immutable observations of what happened.
Assertions evolve: they encode business logic that may change as definitions, rules, or assumptions change.

This separation allows you to version, audit, and reason about both what happened and what we believed happened, without conflating the two.

Time as a First-Class Semantic Dimension

Every metric, rule, and definition has a lifespan. The CDI tracks two types of time:

Valid time: when the fact or metric applies in the real world.
Knowledge time: when the organization codified, recognized, or made a decision based on that fact or rule.

This enables questions like:

“What did we believe was our net revenue for Q4 2025, as of January 1, 2026?”

Even if definitions of “completed” orders, FX rates, or discount rules changed later, the CDI reproduces the answer faithfully.

Dual-temporal modeling ensures metrics are reproducible, context-aware, and auditable, allowing both humans and AI to reason about the past without guessing or hallucinating.

Architecture in Practice

At the heart of the Cognitive Data Interface (CDI) lies the semantic graph, a live, versioned, and queryable representation of organizational knowledge.

Its nodes represent entities, metrics, dimensions, and policies.

Entities might be customer, order, or subscription;
metrics could be RecognizedRevenue or NetRecurringRevenue;
dimensions include region, industry_segment, or customer_size;

and policies encode data access rules or approval constraints.

Edges define relationships such as depends_on for dependencies between metrics or entities, aggregates for roll-ups from facts to metrics, and constrains to enforce policies on metrics or entities.

Versioning ensures that any historical query can reproduce exactly the state of definitions at the time, allowing meaning, not just data, to become first-class infrastructure.

From Intent to SQL

The CDI allows queries to originate from intent rather than pre-written SQL.

For example, when a user asks, “Net recurring revenue growth for mid-market customers last quarter,” the CDI first resolves the metric definitions to determine what qualifies as recurring revenue and which invoice types are included.

It then applies segmentation rules to identify which accounts historically fell into the mid-market bracket, and finally enforces temporal validity, accounting for the FX rates, accounting policies, or definitions in effect last quarter.

Only after these steps does SQL emerge as an execution artifact; it is bytecode, not the source of truth.

Humans and AI alike can rely on the output without ever inspecting the SQL itself.

Governance without friction

In the CDI, access control is not merely a filter: it is part of meaning.

Who can view a metric shapes how it is interpreted.

A revenue metric visible only to finance but hidden from sales carries different implications than the same metric shared across departments.

Encoding access rules as first-class semantic objects ensures that semantics, security, and intent converge, maintaining both trust and compliance across the organization.

Lineage as Explanation

Lineage is not just a directed acyclic graph.

In the CDI, it becomes a narrative: “This number exists because we aggregated completed invoices from these entities, applied FX rates from these dates, and excluded refunded transactions per the finance policy of Q4 2025.”

Every metric carries its reasoning along with its formula, making lineage an executable, auditable, and machine-readable explanation that preserves context for both humans and AI.

Failure Modes

Not all meaning can or should be encoded. Over-formalization risks rigidity: overly prescriptive rules can stifle decision-making and produce brittle systems.

The CDI must balance formalization with flexibility, allowing analysts to override or annotate interpretations when context demands.

Judgment, intuition, and situational awareness remain human responsibilities.

Organizational Truth

The CDI mirrors the organization. When teams disagree on definitions, or when policies evolve differently across departments, the model will fracture.

That visibility is not a flaw; it is a feature.

Analytics systems should reflect organizational complexity rather than pretending it does not exist, ensuring that inconsistencies become actionable insights rather than silent errors.

After the Semantic Layer

The semantic layer was truly inevitable.

Centralizing logic, metrics, and definitions was necessary to establish consistency and trust. But it was never the destination.

The next bottleneck is not scale, nor tooling, but meaning itself. Until analytics systems learn to represent what organizations believe: their assumptions, interpretations, and evolving definitions, they will remain fragile.

The Cognitive Data Interface is not a product. It is a recognition: data was never the hard part.

The true challenge lies in capturing, versioning, and operationalizing organizational knowledge, ensuring that humans and machines alike can reason about the past, present, and future with confidence.

The Software Frontier

Discussion about this post

Ready for more?