# ADR 0001. Generic Party Model

## Status
Accepted.

## Context
PlayerPal needs to represent operators, providers, affiliates, merchants
(reward partners), brands, applications, and configured integrations.
Modeling only "players" and "casinos" would not generalize beyond iGaming,
and would require a new table for every new organisation type.

An early draft also treated the player as a `party` row. Specialised player
tables (spec §15) made that redundant: loyalty identity, aliases, auth
mappings, and links do not fit the org/integration shape.

## Decision
Use one generic `parties` entity with a `party_type` enum for **network
organisations and integrations only**:
`OPERATOR`, `PROVIDER`, `AFFILIATE`, `MERCHANT`, `BRAND`, `APPLICATION`,
`INTEGRATION` (`pp_int_...`).

**Players are not parties.** Private loyalty identity lives in dedicated
tables (`players`, `player_aliases`, `authentication_identities`,
`identity_links`, …). Do not create a `parties` row for a player. The
`PLAYER` enum value is legacy and must not be used for new rows; remove it
from the schema when convenient.

Org/integration relationships (campaign ownership, integrations, external
IDs owned by a partner) reference `parties`. Player relationships reference
`players.id` (internal) or typed aliases (external).

## Consequences
- One reusable framework for partner/org entities.
- Externally, still expose **typed** IDs (`pp_opr_...`, `pp_prv_...`,
  `pp_int_...`, …). See ADR 0002 / 0013 rather than a generic
  `pp_party_...`.
- Adding a new organisation type is a new enum value, not a parallel
  table family.
- See [docs/data-model.md](../data-model.md) and `CONTEXT.md`.