From Ontology Semantics to Ontology Intelligence: Why Understanding Business ≠ Driving It

The article builds on previous discussions of ontology-driven data governance and introduces the Ontology Intelligence Research Report (1.0) , which frames ontology intelligence as three layers: semantic, decision, and action. This framework points from "understanding" to "action" and raises the engineering question: what capabilities are needed between semantic models and decisions/actions?

From an engineering perspective, ontology semantics solves "what is the business world"; ontology intelligence must further solve "what is happening now, what should be done, how to do it under control, and how results feed back."

Semantic Services Let Agents Understand Business, But Don't Execute It

The semantic layer provides a unified business coordinate system: it tells an Agent what customers, contracts, receivables, and collection tasks are, how they relate, how "overdue" is defined, and which data and documents prove the current state. Semantic services also let the Agent query outstanding amounts, overdue days, dispute records, historical repayments, and credit ratings, preserving data and rule evidence for each conclusion.

But actually handling an overdue receivable requires answering further questions:

Is the receivable within the contractually agreed grace period?

Is there an accepted commercial dispute?

Is the customer under special protection or risk control?

Should a reminder be sent, a task generated, or a manual approval submitted?

Who has the authority to decide, and who bears responsibility for the outcome?

These are no longer mere "semantic query" problems; they are decision and action problems.

Understanding Business ≠ Forming Reliable Decisions

The semantic layer provides a unified business coordinate system; the decision layer must combine current business facts, applicable rules, handling goals, and risk boundaries into explainable judgments. These decisions need not all be performed by ontology reasoning:

Concept classification, relationship derivation, and semantic consistency can be handled by ontology and reasoning engines;

Mandatory fields, value ranges, and relational integrity are better suited as data constraint validation;

Credit limits, risk levels, and handling strategies can be executed by decision tables, rule engines, or business code;

Text understanding, complex situation judgment, and proposal generation can be assisted by large models under explicit semantic and evidence constraints.

The key is not to write all rules into the ontology, but to ensure every decision has a clear semantic definition, applicability conditions, data evidence, execution method, and responsibility boundary.

Ontology provides unified semantics for concepts and relationships in decisions, not that all decisions must be executed in ontology language.

Forming Decisions ≠ Executing Actions Directly

A decision output such as "recommend restricting customer credit limit" would actually change business object and system state; it cannot be treated as an ordinary tool call. An executable action must have a clear action contract:

Target object : which object this action changes;

Preconditions : under what state execution is allowed;

Input/output : required parameters and returned results;

Permission boundaries : who can initiate, who must approve;

Post-state : what state the object should be in after successful execution;

Failure handling : how to handle timeouts, duplicates, partial failures;

Audit evidence : which bases, versions, and execution results must be recorded.

Actions can be exposed to Agents via API, MCP tools, or workflow tasks, but these are only invocation entry points. The action must ultimately be executed by controlled business services or business systems that own the business state and transaction responsibility.

Calling Tools ≠ Reliably Completing Tasks

MCP or Tool APIs solve how Agents discover and invoke capabilities, but they do not automatically solve runtime concerns such as state, concurrency, retry, idempotency, compensation, and human takeover.

For example, an Agent submits a "generate collection task" request but receives no response due to network timeout. It cannot simply retry, or duplicate tasks may be created. The system needs business idempotency keys, task status queries, and execution result reconciliation to determine whether the execution failed or succeeded but the response timed out.

If the scenario involves customer-authorized auto-deduction, boundaries are stricter. Each deduction should bind a business idempotency key composed of "receivable + deduction batch + authorization version". On timeout, the system should first query the original transaction status; if status cannot be confirmed, the task should pause for manual reconciliation rather than retry deduction. If deduction succeeded but business state was not written back, reconcile and补写 state; if deduction should not have occurred, enter a controlled reversal or refund process.

These capabilities belong to business systems, Agent Runtime, and security governance. If the platform provides an object runtime, it organizes object state projections, state transitions, and action results by unified semantics, but does not replace the source business system's transaction authority. These capabilities should not be stuffed into the ontology model.

Ontology Intelligence Is Not a Larger Ontology Library

If ontology intelligence is understood as "putting objects, relationships, rules, and actions into a bigger graph", it easily becomes another static model library. True ontology intelligence is a set of engineering capabilities collaborating around unified business semantics:

Business systems & data services : provide current facts and own source business state and transactions;

Object runtime (optional) : organizes current object state, state transitions, events, and action results by unified semantics;

Ontology semantic layer : defines meaning of objects, relationships, states, events, rules, and action semantics;

Decision services : combine current facts, deterministic rules, model judgments, and human experience;

Semantic tools & action contracts : publish queries, validations, explanations, and actions as controlled capabilities;

Agent Runtime : responsible for task orchestration, state management, pause/resume, and human takeover;

Security & governance : responsible for identity, permissions, policies, audit, versioning, and runtime risk.

These seven are responsibility capabilities; they need not be built as seven independent systems, nor does every request have to pass through all modules in fixed serial order. They can be provided by a single platform or coordinated by multiple existing systems.

For a task like "identify overdue risk and initiate handling", a typical path is: Agent Runtime receives the task, semantic tools fetch ontology semantics and current business facts; decision service combines rules and evidence to form a handling recommendation; security & governance verifies identity, permissions, and human confirmation conditions; action contract then calls the controlled business service to execute. Execution results, evidence, and exceptions return to Agent Runtime and feed object state updates, rule evaluation, and model improvement.

The focus is not on how products are categorized, but on whether responsibility boundaries, invocation contracts, and feedback paths are clear.

Ontology is not the business system, MCP is not the decision engine, and Agent is not the permission system.

From Ontology Semantics to Ontology Intelligence: Form a Minimum Operational Loop

Enterprises do not need to build a full-domain "ontology intelligence platform" from the start. A more feasible approach is to close a minimum loop around a single high-value decision point:

Clarify who the Agent assists, at which node, and what judgment it makes;

Build necessary business objects, relationships, states, rules, and evidence models;

Connect real data that can prove the current business state;

Define a verifiable decision and a clear action contract;

Connect real business services via MCP or API, verify idempotency and failure recovery, retain human confirmation for high-risk actions;

Record model, data, rules, tools, and Agent versions; collect execution results and human corrections.

Whether this loop can handle real business is more meaningful than how many concepts were created, how many triples imported, or how many Agent demos shown. It must at least verify:

Agent identifies correct business objects and current states;

Decision references correct data, rules, and evidence;

Action satisfies preconditions, permissions, and human confirmation requirements;

Timeouts, duplicate calls, and partial failures can recover without producing duplicate side effects;

Execution results truly change business state and are traceable and auditable;

Failures and human corrections drive iteration of models, rules, and capabilities.

Summary

Ontology semantics lets AI know what business world it is in and what the objects, states, rules, and evidence mean.

Ontology intelligence then lets these semantics actually enter decisions and actions: decisions are explainable, actions are constrained by contracts and permissions, execution is performed by real business systems, and runtime results can feedback, evaluate, and improve.

From ontology semantics to ontology intelligence is not adding another layer to the model, but letting semantics enter decisions, letting decisions connect to controlled actions, and making every action verifiable, traceable, and improvable.

Reference: China Artificial Intelligence Industry Development Alliance, Big Data Technology Standard Promotion Committee, Ontology Intelligence Research Report (1.0) .