ADR 0010. Linking to an Existing PlayerPal Account Unifies Relationships

Status

Accepted.

Unification-at-link still stands. A richer optional profile must not use email, name or telephone (ADR 0012). Account discovery without email is ADR 0019. Assurance gating is ADR 0020.

Context

ADR 0009 makes linking mandatory at every audience. A player cannot earn anywhere without a one-time link/registration, and that's already the point where a PlayerPal identity is created. Given that, a separate "claim" concept for cross-audience unification would be redundant: the player is already taking an explicit registration-like action at every audience, so there's no reason unification should need a further, distinct action rather than happening as part of linking itself.

Decision

There is one account-creation event, not two:

• The first time a player links to any audience, PlayerPal creates their account.
• At every subsequent audience, linking means the player either:
  1. signs in as that existing PlayerPal account (proving it's the same person), in which case the new audience relationship is unified with all previously-linked ones immediately, with no further "claim" step. Linking is the unification event; or
  2. does not identify as an existing user (declines, forgets, or the flow doesn't surface the option), in which case a new, separate, independent account is created for that audience, which is an expected outcome of player choice/behavior, not a bug.

"Claiming" as a distinct, later, richer-account concept is retired. There is just one PlayerPal account, created at first link, which accumulates additional linked audiences over time whenever the player signs into it again.

This does not remove the option of a richer optional profile (username/password/email, self-service redemption, direct login to a PlayerPal-branded portal outside of any operator/provider session). That remains a valid optional enhancement to an existing account, but it is no longer what triggers unification. Unification is now purely a function of linking a new audience to an account that already exists.

Consequences

• architecture-brief.md §1, §2.3, §2.3c, and §2.4 are reworded to drop the "claim" framing and describe linking-to-existing-account as the unification mechanism.
• New open question: the "sign in as existing PlayerPal account" mechanic at a second+ audience is undefined. Does the player enter an email/phone that PlayerPal verifies, get redirected through a PlayerPal-hosted auth page, scan a code, something else? This determines how much friction unification actually costs versus staying as fragmented, independent accounts. See docs/open-questions.md.
• A player who never signs into an existing account at subsequent audiences simply ends up with multiple independent PlayerPal accounts. This is a legitimate, expected state, not an error case to design around.