Building on the Semantic Layer: OceanBase DataPilot’s Approach to Ontology

A Data Agent that can tell you "What did we spend this month?" isn't necessarily one that can help you manage costs. When costs go up, business users keep asking: Where did the increase come from? Why did it happen? What should we do about it? The number can be exactly right while the explanation still comes from the model's general knowledge rather than the company's actual data. Whether an ontology can help an agent close that gap is the concrete question we faced while building OceanBase DataPilot.

Pulling a number takes reliable data connections, consistent metric definitions, and sound query generation. Explaining a change also requires understanding how business objects relate to each other and finding evidence that can be checked. Supporting what comes next means knowing which workflows and tools are available, and where the permission boundaries are. Over time, we came to a clear conclusion: helping an agent understand how a business actually works takes more than translating table schemas into natural language. Business objects, relationships, knowledge, and executable capabilities need to come together as a shared language that can be verified and maintained. That's what led us to ontology.

Why Ontology Is Getting a Second Look in the AI Era

Ontology isn't new to the LLM era. It started as a way to represent knowledge and make data interoperable: you first spell out which objects exist in a domain, what properties each one has, and how they relate, then agree on consistent meanings for those concepts. The W3C's OWL Web Ontology Language is one standard expression of that tradition. The enterprise ontology we're talking about here leans toward business modeling, and it doesn't mean a product has to use OWL. The problem it tackles is an old one. The same "customer" may be scattered across several systems, under different names and definitions. Business users think of a customer as one complete entity, while data systems store fragmented records. Without a shared layer of meaning between them, people and software have a hard time sharing and reusing that knowledge reliably.

LLMs have made this old problem more urgent. AI can generate queries and write up an analysis, but it doesn't inherently know how a company calculates "cost," which records count as a "customer," or which business relationships to follow to verify a conclusion. Without that context, it may hand you a number along with an explanation that sounds plausible but isn't. And without a description of permissions and operations, it can't safely move into downstream business workflows. Building and maintaining an ontology used to be extremely labor-intensive; now LLMs can help extract and organize business knowledge and take a good share of the repetitive work off people's plates. In scenarios like user growth, business objects also need to connect to controlled actions. That's how a system moves from something you can query to something you can actually run the business on.

As vendors build products for enterprise agents, ontology is no longer just a way to organize concepts and relationships. It's also becoming a way to organize business objects, analytical capabilities, and actions. Palantir Foundry, for example, represents an enterprise's business through objects, links, and actions. Other products are exploring lighter-weight paths that grow incrementally out of specific use cases. But the industry can't yet treat "automatically build the ontology and let the agent make decisions on its own" as a mature answer. A systematic literature review on LLMs for ontology engineering points out that inconsistent evaluation methods, poor reproducibility, and the question of how to combine model automation with human expertise are all still open problems. So the more practical focus right now is to start with high-value use cases, let models assist with modeling, have experts validate the results, and keep refining based on real business feedback.

Getting the Number Right Is Only Step One

DataPilot started with a very specific problem: making natural-language data queries accurate enough to trust. The traditional approach is to build a semantic layer that adds business definitions to tables, fields, and metrics, so the model knows exactly what "customer," "cost," and "revenue" mean inside a given company. That approach works. With reliable business semantics, a model is much more likely to map a user's question to the right data and the right definitions.

But users don't stop at "give me a number." They follow up with "why," and they expect attribution, judgment, and recommendations for next steps. If all the agent knows at that point are table and metric names, its analysis easily falls back on the LLM's general knowledge. The write-up looks reasonable, but it may not match the company's current data or business processes. For business decisions, "sounds about right" isn't good enough.

Ontology offers a way to take that semantic organization further. It's centered on business objects and describes their properties, the relationships between them, and the queries, analyses, or operations that can be performed on them. Instead of a scattered set of tables and a list of tools, the agent works in a space that carries business meaning and can be traced back to the underlying data and rules.

From Tables and Metrics to Business Objects and Relationships

Semantic layers and ontologies aren't at odds. We see ontology as a semantic modeling approach organized around business objects. The key difference isn't whether fields have descriptions. It's that the model's organizing center shifts from the underlying data structures to real-world business objects.

Take "user" as an example. A company's database may have a basic user profile table, a detailed user information table, and user records from several different systems. No single table necessarily matches what a business user means by a complete "user." In an ontology, a "user" can be assembled from multiple data sources through joins, merges, and unified definitions, and it can be linked to other objects such as orders, contracts, and service records. When a business user asks why costs rose for a certain type of customer, the agent can follow those relationships to the relevant data instead of guessing from a table name.

Enterprise knowledge isn't limited to structured data, either. Metric definitions, business rules, documents, analysis methods, and tool interfaces are often spread across different systems. Ontology gives them a reasonably consistent set of business semantics, so for any given question the agent knows what to look up, how to interpret it, and which capabilities it can call. The goal isn't to physically merge every system, or to claim a single model can automatically resolve every ambiguity. It's to reduce the friction of constantly "translating" between business language and the data, knowledge, and tools behind it.

In DataPilot, business objects, properties, relationships, and metrics are already part of the semantic layer. Ontology isn't a separate system bolted on next to the product. It builds on these semantic assets and gradually takes shape as a business model that agents can use, that teams can govern, and that keeps evolving over time.

Lowering the Barrier with AI-Assisted Modeling, Expert Review, and a Q&A Feedback Loop

The value of ontology is easy to grasp. The hard part is building and maintaining one. We tested this in an internal cost analysis project. Even with people who understood both the cost side of the business and ontology methods doing the modeling by hand, it took about two weeks to get an accurate initial model. That was our experience in that particular scenario, not a general estimate of how long the work takes. But it was a clear reminder that a platform can't assume every customer has experts who are fluent in both their business and ontology modeling.

After that round, we captured the reusable lessons from manual modeling and used LLM reasoning to help identify business objects, relationships, and rules. The model produces a first-pass ontology, and business experts then review it, fill in gaps, and correct errors. What "automatic construction" removes here is repetitive work. It doesn't let the model decide what the correct business definitions are. Business goals, metric definitions, and permissible actions still need human sign-off.

We also built a Q&A feedback tool that brings answers and corrections from everyday use back into the modeling process. The initial model doesn't have to cover every question on day one, but it does need to keep improving through real use. Are objects mapped correctly? Are the relationships complete? Do the analysis paths reflect how the business actually works? Only by connecting AI-assisted modeling, expert review, and usage feedback can an ontology go from "good enough to get started" to "reliably useful."

In our experience, the LLM both helps organize and establish business semantics and directly consumes them. That's why ontology shouldn't be treated as a one-off, up-front data engineering project. It should form a closed loop with how the agent is used day to day.

Test It Against Real Business Questions, Not How Complete the Model Looks

So how do you know when an ontology is "done"? Our answer: put it into a minimum viable, real business scenario and see whether it improves the results.

Our internal cost analysis is one example. The original approach could report how costs changed, but when you pushed on the reasons, the analysis tended to drift into generalizations that weren't grounded in the company's data. In an MVP validation after ontology-based modeling, the agent could go further and distinguish whether a cost change came from cloud operating costs, development resources that weren't released on time, or incremental demand from specific customers. That result came from validating one specific business scenario; it doesn't mean the same attribution accuracy will hold everywhere. The point isn't to decide in advance which cause is correct. It's that every explanation should map to data and an analysis path that can be checked.

Just because objects are related doesn't mean one causes the other. An ontology helps the agent find relevant data and organize an analysis path, but the judgment about why something went up still has to be verified against metric definitions, detailed data, and business rules. If you suspect that unreleased development resources drove up costs, for example, you should check resource status, usage records, and billing details, rather than drawing a conclusion just because there's a link between the resource and cost objects.

That's why we evaluate an ontology's contribution to a Data Agent on at least four things. Are the answers more reliable? Can the attribution path be traced and audited? Can business users make decisions and take action based on it? Do the outcomes of those actions flow back into the system? Showing off a relationship graph, or answering a handful of scripted questions in a demo, isn't enough to prove it has made its way into the business workflow. Delivering value consistently in daily use is the real test.

That's also what we actually mean by moving "from answers to decision support." We want the agent to better support human judgment, not take on decisions that haven't been verified. On the governance side, we treat read-only analysis and execution operations separately. Operations with side effects, like writing back to systems or triggering workflows, require human approval before they run, along with clear permission and audit boundaries. An agent making a recommendation doesn't mean it has permission to act on it. Write-back and external integrations also need to open up gradually as governance matures.

Keeping Knowledge Fresh Through Q&A Feedback, and Exploring Cross-Domain Reuse

Enterprise knowledge changes. Updated business rules, revised metric definitions, and system migrations can all cause a relationship that used to be correct to quietly go stale. The subtler problem is that some knowledge goes unused for long stretches, so the team has no easy way to notice it's outdated until an agent calls on it again and the error surfaces.

We focus on two connected paths. The first is usage feedback: recording which business objects and relationships the agent actually traversed to solve a problem, and collecting confirmed good cases and error cases, so maintainers can see which knowledge is working and which needs revision.

Feedback can't be treated as correct knowledge by default, though. Different users may offer conflicting explanations, and the same piece of feedback may only hold under specific business conditions. A safer approach is to first turn feedback into proposed revisions awaiting confirmation, have someone who knows the metric definitions decide how broadly each one applies, and only then decide whether to update the shared model. More usage creates more chances to catch problems, but it doesn't replace validating the knowledge itself.

The second path, reuse, is a direction we're still exploring. The idea is to first build an ontology that solves concrete problems in one business domain, then turn the high-quality knowledge that has proven itself in use into shared assets that other related domains can reference and subscribe to.

That doesn't mean stitching every department's model into one giant graph. Different domains may define the same object differently, and cross-domain integration still has to deal with definitions, permissions, and conflicts. Our direction is to let high-quality knowledge be used in more scenarios under controlled conditions: more use brings more feedback, feedback drives updates, and updates support new scenarios. Whether that flywheel actually gets going depends on whether business users keep using the system, and whether the product can turn feedback into meaningful model improvements.

Point Agents at the Business, Not a Pile of Tables

What ontology means for Data Agents isn't about coining a bigger buzzword. It's about closing a long-standing gap: companies have built up data, rules, and processes, yet agents often see only table names, field names, and scattered interfaces.

OceanBase DataPilot's approach starts from the business questions users actually ask. Building on the semantic layer, it gradually organizes objects, relationships, metrics, and reusable analytical capabilities. It uses models to lower the cost of building them while keeping expert validation in place, and it continuously validates and updates these assets through real use and feedback. We believe that only when an agent can query, explain, and support action along trustworthy business semantics does an ontology become more than a static knowledge graph and turn into a foundation that enterprise AI applications can grow on.

If you're evaluating whether ontology is right for your Data Agent, you don't need to start by mapping all of your company's knowledge into one graph. Start with a business question that comes up again and again and always prompts a "why." Define the objects, the metric definitions, and an analysis path you can verify, then watch whether the answers get more reliable and errors get easier to trace. Getting one concrete question answered more credibly, then expanding the model based on usage feedback, is worth far more than chasing a complete relationship graph from the start.