So you're making big assumptions that the database's table names map to important concepts in the user's vocabulary, and that a thorough understanding of the da

So you're making big assumptions that the database's table names map to important concepts in the user's vocabulary, and that a thorough understanding of the data model can be ascertained from the schema alone? To be brutally honest: that's a silly assumption and likely a dead-end. (One thing I want to emphasize here is how abysmally, unbelievably, depressingly god-awful the vast majority of database schemas are.) You wouldn't expect any user-friendly feature to be automatically stamped on top of a database without the involvement of a programmer, and this is no different. You need some sort of descriptive layer between the database and the query engine (or beside it, helping out) that programmers are involved in building. AI is not going to magically solve this problem for you. Figure out what you need described to you and turn that into a meta language that application developers can write to help your engine out. Frankly I'm wary of any direct link between the user and the database. How do you deal with constraints like "users should only be able to see data associated with their organization in tables X, Y, and Z" if the programmer doesn't tell you? How could you possibly prevent exploits and security problems? Another reason to focus on querying an intermediate layer or relying on a programmer-provided description of what's available. (Or am I assuming way too much, and "hypotheses on the schema" is already this meta-language?)