What This Is
Auto Ontology reached No. 1 on GitHub Trending’s daily chart with a highly specific goal: before generating SQL, the AI should understand the business definitions used across an enterprise’s data. For example, when a user asks for “revenue this month,” the system needs to determine whether that means recognized revenue or order value, and whether cancelled orders should be deducted, then map the answer to explicit fields and calculation rules.
The project consists of a Python backend, LangGraph query orchestration, a Next.js frontend, and Postgres with pgvector. It generates initial drafts of business terms, field mappings, and table relationships from a data catalog. Business users then revise and certify those definitions. At query time, the system passes both semantic and structural information to the model to generate SQL. Because the final SQL is still produced by the model, “automatic generation” does not mean “automatically correct.”
What matters is that Auto Ontology separates generation, validation, repair, and execution into distinct stages. It also provides a REST API and MCP service. Here, MCP—the standard interface that lets AI applications call external tools and data—primarily packages query results; it is not a separate query engine.
Industry View
This approach addresses a reality of enterprise data analytics: database schemas cannot explain every layer of business meaning. Two tables may both contain customer_id without using it in the same way. If an intermediate bridge table is missing, the SQL may still run while producing duplicate counts. Turning reviewed business definitions into shared assets has more long-term value than asking a model to guess them from scratch on every query.
That said, this is not a system that becomes trustworthy simply by adding a chat interface. First, an owner must still confirm whether “revenue” aligns with the finance team’s definition, and the model will not automatically fill in definitions that do not exist in the database. Second, the ingestion service exposes unauthenticated administrative endpoints, while the backend trusts identity information forwarded by the gateway. Exposing internal ports directly could create data and access-control risks. Finally, the model may still choose the wrong aggregation granularity, filters, or join paths. Static checks and formatting constraints cannot replace business acceptance testing.
We therefore view Auto Ontology as a starting point for semantic-layer infrastructure rather than a mature data analytics product. It is better suited to teams with data governance capabilities and the willingness to assign business users to maintain definitions. Without those resources, an organization may end up with little more than a more complicated entry point for generating queries.
Impact on Regular People
For enterprise IT: Businesses may gradually bring data catalogs, business terminology, and query rules under unified management. This can make it easier for conversational analytics tools to integrate with existing permission systems, but it also requires companies to close gaps in semantic governance, certification, and deployment security at the same time.
For professionals: Business users will find it easier to query data in natural language, but the accuracy of those results will depend more heavily on whether internal definitions are clear. People who understand the business and can judge what a metric means will take on more review and certification work.
For the consumer market: Banking, retail, and platform services may offer consumers more natural ways to query information. At the same time, incorrect definitions, permission misconfigurations, or leaked connections could turn back-end problems into service incidents visible to end users.