LS-SPEC-001 — Ambassador & Community Platform

⚠ SUPERSEDED IN PART — READ BEFORE USING THIS DOCUMENT

As of CHG-SPEC-001 (Cobalt Horizon Group — Affiliate, Ambassador & Creator Partner Platform), this document no longer owns referral tracking, the reward engine, campaign management, the marketing asset library, training/certification, ambassador communications, or fraud detection. Those capabilities turned out not to be Legend Studios-specific — they are generic across any Cobalt Horizon Group company — and now belong to CHG-SPEC-001, consumed by Legend Studios (and every other CHG company) rather than owned per-tier redundantly.

What has not been reassigned, pending a full rewrite of this document (see Recommended Next Steps, end of file): the beta tester program (§8) and content creator program (§9) as described below may still contain genuinely Legend-Studios/gaming-specific tracking (build-tied testing, platform-specific content metrics) that plausibly belongs at this tier rather than the CHG tier — that determination has not yet been made. Until this document is formally rewritten, treat every section below as historical context for what CHG-SPEC-001 generalized from, not as a currently authoritative ownership claim. For current ownership, defer to CHG-SPEC-001's header and DL-DEPENDENCY-MAP.md.

Status: Draft v1.0 — not yet frozen. Ownership substantially superseded by CHG-SPEC-001 as of this notice; full rewrite pending. Governed by: LS-PLATFORM-ARCHITECTURE.md (for anything that remains Legend-Studios-specific) and, transitively, CHG-PLATFORM-ARCHITECTURE.md (for everything now owned by CHG-SPEC-001). In any conflict, the more recent document governs: CHG-SPEC-001 > CHG-PLATFORM-ARCHITECTURE.md > this document. Namespace note: This is the first LS-SPEC (Legend Studios) document, distinct from the DL-SPEC (Diamond Legend) series. It is written to be game-agnostic from day one — Diamond Legend is its first consumer, not its owner.

Depends on: DL-SPEC-017 (Advertising & Monetization — revenue/subscription data this system references but does not own), an external Authentication system (consumed, not owned — see §0.3), an external Payment/Payout provider (consumed, not owned — see §7.4).

Owns (as originally written — see supersession notice above for current status): The entire ambassador/community lifecycle — profiles, referral tracking, levels, the reward engine (not payment execution), the beta tester program, the content creator program, campaigns, the marketing asset library, training/certification, ambassador communications, and ambassador-specific analytics and fraud detection.

Explicitly does not own: Payment processing or payout execution (§7.4), subscription/tier entitlement logic (owned by DL-SPEC-017 — this spec reads referral-driven revenue events from DL-SPEC-017, it does not compute them), player identity or custom player logic (unrelated), user authentication/account identity itself (§0.3), and any single game's gameplay systems. As of CHG-SPEC-001, also does not own: referral tracking, the reward engine, campaigns, the marketing asset library, training/certification, communications, or fraud detection — see supersession notice above.

Consumed by: Diamond Legend (and, per §11, any future Legend Studios title) as a client of this platform, not a fork of it. For the capabilities now owned by CHG-SPEC-001, Legend Studios consumes CHG-SPEC-001 directly via its own Brand Adapter, not through this document.

Exposes: Ambassador Profile API, Referral Tracking API, Reward Engine API, Campaign API, Asset Library API, Training API, Communication API, Analytics API, Fraud/Security API — all game-agnostic, all namespaced by game_id per §11. Most of these APIs are now superseded by CHG-SPEC-001's equivalents (§19 of that document) — see the supersession notice above.

Governing principle: One ambassador, one identity, many games. Every data structure in this spec is designed so that a single ambassador record can accrue referrals, rewards, and standing across multiple Legend Studios titles without duplicating their profile per game. Game-specific data (which game a referral converted into, which game a piece of content covers) is a dimension on shared records, never a reason to fork the record itself. This principle itself was generalized, not invalidated — CHG-SPEC-001 §0.1's "one underlying model" and §15's Brand Adapter pattern are this exact idea, one tier up.

0. Foundational Architecture Decisions

This section implements LS-PLATFORM-ARCHITECTURE.md — it does not independently establish platform-independence rules. Where the two differ, LS-PLATFORM-ARCHITECTURE.md governs.

0.1 Platform, Not Feature

This system is modeled as a standalone platform with a thin per-game adapter, not a Diamond Legend feature with hooks. Concretely: every entity in §2 carries a game_id (nullable, meaning "studio-wide") rather than living in a Diamond-Legend-specific schema. A future Gridiron Legend integration adds rows, not tables.

Per LS-PLATFORM-ARCHITECTURE.md §2.2, this spec explicitly does not own and will never absorb: game simulation, game saves, player databases, league databases, multiplayer simulation, or franchise logic. These remain permanently game-owned, regardless of implementation convenience.

0.2 Game Adapter Interface

Each consuming game implements a small adapter, whose full responsibility set is fixed at exactly (per LS-PLATFORM-ARCHITECTURE.md §4.1):

• Authenticating the user
• Reading ambassador status
• Reading affiliate status
• Reading reward entitlements
• Reporting referral conversions
• Reporting campaign participation
• Reporting analytics events

The adapter must never duplicate platform logic. Concretely for this spec: an adapter reports a conversion event to the Referral Tracking API (§5) rather than computing attribution itself; it reads an entitlement flag from the Reward Engine API (§7) rather than re-deriving level/reward eligibility from raw referral data; it reports analytics events rather than maintaining a parallel analytics rollup. If a game's adapter implementation ever needs to recreate any part of §5-§17's logic locally to make integration easier, that is a signal this spec's API surface (§12) is missing something — the fix is extending the API, never duplicating the logic on the game side.

No consuming game writes directly to this platform's core tables (§2) — everything goes through the adapter and the APIs in §12. Games may cache platform data (ambassador status, entitlements, campaign info) temporarily for performance, but a game is never the source of truth for any platform-owned entity — a cached value that disagrees with the platform is stale, not authoritative, per LS-PLATFORM-ARCHITECTURE.md §5.

0.3 Authentication — Consumed, Not Owned

This spec assumes an external identity/authentication system (shared across Legend Studios, likely the same one gating game accounts) issues a stable user_id. Every Ambassador Profile (§4) is keyed to that external user_id, not a platform-local login. This spec owns ambassador identity (status, levels, history) layered on top of that external account identity — it does not implement login, password, or session logic.

1. System Architecture

1.1 Component Map

These are logical services, not a mandate on physical deployment topology — the spec's contract is the API/data boundaries between them, not how they're hosted.

1.2 Data Flow, High Level

Prospect applies → Ambassador Profile created (state: Application Submitted)
        ↓
Admin reviews → Accepted → Onboarding → Training Service tracks completion
        ↓
Active Ambassador → Referral Tracking Service issues code/link
        ↓
Referred user signs up in a game → Game Adapter reports event → Referral Tracking Service
        ↓
Referred user subscribes (DL-SPEC-017 event) → Game Adapter reports conversion → Reward Engine evaluates rules
        ↓
Reward Engine grants reward (commission accrual, badge, level-up check) → Communication Service notifies ambassador
        ↓
Analytics Service rolls all of the above into dashboards (§10, §16)

2. Database Schema and Entity Relationships

Presented as entity definitions with key relationships; field lists are representative, not exhaustive column-by-column DDL.

2.1 Core Entities

ambassadors
  id (pk)
  user_id (fk → external auth identity)
  status (enum, see §3)
  status_changed_at
  applied_at
  onboarded_at
  internal_rating
  community_reputation_score
  notes (internal, admin-only)

ambassador_profiles (1:1 with ambassadors)
  ambassador_id (fk)
  display_name
  country
  languages (array)
  social_platforms (array of platform_handle objects)
  follower_counts (jsonb, per platform)
  primary_content_type
  favorite_game (game_id, nullable)
  biography
  skills (array)
  availability

ambassador_game_links (many:many — the core of §0.1/§11)
  ambassador_id (fk)
  game_id
  linked_at
  active (bool)

ambassador_levels (config table, not per-ambassador)
  level_key (bronze/silver/gold/platinum/diamond/legend)
  requirements (jsonb)
  benefits (jsonb)
  unlocks (jsonb)

ambassador_level_history
  ambassador_id (fk)
  level_key (fk)
  achieved_at

2.2 Referral Entities

referral_codes
  id (pk)
  ambassador_id (fk)
  code (unique)
  game_id (nullable — studio-wide codes permitted per §11)
  created_at
  active (bool)

referral_links
  referral_code_id (fk)
  url (derived/generated, unique)

referral_events
  id (pk)
  referral_code_id (fk)
  event_type (click / signup / subscribe / renew / cancel)
  game_id
  external_user_id (the referred user, distinct from the ambassador)
  occurred_at
  revenue_amount (nullable — populated only for subscribe/renew events, sourced from DL-SPEC-017, see §18.1)

2.3 Reward Entities

reward_rules (config table)
  id (pk)
  trigger_type (referral_conversion / level_up / campaign_goal / manual)
  reward_type (see §7.1)
  conditions (jsonb)
  active (bool)

reward_grants
  id (pk)
  ambassador_id (fk)
  reward_rule_id (fk, nullable for manual grants)
  reward_type
  value (jsonb — meaning depends on reward_type, see §7.1)
  status (pending / approved / fulfilled / reversed)
  granted_at
  fulfilled_at

2.4 Beta Tester Entities

beta_tester_profiles (1:1 with ambassadors, only present if ambassador holds the Beta Tester tag)
  ambassador_id (fk)
  platform
  game_id
  reliability_score
  participation_score

beta_sessions
  id (pk)
  beta_tester_profile_id (fk)
  version
  hours_played
  session_date

bug_reports
  id (pk)
  beta_tester_profile_id (fk)
  status (submitted / confirmed / rejected / fixed)
  submitted_at

suggestions
  id (pk)
  beta_tester_profile_id (fk)
  status (submitted / accepted / declined)

2.5 Content Creator Entities

content_creator_profiles (1:1 with ambassadors, only present if ambassador holds the Content Creator tag)
  ambassador_id (fk)
  platforms (array — YouTube/Twitch/TikTok/Kick/Facebook/Instagram/X/Blog/Podcast)

content_submissions
  id (pk)
  content_creator_profile_id (fk)
  platform
  game_id
  url
  metrics (jsonb — views, engagement, etc., refreshed periodically)
  approval_status (pending / approved / rejected)
  campaign_id (fk, nullable — see §2.6)

2.6 Campaign, Asset, Training, Communication Entities

campaigns
  id (pk)
  name
  game_id (nullable — studio-wide campaigns permitted)
  start_date / end_date
  goals (jsonb)
  target_audience (jsonb)

campaign_participation
  campaign_id (fk)
  ambassador_id (fk)
  performance (jsonb, rolled up from referral_events + content_submissions)

marketing_assets
  id (pk)
  game_id (nullable)
  type (image/video/logo/brand_guideline/press_kit/caption/launch_asset)
  current_version_id (fk → asset_versions)

asset_versions
  id (pk)
  asset_id (fk)
  version_number
  file_ref
  created_at

asset_downloads
  asset_version_id (fk)
  ambassador_id (fk)
  downloaded_at

training_modules
  id (pk)
  title
  game_id (nullable — studio-wide modules like "Community Standards" vs. game-specific "Diamond Legend Overview")
  requires_knowledge_check (bool)

training_progress
  ambassador_id (fk)
  training_module_id (fk)
  status (not_started / in_progress / complete)
  completed_at

certifications
  ambassador_id (fk)
  certification_key
  issued_at

communications
  id (pk)
  type (announcement / dm / email_template / campaign_update / task_assignment / release_note)
  ambassador_id (fk, nullable for broadcast types)
  content_ref
  sent_at

2.7 Security Entities

audit_logs
  id (pk)
  actor_id (admin or ambassador)
  action
  entity_type / entity_id
  occurred_at

fraud_flags
  id (pk)
  ambassador_id (fk, nullable)
  flag_type (referral_abuse / duplicate_account / commission_anomaly)
  status (open / reviewed / confirmed / dismissed)
  evidence (jsonb)

3. Ambassador Lifecycle — State Machine

3.1 States

Prospect
   ↓ (application submitted)
Application Submitted
   ↓ (admin review)
Application Review
   ↓ (approved)              ↓ (rejected)
Accepted                     [terminal: Rejected]
   ↓ (onboarding started)
Onboarding
   ↓ (training complete, §14)
Training Complete
   ↓ (activated)
Active Ambassador
   ↓ (meets level requirements, §6)          ↘ (extended absence)
Elite Ambassador                              Inactive
   ↓ (meets level requirements)                  ↓ (reactivation)
Legend Ambassador                             Active Ambassador (re-entry)
                                                   ↓ (policy violation)
                                               Suspended
                                                   ↓ (resolved)          ↓ (unresolved / repeat)
                                               Active Ambassador          Removed

3.2 Transition Rules

Every row in this table is logged to audit_logs (§2.7) — no state transition is silent, matching the same "every decision is logged" instinct already established for DL-SPEC-006's AI agents and DL-SPEC-013's governance events.

3.3 Terminal vs. Recoverable States

Rejected and Removed are terminal for that ambassador record (a removed ambassador who wants back in submits a new application, rather than reactivating the old record, to keep history honest). Inactive and Suspended are recoverable by design — this system defaults to giving people a path back rather than treating absence or a first violation as permanent.

4. Ambassador Profile

Fields, consolidated from §2.1/2.2 into the conceptual groupings you specified:

Identity: user_id link, display name, join date, status, country, languages. Referral: referral code(s), referral link(s) — an ambassador may hold multiple codes if participating in multiple campaigns/games (§5.1). Presence: social platforms, follower counts (per platform), primary content type, favorite game. Narrative: biography, skills, availability, admin-only notes. Standing: internal rating (admin-set, private), community reputation score (system-computed, see §16.3 for its inputs — potentially visible depending on product decision, not mandated here).

Profile fields are deliberately split between ambassador-editable (presence, narrative) and admin/system-only (identity status, standing) at the schema level (§2.1's notes/internal_rating living outside the ambassador-editable ambassador_profiles table) so permission enforcement (§17.4) has a clean boundary to check against rather than a field-by-field allowlist.

5. Referral System

5.1 Code and Link Generation

Each ambassador receives at least one referral code at Active Ambassador activation. Codes are game_id-nullable (§2.2) — a studio-wide code attributes conversions to whichever game the referred user actually signs up for, while a game-specific code (issued for a game-specific campaign, §13) attributes only within that scope. Both models coexist; which one a given ambassador uses is a campaign/product decision, not an architectural constraint.

5.2 Tracked Events

Per referral_events (§2.2): clicks, signups, subscribes, renewals, cancellations — each an immutable event, never an overwritten counter, so historical accuracy survives even if aggregate metrics are later recomputed differently.

5.3 Derived Metrics

Computed, not stored redundantly, from referral_events:

• Revenue generated, recurring revenue, lifetime value, conversion rate (signups → subscribes), active referrals, inactive referrals, cancelled subscribers.
• All revenue-bearing figures are derived from revenue_amount values that originate in DL-SPEC-017 (§18.1) — this spec computes referral-attribution rollups, it does not independently compute what a subscription is worth.

6. Ambassador Levels

6.1 Level Ladder

Bronze, Silver, Gold, Platinum, Diamond, Legend — stored as config (ambassador_levels, §2.1), not hardcoded, so tuning requirements/benefits is a data change.

6.2 Per-Level Definition

Each level config entry defines, per your spec:

{
  "level_key": "gold",
  "requirements": { "min_active_referrals": 25, "min_months_active": 3, "min_reputation_score": 70 },
  "benefits": { "commission_rate_multiplier": 1.25, "reward_rule_ids": ["gold_bonus_1"] },
  "recognition": { "badge": "gold_badge", "in_game_flair": true },
  "responsibilities": { "expected_monthly_activity": true },
  "unlocks": { "early_beta_access": true, "discord_role": "gold_ambassador" }
}

Level-up evaluation is a Reward Engine responsibility (§7), triggered by the same referral/activity events that feed §5.3 — leveling is not a separate polling job re-deriving state from scratch, it reacts to the same event stream.

7. Reward Engine

7.1 Reward Types (Logic Only — No Payment Provider)

7.2 Rule Evaluation

reward_rules (§2.3) define trigger conditions (a referral conversion, a level-up, a campaign goal met, or a manual admin grant) and which reward type/value to grant when met. Evaluation happens synchronously on the triggering event (a referral_events insert, a level-up computation) rather than on a delayed batch job, so ambassadors see rewards reflect promptly — with the exception of revenue-basis commissions, which by nature settle on whatever cadence the revenue itself settles (see §7.4).

7.3 Grant Lifecycle

reward_grants.status: pending (rule matched, not yet admin-approved if approval is required) → approved → fulfilled (payment/access actually delivered) → or reversed (e.g., a referred subscriber's cancellation claws back a not-yet-paid commission — the grant record is reversed, never deleted, consistent with the append-only philosophy used elsewhere in the Design Bible).

7.4 Explicit Non-Ownership of Payment

This spec computes commission amounts and bonus values as data. It does not integrate with a payment processor, does not store payment credentials, and does not execute a payout. reward_grants.status = 'fulfilled' is set by an external process confirming payment occurred, read back into this system as a status update — the same boundary DL-SPEC-017 draws around payment processing (DL-SPEC-017 §1.4), restated here for the same reason.

8. Beta Tester Program

Tracked per beta_tester_profiles/beta_sessions/bug_reports/suggestions (§2.4):

• Platform, version, hours played (via beta_sessions).
• Bugs submitted vs. confirmed (via bug_reports.status).
• Suggestions submitted vs. accepted (via suggestions.status).
• Testing sessions (structured, scheduled sessions vs. free-form play — both representable as beta_sessions rows, distinguished by a session-type field).
• Reliability score and participation score: computed metrics (formula owned by this spec, values derived from the above tables — e.g., reliability weights session attendance and bug-report quality, participation weights raw activity volume). Exact formulas are a tuning decision, not fixed by this draft.
• Invitation history: derived from communications entries of type campaign_update/task_assignment scoped to beta waves, not a separate table — avoids a redundant schema for what is fundamentally a filtered communications view.

9. Content Creator System

Tracked per content_creator_profiles/content_submissions (§2.5):

• Supported platforms: YouTube, Twitch, TikTok, Kick, Facebook, Instagram, X, Blog, Podcast — stored as an enum/array, not hardcoded branching logic, so adding a platform is a config change.
• Followers, subscribers, videos, streams, views, engagement — periodically refreshed metrics on content_submissions.metrics (source: platform APIs, out of scope for this spec to define per-platform integration detail).
• Content approval: content_submissions.approval_status, admin-reviewed before a submission counts toward campaign performance or reward triggers (§7.2) — this prevents low-quality or off-brand content from silently accruing commissions.
• Campaign participation: content_submissions.campaign_id links content to a campaign (§13).

10. Ambassador Dashboard

This section defines what data is available, not UI — per your framing, Lovable builds the interface against this contract.

Available to an ambassador about themselves: clicks, conversions, revenue attributed, commissions (pending/fulfilled), assigned tasks, announcements, downloadable assets, active campaigns, personal performance trend, leaderboard position (opt-in visibility, see §17.4), training status, support contact path.

Available to admins about any ambassador: everything above, plus internal rating, community reputation inputs, fraud flags, full audit history.

The dashboard is a read model over §2's tables via the Analytics API (§12) — it introduces no new source-of-truth data.

11. Multi-Game Architecture

This is the section that justifies the LS- namespace rather than a DL- one:

• Every referral code, campaign, training module, and marketing asset is game_id-nullable, per §2. A studio-wide entity (e.g., a "Legend Studios Founding Ambassador" badge, or a cross-game training module on community standards) is a first-class case, not a special exception.
• ambassador_game_links (§2.1) lets one ambassador be linked to multiple games without duplicating their profile, standing, or level — an ambassador's Gold status is a property of the ambassador, not of "Gold status in Diamond Legend" vs. "Gold status in Gridiron Legend," unless a future product decision explicitly wants per-game leveling (which would be a config change to §6, not a schema change, since ambassador_level_history already carries no game dimension by default but could add one without breaking existing rows).
• The Game Adapter pattern (§0.2) is the only integration surface a new title needs to implement — Gridiron Legend or Bitcoin Speedway onboarding as a consumer of this platform means writing an adapter, not extending this spec.

12. APIs

13. Campaign System

campaigns/campaign_participation (§2.6): admin-defined campaigns with start/end dates, goals, target audience, and an asset bundle (linked marketing_assets). Performance is a rollup of referral_events and content_submissions scoped by campaign_id and date range — not a separately tracked metric set, to avoid two systems disagreeing about the same underlying activity.

14. Training System

training_modules/training_progress/certifications (§2.6): modules cover Welcome, Game Overview (game-specific, game_id-scoped), Brand Guidelines, Referral Rules, Community Standards, Social Media Best Practices — each optionally gated behind a knowledge check (requires_knowledge_check). Certification issuance (certifications) is a terminal event per module, driving the Onboarding → Training Complete lifecycle transition (§3.2) when all required modules for that ambassador's track (which may differ by ambassador type — Beta Tester track vs. Content Creator track, a config-level distinction, not a schema fork) are certified.

15. Communication System

communications (§2.6) is a single table for every outbound message type (announcements, DMs, email templates, campaign updates, task assignments, release notes), distinguished by type — avoiding five parallel messaging systems that each need their own delivery/read-tracking logic. Broadcast types (announcement, release_note) have ambassador_id = null and fan out at delivery time rather than pre-materializing one row per recipient.

16. Analytics

16.1 Metrics Owned Here

Applications, acceptance rate, retention, active ambassadors, conversions, revenue (attributed, not owned — see §18.1), top performers, country distribution, platform distribution, campaign success, monthly growth, lifetime growth.

16.2 Consumption Boundary

Revenue figures surfaced here are referral-attribution rollups over DL-SPEC-017-sourced events (§5.3), not an independent computation of subscription revenue — consistent with the same non-duplication boundary DL-SPEC-013 draws around DL-SPEC-017's analytics (DL-SPEC-013 §8.2).

16.3 Community Reputation Score — Inputs, Not a Black Box

Since community_reputation_score (§2.1) feeds both profile display (§4) and level requirements (§6.2), its inputs should be enumerable and auditable rather than an opaque single number: candidate inputs include reliability/participation scores (§8), content approval rate (§9), training completion, and admin manual adjustments (logged to audit_logs). Exact weighting is a tuning decision left open in this draft.

17. Security

17.1 Role Permissions

At minimum: Ambassador (self-scoped read/write per §4's editable-field boundary), Content Reviewer (approve/reject content_submissions), Campaign Manager (create/edit campaigns and assets), Reward Admin (approve/reverse reward_grants), Platform Admin (full access, including lifecycle state transitions and fraud review). Roles are studio-level, not per-game, consistent with §11 — a Platform Admin manages ambassadors across every Legend Studios title through one tool.

17.2 Fraud Detection

fraud_flags (§2.7), evaluated by the Fraud/Security Service against patterns including: anomalous click-to-signup ratios on a single code, rapid-succession signups from correlated IP/device fingerprints, and commission accrual rates inconsistent with an ambassador's historical/platform-typical pattern.

17.3 Referral Abuse and Duplicate Account Prevention

Self-referral checks (referred external_user_id must not resolve to the same underlying account as the referring ambassador's user_id), device/fingerprint correlation across referral_events, and velocity limits (max signups per code per time window, configurable) run inline in the Referral Tracking API (§12) before an event is accepted as commission-eligible, not as a post-hoc audit only.

17.4 Commission Validation

Every reward_grants transition to approved is validated against the originating referral_events chain (a commission cannot be approved for a conversion event that was itself flagged and unresolved in fraud_flags) — this is an explicit gate in the Reward Engine's approval path, not a separate reconciliation job that runs after money has already moved.

17.5 Audit Logs

Every lifecycle transition (§3.2), every reward grant/reversal, every admin edit to an ambassador's status/rating/notes, and every fraud flag resolution is written to audit_logs (§2.7) — the same "nothing is silent" principle applied throughout the Design Bible's governance-adjacent specs.

18. Cross-Spec Integration

18.1 DL-SPEC-017 (Advertising & Monetization)

This spec consumes DL-SPEC-017 for the actual dollar value of any referral-driven subscription event (§5.3) — DL-SPEC-017 remains the sole source of truth for subscription state, tier pricing, and revenue recognition. This spec never independently determines what a subscriber is worth; it only attributes an already-known value to a referral chain. Symmetrically, DL-SPEC-017's Entitlement Check API (DL-SPEC-017 §1.3) is the mechanism a consuming game would use if an ambassador reward (§7.1, e.g., early beta access) needs to translate into an actual account-level entitlement — this spec computes and reports that the reward was earned; DL-SPEC-017 or the game itself is responsible for enforcing any resulting access change.

18.2 DL-SPEC-013 (Multiplayer)

No direct data ownership overlap. The integration point is narrow: an ambassador-earned perk like an early multiplayer beta wave (§7.1) is reported by this spec as an entitlement flag (§12, Reward Engine API) that DL-SPEC-013's league-join gating (DL-SPEC-013 §1.4) can read the same way it reads a DL-SPEC-017 entitlement — this spec is simply another entitlement source, not a new gating mechanism DL-SPEC-013 needs to special-case.

18.3 DL-SPEC-018 (Player Creator)

The only touchpoint is §7.1's "limited cosmetic" reward type, which must resolve through DL-SPEC-017's cosmetic catalog (DL-SPEC-017 §3) exactly as any other cosmetic grant would — this spec does not define cosmetics, generate custom players, or touch DL-SPEC-018's attribute/point-budget system in any way. An ambassador-earned cosmetic is presentation-only, same hard boundary DL-SPEC-017 §3.2 already states.

18.4 Authentication

Consumed per §0.3 — this spec assumes and builds on an external user_id, and owns no login/session/credential logic itself.

18.5 Analytics

This spec's Analytics API (§12, §16) is designed to be a source for a future studio-wide analytics rollup, not itself the studio's only analytics system — DL-SPEC-017's revenue analytics (DL-SPEC-017 §5) and this spec's ambassador analytics (§16) are two distinct, cross-linkable views, the same non-duplication pattern already established between DL-SPEC-013 and DL-SPEC-017 (DL-SPEC-013 §8.2, DL-SPEC-017 §5.2).

18.6 Future Legend Studios Platform

§0, §11, and the Game Adapter pattern (§0.2) are this spec's entire answer to "how does this become studio infrastructure" — there is no separate future-platform section needed because the platform-first design is load-bearing from v1.0, not deferred.

19. Future Expansion Strategy

• New game onboarding = implement a Game Adapter (§0.2), register a game_id, no schema change.
• New reward types = add to the reward_type enum and define its value schema (§7.1) — engine logic (§7.2) is generic over reward type, it does not branch per type beyond reading the schema.
• New ambassador tracks beyond Beta Tester/Content Creator (e.g., a future "Community Moderator" track with its own profile extension) follow the same 1:1-extension-table pattern already used for beta_tester_profiles/content_creator_profiles (§2.4/2.5) — a new track is a new extension table plus a new training_modules track tag, not a change to the core ambassadors/ambassador_profiles tables.
• Cross-game leaderboards or unified "Legend Studios Ambassador of the Month" are a natural Analytics API (§12) consumer once a second game is live — the data model already supports it (§11); it's a reporting feature to build later, not an architecture gap now.

20. Cross-Spec Consistency Notes

• This spec's non-ownership boundaries (§18) all follow the same shape already established between DL-SPEC-013/017/018: compute/attribute here, execute/own-the-underlying-truth elsewhere. Worth confirming this reads consistently across all documents once all five specs (013/016/017/018/LS-001) can be reviewed side by side.
• The append-only philosophy (reward_grants reversed not deleted, referral_events immutable, audit_logs on every transition) mirrors DL-SPEC-003's "players are never deleted" and DL-SPEC-013's League Event Log — this is now a pattern repeated across four independent specs and is probably worth naming explicitly as a studio-wide architectural principle rather than something each spec re-derives.
• DL-DEPENDENCY-MAP.md should be updated to add LS-SPEC-001 once this draft is reviewed — it introduces a new namespace the current map doesn't yet account for.

21. Recommended Next Steps

0. (Current, supersedes all steps below) Perform the full rewrite this document has been flagged for since CHG-SPEC-001: remove §5 (Referral System), §6 (Ambassador Levels, if not gaming-specific), §7 (Reward Engine), §12 (Marketing Asset Library), §13 (Campaign System), §14 (Training System), §15 (Communication System), and §17 (Security/Fraud) in favor of pointing to CHG-SPEC-001's equivalents, retaining only what's determined to be genuinely Legend-Studios-specific in §8 (Beta Tester Program) and possibly §9 (Content Creator Program, pending review against CHG-SPEC-001's own Creator program type, §1.1). Steps 1–4 below predate this decision and should be re-evaluated once the rewrite happens, not treated as still-independent priorities.
1. Confirm the LS- namespace decision (§ header note) before any other Legend Studios spec is written, since it sets the convention.
2. Define the actual reward_rules/ambassador_levels config values (§6.2, §7.1) — intentionally left as illustrative examples pending business/product input, not an engineering gap.
3. Decide whether per-game leveling is ever needed (§11) — the schema supports either answer without rework, but the product decision should be made explicitly rather than left implicit.
4. Once DL-SPEC-017's payment-adjacent infrastructure is further along, revisit §7.4/§17.4 to confirm the "compute here, execute externally" boundary still holds at implementation time.