# ADR 0009. Mandatory One-Time Link Before Any Data Reaches PlayerPal

## Status
Accepted.

Link mechanics (signed assertion, PlayerPal-hosted popup, result-code
exchange) are [ADR 0017](0017-operator-assertion-popup-linking.md). Product
policy in spec §33 confirms no pre-registration shadow profiles and no
historical points by default.

## Context
A PlayerPal identity must not come into existence purely from passive
first-contact, i.e. the player never acting, never seeing PlayerPal,
data simply starting to flow. Two problems rule that out:

1. PlayerPal is a standalone product in its own right, not invisible
   infrastructure fully hidden behind whichever party integrates it
   (operator or provider). A player should be aware they have a
   relationship with it.
2. Also, there was no point at which the player had agreed
   to anything from PlayerPal, or even been told PlayerPal exists. Data
   about them was being transmitted to and processed by a third party
   with zero touchpoint. That is not a defensible legal-basis story, and
   it doesn't match the intended product positioning either.

## Decision
No activity data for a given player is transmitted to or processed by
PlayerPal until that player has **registered or linked at least once**.
This is a one-time, per-`(player, audience)` action, not a per-session
login. Concretely:

- A `party_identifier` row (and any associated identity/ledger state) is
  created only at the point this one-time link/registration completes,
  not at "first exposure" as earlier phrasing in §2.3a implied.
- Before that link exists, PlayerPal has no record of the player and
  processes nothing for them; that activity stays entirely inside the
  audience's (operator's or provider's) own systems.
- After the one-time link, subsequent earning is automatic. The player
  does **not** need to log into PlayerPal again on every visit or every
  event. The friction goal from the original requirement is preserved at
  the session/event level; it just no longer extends to eliminating the
  touchpoint entirely.
- This one-time action is also the natural place to satisfy a lawful
  basis for processing (consent/notice specific to PlayerPal). The
  mechanics of what that touchpoint actually shows and who presents it
  (the integrating party's own UI vs. a PlayerPal-hosted widget) are
  still open, see `docs/open-questions.md`.

Linking establishes one `(player, audience)` relationship; it does not
by itself unify relationships across different audiences. A player could
in principle be linked independently at several operators and/or
providers, whichever parties integrate PlayerPal directly, without
ever unifying them. Whether and how a later link joins an existing
account instead of creating a new one is decided in ADR 0010.

## Consequences
- §1's non-negotiable requirement is reworded: earning requires no
  *repeated* login, not no touchpoint at all.
- §2.3a's "generated at first exposure to that audience" is corrected to
  "generated at the point the one-time link completes."
- §2.4's "a loyalty identity can exist before any explicit sign-up" is no
  longer accurate and is removed.
- §4 (ingestion) gains an implicit precondition: an event for a
  `(player, audience)` pair that has never linked has nowhere to be
  attributed and is out of scope for PlayerPal. It is the integrating
  party's (operator's or provider's) event, not PlayerPal's, until linked.
- New open question: the concrete UX/consent mechanics of the one-time
  link flow (surface, content, timing, who presents it) are undefined.