The Party Model
Every system that touches people eventually has to answer the same question: who, or what, is on the other side? A customer signing up, a company you do business with, a department inside that company, a background service calling an API, an AI agent acting for a person. Most platforms model each of these with a different table, a different identifier, and a different login path, then spend years reconciling them.
The party model takes the opposite approach. Everything that participates is a party. A person is a party, an organization is a party, and so are a department, a service, a group, and the tenant itself. Each one is a single typed object that carries its own data and shares a common contract, so you describe your real world once and the platform routes, relates, and authenticates against that one description.
What a Party Is
A party is any participant in your ecosystem, discriminated by its partyType. There are five concrete types. A Person is a human individual that carries a name and date of birth. An Organization is a company, institution, or other legal entity with a legal name, an industry, and contact details. An Organization Unit is a nesting container such as a department, a faculty, a location, or a workspace, and it holds the branding and terms a part of your organization presents. A Service is a software-backed participant such as an application, an endpoint, an integration, or an automated actor, and a service that people sign in to is also a login surface. A Group is a set of members used for addressing and authorization.
The thing that makes this more than a naming convention is that each type is a complete object rather than a thin row pointing at detail tables. When you read a person back, the name is on the same object. There is no second request to a detail record and no join to reassemble on the client. The API speaks in the same nouns you use when you describe your business, which is what keeps the model legible as it grows.
Modelling Your World
Because the five types share one base contract, you compose them the way reality is composed. An organization contains organization units, units nest inside other units, and people and services live in a unit. Groups gather members from anywhere. The structure of a tenant is therefore expressed in parties, so an organization chart, a campus with faculties, or a marketplace with buyers and sellers is a graph of parties you can read and walk.
Two capabilities turn that static picture into a living model, and each has its own page. Parties can be extended with your own properties through specializations, so a person can be a student and a staff member at the same time, each with its own validated attribute set; that is covered under Persons and Organizations. Parties can also form typed relationships with each other, so you can express employment, membership, delegation, or the fact that two records are the same entity; that is covered under Relationships. Organization units carry enough weight in this model to warrant their own treatment in Organization Units.
Identity Is a Separate Layer
A party is the directory entry: it says who or what exists. Identity is a separate layer on top that describes how a party is recognised, discovered, and, when it is permitted, how it signs in. One party can hold several identities, and an identity carries identifiers such as an email address, a phone number, a decentralized identifier, or a federated subject.
Keeping the two apart is deliberate, because many parties in a real tenant will never log in. A contact you imported, a supplier you only invoice, an organization you keep on file: each needs to be discoverable and relatable, but none needs to authenticate. Authentication is a capability you grant explicitly, per application, rather than something every identifier implies. The page on Identities and Identifiers covers discovery, how identifiers are protected at rest, and how the same email address can belong to three different identities in one tenant without any of them being able to log in where they should not.
One Tenant, Three Use Cases
Because participants, their structure, their roles, and their login surfaces are all parties, identities, and bindings, a single tenant can run consumer, business, and agent scenarios at once instead of as three separate stacks.
In a consumer (B2C) setting, a customer-facing application is a service party with a login surface. Customer persons hold a customer role and are bound to authenticate only at that service, using passkeys, social login, or one-time codes, with self-registration and step-up verification configured on the surface. In a business (B2B) setting, organizations and nested organization units carry their own branding and terms, employees live in units and hold an employee role bound to internal services, enterprise single sign-on is gated per surface, and the same organization can act as both a customer and a supplier. For software and AI agents, a service (and, in time, a dedicated agent type) is a first-class identity with its own identifiers, credentials, and authenticable bindings rather than a credential stored on a human's account, and it delegates to a human owner through a typed relationship so that every action remains attributable.
The behaviour that ties these together is that the same email address can resolve to an employee at the internal application, a customer at the consumer site, and a contact that never logs in anywhere, all inside one tenant. That is the login resolution described later, and it falls out of the model rather than being bolted on.
Roles, Attributes, and Relationships Drive Authorization
The same model feeds every common authorization style, so you are not forced to choose one up front. A party's role labels are the basis for role-based access control, its validated attributes are the basis for attribute-based access control, and the typed relationships between parties are the basis for relationship-based access control.
Roles and attributes answer questions about a single party from its own data, such as whether someone is staff or whether their faculty is Law. Relationships answer questions that follow the graph from one party to another, such as whether the requester is the manager of the resource's owner. You choose the style per decision, and the party model supplies the facts for all of them.
What This Section Covers
Persons and Organizations covers the party types in depth, how a party is extended with custom properties through specializations, how one record can wear several hats at once, and the contact data and registrations that hang off a party. Organization Units covers nesting, containment, branding inheritance, and how a unit gives a tenant its internal structure. Relationships covers typed edges between any two parties, the link that ties personas of one real-world entity together, and how relationships become the basis for relationship-based access control. Identities and Identifiers covers the decoupled identity layer, identifiers for discovery and authentication, protected identifiers, and application-bound login. The Party REST API covers the /api/party/v1 surface, with each operation shown as an abstract, a REST call, a service command, and a gRPC envelope.
The semantic profiles and catalogs that give attributes their meaning are part of the semantic model; this section shows where a party's specialization binds to a profile, not how profiles are authored. The engines that evaluate authorization rules live in the authorization layer; this section supplies the party facts they read.