Palantir has shown the market that an ontology can organize enterprise data, business logic, and Actions into a unified operational context. However, as this paradigm enters Chinese enterprises, a more specific question arises: after an Action is successfully invoked, is the order risk truly resolved? Who is responsible for the final acceptance? What is the basis?
Ontology is no longer an unfamiliar concept in the enterprise AI market. More and more enterprises are using ontologies to supplement AI with enterprise-specific business semantics and rules. However, there is still a distance between 'understanding the business' and 'driving business completion.' AI can identify problems, make suggestions, create tasks, and even invoke tools to write back to business systems, but it may not be able to verify whether the actions have improved business outcomes.
If the system cannot continue to observe results, verify completion conditions, and feed the results into the next round of judgment, the ontology will remain at the cognitive level and fail to truly enter enterprise operations.
Qi Yu, Co-founder and CPO of Bateda, has long been involved in BPM, enterprise applications, and business system construction. In numerous projects, he has repeatedly observed a disconnect: the system shows the process has ended, and the interface returns success, but the business problem is not truly resolved. Consequently, he has advanced the research focus of enterprise ontology from semantic understanding and Action invocation to result evidence, acceptance responsibility, and continuous feedback.
In Qi Yu's view, the next step in enterprise ontology construction is not just to make AI understand the enterprise, but to enable this understanding to support a complete chain: identifying problems, understanding context, forming decisions, formulating plans, executing actions, verifying results, and then feeding the results back into the next round of decision-making.
Centered on this judgment, Bateda proposed the 'Six-Step Ontology Operation Method,' advancing the value of enterprise ontology from establishing a common business cognition to driving continuous business closed-loops.
Core Insights
- Ontology construction does not start with a data inventory, but with key business decisions.
First clarify what decisions the enterprise needs to make, and then reverse-define objects, relationships, metrics, rules, permissions, and actions.
- Ontology is not meant to replace data models, knowledge graphs, and business systems.
Existing systems record operational facts. Ontology connects these facts with business objects, rules, permissions, and actions, providing a common business basis for both humans and AI.
- Chinese enterprises do not need to start ontology construction with a large and all-inclusive system.
High-value scenarios with clear boundaries, intensive manual decision-making, prominent cross-departmental collaboration, and measurable business outcomes are more suitable as early landing points.
- Enterprises can delegate action authority to AI, but they cannot hand over responsibility along with it.
To let AI start taking actions, permissions should be granted in tiers based on business risk. High-risk operations involving customer rights or potential losses still require human review or decision-making.
- Successful execution does not equal business completion.
Interface returns, task creation, and system write-backs only prove that an action occurred; they cannot prove that business objectives have been achieved.
- AI completing a single task does not equal forming an action closed-loop.
A complete closed-loop also requires verifying execution results and feeding them back into the next round of decision-making, enabling the enterprise to continuously optimize.
The following is the transcript of this interview, slightly modified without changing the original meaning.
01. The Starting Point of Enterprise Ontology Is Key Business Decisions
iFenxi: From your observation, what is the most core demand of enterprises focusing on ontology today? What stage are they currently in overall?
Qi Yu: On the one hand, enterprises want to use AI; on the other hand, they are still exploring what AI can actually do. Many enterprises have already introduced some AI tools for writing documents, making PPTs, or assisting with personal office work. These things certainly have value, but what enterprises truly want is for AI to participate in daily operations, rather than just staying at office material generation. To achieve this, a common cognition of how the enterprise operates is needed between humans and AI, which is exactly the problem ontology aims to solve. For example, if a salesperson asks what recent orders and opportunities a certain customer has, and what solutions should be provided, to answer this, AI not only needs to know the word 'customer,' but also needs to know that the customer the salesperson is asking about is a group company, the contract is signed with a technology company under the group, the project serves the production factory, and even payments come from different entity companies. It needs to string this information together to trace whether historical deliveries were delayed and whether payments were in default. Lacking this information, the content provided by AI will hardly truly meet the needs. From the perspective of practical stages, I roughly divide the market into three categories. The first category of enterprises has not systematically understood ontology but has already encountered problems such as AI hallucinations, inaccurate answers, and agents working in silos. The second category recognizes the theoretical value of ontology but has not seen enough practical cases and is looking for verifiable business entry points. The third category has already entered local scenario pilots, starting to connect ontology with business systems, processes, and agents, hoping to find a viable path for implementation. Therefore, I believe Chinese enterprise ontology is moving from the stage of 'explaining concepts' to 'verifying value.' The true watershed is not how many objects and relationships have been built, but whether the ontology can support a real business decision and drive that decision to produce verifiable business results.
iFenxi: Why do you think 'business closed-loop' is a problem that enterprise ontology must break through?
Qi Yu: This problem does not start from an abstract concept, but from a phenomenon we repeatedly encountered in the past when doing BPM and enterprise business systems: the process is finished, but the business is not necessarily completed; the system returns success, but the risk is not necessarily eliminated. For example, AI finds that an order has a delay risk, then sends a message to the supplier, creates a coordination task, and the interface returns success. Technically, every Action is successful. But whether the supplier has confirmed the new delivery date, whether the materials are in place on time, and whether the production plan can be restored—these questions still have no answers. This matter involves at least three levels: whether the technical action is executed successfully, whether the process node is completed as required, and whether the business goal is truly achieved. Past systems could usually record the first two levels, but the third level often relied on manual experience, meeting judgments, and post-event reviews. So I propose that 'successful execution does not equal business closed-loop.' This is not a denial of Action capabilities, but a hope to advance ontology research from action invocation to business results: what is the target state, what business evidence is sufficient to prove the goal is achieved, who has the acceptance authority, and how to proceed when evidence is insufficient.
iFenxi: Enterprises already have data models, knowledge graphs, and various business systems. What is the incremental value brought by ontology?
Qi Yu: Do enterprises need to rebuild everything from scratch? My answer is no. Data models, knowledge graphs, and business systems will not be replaced by the emergence of ontology. CRM systems record customers and opportunities, ERP systems record production resources, and warehousing and logistics systems record the delivery process—these are all facts that have already occurred in enterprise operations. But for AI to answer whether a customer is worth continued investment or what risks a contract might have, it must find the facts that support the judgment. The role of ontology is to integrate the facts from the original systems into a set of business objects and relationships, making them a basis that AI can understand and trace. Taking an order as an example, the data model can describe the order fields, the knowledge graph can associate customers, products, and suppliers, and the process platform can configure approval or delivery processes. But enterprise AI also needs to know what business state the order is currently in, which metrics indicate delivery risks, which roles have the authority to adjust plans, which actions require manual confirmation, and what results can prove that the risk has been eliminated. Therefore, ontology construction should not start with 'what data the enterprise has,' but should be reverse-defined from 'what the most critical business decisions of the enterprise are.' What enterprises really care about is not how many supplier fields are in the system, but whether this supplier can guarantee delivery, whether the current order has risks, and whether the procurement plan needs to be adjusted. After determining the key decisions, reverse-search for the required objects, relationships, metrics, rules, evidence, and actions.
02. Let Definitions Enter Instances, Allowing Ontology to Continuously Reflect Real Business
iFenxi: In your research, what problems do the definitions in the business ontology and the instances in business operations respectively solve?
Qi Yu: Ontology definitions describe how an enterprise understands a class of business entities, while ontology instances are the specific operational states of these entities in real business. Taking a contract as an example, the definition layer needs to explain what attributes a contract has, what its relationships are with customers, projects, and suppliers, what rules apply, what actions can be triggered, and where the boundaries are. These definitions constitute the framework of enterprise business operations. And above this framework, every specific customer, every specific contract, and every specific document are instances in operation. When enterprises actually make decisions, they are not facing an abstract 'contract,' but whether a specific contract can be signed, whether it has legal risks, whether the supplier can support delivery, and whether it will conflict with historical contracts. Definitions let AI know the business logic and boundaries, while instances let AI face what is currently happening in the enterprise. With only definitions and no instances, ontology is just a set of abstract concepts; with only instances and no unified definitions, what AI sees are still scattered data records. Only by combining the two can AI both understand business logic and boundaries and face the specific matters currently happening in the enterprise. My view is that ontology must not only remember what state the business is in now but also remember why this state was formed. Only then can humans and AI collaborate around the same business object based on the same business evidence, and re-verify judgments when conditions change.
03. Do Not Blindly Pursue Large and All-inclusive Ontology Construction; Chinese Enterprises Should Start from High-Value Scenarios
iFenxi: Palantir provides an important reference for the implementation of enterprise ontology. In comparison, what kind of ontology implementation path do Chinese enterprises need?
Qi Yu: What is worth learning from Palantir is organizing business objects, data, logic, and Actions around key tasks, rather than simply copying its project scale and delivery methods. The difference for Chinese enterprises lies not in whether to choose high-value scenarios, but in the scope of the first construction, the pace of verification, and the way capabilities are accumulated. Chinese enterprises do not need to first sort out objects, relationships, and rules covering the entire company before finding application scenarios for ontology. A more feasible path is to first find key business decision points with clear business value and clear transformation value. For example, whether a certain order has delivery risks, whether a certain project might be delayed, or whether a certain contract can be paid on time. Around this judgment, the enterprise then reverse-defines what business objects, data, and metrics are needed, what rules to adopt, who has judgment and action authority, what actions can be triggered, and what evidence can prove the problem is resolved. What is formed is a business closed-loop with a limited scope but complete judgment, action, and result verification. In the past, sorting out complex businesses usually required highly experienced consulting consultants to enter the enterprise for a long time. Now, large models and semantic tools can assist industry experts in analyzing materials, organizing business objects, and identifying potential problems, reducing early modeling and verification costs. But they cannot replace business rule confirmation, system integration, permission governance, and result acceptance. After the first scenario is verified, Chinese enterprises can consolidate the formed object models, rules, processes, Actions, and verification methods into platform capabilities and then replicate them to adjacent scenarios. Bateda prefers to summarize this path as: not reducing scenario value, but shrinking the scope of the first construction; not building the ontology first and then finding scenarios, but letting the ontology gradually grow out of high-value scenarios.
04. Action Closed-loop Is Not Just Completing Actions, but Proving Business Success
iFenxi: In your definition, what key links does a complete business action closed-loop contain?
Qi Yu: An action closed-loop cannot be simply understood as 'invoking a tool after finding a problem.' It requires completing the entire chain from state identification, problem understanding, decision formation, action execution, to result verification and feedback iteration. For example, if a manufacturing enterprise finds that its profit margin is low, it cannot stay at the superficial phenomenon of 'profit margin decline,' but must continue to analyze whether the problem is related to inventory turnover. If a better inventory turnover cycle in the industry is 30 days, the enterprise must judge where its gap comes from: supplier stocking methods, payment cycles, sales ordering pace, or production arrangements. These directions could all become solutions, but the enterprise needs to compare which action brings the greatest improvement. After execution, it must also verify whether inventory turnover has truly improved and bring the results into the next customer ordering and production arrangement. Only when results can return to the judgment link can the enterprise continuously optimize; this is the closed-loop we are talking about. Action is the middle link of the closed-loop, and result verification is the core node of the closed-loop. Therefore, a true action closed-loop requires establishing a connection from business decision to result verification: defining the action direction with the target state, judging whether it is completed based on results, and using feedback results to influence the next decision. If the results do not re-enter decision and action, the so-called closed-loop is just a technical link closure.
iFenxi: Which scenarios are suitable for verifying the closed-loop from problem discovery to system write-back?
Qi Yu: Scenarios suitable for verifying this process usually have three characteristics: clear business objects, relatively clear completion standards, and continuously observable action results. Quality inspection is a relatively typical scenario. After defective products are found on the production line, in the past, quality inspection personnel usually analyzed them offline and then submitted adjustment suggestions to the equipment or engineering departments. After establishing a closed-loop, the system can associate quality inspection issues with equipment, process parameters, and historical records, assist in judging the cause, and write the tasks back to the work order system for relevant departments to handle. Another example comes from automobile production. Vehicles need to be exported to multiple countries, and the vehicle machine interface needs to check whether texts in different languages are accurate and whether they exceed the readable range. AI can first complete part of the inspection and feed the discovered problems back to the R&D department; after R&D adjustments, the new production and inspection results enter the system again; problem discovery, R&D correction, and production verification thus form a cycle. Currently, these links still require human participation. As enterprises become more confident in the results, they can gradually give AI more permissions and shorten the cycle from problem discovery to correction and verification.
iFenxi: Once AI starts writing back to the system, enterprises will worry about permissions, responsibilities, and data modification risks. So, how should AI's action permissions be opened?
Qi Yu: AI action governance cannot rely solely on a switch of 'whether to allow invocation,' nor is there a fixed authorization sequence applicable to all enterprises. Permissions must be bound to business objects, action types, risk levels, and responsible roles. AI can be granted action authority, but this cannot eliminate the responsible subject. Actions with clear rules, sufficient evidence, low risk, and reversible results can be executed by AI within the authorized scope; matters involving funds, contracts, core customers, production safety, or major business outcomes should retain manual approval and responsibility confirmation. Even if it is just creating a task or modifying a field, the consequences produced in different business scenarios can be completely different, and risks cannot be judged solely by the technical action type. Enterprises also need to be able to trace what facts AI based its judgment on, why it chose this action, who granted the permission, and who confirmed the result. Whether to expand AI permissions cannot be judged solely by model accuracy, but also by whether past business results are stable, whether the reasons for judgment are explainable, and whether anomalies are traceable. My principle is: enterprises can delegate action authority to AI, but they cannot hand over responsibility along with it.
05. From BPM to Ontology: Focusing on How Business Is Driven
iFenxi: You have always studied ontology from the perspective of BPM and business execution. What difference does this starting point bring?
Qi Yu: Starting from the data platform, the first things seen are data connection and semantic unification; starting from the knowledge graph, the first things seen are object relationships and reasoning; starting from BPM, the first thing we see is how a task is driven within an organization. A lot of frontline business data is generated during process execution. What tasks business departments are handling, what step the process has reached, and what problems customers have raised—this information can be directly upgraded to ontology instances. AI analyzes based on this, making it easier to understand the current state of the enterprise and to bring the results back into the execution process. In my view, business process management still undertakes the underlying execution, ensuring that each business unit completes tasks as required. Ontology sits above it, connecting objects, data, and rules in different processes to support risk discovery, cause analysis, solution deduction, and action suggestions. The relationship between the two is not mutual replacement, but a coordination between the execution foundation and business cognition. Ontology lets the process know why to act, and BPM lets the judgments in the ontology truly enter organizational operations. This is also where Bateda differs from the path of many data-oriented products. We did not study ontology because we mastered more data, but because of our long-term participation in process and enterprise application construction, we are more familiar with how business states are formed during tasks, approvals, collaboration, and execution, and we pay more attention to how ontology connects responsibility, permissions, actions, and results.
06. Six-Step Ontology Operation Method: Consolidating a Single Delivery into Reusable Capabilities
iFenxi: How do you advance enterprise ontology from a construction method to continuous operation?
Qi Yu: We summarize this thinking as the 'Six-Step Ontology Operation Method': define decisions, build evidence, verify completion, use feedback, accumulate experience, and reuse. It is not six isolated functions, but a complete path for ontology from modeling to enterprise operation. Defining decisions is first clarifying what key business decisions the enterprise needs to make; building evidence is establishing objects, relationships, metrics, rules, permissions, and actions around judgments, giving humans and AI a common business basis; verifying completion is judging whether the business is truly completed using target states, result evidence, and responsibility acceptance. Using feedback is letting execution results re-enter the ontology state, influencing the next judgment and action; accumulating experience is recording why the judgment was made at that time, what actions were taken, and whether they were ultimately effective; reusing is consolidating the object models, rules, processes, Actions, and scenario methods formed in the project into platform assets. The core problem the six-step method aims to solve is to ensure that enterprise ontology no longer stays at one-time modeling, but continuously updates, verifies, and accumulates with business operations.
iFenxi: Has this ontology methodology been transformed into runnable, demonstrable, and verifiable product capabilities for Bateda?
Qi Yu: This methodology has formed engineering support at the product level. Bateda currently uses the enterprise ontology engine as a unified business semantic foundation and has formed capabilities around the ontology, including construction, decision analysis, intelligent prediction, digital employee collaboration, business action closed-loop, and the FDE workstation. The enterprise ontology engine unifies objects, relationships, metrics, rules, permissions, and actions, and continuously manages running object instances; construction capabilities transform the ontology into applications, processes, agents, and business workstations; decision analysis and prediction capabilities conduct real-time analysis, anomaly explanation, root cause diagnosis, risk warning, and business deduction around object states. After the system forms a decision, digital employees and the BPM execution engine link the judgment to tasks, approvals, system invocation, result write-back, and acceptance feedback; the FDE workstation provides a unified analysis and action entry for managers, business personnel, and operational roles. Ontology is not an isolated module among them, but the common business layer connecting understanding, construction, decision, prediction, action, and results. The goal of the FDE team entering the customer site is not just to complete a single project delivery, but to consolidate the object models, rules, processes, and Actions in the scenario into reusable platform capabilities for the future. At the same time, Bateda is also continuously verifying the business effects and reuse value of these capabilities through real customer scenarios.
iFenxi: You just mentioned that Bateda is continuously verifying product capabilities. So in the next few months, what business propositions does Bateda plan to focus on verifying?
Qi Yu: We hope to verify three questions around real customer scenarios. First, can the ontology enable humans and AI to form decisions based on the same set of business evidence? Second, after AI takes action, can the system judge business completion based on target states, result evidence, and responsibility acceptance? Third, can the experience formed from a single project delivery be consolidated and reused in subsequent business scenarios? Verification will not just look at model answer accuracy or interface invocation success rates. We will also pay attention to efficiency indicators such as problem discovery time, judgment time, and handling cycle, closed-loop indicators such as task completion rate, overdue rate, and repeated problem rate, as well as the reuse of objects, rules, Actions, and templates. This is not verifying whether a single isolated function can run, but verifying whether the ontology can enter enterprise operations from a cognitive tool. Subsequently, Bateda also plans to combine customer practices to further disclose verification methods and phased results.
07. Enterprise Ontology Will Become the Common Business Layer for AI Entering Organizational Operations
iFenxi: In the long run, what role will ontology play in the AI system of Chinese enterprises?
Qi Yu: In the long run, I believe ontology will not just be a modeling tool, nor will it belong only to an independent system, but will gradually become the business layer that enterprise data, AI, processes, and applications all rely on. In terms of product form, ontology may exist as an independent platform or be embedded as a foundational capability into data platforms, agent platforms, and enterprise applications. The two forms are not contradictory; the key is not what product name it exists under, but whether it can provide a common business basis for humans and AI in the enterprise. The important inspiration from Palantir Ontology is bringing objects, data, logic, and Actions into a unified operational context. But the system environment, organizational structure, permission system, and delivery methods of Chinese enterprises have their own complexities. Chinese enterprise ontology cannot just replicate a product structure; it must also answer how to enter existing systems, how to connect complex processes, how to close the loop of evidence and responsibility, and how to consolidate a single delivery into reusable capabilities through FDE. The improvement in enterprise iteration speed brought by ontology is not just about making software development faster; more importantly, when business changes, the enterprise can quickly adjust decision logic, action paths, and acceptance standards around the same set of objects, rules, and permissions, and reuse effectively verified experience in new business scenarios. Personal efficiency improvement does not equal organizational efficiency improvement. Only when business objects, data, knowledge, processes, and actions are connected can humans and AI, and AI and AI, collaborate around common goals. Therefore, ontology will become the common business layer for AI entering enterprise organizational operations, and its true value lies not in letting AI know more, but in enabling the enterprise to form decisions, drive actions, verify results faster, and continuously reuse effective experience.