Ask in operational language
Questions could take forms such as “Show me purchase orders from last month,” “List everything we bought from Acme,” or “What did we order from vendor 2241?”
Result · resilient aviation operations
Make difficult ERP information easier to reach—and keep the query path controlled.
An aviation software vendor wanted people to ask operational questions in everyday language. The work created a governed route from those questions to approved ERP functions while keeping the reported execution local.
Business consequence
Operational questions were trapped behind a schema built for systems, not people.
The original case describes a multi-terabyte Oracle database with more than 900 tables and thousands of columns. Names such as MT05_TRK_LNK, ORD_HDR_FLG_X, and INV_RSRC_IDX made the structure difficult to interpret without specialized knowledge.
Teams needed a practical way to retrieve information about inventory, maintenance records, and part tracking without exposing an unrestricted database surface or sending sensitive industrial data to public cloud models.
Source-attributed case facts
The reported design started with a bounded query surface.
900+ tablesin the legacy Oracle environment described by the original case.
10–15 function classesformed the reported starting set before iterative expansion.
Local query pathkept the reported interpretation and execution inside the operating environment.
The figures and operating details on this page are reported in the original Intelligence Factory case. Customer identity, production deployment status, user volume, response time, accuracy, and quantified savings are not published.
Operating explanation
Translate many phrasings into a known, executable action.
Training manuals and developer notes were ingested and aligned with the live schema. That created a crosswalk from cryptic table and column names to concepts such as purchase order, line item, and vendor.
Incoming questions were then classified against curated, parameterized functions rather than converted into arbitrary SQL at runtime.
Resolve the intent
The ontology mapped those variations to a function class—for example, GetPurchaseOrdersByVendorAndDateRange—and extracted concrete parameters.
Execute a governed function
The function defined how to call approved SQL, a stored procedure, or an internal REST API instead of opening unrestricted query generation.
Expand from observed needs
The reported starting set of 10–15 function classes came from customer interviews, log mining, and informed judgment, then expanded iteratively.
Semantic-layer diagram key
- Documents, Notes, and Manuals—shown as raw inputs with cryptic, unintelligible names—feed the Semantic Mapping Engine.
- The engine produces an Ontology Framework expressed in Natural Language.
Technical reason to believe
Move ambiguity into design, then keep runtime behavior bounded.
SemDB generated first-pass mappings from the vendor’s documentation. Those mappings were aligned with the database schema and expressed as an ontology in ProtoScript, implemented through Buffaly.
The resulting abstraction separated business meaning from raw schema names. For operational-data questions, the local parser mapped entities and intents to known function classes; broader advisory questions stayed outside that database workflow.
Execution architecture key
- User Input enters the Local Parser.
- The parser proceeds to Ontology Lookup.
- The lookup proceeds to Function Invocation.
- The function connects to the Database / External API.
- The path returns a Response.
The diagram places these processing steps inside a dashed boundary labeled Safe, Self-Contained Process.
This design reduced reliance on serializing an enormous schema into a model context and limited runtime requests to an intentionally exposed database surface.
The original case reports that operational data stayed local and that no general-purpose external model call was required for this query path. Independent security, regulatory, injection-resistance, accuracy, and performance validation are outside the published record.
Case authorMatt Furnari, CTO, Intelligence Factory
Talk to Us
What information is hardest for your team to reach?
Start with the questions people need answered, the systems holding the data, and the boundaries the query path must respect.
Talk to Us