AI system for corporate terminology management

AI Terminology Management: Where Data Meanings Diverge

In CRM, the same object is a "counterparty," in billing it is a "subscriber," in logistics it is a "recipient," and in an analytics export it appears as a "partner." With a dozen records, this looks harmless; with thousands, it turns into inconsistent naming: an entity acquires several loosely connected versions, and none is recognized as the primary one.

Terms divergence hits reporting first.

Aggregation does not merge records because keys differ; shares are calculated from incomparable bases, and totals in two reports diverge by percentages that are blamed on "export specifics." Search and an AI assistant repeat the same mistake: a synonym finds only part of the documents, and the answer is built on an incomplete sample.

The most common replacement for a proper layer is manual mapping of reference data: an analyst maintains a correspondence table and updates it with every change in the source. The table lags behind reality, and after a release, some links are silently lost.

ISO 25964 describes how such dictionaries are structured: terms, synonyms, hierarchy, and relationships between them are defined explicitly rather than reconstructed by guesswork.

We build AI terminology management as a layer over sources: the model proposes correspondences by context and validates them against historical data, while disputable cases go to a human for review. Let's break down how this is addressed.

What Changes in Analytics After Implementing a Unified Dictionary

Implementation of a unified glossary changes not reporting itself but the cost of preparing it.

The effect is visible in the second or third month of operation: the system accumulates relationships between concepts, and the share of records linked automatically grows with each export, while manual operations gradually leave the procedure.

Share of Automatically Linked Records Grows

Each concept receives a stable identifier and links to synonyms, abbreviations, and related reference data.

When the base covers the main domains, most incoming records are matched without an analyst: questionable cases go into a short confirmation queue rather than a full review.

Reference Data Consistency Is Maintained Without Manual Reconciliation

Previously, reconciling two exports was a separate task lasting several days and ended with a new discrepancy. Now inconsistencies are calculated regularly and shown in a targeted manner — the dictionary itself is corrected, and the next export comes out already consistent.

Information Search Speed Stops Depending on People

Search runs by name, synonym, and abbreviation simultaneously, so there is no need to remember which reference data contains an entity. A new employee finds the definition and data owner on their own without digging through message history.

Manual Reconciliations Leave the Procedure

The freed-up analyst hours go to reviewing disputable cases and refining rules, not to reconciling tables. Reporting is assembled from consistent data, and the discrepancy between data marts stops being a surprise before submission.

Dictionary Management Approaches: Comparing Three Approaches

The way a dictionary is managed determines what the system can validate on its own and what remains with an editor.

A flat registry catches spelling discrepancies and prohibited forms; a centralized glossary fixes the meaning of a term and its owner; and a concept graph maintains relationships — synonymy, genus-species links, "part of a whole," and scope of application.

The difference between the approaches is not in dictionary size but in the class of errors they close automatically.

Comparison of Approaches

What to Consider When Choosing

Limitations are not removed by growing the dictionary. If relationships between concepts are needed, a flat list will have to be rebuilt together with validation rules — moving the dictionary into a relationship model requires more effort than laying it down from the start.

We begin with an inventory: what entity types exist, where terms already diverge, who approves changes. Based on the result, we choose an approach or a combination — a registry as the foundation, a graph over disputable areas.

Implementation Stages: From Inventory to Procedure

The order of work does not depend on the size of the reference data: first we record where the system takes terms from, and only then formulate rules. The reverse order produces rules that break on the very first source with outdated abbreviations.

1. Inventory of sources. Procedures, knowledge bases, document templates, support communications, interface texts, old glossaries. For each source, we record the owner, format, and frequency of changes.
2. Relationship schema. Term graph: synonyms, abbreviations, outdated forms, "genus — species" relationships. It immediately reveals conflicts where the same word means different things in two departments.
3. Reference sample. We manually label several hundred real employee queries — it becomes the quality measure: the share of correct normalizations before and after fine-tuning.
4. Rule setup. We determine what is replaced automatically, what goes to an editor for confirmation, and at what confidence level. Rules are versioned together with the dictionary.
5. Validation on real queries. Running through the history of requests, reviewing false positives, adding synonyms and prohibitions. Iterations until a stable error share on the labeled sample.
6. Procedure and handover to operation. We fix roles: who proposes a term, who approves, who monitors obsolescence. Plus a change log and rollback to the previous dictionary version.

At the output, the customer receives not a one-time dictionary but a workflow: a new term goes through approval, enters the dictionary, and begins to be applied in search and documents without manual text editing.

Regulations, Schemas, and Policies for Working with the Dictionary

An AI system does not replace agreements about terms but executes them.

Therefore, handover includes not only a working terminology management contour but also documentation by which the dictionary lives without us: without it, within a few months, duplicates, discrepancies between departments, and rules known to one person appear.

• Entity registry — a passport for each term: definition, scope, source, owner, allowed and prohibited synonyms, usage examples.
• Relationship schema — relationships between terms, products, and departments: broader and narrower concepts, equivalents, conflicting pairs.
• Access policies — roles and rights: who proposes a term, who approves, who publishes; editing is limited to one's area, disputable cases go to an arbitrator.
• Dictionary management procedure — the term's path from request to publication, review timelines, composition of approvers, procedure for retiring an outdated concept.
• Change and rollback procedure — what is considered a breaking change, how a new dictionary version is released, and how to return to the previous one.
• Labeling and linking rules — how documents pull in terms automatically and how a collision is resolved when one word is used in two meanings.
• Quality metrics — share of terms with an owner and definition, number of unresolved conflicts, coverage of key areas.
• Role memos — short instructions for authors, editors, and integrators: what to do when in doubt and whom to contact.

Documentation is updated together with the system: with each schema revision, rules are corrected in the same release, otherwise the dictionary and its description begin to diverge.

Implementation Case Study: A Unified Dictionary in an Industrial Holding

A holding with several production sites managed terminology in local registries: technical writers, translators, and the quality service used different versions of the same concepts.

At the input — about 40 thousand records, almost a third diverged in definitions between sites, and approving a new term took weeks.

Relationships between terms were built not by name but by a combination of features: matching of the semantic core of definitions, context of use in technical documentation, already confirmed "genus — species" relationships.

Each candidate received a confidence score: above the threshold, the link was created automatically; below, it went to the terminology commission.

That is precisely why the share of automatic links grew from 18% to 76% without loss of accuracy — disputable pairs are still decided by a human.

Of 1,200 contradictory pairs, 84 remained: those where the discrepancy reflects a real difference between sites' shop-floor practices were separated manually.

What Changed in Daily Work

A technical writer no longer reconciles definitions across six files: they search for a concept in the unified dictionary and see where it has already been used and what confirmed synonyms it has.

A disputable term goes to the commission once, the decision is recorded in the registry — at another site, the same question does not come up.

The structure and types of relationships were described according to ISO 25964 so that the dictionary remains extensible when new enterprises are connected and when exchanging with partner registries.

What to Do If Terminology Has Already Diverged Across Systems?

Diverged terminology is not brought together by a single rewrite.

If reference data have already spread across dozens of systems, an attempt to replace them all at once stops services and breaks exports into reports — therefore the work proceeds in waves, and the legacy remains operational until the last step.

First, an inventory: we collect all places where concepts live — accounting systems, storages, export files — and record which code means what and who reads it.

The output is a divergence map: where one term means different things, where different terms mean one thing, which codes are outdated but still used.

Then a unified glossary appears as a source of truth, versioned and suitable for export to TBX — a terminology exchange format read by reference and translation systems.

Consumers do not switch to it all at once: a mapping layer is placed between old reference data and the glossary, where a concept has a current code and a set of synonyms, including historical ones. Old values continue to resolve, so reports and exchanges do not fail.

Reconciliation proceeds by subject areas: first counterparties or nomenclature, then the next block. Each wave is mapping, a run on real data, reconciliation of discrepancies, and only then switching consumers.

The previous reference data are not deleted but marked as becoming outdated, so rollback is possible at any step.

As a result, the share of concept conflicts falls, search and analytics rely on one version of a term, and legacy systems are upgraded without stopping services.

Typical Doubts and Limitations of the Approach

The approach relies on a dictionary — a source of truth — but real data are always messier than the schema.

External partners send names in their own transliteration and abbreviations, some terms are hard-coded inside text fields of reports, and nomenclature changes faster than the procedure is updated. Let's break down three cases that most often raise doubts at the start.

The approach has honestly one limitation: the system does not guess the meaning but proposes an option and shows the basis — source, rule, degree of confidence. The decision on disputable cases remains with the dictionary owner.

A term is hard-coded inside a report or an embedded table?

Search runs not only over explicit columns: entities are extracted from text fields, headers, and appendices. A stable collocation is pulled out and linked to the term card.

Complex cases — homonyms and matching abbreviations — are separated by context and source department; disputable ones go to manual confirmation.

Who maintains the dictionary after launch?

The dictionary is versioned: each term has an author of the change and a history. Edits go through roles — the dictionary owner approves, approvers review their area. Any change is rolled back to the previous state, so an erroneous edit does not break reporting.

Let's Discuss the Task: What to Send for an Accurate Assessment

To return with a scope assessment and a work plan rather than general considerations, we need a picture of your lexical economy: where terms appear, where they live, and who edits them. A separate export is not required — working files and examples already at hand will do.

From them, we calculate the dictionary size, the share of discrepancies, and the number of systems that will have to be linked.

We analyze the received input data and return with a plan: the sequence of stages, scope of work, what quality checks we include, and at which step we connect your editors. Below is what to send.

• An export of current dictionaries and glossaries: tables, knowledge base descriptions, translation files — in the form in which you store them.
• 10–20 pages of live texts from each system: instructions, support articles, procedures, product descriptions.
• A list of noticed discrepancies: where one object is named differently or one word means different things in different departments.
• A list of source systems and languages, including those you plan to add.
• A description of roles and approval: who proposes a term, who approves, where the decision is recorded.
• Requirements for storage and access: where the system should be hosted, what must not leave your perimeter, what change logs are needed.
• Readiness criteria: what you consider the result — fewer disputable edits, a unified dictionary in publications, faster translation.

If some data are not yet available, describe them in words — that will be enough for a first assessment.