How Ontology Engineering Gives AI Agents a Business Cognitive Layer

Overall Architecture: Four Layers

The system separates concerns into four layers:

Business Data Sources (leftmost) : Existing structured databases, policy documents, operation manuals, Excel ledgers, external APIs, MCP endpoints, and reusable domain ontologies.

Ontology Construction & Governance : Documents undergo class recognition, structure recognition, and entity recognition; databases undergo table semantics, field semantics, and cross-table relationship analysis. Builders can also maintain classes, properties, relations, and natural-language rules via a management UI.

Real-Time Ontology (core) : Stores business object types, concrete entities, attributes, relations, and rules. Maintains stable object identities and hybrid retrieval indexes (exact, keyword, vector).

Business Agents & Applications (rightmost) : Business agents locate objects, traverse relations, and read rules; builders use the ontology star map and management UI; other platforms consume the same business semantics and investigation capabilities via API or MCP.

A shared governance foundation underpins all layers: identity & permissions, read-only data sources, operation audit, index status, failure rollback, and runtime health checks. Models handle semantic understanding and investigation planning; deterministic services control permissions, writes, index switching, and external query limits.

Data Ingestion Pipeline: From Document/Table to Ontology

The first data flow turns business materials into agent-usable knowledge:

本体推理链
注册来源 → 抽取或映射 → 质量检查 → 写入实时本体 → 同步检索索引

Documents and tables enter an ontology generation flow: the system identifies business object types from materials, then completes attributes, relations, and concrete entities. For databases, it identifies what each table represents, binds source fields to formal properties, confirms object identity via primary keys or composite fields, and establishes relations via foreign keys or composite fields.

LLMs have a defined role: they interpret unfamiliar documents and table schemas, while the system constrains output protocols, evidence scope, and relation types. Models propose semantic judgments; the backend still verifies object identity, reference relations, and data quality.

After passing checks, classes, properties, entities, relations, and rules enter the current project's real-time ontology. The system simultaneously builds exact, keyword, and vector retrieval indexes. Write, quality check, and index update belong to a single controlled operation; any step failure rolls back both data and active indexes to the pre-modification usable state. This guarantees agents never operate on an intermediate state where the ontology has changed but indexes have not.

Ontology Star Map: View Structure Then Instances

The star map provides two perspectives:

Class Graph (skeleton of the business world) : e.g., "Traffic Accident" can "occur on" a "Highway Segment"; a segment can be "monitored by" cameras, "associated with" entrances/exits, "managed by" maintenance units, and linked to medical facilities, rescue stations, and diversion routes. Clicking a class shows its property definitions, allowed class relations, applicable rules, and related entities.

Entity Graph (concrete instantiation) : Under "Traffic Accident" there may be entity "Qingyun Expressway K50+200 Northbound Accident"; under "Road Rescue Station" there are "Qingyun Heavy Rescue Station" and "Yunxi Light Rescue Point". Class relations define semantically valid connections; entity relations record actual links.

Key difference from typical knowledge graph viewers: the star map also answers "What class does each belong to?", "What formal properties does this class have?", "What relations are allowed?", "Which rules apply?", and lets agents start investigations from the selected object's stable identifier. The star map directly projects the real-time ontology: class graph for structure, entity graph for objects and facts, neighborhood view for investigation scope, node details and agents share the same objects, relations, and rules. Content changes with the ontology; the sole fact source is the current ontology.

Query Processing: From User Question to Evidenced Judgment

The second flow starts from a user question:

本体推理链
用户问题 → 定位稳定对象 → 读取属性与关系 → 调用只读数据 → 对照规则 → 返回有证据的判断

Users rarely use standard ontology names. The system first attempts exact match; if not unique, it runs keyword and vector retrieval in parallel, then fuses, re-ranks, and disambiguates to a stable object identifier.

Stable identifiers act as business object identity cards: names can change, databases can migrate, source fields may vary, but the identity remains stable so relations, rules, and historical investigations still point to the same object.

After retrieval, the agent reads facts: object attributes, traverses class and entity relations to expand a limited evidence subgraph, reads natural-language rules, and can fetch current values from authorized read-only databases via controlled queries.

Retrieval scores only locate objects. Final conclusions come from object records, relations, rules, source documents, or authorized database results — avoiding the pitfall of treating "semantically similar" as "business confirmed".

Six Product Trade-offs

Structured data and documents share one business semantics : Rules from policy files, attributes from table schemas, entities from data rows, and cross-table relations all enter the same ontology. Agents can answer both "what does the policy say?" and "what is the current object state?" and explain how they relate.

Business data stays in source systems, no full replication required : The system stores mappings between tables and formal classes, fields and formal properties, and generates lightweight entity indexes. When agents need latest business values, they query authorized read-only sources by stable primary key. This preserves source system data ownership and reduces duplication and sync issues. Ontology stores "how to understand these data"; business databases store "what the current data is".

Object identity and relations persist across sources : The same equipment may appear in asset tables, maintenance records, and policy documents with different names/fields. Stable object identity links these sources to one business object; class relations define allowable inter-type links; entity relations record actual connections. This goes beyond finding similar text: the system knows what object text and data jointly refer to, and what that object relates to.

Ontology writes and retrieval indexes stay consistent : Daily additions, attribute modifications, or relation adjustments are handled in a single controlled operation covering quality check, formal write, keyword index, vector index, and active index switch. Failure triggers full rollback; success publishes new state. Business users and agents always face the same current knowledge.

Retrieval finds objects; facts come from authoritative sources : Many RAG failures happen at the last step: retrieval returns similar content, model writes it as fact. This system first grounds similar content to a stable object, then reads object attributes, relations, rules, and authorized data. If retrieval channels degrade, exact, keyword, or structured queries remain available, with explicit logging of which channels degraded.

Agents can reason but remain read-only : Business agents investigate, rank, flag risks, and suggest actions. They have no ontology create/update/merge/delete tools, nor arbitrary SQL execution. External OpenAPI and MCP tools enter a unified catalog only after testing read-only capabilities. Actions like calling, messaging, creating tickets, or modifying business system state are outside current product scope. This trade-off gives agents complex problem-solving ability while making clear their role is investigation and advice; external execution stays under organizational authorization and approval.

Case Study: Traffic Accident Investigation

Scenario: "Qingyun Expressway K50+200 Northbound accident". Follow-up questions: which segment? nearby cameras and entrances? bidirectional closure? rescue force selection? vehicle diversion?

The system does not store a pre-written answer like "choose Qingyun Heavy Rescue Station". The agent uses four interconnected ontology content types:

Classes : Traffic Accident, Highway Segment, Surveillance Camera, Highway Entrance/Exit, Medical Emergency Facility, Road Rescue Station, Diversion Route.

Class Relations : Traffic Accident --occurs_on--> Highway Segment; Segment --monitored_by--> Camera, --has_access--> Entrance/Exit, --medical_coverage--> Medical Facility, --rescue_coverage--> Rescue Station, --diversion_route--> Diversion Route. Class relations constrain investigation directions, preventing free association by linguistic similarity.

Entities, Attributes, Entity Relations : Each entity inherits its class's attributes and rules. Accident entity records: milepost 50.2km, northbound, 3 lanes blocked, 2 suspected injuries, no hazardous material leak, no spread to opposite direction, heavy truck rollover; linked segment records 4 lanes one-way. Cameras, entrances, medical facilities, rescue stations, diversion routes each have location, online status, ETA, capability, or traffic status, connected via entity relations to the specific segment.

Rules attached to Traffic Accident class : e.g., blocked lane ratio ≥75% → recommend temporary directional closure; bidirectional closure only if hazardous leak or spread to opposite direction; heavy truck rollover → select rescue station with heavy towing capability and current availability, not just shortest ETA; before disposal suggestion, verify online cameras within 3km upstream/downstream, only select available diversion routes.

The agent's actual reasoning chain:

本体推理链
事故实体 → 发生于 → 路段实体 → 摄像头、出入口、责任单位、医疗、救援和分流候选
事故所属类 → 适用规则 → 把事故属性代入条件 → 筛选候选实体 → 形成结论和排除理由

Locate accident to stable entity INC-QY-20260811-001 , then via entity relation occurred_on find "Qingyun Expressway Northbound K42—K58 Segment". All subsequent investigation expands from this anchor, not aimless search.

From segment entity, retrieve candidate objects via relations : monitored_by → cameras at K49+800, K51+000, K56+800; has_access → entrances K46, K55.5, K60; managed_by / jurisdiction_by → Qingyun Expressway Maintenance Center & Highway Traffic Police Brigade 3; medical, rescue, diversion relations yield their candidates. Investigation depth limited to two hops, yielding 26 relevant nodes, 41 explicit relation edges, 6 applicable rules — forming an evidence subgraph for verification, not final answer.

Substitute entity attributes into class rules : Accident at K50.2; scene verification rule requires online cameras within 3km upstream/downstream. K49.8 (0.4km) and K51.0 (0.8km) retained; K56.8 (6.6km) excluded despite segment relation. For entrances, agent compares accident direction and milepost, selects nearest upstream entrance Qingyun North Toll Station and nearest downstream exit Qingyun South Interchange.

Closure judgment : 3 blocked lanes / 4 one-way lanes = 75% → triggers "directional closure threshold", recommend temporary northbound closure. Accident records "no hazardous leak" and "no spread to opposite direction" → neither bidirectional closure condition met, so cannot recommend bidirectional closure just because of heavy truck rollover.

Rescue selection : Not by name "light" vs "heavy". Accident attribute vehicle_type=heavy truck rollover triggers "heavy vehicle rescue selection" rule. Agent compares two served_by_rescue candidates' typed attributes: Yunxi Light Rescue Point ETA 6min but heavy_towing_capability=false; Qingyun Heavy Rescue Station ETA 8min, heavy_towing_capability=true and currently available. Rule constrains capability and status first, then compares time → selects latter. Medical similarly: community hospital 7min but no trauma capability; trauma center 12min meets rule.

Diversion routes : From alternative_route relation. G312 East Line status available, residual capacity 1200 vehicles/hour; Yunxi Connector under construction, status unavailable, capacity 0. Rule requires available routes → former retained, latter excluded.

This case illustrates the core of ontology reasoning: the system does not store ready-made answers but stores the business world's types, objects, relations, attributes, and rules. Each investigation anchors on a concrete object, retrieves a limited evidence subgraph, and within that round completes multi-hop association, rule matching, candidate comparison, and exclusion reasoning. Objects and rules retain source materials for further verification; source materials serve as evidence traceability, not pre-written disposal conclusions. Derived judgments are not automatically written back to the ontology.

Integration with Other Systems

Three connection methods:

External databases via read-only connections and class-level data mappings. Models submit structured query plans; backend validates data source, table, field, permissions, then generates parameterized SQL with execution time, row count, and result size limits.

OpenAPI and MCP tools enter a unified catalog, still subject to permission, schema, timeout, and audit checks.

Other knowledge platforms or business systems can call ontology retrieval and investigation capabilities via API or MCP.

For cross-project reuse, the system exports .ontology.zip containing classes, properties, relations, rules, domain prompts, and reasoning Skills. Runtime entities, physical table bindings, database credentials, business documents, indexes, and sessions remain in the original project. In essence, the system migrates "how this domain should be understood" while preserving each project's own data and permission boundaries.

Current Progress

The local engineering now supports ontology construction, quality checks, index synchronization, graph browsing, read-only agent investigation, and external tool integration. The goal: enterprise original data continues its duties; ontology interprets them into a single business world; agents investigate questions on that world. Thus ontology evolves from a relation graph into a business cognitive layer that enterprise AI can use long-term.