Concepts, not schemas: handling data through an ontology
To turn "which department had the highest attrition this year?" into correct SQL, you need to understand business concepts before database schemas. How we built IRIS, a natural-language data platform, on an ontology-first design.
"Which department had the highest attrition this year?" When an executive asks that, the data team has to translate it: count rows in employees where resignation_date falls in the current year, group by department_id, divide by each department's headcount to get a rate, sort descending. A human can do that translation — because they know what attrition means and which column in which table holds it.
The problem is that an AI handed only the database schema has none of that knowledge. The schema contains a column called resignation_date and nothing else: not the concept of attrition, nor the fact that it maps to this column. That was the first wall we hit building IRIS, our natural-language data platform. Our answer was an ontology.
Why natural language to SQL is harder than it looks
Feeding an LLM the full table schema and saying "turn this question into SQL" — plain Text-to-SQL — demos well. In production it breaks down in three places.
- The vocabulary gap: users say "revenue", "attrition", "premium customers"; the database has
rev_amt,resignation_date,grade='A'. Something has to translate between human speech and column names. - Relationship complexity: the single phrase "by department" can require joining two or three tables. Which join path is correct isn't uniquely determined by the schema alone.
- The accuracy requirement: an analytics tool that confidently produces wrong numbers is worse than none. When a business decision rides on the answer, "plausible SQL" is a failure.
A schema tells you how data is stored; it says nothing about what the data means. Filling that gap in meaning is what an ontology is for.
What an ontology is
Ontology, in philosophy, is the study of what exists and how those things relate. In software it refers to an explicit knowledge model describing a domain's concepts, properties and relationships.
Put plainly: where a database says "the employee table has name, department ID and hire date columns", an ontology says this.
An Employee belongs_to a Department. An employee may also be called "staff" or "personnel". "Attrition" means an employee's employment status has ended.
An ontology assigns aliases to concepts, defines the relationships between them, and bridges human language and database structure. It is a semantic layer sitting on top of the schema.
Ontology-first architecture
IRIS's design philosophy fits in one sentence: business concepts, not the database schema, drive SQL generation. It is an "ontology-first" approach inspired by Palantir Gotham.
Where ordinary Text-to-SQL is question + schema → SQL, IRIS inserts an ontology in between.
Question → [semantic interpretation] → ontology concepts and relations → [mapping] → SQL
The key benefit is separation. Because business concepts (the ontology) are decoupled from physical storage (the schema), a renamed column only requires fixing the ontology mapping, and entering a new industry means writing a new ontology rather than new code. That is why IRIS targets deployment into a new domain within two weeks: analyse the database, write the YAML ontology, ship.
Defining the ontology in YAML
Ontology sounds grand, but in IRIS it is a YAML file people can read and write — so a domain expert can define and extend concepts without a developer.
classes:
- name: Employee
table: employees
aliases: ["직원", "사원", "임직원"]
properties:
- name: department
column: department_id
join: departments.id
- name: is_resigned # the concept of "has left"
column: resignation_date
rule: "resignation_date IS NOT NULL"
Those few lines connect human words like "attrition", "department" and "personnel" to actual columns, join paths and calculation rules. Derived concepts that don't map directly to a column — like is_resigned — can be defined as rules. An ontology is not just a lookup table; it is a knowledge base that carries the domain's rules too.
Where the ontology fits in the eight-stage pipeline
In IRIS a question passes through eight stages: orchestrator → intent parser → ontology resolver → SQL generator → SQL validator → query executor → response formatter → query logger.
The ontology intervenes decisively at stage three, the ontology resolver. It extracts business concepts from the intent the LLM parsed, looks them up in the ontology, and converts them into concrete tables, columns, join paths and calculation rules. Because the SQL generator works from that resolved structure, the LLM guessing wildly at the schema largely disappears.
Safeguards follow. The SQL validator allows only whitelisted patterns through, and five-level RBAC plus department filtering and PII masking prevent users from seeing data outside their permissions. Controlling what may be shown matters as much as getting the number right.
An ontology that grows itself
The biggest weakness of an ontology is the cost of building it. You cannot enter every concept and alias in the world up front. So IRIS's ontology was designed to be self-reinforcing.
- User questions that fail to match the ontology are collected automatically.
- Queries that worked well accumulate in a golden query library (over 100 curated).
- New aliases and concepts are added to the ontology automatically based on usage patterns.
The more it is used, the richer the ontology becomes and the wider the range of answerable questions. It may not understand "attrition" at first, but once defined it knows forever. Knowledge accumulates inside the system.
Why this is better
The real value of ontology-first design is a shift in who is in charge.
Previously, only developers who knew SQL could answer data questions. With an ontology, the people who know the domain best — HR, finance, the operators themselves — define the concepts, and everyone else asks in plain language. The bottleneck on data access disappears.
The structure also scales well. A new domain means describing a new ontology, not rewriting code. A pipeline proven in HR runs unchanged in logistics or commerce once the ontology is swapped. One engine, one body of knowledge per domain.
The bigger picture
Text-to-SQL is "technology that turns questions into queries". But what we actually want to build is a system that accumulates an organisation's knowledge as concepts rather than code.
The ontology is the vessel for that accumulation. Concepts, relationships and rules pile up in a form humans can read; AI answers questions accurately on top of them; and the whole thing grows with use. A schema tells you how data is stored. An ontology tells you what that data means to the organisation. We believe the latter is the real asset of the AI era.