Resolving Conflicting Names Across Company Knowledge Sources
Learn how to reconcile conflicting department terms and entity aliases across enterprise systems using operated knowledge graphs, source provenance, and glossary conflict resolution rather than fragile static mapping tables.
The same name can refer to different entities, while different names can refer to one entity. Resolve the evidence before deciding whether to link records. A disagreement about a business definition needs a separate decision.
Key takeaways
- Preserve source names and record IDs; name similarity alone is not identity evidence.
- Separate entity matching from differences in business definitions.
- Keep uncertain mappings unresolved until an accountable reviewer decides.
- Record evidence and revisions, then test the downstream effects of corrections.
Identify the kind of conflict
Aliases for one real-world entity and distinct entities with similar names are both entity-resolution or disambiguation problems. Compare corroborating identifiers, jurisdiction and source context before linking records. Normalization can help find candidates but may erase meaningful differences if applied indiscriminately. A shared word with different departmental meanings is a concept-definition problem. Do not force those definitions into one canonical meaning merely because their labels match. A maintained mapping table can be sufficient for a bounded workflow; assign an owner and review triggers as sources change.
Work through the evidence
The following cases are fictional illustrations, not customer records or measured results. IDs are invented.
| Source records | Evidence | Proposed action |
|---|---|---|
| CRM C1: Example Co; billing B1: Example Company | Both corroborated against fictional registry ID R100 in the same jurisdiction | Propose a same-entity link for owner review; retain both source IDs |
| Supplier S2: Example Co | Verified registry ID R200 in that jurisdiction | Keep distinct from R100 despite the similar name |
| Imported X3: Example Co | No reliable identifier or sufficient supporting context | Leave unresolved and request evidence |
An identifier must be interpreted in its issuing system and checked for errors or reuse. A confidence score is a prioritization aid, not proof. A proposed link should not silently become an approved mapping.
For a separate fictional vocabulary example, Sales defines active customer as a signed contract, while Operations requires activated service. Retain scoped IDs such as sales-active-customer and operations-active-customer. Describe their relationship without asserting equivalence. Ask which definition the user's workflow needs when the question is ambiguous.
Keep a small decision record
Use these suggested workflow fields: source record ID and version, original label, candidate entity or scoped concept, evidence, effective date, reviewer, proposed/approved/rejected/unresolved status, reason and revision. These are proposed operational fields, not a mandatory standard or built-in AKB approval schema. The owner reviews disputed mappings. Preserve rejected candidates so future imports do not repeatedly propose the same mistaken link without new evidence. When correcting a mapping, retain the prior decision, identify affected records and answers, update the downstream representation, and test the change. Keep source access restrictions intact; copying a reference does not grant permission to its contents. Historical reconstruction requires retained observations and source versions plus clear effective-time and observation-time semantics. A timestamp alone does not make every past state recoverable.
Use standards where they help
The W3C SKOS Primer describes labels and relationships for conceptual vocabularies. SKOS is optional for this worksheet and is not a universal customer-record matching algorithm. In the SKOS Reference, exactMatch is transitive but does not assert owl:sameAs identity. closeMatch is not defined as transitive; the property alone does not license transitive inference or control application-level merging. owl:sameAs asserts identity under OWL semantics, rather than commanding a physical database merge. PROV-O can represent origins and derivations. Choose useful granularity and consistent links across records; there is no general requirement to omit provenance merely because related information exists at another level. Provenance helps explain a decision but does not establish that it is correct.
Test mappings and downstream answers
Build a small human-reviewed set containing true matches, similar-name nonmatches and ambiguous cases. Track false merges and missed matches separately. Test whether agents select the intended scoped definition and retain supporting sources. Set acceptance criteria for the risk of the workflow; there is no universal similarity threshold. Record and link counts can flag drift but do not establish accuracy. Recheck examples when sources, matching rules or definitions change, and make corrections reversible through retained mapping revisions and a tested update process.
Store reviewed knowledge for reuse
AKB provides documents, tables, files, explicit relations and hybrid retrieval, with document revision history and agent access through MCP. Teams can use these building blocks to store reviewed mappings and source context. Storage capabilities alone do not establish automatic entity resolution, formal SKOS/OWL reasoning, inherited source permissions or identical rollback coverage for every resource type. Approval and enforcement depend on the configured operating workflow.
FAQ
Must we merge records with matching names?
No. Check corroborating identity evidence and retain unresolved cases when it is insufficient.
Do we need SKOS to begin?
No. A maintained worksheet can support a bounded workflow. SKOS is useful when interoperable conceptual vocabularies are required.
Can provenance prove a mapping is correct?
No. It records origins and decisions; reviewers and evaluation still need to assess correctness.
What if departments disagree about a term?
Preserve scoped definitions, sources and owners. Clarify the user's intended context rather than assuming equivalence.
Explore AKB knowledge records
Review documented storage, relations and agent access.