One Regulatory Definition, Three Legal Glossary Terms
A retail bank has 4,200 assets cataloged in CDGC from 14 source systems. Its business glossary contains three approved terms - Customer, Client, and Account Holder - each owned by a different group: Retail, Wealth, and Compliance. A new regulatory report needs one definition of “primary customer.” The steward finds 38 column assets named CUST_ID, CLIENT_NO, or ACCT_HOLDER_ID: 22 linked to Customer, 9 to Client, and 7 to Account Holder. Column lineage shows the regulatory mart receives data from all three groups. Compliance says none of the three terms can be retired because legal references them by name. Retail wants a single term. The glossary workflow requires two approvals and cannot be bypassed; a new term takes five business days. The report is due in nine days. The team has one glossary administrator and two part-time stewards.
1. How should the team model the glossary so the regulatory report has one authoritative definition while Compliance keeps its legal terms? State the artifacts and relationships you would create, and why.
Read the worked answer
Create a new, scoped term - for example, Primary Customer (Regulatory Report) - rather than renaming or retiring any existing term.
Artifacts and relationships
- New term owned by enterprise data governance, with a definition that states the regulatory inclusion criteria (for example: the party that holds the primary contractual relationship at the report grain).
- Link the new term to Customer, Client, and Account Holder as related terms, not synonyms. They are not interchangeable: a client may hold multiple accounts, and an account holder may not be the primary customer. Marking them as synonyms would encode a false equivalence.
- Link only the report-facing and report-feeding column assets to the new term. Do not mass-link all 38 columns.
- Keep the three existing terms active and approved so legal references remain valid.
Why this works The report gets a single authoritative anchor without deleting legal vocabulary. The relationships preserve traceability from the narrow regulatory meaning to the broader business terms. The two-approval workflow still applies, so the new term is not a shortcut around governance. The trade-off is that the glossary now has four related terms, which is acceptable if the scopes are documented. If the team instead renamed Customer, it would change an approved term’s meaning, break legal references, and create ambiguity for every asset already linked to Customer.
2. Which of the 38 column assets should be linked to the new term, and what evidence should the stewards require before linking? Explain how lineage changes the answer.
Read the worked answer
Start from the regulatory mart, not from the 38 source columns. Use column-level lineage to identify which source columns actually feed the report’s primary-customer field. Link the report-facing column first, then the upstream columns that demonstrably contribute to it.
Evidence to require
- Column-level lineage path from source to report, with any missing hops documented.
- ETL or view logic showing the column is used as the primary customer key, not merely present in the same table.
- Profiling evidence that the column is populated and has the expected cardinality at the report grain.
- Steward confirmation where lineage is incomplete or the transformation is ambiguous.
How lineage changes the answer Without lineage, a steward might link all 22 Customer columns because the names match. That would overstate the term’s usage and make future impact analysis noisy. With lineage, some columns may feed only operational reporting or may represent account holders rather than primary customers. The correct set may be much smaller - perhaps 8–12 columns. Conversely, lineage may reveal a differently named column that feeds the report, which name-based matching would miss. The rule is: link what the report actually depends on, and record exclusions explicitly.
3. What is the governance risk if Retail simply renames Customer to “Primary Customer” and maps all three term types to it?
Read the worked answer
Renaming an approved term changes its meaning and identity, not just its label. The main risks are:
- Legal and audit traceability. Compliance references Customer by name in policies and legal documents. A rename can break the chain between the obligation and the glossary artifact, even if the term ID remains the same.
- False equivalence. Mapping Client and Account Holder to the renamed term implies they mean the same thing. They do not. Downstream users may apply the term to populations it was never meant to cover.
- Policy and classification inheritance. Assets, policies, and classifications linked to Customer may inherit a new definition without review. That can change masking, access, or reporting treatment unexpectedly.
- Workflow bypass. If the rename is treated as editorial rather than a governed change, it avoids the two approvals the organization requires. That undermines the glossary’s control value.
- Impact noise. Every asset linked to Customer now points to a term whose scope has silently expanded, making impact analysis unreliable.
The safer path is a new scoped term with explicit relationships. If leadership insists on a single term, the change should go through the full workflow with legal sign-off and a documented migration plan for existing links.