Supper · The semantic layer

Every BI tool has a semantic layer. Almost none are good enough to trust with an AI agent.

Most are thin extensions of SQL view logic — renamed columns, basic joins, hand-maintained measures. Supper's AI generates a far richer model: table grain, join safety, business vocabulary, institutional quirks, multi-step calculations, and live SaaS context. Automatically, from day one, kept current without engineering work.

16.7%
LLM accuracy against real enterprise schemas with no governed semantic layer
arXiv 2311.07509
>95%
Answer accuracy through Supper's AI-generated governed semantic layer
 
4–32×
Higher token cost when agents query raw data without a governed layer
OnlyCLI benchmark 2026

01 — Layer comparison

Three ways to get intelligence out of your data — and how much each one actually knows.

Traditional BI encodes structure. Teams experimenting with AI encode context in skills and system prompts. Supper generates a complete governed model autonomously — covering the layers neither approach reaches.

Traditional BI stack
Transform + BI tool
SQL models · BI config · manual upkeep
DIY AI approach
Skills + system prompts
Schema in context · per-user · per-conversation
AI-generated · always current
Supper
Built overnight · maintained by your FDA
Foundation — where most approaches stop
01Raw schema
Native
Tables, columns, data types read from the warehouse. Manually documented where it matters.
Via skill
Schema pasted or fetched into the context window. Works at connection time.static · drifts silently
AI generated
Full schema ingested across every connected source — warehouses and SaaS APIs — with field descriptions generated from naming patterns and value distributions.
02Structural transforms
Native
Models, renamed fields, type casts, basic aggregations. Maintained by engineers — and they break silently on schema changes.
Partial
Mappings described in prose: "revenue is stored as amount_usd." The model tries to follow it — no validation.unverified · no enforcement
AI generated
Field aliases, type normalisation, and aggregation patterns resolved automatically across sources. No transform pipeline required.
03Join paths
Manual
Declared in BI config or transform contracts. Explicit — but scope-limited and brittle to schema changes.
Partial
Join logic described as instructions: "customers joins to orders on customer_id." No fan-out or dedup validation.no safety checks
AI generated
Cross-source joins inferred and validated — including warehouse-to-SaaS joins — with fan-out risk flagged automatically.
04Dimensions & measures
Native
Rich dimension/measure library in BI config. Powerful — but locked inside the BI tool, invisible to external agents.
Via skill
Metric definitions written into the system prompt. One skill, one user, one version — different users may run different ones.not shared · not governed
AI + FDA
Generated from schema, refined by your FDA. Portable — available to Claude, agents, workflows, and dashboards through one governed layer.
Business intelligence — where the accuracy gap opens up
05Metric definitions & business logic
Partial
Sometimes encoded in BI expressions — but not portable, not governed outside the tool, not applied to ad hoc questions.
Via skill
Logic described in prose, no enforcement. The CRO and CFO asking the same question can get different numbers.inconsistent across users
SupperAI + FDA
Your ARR formula, churn definition, segment logic — surfaced by AI, confirmed by your FDA. One definition, enforced for every user and agent.
06Table grain & join safety
Not captured
Partial
Occasionally noted in prompts: "this table is one row per subscription." The model reads it — but can't be held to it.stated but unenforceable
SupperAI generated
Each table's grain documented — one row per what, keyed how. Join paths validated for fan-out. Supper encodes it so the model never guesses.
07Complex calculations
Manual
Ad hoc SQL or Python — not part of the semantic layer, not reusable, run by hand when someone needs them.
Partial
Simple formulas work in a skill. Multi-step calculations spanning Python, SQL, and several sources degrade as complexity grows.degrades with complexity
SupperPython + SQL
Cohort retention, blended CAC, LTV ratios, custom fiscal periods — encoded in the model and applied to every relevant question automatically.
Institutional knowledge — only Supper captures this
08Business vocabulary
Not captured
Via skill
Aliases written into system prompts. Bloats every conversation, even when irrelevant. Stale the moment your team's language evolves.context tax · stale over time
SupperAI + FDA
Plain-language aliases for every field — so "bookings this quarter" resolves to the right table, join, and metric without guessing. The vocabulary your team uses, not your schema's.
09Quirks & known caveats
Not captured
Not captured
SupperAI + FDA
"The March 2023 cohort is unreliable after migration." "This field double-counts multi-product deals." Surfaced with every relevant answer — not buried in an 18-month-old Slack thread.
10Usage guidance
Not captured
Not captured
SupperAI + FDA
Field-level guidance — "use contracted_arr for finance, pipeline_arr for sales forecasting." Encoded once, surfaced whenever it's relevant.
Live source context — updated automatically
11Live SaaS source context
Not captured
Via skill
SaaS field descriptions copied into prompts by hand. Stale the moment a field is renamed or a property added.always behind · manual upkeep
Live · auto-updatedConnected SaaS
Field labels, property descriptions, and object definitions pulled from connected SaaS sources and kept current. The live definition from the source itself, in real time.

Already have transform models or BI definitions?

Supper can read existing SQL transform models and BI definitions as a starting point during migration — so you don't rebuild from zero. A convenience for teams moving off existing tooling, not a dependency. Supper generates its own complete model autonomously.

02 — How it's built

Building this by hand takes months. Supper generates it overnight.

A first-pass model is generated automatically the night you connect a source. Your forward-deployed analyst encodes the business knowledge over the following days, and the model stays current on its own.

Step 1 · Overnight

AI scans every connected source

Schema structure, field names, data types, value distributions, and relationships — all ingested and used to generate a first-pass semantic model automatically.

Step 2 · Days 2–4

Your FDA encodes business knowledge

Metric definitions, business vocabulary, table grain, usage guidance, and known quirks — reviewed and approved with your data team in short async sessions.

Ongoing

The model stays current

Schema changes are detected and surfaced. SaaS field definitions update in real time. Your FDA handles refinements as the business evolves.

03 — Why it matters for agents

A shallow semantic layer isn't just a BI problem. It's an AI accuracy problem.

Query your data through a thin layer — or none — and an agent has to infer everything Supper encodes explicitly: table grain, metric definitions, vocabulary, caveats. It guesses. On real enterprise schemas, it gets those guesses wrong most of the time.

Without a governed semantic layer

16.7%

Average LLM accuracy on real enterprise SQL schemas, zero-shot. For high-complexity queries: 0%. The model returns confident answers that look correct. They're not.

With Supper's semantic layer

>95%

Answer accuracy when the model queries through Supper's governed layer. The model is the same. What changes is how much it knows before it answers.

Token cost — without Supper

4–32×

Higher cost for agents querying raw data or thin layers. Schema rediscovery, retry loops from wrong answers, and context bloat compound on every question. One documented team: $81K/month in overhead.

Round trips per question

5 → 1

An agent on raw data makes 5 sequential calls to discover schema, find fields, resolve filters, and run the query. Supper's pre-compiled model resolves all of it internally — one call, ~10 seconds.

The accuracy gap isn't a model-quality problem. Layers 1–4 — what most teams have — get an agent to a number. Layers 5–11 get it to the right number, with the right definition and the right caveats applied. That's the difference between an answer you can act on and one you have to verify by hand before you trust it.

The practical difference

The semantic layer that needed a data team to build is now something any company can have by day five.

Building layers 5–11 by hand — encoding metric definitions, documenting table grain, capturing institutional quirks, maintaining vocabulary — is a multi-month data-team project. One that drifts the moment someone renames a field or revises a definition. Supper generates the foundation automatically, your FDA maintains it as the business evolves, and the model stays current without engineering work.