Identity & keys

Two patients, years apart, both named Jon Smith, both born in 1990.

The system had decided that a patient was "name plus birth year." So when the second Jon arrived, it found the first one and treated him as the same person. It merged them. One chart, two people, two sets of allergies. The first Jon was allergic to penicillin. The second Jon was not. Guess which one the system remembered.

Nobody typed a wrong value. The data was clean. The bug was one quiet decision: what makes two records the same patient. That decision is the key.

Two ways a key goes wrong

Think of a key as a promise: one key, one real thing. It can break in two ways.

Too loose, and two different John Smiths share one key, so they merge into one record. That is an undercount. In a hospital, that is dangerous. Not stable, and one person changes the thing you keyed on (their email), so they split into two records and their old history is left behind. That is an overcount. Now a customer feels forgotten.

Why this matters for an AI agent

An AI agent counts and joins by the key. Give it a bad key and every number it returns is quietly wrong. It double-counts customers who are really one person. It misses a person who is split across two ids. And it still answers with full confidence. A key that is unique and stable is what makes an agent's counts safe to trust.

Natural keys tempt you: name, email, phone. But two things can share one, and they change over time. When nothing in your data is both unique and stable, you create your own key: a plain id, one per thing, that never changes.

Try it. Turn columns on until every row is unique.

Where the key lands in Fabric

Most tools, including the lab you will build in, call this created key the unique identifier or primary key. Same idea, different name. Fabric IQ calls it the entity type key: the property, or the set of properties, that identifies one instance of an entity type. It is what lets Fabric line up many rows, and many sources, as the same one thing. It is also what an entity instance's identity is built on.

Do not assume you get one for free. Generate an ontology from a Power BI semantic model and a usable key does not always come with it. Microsoft's own tutorial walks through a generated fact table that arrives with its entity key missing, and a step called "Define entity type key" where you supply it by hand. Generation is a starting point, not a finished ontology. The decision you just practiced, what makes two rows the same thing, stays yours to make. The ontology item is still in preview as of July 2026, so expect this part to change. The decision underneath it will not.

The one trap

Do not trust a key just because it is unique today. Email is unique this month, until someone changes it or two people share one. Then the merges and splits begin, one quiet record at a time. Later they show up as a number nobody can defend. Treat identity as a decision: is this unique for every distinct thing, and does it stay the same when the thing changes? If nothing answers yes to both, create a key that does.

Now you have a key that reliably names one thing. Watch what it does next: it folds all those scattered rows into one real thing. That is an entity instance.