Relationships
A party on its own is a directory entry. The reason to model your whole world as parties is that you can then connect them, and connect them with meaning. Relationships are what turn a list of parties into a graph you can reason over, and they are the complementary axis to the roles and attributes covered in Persons and Organizations: not what a party is, but how it is connected.
Typed Edges Between Any Two Parties
A relationship connects two parties and carries a type that says what the connection means, such as employed_by, member_of, manages, delegates_to, or same_entity, drawn from a catalog your deployment registers. Because every participant is a party, a relationship can link any two of them: a person to an organization, an organization to another organization, a service to its owner, a unit to a unit.
Relationships are records in their own right rather than flags tucked inside another object, and three properties make them dependable. The type comes from a registered catalog, so a relationship means the same thing everywhere and can be queried by type. Each type carries a reading in both directions, which is what the diagram above shows: the single edge between Lena and the university is studies_at read from her side and has_student read from the university's side, and employed_by from one side is employs from the other. Some types are symmetric, like same_entity, where both readings are the same. A relationship can also carry a validity window together with full audit, so a question like "who managed whom last March" has an answer. Adding a new kind of connection is registering a type, not migrating a schema, which is what lets the model keep up with how your world actually fits together.
Relationships Model the World
Once both participants and their connections are expressed in one graph, the structures you care about are simply shapes in it. An organization chart is employed_by and manages edges between people and organizations, with units providing the containment. A marketplace is buyer and seller organizations linked to the parties they transact with. Delegation is a delegates_to edge from an agent service to the human who is accountable for it. A campus is a university organization with faculty units nested beneath it, students and staff contained in those units, and enrolment or membership edges where you need them.
The value shows up when you walk the graph to answer questions a single record cannot: every party an organization employs, every group a person belongs to, every service that delegates to a given owner. The graph in the diagram above reads this way. The university has its units, the Faculty of Law and IT Services, so each unit is part_of the university. Lena exists as two personas: a student whose home unit is the Faculty of Law and who studies_at the university, and a staff member whose home unit is IT Services and who is employed_by it. The two personas are the same human, which a symmetric same_entity link records explicitly. Notice the two axes at work together: containment places each persona in exactly one home unit, while typed relationships connect the personas to the university and to each other.
Same Entity: Linking Personas
One relationship type deserves its own treatment, because it solves a problem every real directory runs into: the same real-world person or organization existing as more than one record. The same_entity relationship links two parties, or several pairwise, that represent the same real-world entity across organization units or login surfaces. The human case of two person records that are the same human is only one use of it; it equally ties two organization records that are the same legal entity, such as a supplier organization under procurement and a customer organization under sales.
This is the second way to model "one person, several roles" introduced under multi-typing. When the personas need different home units, separate attribute sets, or separate login identities, you keep them as distinct parties and connect them with same_entity rather than collapsing them onto one record.
What makes it the right tool is that it is the intentional, governed link. Joining two personas is an explicit administrative or onboarding act that is recorded and can be revoked, and it is deliberately different from any incidental equality that might be inferred from a shared email address, which the platform actively suppresses at the data layer (see protected identifiers). Because it correlates personas on purpose, it is itself privacy-sensitive: who may create or read it is an authorization concern, and it should not be exposed on low-trust surfaces. In return it gives you consolidated views and cross-persona reasoning, such as "show me all personas of this human" or "the employee and the customer are the same subject," without forcing the personas to share an identifier, a home unit, an attribute set, or a login identity.
Relationships Are the Basis for ReBAC
Roles and attributes let you decide about a single party, which is role- and attribute-based access control. Relationships let you decide based on how parties are connected, which is relationship-based access control. The pattern is that a permission follows an edge. A manager of the request's owner may approve it, walking a manages edge from the requester to the owner. A member of the group that owns a resource may read it, walking member_of from the principal to the group. An agent may act only for the owner it delegates to, walking delegates_to from the agent to the human.
Because relationships are typed and directional, these rules are expressed against edge types and traversal rather than against ad-hoc joins. The same_entity link extends this reasoning across personas, letting a rule treat the employee and the customer as one subject precisely when an explicit link says they are, and not otherwise. The engine that evaluates these rules lives in the authorization layer; the relationship graph on this page is the fact base it traverses. Creating, reading, listing by party, updating, and deleting relationships over REST is covered on the Party REST API page.