Skip to main content
InternalMarkdown

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 and CONTEXT.md.