Ontology-Driven Data Governance: Start with Business Scenarios, Not Table Fields

Ontology-driven data governance follows a six-step process, but the first step — choosing a business scenario — is often underestimated. Many projects jump straight into master data, metadata, table fields, indicators, and quality rules. While these are important, starting from existing data assets, reports, and statistical calibers locks the governance scope into current systems and data structures.

Why Not Start from Table Fields

Table fields, reports, and indicators tell us what systems have recorded, what management currently monitors, and what statistical calibers exist. They do not fully reveal:

How the business actually operates

How business objects participate in processes

How processes change states

How rules constrain actions

Which business facts need data proof

Therefore, the first step should be selecting a suitable business scenario, not opening database schemas.

Not a Rejection of Metadata Governance

Master data governance ensures core object consistency; metadata, data standards, and indicator governance make assets visible, manageable, queryable, and traceable. Traditional requirement gathering also involves reports, interviews, and business experts. However, business participation often stops at requirement confirmation and caliber explanation. Later stages — data modeling, quality rules, development, service encapsulation — become technically driven, falling back to report items, indicator items, field items, and standard items. This still reverse-engineers business from existing data and reports.

Why Choose a Business Scenario First

Real systems accumulate historical rules, temporary demands, display fields, interface compatibility, manual entries, and report calibers. Reports reflect specific periods, management calibers, or reporting requirements — not necessarily complete business logic. Treating fields, indicators, and report calibers as business ontology leads to:

Mistaking system fields for business concepts

Mistaking report calibers for complete business rules

Mistaking statistical needs for business operating mechanisms

Mistaking historical processes for current processes

Mistaking data gaps for non-existent business

Mistaking system boundaries for business boundaries

Ontology-driven governance must answer business questions first: what objects exist, how they participate in processes, how processes change states, which rules constrain state changes, which data proves business facts, and where AI agents can assist. These cannot be answered by looking at table fields alone.

Five Criteria for a High-Value Scenario

Clear business pain point — e.g., inaccurate equipment failure alerts, high case-material review costs, hard-to-detect contract performance risks, delayed customer risk identification, low work-order efficiency, difficult quality traceability.

Clear business loop — distinct start, process, states, result, and feedback.

Relatively usable data foundation — traceable sources: business systems, documents, logs, sensor data, process records, manual confirmations.

Verifiable value — can validate reduction in manual check time, improved anomaly detection accuracy, reduced material omissions, enhanced data explainability, support for high-quality datasets, more reliable AI agent outputs.

Reusable semantic assets — the scenario should yield reusable business objects, processes, states, rules, indicators, data mappings, and agent capabilities, not just serve an isolated page.

Pain Point Map for Prioritization

Plot pain points on two axes: business impact (low to high) and urgency (low to high). Four quadrants emerge:

High impact, high urgency — prioritize first.

High impact, low urgency — important, second phase.

Low impact, high urgency — handle but don't over-invest modeling resources.

Low impact, low urgency — backlog.

The map's value is aligning business, data, tech, and AI teams on priority, avoiding the extremes of modeling everything or only modeling familiar data.

Translating Pain Points into Value Opportunities

A value opportunity answers: what we do, for whom, in what scenario, from what state to what state, delivering what verifiable value. Standard formula:

Through [what we do] + help [who] + in [what scenario] + achieve [state A → state B] = deliver [verifiable value]

Example 1 — Equipment Monitoring: Through equipment temperature semantic model and anomaly rules, help maintenance staff during catalytic heating, from post-event sensor anomaly detection to in-process warning and early intervention, reducing equipment burnout risk.

Example 2 — Legal Case Review: Through case-material semantic model and evidence-relation validation, help judge assistants during case reading, from manual page-by-page check to automatic prompts for material gaps, dispute points, and evidence support, reducing re-reading and omission risk.

These expressions act as project boundary control tools, forcing vague goals like "intelligentization" or "data governance" into concrete roles, scenarios, changes, and benefits.

Summary

Ontology-driven data governance starts with selecting a suitable business scenario, not examining table fields. Selection relies on pain points, business loops, data foundation, value verification, and semantic asset reuse. Metadata, standard, and indicator governance are important but reverse-engineer from existing data. Ontology-driven governance goes a step further: find the real business scenario, judge if it's worth modeling, if value can be verified, and if reusable semantic assets can be produced. Only with the right scenario do subsequent steps — business research, symbolic business modeling, data asset mapping, semantic quality rules, and semantic service publishing — have a foundation.