In the last unit you settled a single term and named one owner for it. But a definition fight is almost never just two people in a room. Behind every disputed number sits a whole crowd: people who create the data, people who live off it in their daily work, and people who quietly worry about whether it's safe to use at all. This unit zooms out from the one term to the bigger picture, so that before anyone changes data, you can name everyone the change touches. Get this right and you stop the most common own-goal in governance: someone "fixes" data and accidentally breaks three teams downstream.

When a data problem lands on your desk, your first move is to name the data domain it lives in. A data domain is just a big bucket of related data organized around one business subject. The common ones are customer, product, supplier, employee, and finance. Naming the domain matters because each one quietly feeds a set of business processes, and those processes are what actually break when the data is wrong.

Think about how this plays out. The customer domain feeds onboarding, marketing outreach, and support. The product domain feeds order fulfillment, pricing, and most reporting. The supplier domain feeds procurement and paying invoices on time. The employee domain feeds hiring and payroll, and the finance domain feeds the monthly close. So when someone says "the product hierarchy looks off," you immediately know that fulfillment, pricing, and reporting are all in the blast radius. The domain is your map of who could get hurt.

Once you've named the domain, zoom in on the single dataset in question and ask who's standing around it. There's a predictable cast, and you'll meet each of these roles in much more depth in the next course. For now, you just need to recognize them. Producers create or supply the data, like the front-line staff typing in new records. Consumers use it to do their jobs, run dashboards, or make decisions. The owner is the one person accountable for what the data means and for the big calls about it. The steward handles the day-to-day coordination and quality issues. The custodian manages the technical home where the data lives and keeps it secured. And the risk partner weighs the compliance, privacy, or security angle when the data is sensitive.

The whole point is that no single team owns all of this, even when one person feels like they do.

• Ryan: I'm just updating the product list this afternoon, it's my data.
• Natalie: Before you do, who actually relies on that list after you change it?
• Ryan: Well, the order team uses it to ship, and finance rolls it into pricing.
• Natalie: Right, those are your consumers. And whoever stores and secures it is the custodian. Change it with no heads-up and shipping breaks tomorrow.
• Ryan: Okay, so I should at least tell them first.

Notice the move Natalie made: she didn't argue about who "owns" the data. She just asked who relies on it, and the cast revealed itself.

Now turn that cast into something you can actually use: a stakeholder map. You don't need a tool or a diagram. A stakeholder map is simply your answer to five plain questions about one dataset: who defines it, who supplies it, who uses it, who protects it, and who approves changes to it. Write a name or a team next to each. The owner and steward define it, producers supply it, consumers use it, the custodian and risk partner protect it, and the owner (usually with the risk partner's input) approves changes.

The habit to build is this: run the map before any change, not after the complaints roll in. If a slot comes up blank, that gap is your warning. A dataset with no named owner is the reason definition fights keep recurring, and a change meeting that invited only two analysts is missing the producers who supply the data and the risk partner who'd catch a compliance problem. The map turns "I didn't know anyone else cared" into a checklist you ran on purpose.

The one idea to carry out: every dataset has a domain and a full cast around it, and your job is to name them before a change, not apologize after one. A short arc of practice sits ahead. You'll first do a quick sorting drill matching business processes to their domains, then write an assessment of who interacts with one dataset and who got left out of a decision, and finally coach a peer through a stakeholder map live. As you go, keep running those five questions on every dataset that crosses your desk.