Skip to content

Semantic layer vs. context layer

"We already have dbt" — or Cube, or MetricFlow — is the most reasonable objection to a context layer, and it deserves a real answer rather than a rebrand of the same idea.

The short version: a semantic layer models your metrics; a context layer governs everything your metrics can't say. They are adjacent layers, not competitors: Renbase reads your dbt project as a source and serves its definitions alongside the knowledge that never made it into YAML. Nobody throws away a semantic layer to adopt a context layer.

What semantic layers do well

Credit first, because these are serious tools:

  • dbt Semantic Layer / MetricFlow defines metrics once, in code, next to the models that materialize them — reviewed in pull requests, versioned in git, consistent across every BI tool that queries them.
  • Cube adds a universal layer with caching, access control and APIs, built to serve the same governed metrics to dashboards, embedded analytics and, increasingly, AI agents.

If a question can be phrased as "aggregate this measure by these dimensions" over modeled tables, a semantic layer answers it correctly and repeatably. That's exactly what it's for.

Where the YAML stops

The knowledge that breaks data agents in production is rarely a missing metric definition. It's the part that has no field to live in:

Conditional, tribal knowledge. "For CRM questions, new USCAN deals since 2025 live in Affinity; older global leads stay in Salesforce." That's a rule with a scope and an expiry, not a measure with dimensions. There is no YAML key for it, so it stays in Slack — and every agent that doesn't read Slack gets it wrong.

Documents. The policy that explains why the metric excludes promotional credits lives in a PDF, a wiki, meeting notes. A semantic layer doesn't ingest documents at all; for a context layer they are first-class content, indexed and citable next to the definitions.

Disputes and drift. When finance and product both have an approved definition of active_user, a semantic layer holds whichever one got merged. Renbase returns both, marked as conflicting, with provenance — and when a definition's source changes or disappears, the entry is flagged stale and answers say so.

An answer contract for agents. A semantic layer returns query results. It has no concept of abstaining, of citing an approver, or of telling an agent "this definition expired". That contract — cite, or decline, and expose conflicts — is the part agents actually need to stop confidently inventing numbers.

Side by side

Semantic layer (dbt SL, Cube) Context layer (Renbase)
Core object Metrics and dimensions over modeled tables Definitions and documents in one governed corpus
Conditional rules No place for them First-class entries with scope, version and approval
Documents Out of scope Ingested, indexed and citable
Conflicting definitions Whichever is in the repo Both returned, marked, with provenance
Staleness Not tracked at answer time Flagged; freshness travels with every answer
Agent interface SQL/API for metric queries MCP tools: exact resolution, retrieval, cited answers, abstention
Authoring loop Engineers, via pull requests Connectors draft; any approver reviews in the workspace
Relationship to your dbt Is your dbt Reads it as a source; never replaces it

When the semantic layer alone is enough

Honesty cuts both ways. You don't need a context layer if:

  • Every question your agents face is a metric query over modeled tables, and the answers don't hinge on documents or conditional exceptions.
  • Your definitions are stable, undisputed and fully captured in the repo — no "it depends on the region and the year" anywhere.
  • The consumers are dashboards and analysts, not agents that must justify answers to customers or auditors.

If, instead, your agents keep being wrong for reasons that are written down nowhere — or written down in four contradictory places — that's the gap the context layer exists to close. The context layer page describes the category in full, and vs. managed RAG covers the retrieval side of the same question.

Sources