How governed SQL, a medallion semantic layer, and three query engines make enterprise data actually queryable — without hallucinated column names.

Most Text-to-SQL demos look great until you try them on real enterprise data. You ask “what were our top 10 materials by revenue last quarter?” and the model confidently returns a query that joins ORDERS to PRODUCTS — tables that don’t exist in your SAP system. Or it invents a column called revenue when the real one is buried inside VBAK.NETWR, a field whose meaning you’d only know if you’d spent years as an SAP consultant.

That’s the problem we set out to solve with Onibex ASK — Agentic Semantic Knowledge, an open platform that turns natural language into governed SQL over SAP data. The word “governed” is doing a lot of work in that sentence, and it’s worth unpacking exactly what it means and why it changes everything.

The LLM Should Be a Compiler, Not an Inventor

Most Text-to-SQL systems give the LLM a database schema and ask it to “figure it out.” That works surprisingly well for simple schemas — a handful of tables with obvious names. But SAP HANA schemas are not simple. A real S/4HANA system might have thousands of tables, cryptic four-letter field names, and join conditions that were designed for performance, not readability.

Our approach is different: the LLM never invents structure. It only maps business terms to a curated semantic layer.

The semantic layer — a set of YAML files we call Data Products — is the single source of truth. Every field in every query must trace back to a real column in a real table, with the exact join predicate that connects it. The LLM is a compiler: it takes a natural-language question, looks up the matching business terms in the layer, and emits SQL from those resolved mappings alone. If a term isn’t in the layer, the agent asks for clarification rather than guessing.

When a user asks “what’s our revenue by material?”, ASK maps “revenue” to VBAK.NETWR via the synonyms field. It knows the join from VBAK to VBAP because the Data Product defines it. It never touches any other table. The SQL is reproducible, auditable, and deterministic — not because the LLM is unusually smart, but because it operates inside tight guardrails.

The Medallion Model, Applied to SAP

One of the structural decisions that made everything else work was adopting a Bronze / Silver / Gold medallion model for the semantic layer.

Bronze is raw SAP tables — columns and primary keys, no join logic. VBAK (sales order header), VBAP (sales order item), MARA (material master). These exist so ASK understands the physical schema.

Silver is where the business logic lives. A Silver entity joins several Bronze tables into a coherent business concept, owns the complete join topology for that concept, and defines field roles: measure, dimension, identifier, timestamp. The Silver plane is the agent’s fallback — if no Gold entity covers a question, ASK resolves from Silver and computes the joins.

Gold is denormalized analytics — a pre-joined, pre-aggregated entity that the agent can query in a single scan. When a Gold entity covers the exact metrics and dimensions a question needs, ASK answers from Gold alone. No joins, no planning overhead, minimal latency.

Question: “top 10 materials by net value, Q1” │ ▼ Does a Gold entity cover this? ├─ Yes → single query against Gold table └─ No → resolve via Silver entity (VBAK + VBAP join)

This Gold-first resolution is what keeps query latency reasonable at scale. Well-modelled Gold entities cover the 80% of questions your business users actually ask. Silver handles the long tail.

Three Engines for Different Tradeoffs

One of the questions we wrestled with longest was: how much planning should the agent do per query? More planning means better SQL — but it also means more LLM calls, more latency, and more cost. We ended up shipping three engines that let users and administrators make that tradeoff explicitly.

Flash
1 LLM call · ~15 s · Low cost

Searches the schema as free-text chunks and writes SQL in a single shot. No semantic plan, no join verification, no scope check. Fast and cheap — good for exploratory questions. Least reproducible: the same question asked twice may produce slightly different SQL.

Precise
3 LLM calls · ~60 s · High confidence

Extracts a Semantic Plan IR, runs hybrid kNN+BM25 search with Medallion re-ranking, plans joins with Dijkstra’s algorithm, generates SQL, then audits it against the allowed table set — retrying once if it strays outside. Fully deterministic Data Product selection. Use for compliance, audit trails, or when Flash fails.

Smart
2 LLM calls · ~40 s · Default

Shows the LLM a compact catalog and lets it pick the relevant Data Products — selection is model-driven. But join planning after selection uses the same Dijkstra graph as Precise. Balances speed and accuracy for everyday production use.

The insight behind this design is that where you put the determinism matters. Precise makes the selection of Data Products deterministic. Smart makes the join planning deterministic. Flash leaves both to the model. Users who need auditability use Precise; users who need throughput use Smart; users who need speed use Flash.

What Happens When the Question Is Ambiguous?

Real enterprise data has vocabulary problems. “Sales” might mean VBAK in the SD module or EKKO in MM, from a procurement perspective. “Revenue” might mean gross or net depending on whether the user is in Finance or Sales.

ASK handles this with a three-level disambiguation system backed by a semantic dictionary index in OpenSearch.

Level 1: if a term maps to exactly one entity, the agent auto-resolves. No interruption.

Level 2: if a term maps to multiple entities across different SAP modules, the agent surfaces a disambiguation message — “Did you mean the SD sales order or the MM purchasing order?” — and waits. It doesn’t guess.

Level 3: if the term has no mapping at all, the agent returns a clear message directing the user to their Agentic Trainer. It never hallucinates a resolution.

The semantic dictionary is managed by administrators through the ASK Configuration App — a React SPA that lets you register canonical field labels, SAP column mappings, synonyms, context clues, and disambiguation hints per module, all indexed in OpenSearch for hybrid retrieval.

Artifacts

An artifact is a complete business document — a sales report, an executive brief, a data table pack — generated entirely from natural language. The user describes what they need in a four-step conversational wizard covering name, audience and purpose, data to include, and format. The agent plans and executes multiple SQL queries, writes a structured narrative from the results, and returns a formatted document with embedded data tables.

The output is downloadable as an Excel file — a workbook with a narrative Report sheet, one Data sheet per query result, and a SQL sheet — assembled entirely in the browser with no server-side Excel dependency.

What makes this different from “just generate a report” is that the data in the document is governed by the same semantic layer as every other query. The revenue-by-material table in the executive brief uses the same VBAK.NETWR column as the chat answer. There’s no separate reporting layer to keep in sync.

What We Learned

01. Schema quality is the product

ASK is only as good as the Data Products that describe the data. Every synonym you add, every disambiguation hint in the dictionary, every business-language description of a join condition — all of it directly improves answer quality. The engineering is infrastructure; the semantic layer is the product.

02. Determinism is a feature, not a constraint

We chose to make join planning deterministic — Dijkstra over a graph, not an LLM choosing joins — because our users needed to explain answers to auditors. “The agent picked this join because it’s the shortest path between these two entities in the relationship graph” is a much more defensible answer than “the model chose it.”

03. Three engines is not over-engineering

Flash and Precise serve genuinely different use cases — no single engine covers both well. Smart emerged as the 80%-case default. Having explicit modes also gives users a debugging tool: if Smart fails, try Precise; if Precise is too slow, try Flash. The mode selector is a diagnostic affordance as much as a configuration option.

04. Governance requires ceremony

The dev → prod promotion flow felt like overhead when we designed it. In practice, users told us it was one of the most valuable features. A bad field description can break dev queries, but it can never silently break the production data your CEO is querying on Monday morning.

Try Agentic Semantic Knowledge

The semantic layer specification, the platform code, and the full manual are published on GitHub. If you’re working with SAP data — or any enterprise data with a complex schema — the Bronze/Silver/Gold model and the governed SQL approach are worth understanding regardless of whether you use this platform. View on github.