In the last unit you learned to put a number on governance and frame it in a leader's terms. But almost every value case you make eventually traces back to the same root: two teams using one word to mean two different things. Before you can settle that, you have to see what kind of data you're actually arguing about, because "active customer" and "currency code" are not the same animal and they don't drift for the same reasons. This unit gives you the vocabulary to sort the data, the moves to align people on a definition, and a way to write it down so it sticks.

Start by learning to recognize the four Core Data Types, because naming the type tells you where a problem lives and what kind of fix it needs.

Master data is the important "nouns" your business reuses everywhere: customers, products, employees, suppliers. Reference data is the standardized lists people pick from, like country codes, currency codes, or status values that everyone is supposed to share.

Metadata is data about data: the definition, the source, the owner, the last-updated date. Think of it as the label on the jar rather than what's inside. Transactional data is the record of events that happened: an order placed, a payment made, a ticket logged, a login.

Here's why this matters in your day-to-day. When a number is disputed, the type points you to the cause. A fight over "who counts as a customer" is a master-data problem (one real person showing up as several records). A complaint that "this code isn't allowed" is reference data. A question like "what does this field even mean?" is metadata. And "the order total looks off" is transactional. Diagnosing the type first keeps you from treating a definition disagreement as if it were a broken record.

Most of the value lives in master data and the metadata that defines it, so your core skill is getting people to agree on what a term means. Your job here is facilitator, not judge. You surface why two teams differ, then drive them toward four things: a single business definition, a named owner, the valid values that count, and usage notes that stop future drift.

• Marcus (Finance): We only count someone as active if they've paid this quarter.
• Jessica: And we count anyone who logged in within ninety days. That's why our dashboards never match.
• Chris: So the gap is the time window and whether payment is required. Let's land one business meaning you both can live with, then name who owns it.
• Jessica: I can accept "paid within the last quarter" as the official one, as long as my engagement view keeps its own clear label.
• Marcus (Finance): Works for me, as long as Finance signs off on any change to it.

Notice the moves Chris made. He didn't crown a winner; he restated the trade-off neutrally, secured a single owner, and let each team keep its local view under a different, honest label. That last part matters: people resist alignment when it feels like erasure, so give the side view a name instead of killing it.

A spoken agreement evaporates by next month, so you capture it as a Business Glossary Entry. The full structure is the term, a plain business definition, the owner or steward, the domain it belongs to, the valid values, examples and non-examples, usage notes, and related terms. The entry itself is metadata, and your goal is that a brand-new colleague could read it and use the term correctly with no one explaining it to them.

The discipline that makes or breaks the entry is separating three things people constantly blur: the business meaning, the system label, and the local habit. The business meaning is what the term means to the organization, written so it survives even if you switch tools tomorrow. So never anchor a definition to a field name like "the value in ACT_FLG"; describe the real-world condition instead. The local habit is the undocumented shortcut one team has fallen into, and a strong entry calls it out by name in the usage notes ("Marketing has historically counted logins as active; for the official figure, do not"). When you keep these layers apart, a newcomer judges the term by its meaning rather than by whatever your systems happen to call it this year.

The one idea to carry out of this unit: a shared vocabulary is what stops the same definition fight from recurring, and you build it by naming the data type, facilitating one agreed meaning with an owner, and writing it down so the meaning stands on its own. Three practices build on each other next. You'll start with a quick sorting drill to make the four data types reflexive, then step into a live alignment session where you have to keep a drifting conversation on the four targets, and finally turn what you land on into a glossary entry a new hire could actually use. As you go, practice the facilitator's habit from the dialogue: restate the trade-off, pin one owner, and give the losing view a label rather than a burial.