7. Kinds, roles, and phases

In chapters 5 and 6 you learned to test a category and check a hierarchy. Now we use those tools on the single most common bad entity in enterprise data.

Maya Chen registered in March 2024. She bought regularly for two years. She went quiet. In August 2026 she came back and signed up again with a new email address.

The system created a second Maya Chen.

There is no bug to find. Every line of code did what it was written to do. The registration worked perfectly and the duplicate was created correctly. The mistake was made two and a half years earlier, by someone who thought they were doing something obvious.

Telling them apart

Use the answers from chapter 5. Nothing new is needed.

Kind. Rigid, decides identity, needs nothing else. +R +I -D.

Person, Freezer, Shipment. Every one of them stays a Person for as long as it exists, and Person is what tells you when two records are the same one.

Role. Anti-rigid, borrows identity from a kind, and needs something else to exist. ~R +D.

Customer, Employee, Supplier, Patient, Tenant. You cannot be a customer without a seller. You cannot be an employee without an employer. The other party is not incidental to the role. It is what makes the role apply at all.

Phase. Anti-rigid, borrows identity from a kind, and needs nothing else. ~R -D.

Minor, Adult, Active, Churned, Expired. You pass through it because of how you changed, not because of a relationship with anybody.

Watch it break

Two models. One person. Four events. For the first three events the two models are indistinguishable, which is exactly why this mistake survives design review.

What actually went wrong

The error was not "Customer should not exist". Customer should absolutely exist.

The error was giving Customer its own identity, created at registration, with no kind underneath it.

Once identity lives on the role, three things follow, and none of them can be fixed later.

One. Ending the role has to destroy or contradict the record. She is declared to be a customer. She is not one any more. So either you delete the row and lose the history, or you keep it and add a flag that contradicts its own type.

Two. Coming back creates a new identity. There is nothing for the second registration to attach to. So it makes a new customer alongside the old one.

Three. One human in two roles becomes two things. She is a customer, and later a supplier. Two identities, no link between them, and no query can join them because the joining key never existed.

The fix is not clever. Put the kind underneath. Let the kind own identity. Let the role carry a period and a partner. That is all.

The default path is the wrong one

Fabric IQ entity types are flat. There are no kinds, roles, or phases. There is no subtyping and no way to say that one entity type borrows identity from another. Every entity type gets a key, and that key is its identity.

Which means the mistake in this chapter is not something you have to work at. It is what you get by following the tutorial.

You have a customers table. You make a Customer entity type. You pick CustomerID as the key. You bind it. You have just given a role its own identity. The tool will not object, the graph will build, and the agent will answer questions from it.

What to do instead, inside what Fabric offers

Make the kind an entity type, and give it the stable key. Person, keyed on something that survives re-registration. Or Organization, keyed on a registration number. This is the entity type that owns identity.

Where the role is really a link, make it a relationship. Person and Seller joined by a buys from relationship is closer to the truth than a Customer entity type.

Where the role must be its own entity type, because it carries facts, bind it to a key that refers back to the kind rather than one minted by its own signup flow. Then relate it to the kind so a traversal can get back to the person.

The one trap

When someone names a thing, do not model the name. Ask what else has to exist for that name to apply.

If the answer includes another party, it is a role, and identity belongs somewhere else.

Customer, patient, supplier, tenant, student, employee, member. Every one of those is a role. Every one is an entity type in somebody's model right now. Every one will eventually create a duplicate human being.

Next, chapter 8. Roles borrow identity from a kind. That raises the obvious question: what is identity, exactly? Chapter 8 answers it, and shows why a primary key is not the same thing.