Ontology Review Exposes Governance Conflicts: Customer & Revenue Disputes

The Same 'Customer' May Not Be the Same Statistical Object

An enterprise building a customer management assistant drafts an ontology with customers, contracts, orders, and receivables mapped to source systems. During review with sales, finance, and risk control, disputes emerge immediately. Sales views a group as one large customer; finance insists each legal entity's receivables must be managed separately; risk control notes its risk grouping differs from sales' group definition. Asking "how much revenue did this customer contribute" triggers further conflict: sales cites contract value, finance demands revenue recognition criteria, operations adds a collection report. The modeling review becomes a debate over how to count customers and amounts.

A participant suggests unifying definitions, but unification changes headcounts, performance metrics, and accountability for erroneous mergers. The discussion shifts from modeling to business governance. The Big Data Technology Standards Promotion Committee's Ontology Intelligence Development Trends lists organizational interest coordination around core concept definition rights as a key adoption obstacle. Some models stall because the enterprise hasn't decided which meanings can be shared, which differences must be kept, and who has authority to confirm.

Ontology construction needs consensus that gives every business meaning a clear scope, basis, and responsibility, so systems know when to associate and when not to substitute.

The following distinctions are critical:

Sales operations focuses on group customers, regional relationships, opportunity ownership. Boundary: one operating unit may link to multiple transaction entities.

Contract fulfillment focuses on signing entities, contracts, orders, fulfillment responsibilities. Boundary: group relationships cannot replace specific contract liable parties.

Financial management focuses on counterparties, receivable objects, accounting records. Boundary: signing, invoicing, collection records cannot be merged by name alone.

Risk management focuses on entities and correlation groups under risk policies. Boundary: risk grouping not equivalent to sales group division, has effective scope.

First separate two things: identifying the same entity versus adopting the same statistical granularity . The same company may have different codes in CRM and finance systems, requiring a confirmed identity mapping. It may simultaneously play roles like signing party and paying party; roles alone shouldn't duplicate entities. Conversely, a single transaction's signing and paying parties may differ and must be verified separately. Sales' group operating unit and its member companies need member/control relationships; they cannot be merged into one identity just because they're called "one customer." After correct identity linking, group customer count and transaction entity count may still differ — that difference can be correct. The ontology's role is to express object types, identity relationships, business roles, and applicable scopes. Real-time receivables and order status come from source systems; statistical computation remains in data services or compute engines.

First Distinguish Disagreements, Then Decide Whether to Unify

Facing same-named concepts, teams often swing to extremes: enforce a single enterprise-wide definition, or let each department maintain its own set for LLMs to interpret. Instead, investigate along four directions — a single issue may involve multiple difference types; don't stop after categorizing just one.

Different names, same meaning → unify. Two systems use different terms for the same customer category. If object scope, identification conditions, and business purpose align, establish a unified concept with aliases. Whether specific company abbreviations point to the same entity requires separate identity verification. Neither can be decided by text similarity alone.

Same name, different business purposes → distinguish clearly. Group operating customer and contract transaction entity can be related but not equated. Governance outcome can be two concepts and their relationship; no need to argue which department owns the word "customer."

Same meaning and purpose, different data → check fact chain. Two systems count the same signing entities at the same point in time but produce different results. Investigate duplicate codes, sync latency, expired records, mapping errors. Don't tweak definitions temporarily to align numbers.

Same purpose, different recognition rules → verify rule basis. Sales dept A counts new customers at contract signing; dept B counts after first fulfillment. If current policy is clear, correct execution deviation. If policy is absent or conflicting, an authorized role must adjudicate, setting formal criteria and exceptions.

Separating name, purpose, fact, and rule first tells you which record to check and who to confirm. Otherwise a "caliber unification meeting" easily slides from fact-checking into departmental stance battles.

Why 'Revenue' Easily Leads Technical Teams Astray

The assistant's second question: "How much revenue did this customer contribute this month?" misses at least three specifics: group vs. entity granularity, which business time defines "this month," and which amount — contract value, collection, or accounting-standard recognized revenue. These amounts collectively reflect operations but cannot map to a single indicator just because they're monetary. Revenue recognition rules must be validated by finance per applicable standards and enterprise policies, not inferred by modelers from sales report labels.

Definition authority is not arbitrary naming or fact-changing power. Management may approve an internal operational metric, but cannot turn contract value into financial revenue by renaming a field.

For the assistant, handling must map to concrete behaviors:

In configured financial analysis scenarios, use confirmed financial metrics, stating period, entity scope, and caliber version.

In ambiguous general Q&A, ask the user whether they want contract, collection, or revenue; list separately but never merge into one number.

In group aggregation, follow explicit member scope, effective time, and aggregation rules; never default to summing all affiliated companies' amounts.

When mapping or basis is missing, return the gap; don't treat unknown as zero or substitute another amount.

LLMs can recognize intent and explain differences; selecting criteria relies on approved scenario conventions or user-supplied conditions. Supplementary conditions do not grant authority to modify formal definitions.

Who Decides Must Be Concrete

Building on the distinction between knowledge contribution and formal confirmation (see Enterprise AI's Hardest Part Isn't Building Ontology: Why Frontline Experience Never Gets Adopted ), authorization must be explicit: senior sales can explain customer relationships but may lack authority to modify financial metrics; data leads can detect mapping conflicts but may lack authority to change assessment policies.

In the customer management assistant project, decisions split into three categories:

Domain-internal meanings confirmed by authorized domain business lead. Example: new-customer definition in sales assessment approved by sales-management-designated owner; financial metric caliber confirmed by finance lead. Experts provide facts and professional explanations; confirmer must hold matching authorization.

Cross-domain relationships and usage conventions approved by designated cross-domain governance lead. Example: how group operating customer links to transaction entities, which caliber the assistant uses at different entry points. Sales, finance, and specialists confirm respective boundaries; cross-domain lead approves overall plan. Not just "sales and finance jointly responsible" leaving the final decision hanging. This lead approves cross-domain linking and usage plan, not authority to modify domain formal policies. If professional confirmation missing, plan returns for adjustment.

Conflicts involving targets, resources, or assessment policies go to authorized manager for adjudication. Example: unifying new-customer criteria changes business targets and team incentives — must enter existing management decision mechanism. Escalation materials should describe candidate options, impact scope, professional boundaries, and consequences of inaction, not merely "two departments disagree." Each decision needs a single ultimate owner. If decision exceeds authority, escalate along established path; no multiple signatories waiting on each other, no majority vote bypassing mandatory professional requirements.

Use a Caliber Decision Card to End Endless Discussions

Governance doesn't require a large committee. Pick a dispute affecting a real task, write the conclusion as a verifiable caliber decision card. Suppose the review confirmed group-to-entity mapping but group revenue aggregation rule remains unconfirmed. A bounded decision card can capture:

Task to solve: Navigate by group operating customer, support drill-down to specific transaction entities.

Objects to retain: Group operating customer, transaction entities, and their stable identifiers.

How to establish relationships: Based on confirmed member and business relationship mappings with effective time; risk grouping expressed separately.

How to use metrics: At entity level, show contract value, collection, and revenue per confirmed caliber, annotated with period and source; temporarily do not show group revenue aggregation.

Who is ultimately responsible: Designate one cross-domain plan approver with recorded authorization scope; sales and finance each complete professional confirmation.

Situations where no direct conclusion: When mapping or relationship effective time missing, prompt incomplete scope; group revenue aggregation returns "caliber pending confirmation," no estimated values.

How to verify: Use typical cases and counter-examples to check object merging, metric selection, time boundaries, and missing handling.

When effective and how to correct: Record version, effective time, affected reports and assistant; on failure roll back revision; parts not meeting release conditions stay disabled.

In practice, "designate a responsible person" must name a concrete role and current individual, not a placeholder. Approved cards must map to model, data mappings, and application behavior: model retains group vs. entity distinction; data mappings carry effective time; assistant only exposes confirmed query ranges. Transformation method detailed in Ontology-Driven Data Governance: How to Build Business Semantic Models — From Business Model to Semantic Assets .

For historical data, clarify whether to restore per then-effective relationships or recalc per current management criteria; both results must be clearly labeled. New definition release must not silently rewrite past reports' meanings.

During Acceptance, Don't Just Check 'Numbers Finally Match'

Semantic governance may keep numbers different that shouldn't be the same. Real verification: can differences be explained? Can the system use them in correct scopes? The assistant can first validate four case groups:

One company, two system codes. After identity verification, link to same entity, retain source records; same name different entity must not merge; missing basis marked pending verification.

One group, multiple transaction entities. Retain group vs. entity distinction; query group customer count and transaction entity count separately with correct granularity.

Entity's group affiliation changes. Historical queries follow agreed time criteria; cannot unconditionally apply current affiliation to past.

User only asks "revenue" or mapping missing. If scenario has formal default, state basis; else ask or return gap; never auto-substitute metric or omit and claim completeness.

Business leads confirm expected results; data and app teams provide runtime evidence; release lead decides enablement. If differences unexplainable, trace definitions, mappings, implementation; if expectation itself is wrong, re-confirm and record — don't just change answer to pass test. Post-launch observation should center on real tasks: does the same dispute recur? Do queries still need manual re-explanation? Has metric misuse decreased? Do changes cause unidentified impacts? These evidences prove governance effectiveness better than counting new concepts.

No Need to Build 'Grand Ontology' Just for Unification

If only a few name inconsistencies exist in single-department reports, maintaining a glossary, metric descriptions, and owners may suffice. If object definitions are stable and system relationships simple, master data mapping or data contracts can solve the problem. When multiple systems long-share objects, relationships and time boundaries are complex, and rules need reuse by multiple applications or agents, then evaluate ontology expression benefits. Governance consumes expert review, mapping maintenance, and version verification time. Scope should expand with actual reuse needs; like the decision card, enable confirmed parts first, don't wait for all disputes to resolve, and don't package undecided parts as complete capabilities.

Summary

Ontology drawn, sales and finance argue — doesn't mean modeling lacks value. It may just bring hidden differences in reports, systems, and department habits to the same table for the first time. Key is turning arguments into verifiable, adjudicable items. A model drawn doesn't mean business consensus reached; review conclusions entering system and passing validation is completion. When someone demands "unify customer" or "unify revenue," first clarify what task it serves, whether differences stem from object, purpose, data, or policy, then implement confirmer, adjudicator, and effective conditions. The definition authority enterprises truly need: confirm business meanings with basis, handle differences with boundaries, and continuously own results after definitions enter systems.