Identity Graph

Purpose

The Identity Graph models how Stratastax represents players over time.

Rather than replacing or mutating identities, Stratastax continuously enriches its understanding of player identity by creating relationships between personal, recorder-owned references (GhostPlayers) and authoritative identities (CanonicalPlayers).

This allows gaming history to remain immutable while identity resolution continues to improve.

---

Core Principle

Gaming history is never rewritten.

A Match never references a CanonicalPlayer directly. It always references a GhostPlayer, through a MatchParticipant. Identity is established afterward, by creating a ClaimEdge between a GhostPlayer and a CanonicalPlayer — never by rewriting the Match.

Match ──► MatchParticipant ──► GhostPlayer ◄── ClaimEdge ── CanonicalPlayer

Every claim adds knowledge to the graph without changing historical records.

---

Identity Graph

Canonical Player

Persistent identity

claims ↓

Claim Edge

Approved relationship

links ↓

Ghost Player

Observed player

referenced by ↑

Match

Historical record

---

Entities

CanonicalPlayer

Represents the authoritative identity of a real person.

Responsibilities:

• represents a real player;
• owns a Personal Gaming Archive;
• aggregates statistics and achievements;
• may claim multiple GhostPlayers.

---

GhostPlayer

A personal, reusable reference kept by the User who recorded a match — not a snapshot of a player, and not globally unique.

Characteristics:

• owned by exactly one User (the recorder);
• reusable across any number of matches recorded by that owner;
• display name is mutable by its owner;
• may remain unclaimed indefinitely — claiming is never required;
• may be claimed later by a CanonicalPlayer, via a ClaimEdge.

Two different recorders can each keep their own GhostPlayer referring to the same real person, entirely independently — see the example below.

---

MatchParticipant

Represents one player’s role and result within one specific Match.

Characteristics:

• references exactly one GhostPlayer;
• belongs to exactly one Match;
• holds the player’s result (score, rank, outcome) and, where applicable, their Loadout;
• changes only through an approved MatchEdit; otherwise unaffected by anything that happens elsewhere in the graph.

---

Loadout

Represents what a specific player brought to a specific Match — faction, character, starting cards, or other player-specific game configuration. Distinct from Playset, which is shared across all participants in a Match.

---

ClaimEdge

Represents an approved relationship between a CanonicalPlayer and a GhostPlayer.

A ClaimEdge:

• does not modify either the CanonicalPlayer or the GhostPlayer;
• can be revoked;
• is fully auditable.

---

Match

References MatchParticipants, never CanonicalPlayers or GhostPlayers directly.

Historical match data never changes because of identity resolution.

---

Relationships

Source	Relationship	Target
Match	references	MatchParticipant
MatchParticipant	references	GhostPlayer
MatchParticipant	holds	Loadout
GhostPlayer	owned by	User
CanonicalPlayer	claims (via ClaimEdge)	GhostPlayer
ClaimRequest	proposes	ClaimEdge
User	owns	CanonicalPlayer
User	authenticates via	UserIdentity

---

Example

Emma records a match.

Match
├── MatchParticipant ──► GhostPlayer ("Peter", owned by Emma)
├── MatchParticipant ──► GhostPlayer ("Sarah", owned by Emma)
└── MatchParticipant ──► GhostPlayer ("Emma", owned by Emma)

Peter does not yet have a Stratastax account.

Separately, Sara and Ruud each keep their own GhostPlayer named “Peter” — each owned by them individually. Whether these refer to the same real Peter or different people entirely does not matter to either of them; the references are independent.

Months later Peter joins Stratastax:

CanonicalPlayer (Peter)
        │
        ▼
   ClaimEdge
        │
        ▼
GhostPlayer ("Peter", owned by Emma)

The Match remains unchanged. Identity resolution simply establishes that this particular GhostPlayer belongs to Peter. If Sara’s or Ruud’s “Peter” GhostPlayers also belong to the same real person, each is claimed independently, through its own ClaimEdge.

---

Design Principles

The Identity Graph follows five fundamental principles:

1. Historical data is immutable.
2. Identity is additive, never destructive.
3. GhostPlayers are personal, recorder-owned references, not identities.
4. CanonicalPlayers are persistent, authoritative identities.
5. Claims create relationships instead of replacing data.