# 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](0012-never-receive-player-pii.md)).
Account discovery without email is [ADR 0019](0019-scoped-bootstrap-proofs-controlled-merge.md).
Assurance gating is [ADR 0020](0020-assurance-levels-provisional-password.md).

## 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.