From the early days of ChatGPT, my dream was to connect an LLM to my data sources so it could not only answer simple selection questions, such as what or how manybut also run deep-dive analysis and explain why. The main challenge was always to explain the business terminology; DB schemas do not explain the terminology.

For example, revenue ,in Finance, it means net settled cash after refunds.
Growth may mean campaign-attributed revenue.
Merchandising may mean product sales before discounts.

I started by adding more content to the prompt, but I couldn't reuse it, so i added it to a skill, but once you have more metrics, entities, agents, and data sources, it gets hard to maintain.

I decided to design a lightweight YAML business ontology. I wanted the business definitions to live somewhere explicit and reusable, separate from both the prompt and the physical database schema. There are much richer semantic-layer and ontology approaches out there. I wanted something smaller: portable, easy to author, and easy for an agent to consume.

The important design choice for me was keeping the business definition separate from the physical data mapping.

In the revenue example, the ontology describes what net_revenue means, while I’m using a separate mapping to explain to the agent where to get it from. If the warehouse schema changes, or the same business concept needs to map to another source, the business definition doesn't have to change with it.

I wrote up the reasoning and open-sourced the schema:

Full write-up: https://talc2.substack.com/p/before-you-connect-ai-to-your-data
Schema/repo: https://github.com/valority-luke/ontology-language

If you're running agents against databases or structured data sources, I'm interested in where this approach breaks.

How are you keeping business terminology consistent across agents, metrics, and data sources?