I was approached by a software vendor in the aviation industry who wanted to explore integrating AI into their platform. The motivation was straightforward: enable natural language interaction with their data. The challenge, however, was anything but simple.
Their core data lives inside a multi-terabyte Oracle database comprising over 900 tables and thousands of columns, many with cryptic, unintelligible names—things like MT05_TRK_LNK, ORD_HDR_FLG_X, or INV_RSRC_IDX. Even if we could make semantic sense of the schema, there's no way to cram more than a few hundred kilobytes of structure into an LLM’s context window. And of course, sending sensitive industrial data across the internet to OpenAI or Anthropic was a nonstarter for both security and regulatory reasons.
So we were faced with four core challenges:
The first thing I did was establish a semantic layer. Using SemDB, I ingested the vendor's internal documentation—everything from training manuals to developer notes—and applied standard embedding techniques to generate first-pass mappings between domain language and database elements. I then aligned those embeddings with the live schema, creating a crosswalk between real table/column names and human-meaningful concepts like "purchase order," "line item," or "vendor."
This mapping became the basis for an ontology, encoded in ProtoScript and implemented in Buffaly. One advantage of this setup is that ProtoScript can be generated from natural language. So as we updated the documentation or refined the ontology, it was simple to regenerate clean, structured representations of domain logic. This process gave us an interpretable, extensible abstraction over the raw schema.
But the ontology alone doesn't solve the query generation problem. The default approach in the AI world is to serialize the schema into text and drop it into the LLM's context window—then ask for SQL. This is broken by design when you’re dealing with a schema of this size, and even when it’s possible, it’s often wrong. SQL generation from natural language remains unreliable, especially at scale.
So I moved the ambiguity out of the runtime and into the design phase. Rather than trying to generate arbitrary SQL on the fly, I used the ontology to semantically classify incoming queries and resolve them to a curated set of parameterized function classes. For instance, user queries like:
All resolve to a single function class: something like GetPurchaseOrdersByVendorAndDateRange. The function class defines exactly how to translate the parameters into SQL or stored procedures. This setup avoids both hallucination and query injection risk, and we retain full control over the database surface area exposed to users.
We started with the 10–15 most common function classes—based on customer interviews, log mining, and gut sense—and iteratively expanded the set. Thanks to the ontology, one class often generalized across a surprising number of different phrasings. Instead of writing thousands of SQL queries, we built a handful of robust, reusable ones.
Some questions, like “how do I become a better aircraft mechanic?” don’t map cleanly to database queries. Ironically, these are the ones best left to LLMs. But everything grounded in operational data—inventory, maintenance records, part tracking—stays inside the bounds of the system.
The final challenge was security: how to support natural language interaction without sending data to the cloud. Our solution relied on Buffaly’s embedded domain-specific natural language parser, which can interpret queries locally without needing to call out to a general-purpose LLM. Unlike cloud models, our parser is trained specifically within the aircraft manufacturing and maintenance domain. It doesn’t hallucinate, wander off-topic, or break containment. It literally cannot talk about anything outside the domain.
Once the local parser interprets the request, it uses the ontology to map entities and intents. The result is a function class invocation with concrete parameters. From there, Buffaly can execute SQL, call a stored procedure, or hit an internal REST API—whatever the system requires. All of this happens locally. No context windows, no external calls, no surprises.
We delivered a complete natural language interface over a massive legacy ERP database, with zero hallucinations, zero cloud risk, and full traceability. Users can now ask operational questions in natural language, and the system responds quickly, safely, and precisely.
The key insight wasn’t in trusting the LLM to generate SQL—it was in building a semantic layer that let us reason about meaning up front, then resolve meaning to known, safe, executable actions. The result is explainable, maintainable, and fast.
If you’re trying to do something similar—natural language over structured data without security compromise—reach out. This problem’s hard, but solvable, and we’ve got the stack to do it.
