Skip to content
Stratastax

ClaimRequest Domain Model

Purpose

Section titled “Purpose”

A ClaimRequest represents a proposed relationship between a CanonicalPlayer and one or more GhostPlayer references.

It does not modify identity directly. It introduces a pending edge that must be validated before becoming authoritative.

In essence: “This CanonicalPlayer believes these GhostPlayer references belong to them.”

Responsibilities

Section titled “Responsibilities”

A ClaimRequest is responsible for:

  • proposing ownership of one or more GhostPlayers;
  • preserving intent and context of a claim;
  • enforcing an approval workflow (anti-identity-theft protection);
  • tracking approval/denial state;
  • enabling reversible identity linking (via edge removal, not mutation);
  • capturing who initiated and who validated the claim.

Not Responsible For

Section titled “Not Responsible For”

A ClaimRequest is NOT responsible for:

  • merging data into CanonicalPlayer;
  • rewriting Match or Participation history;
  • changing GhostPlayer records (beyond the ClaimEdge itself);
  • computing statistics;
  • resolving identity automatically;
  • deciding correctness of identity.

Those belong to the Identity Resolution domain service and to Player graph operations.

Invariants

Section titled “Invariants”
  • A ClaimRequest always has exactly one claiming CanonicalPlayer.
  • A ClaimRequest may reference one or many GhostPlayers.
  • A ClaimRequest is immutable after creation (state changes only via events).
  • A GhostPlayer can be referenced by multiple ClaimRequests (conflict is allowed).
  • A ClaimRequest must be explicitly resolved: Approved or Rejected.
  • Approval requires authorization from the GhostPlayer’s owner (the User who created it), unless pre-approved via a trusted invitation path.
  • A ClaimRequest never deletes or alters GhostPlayer data.
  • A ClaimRequest cannot directly change CanonicalPlayer state.

Lifecycle

Section titled “Lifecycle”

Created

Section titled “Created”

A ClaimRequest is created when:

  • a user finds a GhostPlayer they believe represents them, OR
  • the system suggests a match via identity resolution heuristics, OR
  • an invitation-based pre-link is triggered.

State: Pending

Under Review (optional intermediate state)

Section titled “Under Review (optional intermediate state)”
  • awaiting confirmation from the GhostPlayer’s owner;
  • awaiting additional verification.

Approved

Section titled “Approved”

When validated:

  • a ClaimEdge is created;
  • the GhostPlayer remains unchanged;
  • the CanonicalPlayer gains a new relationship link.

State: Approved

Rejected

Section titled “Rejected”

When denied:

  • no ClaimEdge is created;
  • the request is stored for audit/history;
  • future re-requests may be allowed depending on policy.

State: Rejected

Revoked (optional future state, only reachable from Approved)

Section titled “Revoked (optional future state, only reachable from Approved)”

A previously approved claim can be reversed:

  • the ClaimEdge is removed (not the data);
  • the GhostPlayer remains intact;
  • the CanonicalPlayer loses that association.

State: Revoked

Relationships

Section titled “Relationships”
ClaimRequest
├── originatesFrom → CanonicalPlayer
├── targets        → GhostPlayer(s)
├── validatedBy    → User (GhostPlayer owner / trusted invitation path)
├── resultsIn      → ClaimEdge(s)

Domain Events

Section titled “Domain Events”
  • ClaimRequestCreated
  • ClaimRequestSubmitted
  • ClaimRequestApproved
  • ClaimRequestRejected
  • ClaimRequestExpired
  • ClaimRequestRevoked
  • ClaimEdgeCreated
  • ClaimEdgeRemoved

The real identity changes happen on the ClaimEdge events, not on the request itself.

Aggregate Design

Section titled “Aggregate Design”

ClaimRequest is an Aggregate Root, with a strict boundary: it only manages request state, participants (claimer, targets, validator), and lifecycle transitions. It does NOT own CanonicalPlayer or GhostPlayer.