Semantic Layers · by Ogentech

Ask your data the questions you'd ask your best analyst.

Semantic Layers connects to the databases you already run — SAP HANA, Oracle, Snowflake, Postgres, your S3 data lake — and lets planners ask real business questions in plain language. Every answer arrives with a definition you can audit and a number telling you how much to trust it.

Runs inside your environment. No frontier LLM. Your data never leaves your perimeter.

Semantic Layers
Planner

Was the September end-cap promo successful?

Incremental units vs. matched control stores

+12.4% uplift

Sustained through the two weeks after the promo ended, with no meaningful pull-forward. 96% posterior probability the effect is real.

Confidence 94% Data purity 98% 312 stores · 4 weeks Show the query

“Successful” resolves to the certified metric promo_incremental_units (v3), owned by Demand Planning — not to whatever the model guessed this morning.

The questions planners actually ask

Was the promo successful? Which stores look stocked out right now? Where is demand shifting away from forecast? Which SKUs are over-stocked against plan? What changed since last week? Is this supplier slipping?

None of these are a single SQL query. Each one needs a business definition, the right data, and a statistical test — which is exactly what a semantic layer provides.

Why most “chat with your data” tools disappoint

Impressive in the demo. Silent and wrong on your warehouse.

Tools that ask a language model to write SQL score above 90% on academic test databases — a handful of tables with clean names. Put the same systems in front of a real enterprise warehouse, with hundreds of tables, cryptic columns and no declared join keys, and accuracy collapses.

Text-to-SQL accuracy: laboratory vs. real enterprise data

Execution accuracy of leading published systems on four public benchmarks. The first two use small, tidy databases; the last two use enterprise-scale and real private warehouses.

Academic / tidy databases Enterprise-scale & real warehouses
Spider 1.0 ~5 tables per database
91%
BIRD larger public databases, dirty values
82%
Spider 2.0 enterprise workflows, 3,000+ columns
17%
BEAVER real, private enterprise warehouses
11%
0%25%50%75%100%

Best reported execution accuracy, public benchmark results 2023–2026 (Spider 1.0, BIRD, Spider 2.0, BEAVER). The gap is not a model-size problem — it is a grounding problem.

The silent wrong answer

A query that runs cleanly and returns a confident, incorrect number is worse than an error. Nobody catches it until a plan is already built on it.

Your terms aren't in the schema

“Stocked out”, “successful promo”, “active store” are business definitions. They exist in your team's heads, not in a column name a model can read.

Your data isn't clean

Missing days, late feeds, broken joins, a store that changed region. An answer computed on incomplete data looks identical to one computed on complete data — unless something is measuring it.

How Semantic Layers works

A governed layer between the question and your data.

We don't ask a model to guess your schema. We build a certified map of your business — entities, metrics, joins, security — and the question is answered by choosing from that map. Every step is inspectable.

01 · Connect

Your existing data

Read-only connections to the systems you already run. Nothing is copied out, nothing is sent to a third-party model.

SAP HANAOracleSnowflake PostgresS3 / Parquet
02 · Define

The semantic layer

Your metrics, defined once and owned by your team: grain, additivity, joins, synonyms, row-level security — versioned in git.

Certified metricsDeclared grain Row-level security
03 · Answer

Text-to-metric engine

A small, self-hosted model selects the right metric, dimensions and filters — then a validator checks the generated query before it ever runs.

Runs on your hardwareQuery validated Read-only enforced
04 · Score

Confidence engine

Data purity, model certainty and a statistical test combine into one number: how likely this answer is wrong. Below your threshold, it declines instead of guessing.

Confidence scoreAbstention Full audit trail

Because the layer is governed, security travels with the question: a regional planner and a category director asking the identical question receive correctly different answers — enforced in the generated query, not filtered afterwards.

The core difference

Text-to-metric, not text-to-SQL.

Asking a model to write SQL means trusting it to invent one correct answer out of an unbounded space. Asking it to pick a certified metric means choosing from a short list your team already approved. Same question, radically different risk.

Text-to-SQL

The model writes the query

-- generated, unverified SELECT s.region, SUM(f.qty) / COUNT(DISTINCT f.day) FROM fact_sales f JOIN dim_store s ON f.str_cd = s.store_key ← wrong key WHERE f.promo_flg = 'Y' ← wrong promo GROUP BY 1;

It runs. It returns a plausible number. Nothing in the system knows it joined on the wrong key or that promo_flg was retired two years ago.

Space of possible outputs

Effectively unbounded. Every join, filter and aggregation is a chance to be silently wrong.

Text-to-metric

The model picks from your metrics

promo_incremental_units stockout_rate fill_rate forecast_error_mape on_hand_days_cover sell_through_rate

It chooses a metric, a dimension and a time window. The SQL is then generated by the semantic layer — the same way it is for your BI dashboards, with the same joins and the same security.

Space of possible outputs

Your certified metric set. If no metric fits the question, the system says so instead of improvising.

What you get either way

  • An answer in seconds, in the planner's own language
  • The exact query, shown on request

What only the governed layer gives you

  • One definition of “revenue” across chat, BI and planning
  • Row-level security a question cannot talk its way around
  • A refusal when the question has no certified answer

Trust, quantified

Every answer carries a number: how likely it is to be wrong.

Other tools show you a badge. We compute a score. Data completeness, freshness and referential integrity on exactly the tables your question touched, fused with the engine's own certainty and the statistical strength of the result.

Confidence on the promo question

Three independent signals, measured per question, combined into one score — and a threshold below which the system declines to answer.

94%
confidence · 6% probability of a false answer
Data purity98%
Nulls, freshness and referential integrity on the 4 tables this question touched.
Coverage & availability91%
312 of 344 stores reported for every day of the promo window; 32 excluded and named.
Statistical strength96%
Posterior probability that the uplift is real, from a matched-control causal test — not a raw before/after difference.
And when it isn't confident

Two of your three source feeds haven't refreshed since Tuesday, so 19% of stores are missing from this window. I can't answer this reliably yet — here's what's missing. A system that reliably knows when it doesn't know is worth more to a planner than one that is occasionally, silently wrong.

Illustrative values from a promotion-effectiveness question. Thresholds for answering vs. abstaining are set by you, per question type.

It learns from your planners

When a planner corrects a definition or rejects an answer, that correction becomes part of the layer's memory — retrieved the next time a similar question is asked. No opaque retraining.

It notices when the data moves

New feeds, new stores, a distribution that has drifted — the layer re-checks its assumptions when data changes and flags questions whose answers should be revisited.

It stays inside your walls

Small, self-hosted models. No question, schema or row leaves your environment — which is also why we can measure the engine's own certainty rather than guess at it.

Fits what you already run

Legacy systems included.

Most planning data doesn't live in one modern warehouse — it lives across an ERP, a legacy relational database, a lake of Parquet files and a couple of extracts nobody wants to touch. Semantic Layers reads them where they are, and federates the query.

Ogentech has spent 20+ years connecting to exactly these systems for forecasting and inventory optimisation. Semantic Layers is that integration experience, turned into a question box.

SAP HANA Oracle SQL Server Snowflake Databricks PostgreSQL Amazon S3 / Parquet BigQuery Trino Blue Yonder / JDA Power BI CSV & flat extracts

Built by Ogentech

Not a first attempt at supply chain data.

Semantic Layers comes out of Ogentech's forecasting and inventory practice — the same team behind ForecastPlanner™, and the same commitment to explainable AI rather than a black box.

1,000+
endpoints in retail, pharma & industry
6B+
data points processed
20+
years of forecasting expertise
20%+
improvement in forecast accuracy
10+
year client partnerships

See it answer a question from your own data.

Bring one messy dataset and three questions your planners actually argue about. We'll model them, run them, and show you the confidence score — including where it declines to answer.

Semantic Layers is an Ogentech product. Everything about the company, ForecastPlanner™ and our case studies lives on ogentech.com.