Ontology-Driven Data Governance: Business Modeling from Research to Symbolic Models

Sequence After Scenario Selection

After selecting a business scenario for ontology-driven data governance, the next step is not to open the database or start drawing ontology models. Instead, the proper order is: clarify the business first, then transform it into a machine-understandable, queryable, constrainable, and reusable semantic model.

Business Research Starting with Value Narrative

Research should not simply ask "what features do you want?" because business stakeholders' answers are often constrained by existing systems and reports. Nor should modeling questions be dumped directly on them. A better approach is to start with a value narrative and scenario walkthrough.

Value Narrative Templates

The value narrative provides an alignment entry point, helping modelers identify business objects, processes, states, rules, data sources, and Agent assistance opportunities from real business changes. It is not a feature list but an executable statement: who is helped, in which scenario, what current state becomes what target state, and which metric verifies the result.

Formal template:

为了帮助【具体角色/对象】，在【明确业务流程/场景】中，把【当前低效/断裂/高风险状态】转变为【目标状态】，并将【关键指标】从【当前基线】改善到【目标值】。

Colloquial template:

让【谁】在【什么业务场景】中，不再【当前痛点】，而是能够【新的工作方式】，最终把【可衡量结果】提升/缩短/降低到【目标值】。

Both templates capture four elements: specific object (who), clear boundary (which process), change comparison (from what state to what state), quantified result (which metric judges success).

Example: Judicial Case Review

为了帮助法官助理在案件阅卷和材料审查流程中，把当前人工逐份翻阅卷宗、手工整理争点和证据关系的状态，转变为系统自动提示材料缺口、争议焦点和证据支撑关系的工作方式，并将阅卷准备时间和材料遗漏风险降低到可验证范围内。

Scenario Walkthrough

After aligning on the value narrative, conduct a scenario walkthrough where business stakeholders describe the real work process: where it starts and ends, which roles participate and do what, which nodes are error-prone, which judgments depend on experience/materials/data/systems, and how completion is confirmed and exceptions handled. Business stakeholders provide the real process and problems; business architects or ontology modelers abstract the modeling elements.

Research must cover at least: business owners (goals), frontline staff (real process), data/system personnel (existing constraints), compliance/risk staff (boundaries), and future Agent users.

Six Modeling Elements to Capture

Business modeling is more than drawing a flow chart. In ontology-driven data governance, at least six categories of modeling elements must be settled after research:

Business Objects : e.g., customer, order, device, work order, case, personnel, material, evidence, indicator. Objects are what the business world truly manages, judges, and operates — not database tables.

Business Processes : e.g., application, approval, inspection, alert, handling, review, archiving. Processes are the causes of object state changes, not just flow lines.

State Changes : e.g., pending, in-progress, completed, abnormal, overdue, closed, confirmed, rejected, warned. States connect rules, metrics, and Agent actions.

Business Rules : including process, risk, compliance, metric definitions, action triggers, manual confirmations.

Data Sources : clarify which business facts are supported by which data — from business systems, documents, logs, APIs, sensors, manual confirmations, model outputs, or external sources.

Agent Assistance Opportunities : identify where AI Agents can intervene (prompt, retrieve, verify, generate, compare, alert, explain, recommend, call tools) and which actions must remain manual.

Visual Modeling for Confirmation

After capturing the six elements, the next step should not be only a natural-language requirements document, because natural language easily creates ambiguity (e.g., "after approval enters handling" — different people interpret "approval", "handling", "enters" differently). Better: have business architects or ontology modelers transform the elements into a visual business model.

Visual models are more suitable for business stakeholders to confirm and correct. They can directly point out: object misplaced, process sequence wrong, missing state, invalid state transition, rule only applies to certain scenarios, missing manual confirmation node.

The value of visual modeling is not just drawing; it turns business knowledge from natural-language discussion into a discussable, confirmable, correctable, reusable symbolic structure. Only after the business model stabilizes can subsequent data asset mapping, semantic quality rules, semantic service publishing, and Agent action contracts have a stable business semantic foundation.

Visual Modeling Can Use OPM, But Not Only OPM

Many notations exist: BPMN, domain modeling, event storming, capability maps, business object models, process models. OPM/OPD is one of them. Its characteristic: using objects, processes, and state changes to turn business knowledge from natural language into a discussable, confirmable, deducible symbolic structure. OPM can express the business model, but it is not a separate phase after business modeling, nor the only way. The key is whether objects, processes, states, rules, data sources, and Agent assistance points are clearly expressed.

OPM's advantage: it natively expresses objects, processes, and state changes simultaneously, making it suitable for feeding into subsequent ontology modeling. Ontology models further solve: how to express business objects, relationships, states, rules as computable, queryable, constrainable, reusable semantic assets.

End-to-End Path

业务场景 → 业务调研 → 业务建模要素沉淀 → 可视化业务建模表达（OPM/BPMN/领域模型等） → 本体语义模型 → 数据资产映射 → 语义服务和Agent能力

This is why ontology-driven data governance starts from business scenarios, not databases. Database fields must be examined, but cannot bind the effort from the beginning. The real goal is to build the business operating logic, then let data, models, and Agents work around that business semantic model.