Skip to main content
InternalMarkdown

ADR 0013. Typed Pairwise Aliases (pp_plr_, pp_plr_opr_, pp_plr_prv_, …)

Status​

Accepted.

Supersedes the partner-facing prefix in ADR 0002. Random 128-bit generation, Crockford Base32 and stored mappings still apply.

Context​

Early ID architecture used pp_plr_... as the external alias given to every audience. That made the player-visible PlayerPal ID indistinguishable from a partner handle and invited sending pp_plr_... to operators. Party IDs such as pp_opr_... were also sometimes mistaken for player aliases.

Alias audiences beyond operator and provider (affiliate, application, reward partner) need distinguishable prefixes before they are implemented, so logs and APIs do not invent ad-hoc strings later.

Decision​

  • Internal primary keys are UUIDv7 and are never exposed.
  • pp_plr_... is the player-visible PlayerPal identity. Player and PlayerPal only. Never sent to an operator, provider, affiliate, application, or reward partner.
  • Reserved player-alias prefixes (audience-scoped):
    • pp_plr_opr_..., operator (active)
    • pp_plr_prv_..., provider (active; integration-scoped by default; ADR 0014)
    • pp_plr_aff_..., affiliate (reserved; audience entity undecided)
    • pp_plr_rwd_..., reward partner (reserved; audience entity undecided)
    • pp_plr_app_..., application (reserved only; not an active alias audience yet)
  • Brand is a party type only, never an alias audience.
  • pp_opr_..., pp_prv_..., pp_aff_..., pp_int_... (and other party prefixes) identify parties or integrations. They are not player aliases.

Aliases remain cryptographically random 128-bit values, Crockford Base32 encoded, unique per (audience_id, external_alias) and one active alias per (player_id, audience_id). They are created at completed link/consent for that audience relationship, not at passive first exposure. Do not mint affiliate / reward-partner aliases until their audience entity is decided.

Consequences​

  • Partner APIs and launch payloads must never echo pp_plr_....
  • Logs and support tooling can tell player-visible IDs from partner aliases by prefix.
  • Encoding detail: docs/identity.md. Spec §4 and §30. Glossary: CONTEXT.md.