What is data governance, and what does it actually change day to day?

Data governance is the operating model that decides who owns each data asset, what it means, where it came from and who may use it. Day to day it changes four things: every important table has a named owner, contested terms like active customer have one approved definition, any figure can be traced back to its source columns, and access follows data sensitivity rather than old tickets.

What is OvalEdge — is it a database?

No — OvalEdge is not a database, and it does not store your data. OvalEdge catalogs metadata about the systems you already run — names, definitions, ownership, sensitivity and how data flows. It connects with read-only credentials, reads structure and statistics, and writes only metadata to its own store. Your data never moves, which is the answer to the first question every security review asks.

Can OvalEdge be deployed on-premise or in an air-gapped environment?

Yes — OvalEdge can be deployed on-premise or in an air-gapped environment, and that is the normal deployment here rather than an exception, which is why it survives the first filter in Azerbaijani banking and government evaluations. It needs its own database and network access to the systems it reads. Nothing requires internet connectivity at runtime.

How long does a typical OvalEdge implementation take?

A typical OvalEdge implementation takes six to twelve weeks to a working catalog for one domain, with harvested lineage and a glossary people use. Installing, connecting and harvesting take three to four weeks and are largely mechanical. The rest is the human phase — definitions, ownership, classification — which slows down in proportion to how many domains you attempt at once.

Which data sources does OvalEdge connect to?

OvalEdge ships more than 170 pre-built native connectors, covering Oracle, SQL Server, PostgreSQL, Teradata, SAP, 1C, mainframe extracts, object storage, Snowflake, Databricks and the major BI tools. Ask about your systems rather than the total, and ask specifically whether lineage is supported for each — many products can read a source's metadata but cannot parse its transformation logic.

Does a data catalog replace our data warehouse?

No — a data catalog does not replace a data warehouse. The warehouse stores and serves data; the catalog stores metadata describing that data and everything in your other systems. They are used together. Deploying a catalog changes nothing about your pipelines or reports — it makes them findable, documented and traceable.

What is the difference between a data catalog, a data dictionary and a business glossary?

A dictionary describes one database's structure for developers. A glossary defines business concepts like net exposure for the business. A catalog is the platform that spans the whole estate and holds both. What makes the catalog more than a document is the binding: each glossary concept is linked to the physical columns that implement it.

What is column-level data lineage, and why does it matter during an audit?

Column-level lineage traces a single column from its source, through every transformation, to the figure in a report — which is exactly the shape of the supervisory question show us how this number was calculated . Without it the answer is a reconstruction from memory that takes days. Insist on lineage parsed automatically from your SQL: hand-drawn diagrams are misleading within a year.

Who should own data governance — IT or the business?

Data governance is owned by the business, with heavy technical support from IT. IT can implement a catalog and harvest lineage; it cannot decide what active customer means. When governance sits entirely inside IT, definitions get made by people without the business context to make them, and the business ignores the result.

Do we need a data governance program in place before we start doing AI?

You do not need a full data governance programme before starting AI, but you do need governance on the specific data your AI will use — and that is more than most organisations have. Gartner expects over 40% of agentic AI projects to be cancelled by end-2027, with inadequate controls among the causes. Catalog and classify the one domain your first use case depends on: a few weeks, not a year.

How does OvalEdge handle Azerbaijani, Russian and English metadata in one catalog?

OvalEdge holds trilingual metadata as one canonical concept carrying a label in each language, rather than three parallel glossaries. `müştəri`, `клиент` and `customer` share no characters, so no automated matching will connect them — a person who knows the business in all three languages has to decide they are one concept. Design for this on day one; retrofitting it is expensive.

Does OvalEdge help satisfy Central Bank of Azerbaijan reporting requirements?

OvalEdge supplies the evidence CBAR requirements depend on, though no software makes an institution compliant on its own. CBAR's Regulation on Information Security Management in Banks, in force since April 2022 and built on ISO/IEC 27000, expects asset ownership, classification and access control tied to it. A catalog produces that evidence from the systems themselves rather than from memory.

How do you measure whether a data governance program is working?

Measure a data governance programme by behaviour change, not by row counts. A catalog with fifty thousand documented assets and no users is a more expensive spreadsheet. The metrics that mean something: analysts checking the glossary before building a report, engineers checking lineage before changing a schema, and how long it now takes to answer a regulator's question about a figure.

What does data stewardship involve, and how many stewards do we need?

A steward is a named person in the business accountable for a set of assets: approving definitions, confirming ownership, settling disputes. Roughly two hours a week. Fewer than you expect — one per domain, so ten to twenty across a large bank. Make it part of an existing role, because a programme built around a few exceptional individuals collapses when two of them leave.

Is Yukon Labs an OvalEdge reseller or an implementation partner?

Yukon Labs is an OvalEdge implementation partner, not a reseller. We deploy, configure and operate OvalEdge inside your environment rather than selling a licence and leaving. That means connectors against your real systems, lineage validated on your own transformation code, the multilingual glossary modelled correctly from the start, and the change management that decides whether the catalog gets used.

Business Glossary: Definitions as Assets

A business glossary is where governance stops being technical. How to define terms that survive an argument, bind them to physical columns, and keep them alive after launch.

A business glossary is the agreed set of definitions for the terms your organisation runs on — active customer, net exposure, delinquent account — with each definition bound to the physical columns that implement it. It is the point where a governance programme stops being a technical exercise and starts requiring decisions that only the business can make.

It is also the phase that programmes underestimate most reliably. Teams budget four weeks for the glossary and spend twelve, because the work is not writing definitions. It is discovering that two departments have been using the same word differently for years, both defensibly, and getting someone to decide which one wins.

That discovery is the point. Resolving it is worth more than the catalog it lives in.

Why definitions are governance rather than documentation

The distinction is easiest to see through a concrete case, and the same one occurs in nearly every bank.

Risk defines an active customer as one with a non-zero balance in the last ninety days. Marketing defines it as one with any interaction in the last twelve months. Regulatory reporting uses a third definition set by the supervisor. All three are correct for their purpose. The organisation has three numbers for "active customers", every one of them defensible, and no way to reconcile a board pack that contains two of them.

Documentation records that this is the situation. Governance changes it — either by declaring one definition canonical and the others explicitly derived, or by giving the three terms distinct names so nobody mistakes one for another. Both are decisions. Neither can be made by IT, and neither happens without someone holding decision rights.

This is why a glossary maintained as a wiki page fails: a wiki records what people believe. A governed glossary records what was decided, by whom, and when.

What a governed term contains

A definition in isolation is nearly useless. A governed term carries six things.

A name and a definition written for a business reader, in one or two sentences, without reference to table names. If the definition mentions a column, it is a data dictionary entry rather than a glossary term.

An owner. A named individual accountable for the definition — normally the business owner of the domain, not the person who typed it in.

Status. Draft, approved, deprecated. A glossary where everything has equal weight cannot be trusted, because readers cannot tell a proposal from a ruling.

Bindings to physical columns. The specific columns, in the specific systems, that implement this concept. This is what converts a glossary from prose into infrastructure: an analyst looking at cst_st_cd sees the approved definition, and a steward looking at the term sees everywhere it is implemented.

Relationships. Which terms this one derives from, contains, or excludes. Active customer relates to customer, dormant account and closed account, and those relationships carry most of the meaning that a standalone sentence loses.

A decision record. What was disputed, what was decided, by whom, on what date, and why. This is the field that experienced governance leads say they wish they had started keeping earlier, because the same argument returns in eighteen months with new people, and without the record it is re-litigated from scratch.

How to run the definition phase

The sequence that works, and the two shortcuts that do not.

Start from reports, not from systems. Take the terms that appear in regulatory submissions and executive dashboards. That is fifty to eighty terms in a domain, not five hundred, and every one of them has a consequence attached, which is what makes people show up to the meeting.

Draft from existing usage, not from first principles. Collect how the term is currently defined in each department — from report specifications, code comments, the analyst who maintains the spreadsheet. Bring the conflicting versions into the room. A glossary written from scratch by a governance team produces definitions nobody recognises, and adoption fails silently.

Time-box the argument. A definition dispute that reaches the forum is settled at that meeting or escalated. Never carried. Definitions carried to the next meeting are carried forever.

Publish deltas, not the whole glossary. When a term changes, notify the people whose reports depend on it — which requires the bindings and the lineage to exist. This is where a glossary stops being passive and starts changing behaviour.

The two shortcuts that fail: defining terms without binding them to columns, which produces a glossary that is technically correct and operationally inert; and defining everything before deciding anything, which produces five hundred draft terms and no rulings.

Multilingual glossaries

In an Azerbaijani institution this is a first-day design requirement rather than a later enhancement.

The organisation runs an Azerbaijani-language core system, a Russian-language legacy application and English-language modern infrastructure. The same concept exists as müştəri, клиент and customer, and no automated matching connects them because they share no characters.

The correct model is one canonical concept carrying language-specific labels, with physical columns from all three system generations bound to that single concept. The incorrect model — and the one that products push you toward if you are not paying attention — is three parallel glossaries, one per language, which immediately drift apart and then require reconciliation nobody has time for.

Retrofitting the correct model after a thousand terms are catalogued is expensive and demoralising, which is why this belongs in the platform evaluation. Ask each vendor to demonstrate a single glossary term with three language labels, bound to columns whose names are in three different scripts, and then to show search working from any of the three. Products that claim localisation will often show a translated interface instead, which solves a different problem entirely.

One practical note: technical terms should stay in English in Azerbaijani and Russian definitions. Data lineage, lakehouse and orchestration are how practitioners in this market actually speak and search, and translating them makes the glossary less usable rather than more.

Keeping it alive after launch

Glossaries decay faster than any other governance artefact, because a definition that was true at approval is silently invalidated by a change in the source system.

Four mechanisms keep one honest.

Review cadence tied to the owner. Each term gets an annual review, staggered so no owner faces fifty at once. A term that has not been reviewed shows its age in the interface.

Change alerts through the bindings. When a bound column is altered or dropped, the term's owner hears about it. This is the practical payoff of binding definitions to physical columns, and it only works if lineage exists.

Usage as a signal. Terms that are never viewed are either wrong, unknown or unnecessary. Usage data tells you which of your definitions are actually load-bearing, and it is the fastest way to prioritise the review effort.

Deprecation rather than deletion. A term that is retired stays visible with a deprecated status and a pointer to its replacement. Deleting it breaks every report specification that referenced it and produces the archaeology problem the glossary was meant to prevent.

What the glossary makes possible

Worth stating, because the glossary is frequently treated as an end in itself.

Approved definitions bound to columns are the precondition for classification, because you cannot decide the sensitivity of a field you cannot name. They are the precondition for meaningful quality rules, because a completeness rule on active customer requires knowing which customers count. And they are increasingly the precondition for AI: a retrieval system or an agent answering questions about business concepts needs the same definitions the humans use, or it produces confidently wrong answers that look plausible — the failure mode behind a large share of shelved AI projects.

An organisation that has settled its fifty most contested definitions has done the hardest part of both its governance and its AI programme, and most of the remaining work is engineering.

Key points

A glossary is where governance requires decisions only the business can make. The arguments it starts are the value, not a delay.
A governed term carries a definition, an owner, a status, bindings to physical columns, relationships and a decision record. Definitions without bindings are inert.
Start from the fifty to eighty terms that appear in regulatory reports and executive decisions, drafted from existing usage rather than from first principles.
Time-box disputes. A definition carried to the next meeting is carried forever.
Multilingual is a day-one model requirement in this market: one canonical concept, multiple language labels, not three parallel glossaries.
Keep technical terms in English in Azerbaijani and Russian definitions — that is how practitioners speak and search.

We implement OvalEdge, including multilingual glossary modelling for Azerbaijani, Russian and English estates. Related reading: data catalog vs data dictionary vs business glossary and metadata management.

Business Glossary: Turning Definitions into Governed Assets