Stop Treating Every Relationship Like an Entity. Your Knowledge Graph Is Dying.

You built a knowledge graph. It started clean. A few nodes, a few edges. Then someone added a valid_from field to a relationship. Then another. Now you’re staring at a tangled mess of 10,000 entities, half of which are just relationships wearing a costume.

I’ve been there. The frustration is real. Data modelers, product managers, engineers—everyone wants governance, traceability, and query efficiency. But the moment you start entity-izing every relationship that carries a few extra attributes, your graph bloats. It becomes incomprehensible. And the opposite—keeping everything as a thin edge—leaves you unable to capture business rules that actually matter.

There’s a way out. And it’s not about counting fields.

The boundary between a relation and an entity isn’t technical—it’s existential.

Let me show you with a real example. A telecom company sells a product called “Honor of Kings Big Data Card” through different channels. The natural model: Product → (sells through) → Channel. Simple. But when you add start date, end date, price, status, region, source system… suddenly everyone argues: “This relationship has enough attributes to be an entity!”

Wrong. Attributes alone don’t make an entity. What makes an entity is whether the relationship itself needs to be managed as an independent business object with its own lifecycle, identity, and audit trail.

Here’s the test: If you can change the price without creating a new version of the product-channel pair, it’s still a relationship. But if you need to keep a history of every price change, track approvals, and let orders reference a specific instance of that product-channel link—then congratulations, you’ve got an entity.

I call this the Identity Test: Does the relationship have its own ID that other objects reference? If yes, it’s an entity.

Let me give you the six questions that will save you hours of debate. Use them in your next model review:

1. Lifecycle: Does this relationship have its own creation, modification, and termination dates that are independent of the two endpoints?
2. Identity: Do other business objects (orders, invoices, contracts) reference this specific relationship instance?
3. Audit: Do you need to track who changed what and when on this relationship?
4. State Machine: Does the relationship go through states (draft, active, suspended, terminated) that are not simply inherited from the endpoints?
5. Multiple Instances: Can the same pair of entities have multiple concurrent or sequential versions of this relationship?
6. Governance: Is this relationship subject to its own business rules, approvals, or compliance checks?

If you answer ‘yes’ to two or more of these, upgrade it to an entity.

Now, a critical caveat: Just because you have a relational database table that stores a many-to-many mapping doesn’t mean you have a business entity. I’ve seen teams blindly promote every join table to a graph entity because “it has fields.” That’s a mistake. A technical implementation detail is not a semantic decision.

The twist? The same relationship can be an entity in one context and a simple edge in another. In the telecom example, the product-channel link might be a simple edge for the marketing team (who just want to know which channels are active) but an entity for the finance team (who need to track commissions per channel instance).

Your knowledge graph should reflect the business reality, not the database schema. And the business reality is: if a relationship needs its own manager, it’s probably an entity.

Don’t let graph bloat kill your project. Next time someone says “this relationship has a lot of attributes,” ask them the six questions. The answer will be clear.

And remember: the best models are the ones that make the next developer cry the least.