Domain-Specific AI Chatbot
A semantic layer over an existing relational database, so business questions can be asked in plain language and answered from structured data.
- Role
- Designed and built the semantic layer
- Year
- Recent
- Stack
- Private — available to discuss
01The problem
Relational databases hold the answers to most business questions, but getting them out requires knowing the schema: which tables matter, how they join, what a column like status_cd actually means, and which filters define a metric.
A chatbot that writes queries straight against raw tables tends to guess at those meanings. The gap isn't language — it's missing business context.
Built for — People who understand the domain and the questions, but not the database schema.
- 01Business questionAsked in plain language by someone who knows the domain
- 02Semantic layerBusiness terms mapped to the data: entities, relationships, and what each field means
- 03Structured queryBuilt against defined concepts, not guessed table names
- 04Existing databaseThe relational source of truth, unchanged
- 05Grounded answerReturned in the language of the question
Conceptual illustration of the approach. Implementation specifics are private.
02What I built
- Built a semantic layer on top of an existing database that describes the data in business terms — entities, relationships, and meaning — rather than raw tables and columns.
- Used that layer as the foundation for a domain-specific chatbot, so questions are interpreted against defined concepts and the underlying structured data is easier to understand and query.
The source for this project isn't public, so implementation specifics are left out here. I'm happy to walk through the architecture and trade-offs in conversation.
03Key decisions
- D1
Model meaning before generating queries
Encoding domain concepts once in a semantic layer gives the assistant a stable vocabulary to reason with, instead of re-deriving the meaning of the schema on every question.
- D2
Keep the source of truth in the database
The layer sits on top of the existing database rather than copying data out of it, so answers come from the same structured data the business already relies on.
Want to talk through how this was built?