When entities and KPI definitions are ambiguous, teams pay the cost over and over again. The same transformations get rebuilt in parallel, leadership sees conflicting numbers, and trust erodes. This step breaks that cycle by defining a small, shared semantic core that becomes the foundation for reusable data products.

Start small, not enterprise-wide

You do not need an enterprise model to get started. Begin with 3–7 core business entities and the few KPIs that people argue about most often. These are typically the concepts at the center of your most important value chains.

A good starting set is often Customer, Product, Order, and Shipment. The key is to make identifiers explicit early and treat them as first-class design decisions, because everything downstream depends on them.

Turn definitions into something people can use

A definition only helps when it changes behavior. That means semantic work must be operational, not theoretical.

For each core entity and business-critical KPI, assign an accountable owner and agree a lightweight way to approve, reject, or version changes. Do not wait for perfect consensus. Pick a definition, socialize it, and refine it as you learn.

Make reuse safe

Reusability breaks down when people cannot combine products safely. To prevent that, make three elements explicit in every definition:

• The grain (what one row represents)
• The join keys (how the entity connects to other entities)
• The source-of-truth rules (where the authoritative record lives, and which system owns which fields)

What “done” looks like (minimum viable)

In practice, this work is “done enough” when teams can build and reuse data products without re-litigating definitions every time.

A minimal, practical package is:

• A short list of core entities (3–7) with explicit identifiers, plus a clear rule for where each identifier is created and how it propagates.
• Source-of-truth rules per entity that clarify which system owns which fields today, including known exceptions.
• A small set of business-critical KPI definitions that spell out the grain, inclusions and exclusions, time logic, and caveats, so the same KPI is not implemented ten different ways.

Once this exists, you have a semantic core that can be referenced, governed lightly, and expanded as new value chains and use cases appear.