CHG-SPEC-001 — Affiliate, Ambassador & Creator Partner Platform

Status: Draft v1.1 — not yet frozen (v1.1 adds content submission tracking and follow-up reminders to §10, surfaced by Diamond Legend's Outreach Center requirement — see DL-SPEC-020) Governed by: CHG-PLATFORM-ARCHITECTURE.md Supersedes (in ownership, not in existence — see §0.2): LS-SPEC-001's referral tracking, reward engine, campaign management, marketing asset library, training, communications, and fraud detection. LS-SPEC-001 remains the correct home for anything genuinely Legend-Studios/gaming-specific that doesn't generalize across Cobalt Horizon Group — see LS-SPEC-001's own updated header. Depends on: an external Authentication system (consumed, not owned), an external Payment/Payout provider (consumed, not owned — same boundary as every prior spec in this series), CHG-PLATFORM-ARCHITECTURE.md.

Owns: The complete affiliate, ambassador, and creator partner system for every Cobalt Horizon Group company — programs, applications, member dashboards, referral link generation, the commission engine, payout scheduling, the marketing/asset center, missions and gamification, the creator CRM, program analytics, notifications, fraud/security, and administration.

Explicitly does not own: Payment processing execution (§7.4 — this spec computes what's owed and schedules payouts; it never moves money). Any brand's actual product, service, or gameplay logic (Diamond Legend's simulation, PipeDesk's product, a coffee subscription's fulfillment — none of it). A dedicated cross-brand content/publishing system beyond this spec's own program pages (§2 defines only what this spec needs; a general CHG-wide CMS is flagged, not built, in §18.1). A dedicated cross-brand notification delivery service (§12 builds a self-contained notification module for practical necessity now, while flagging the future consolidation risk explicitly in §18.2). Cross-brand business analytics unrelated to the affiliate/ambassador/creator programs themselves (§11 scopes analytics to program performance, not e.g. PipeDesk's SaaS metrics or Samson Grind Coffee's sales — a future CHG-wide operations platform, generalizing LS-SPEC-004, is flagged in §18.3, not built here).

Consumed by: Legend Studios (on behalf of Diamond Legend and future titles), PipeDesk, SkyLinkStarLink, Keystone Acquisitions Group, Samson Grind Coffee, future Cobalt Horizon Group companies — each through its own Brand Adapter (§0.4).

Exposes: Program API, Application API, Member Dashboard API, Referral Link API, Commission Engine API, Payment Center API, Marketing/Asset API, Missions/Gamification API, Creator CRM API (admin-facing), Analytics API, Notification API, Security/Fraud API, Administration API.

Governing principle: One partner platform, every brand. An affiliate, ambassador, or creator who works with one Cobalt Horizon Group company should be recognizable — one identity, one commission ledger, one dashboard — if they ever work with another, the same way a Legend Studios player's community identity now follows them across games. No brand forks this system to get a feature; the system grows to serve every brand instead.

0. Foundational Architecture Decisions

0.1 Brand, Not Game

Every entity in this spec carries a brand_id, not a game_id — the direct generalization of the pattern LS-SPEC-001 established (LS-SPEC-001 §11) and DL-SPEC-019/LS-SPEC-002/003/004 continued. A "brand" is any Cobalt Horizon Group company: Legend Studios (which may further sub-tag by game internally, in its own Brand Adapter, for its own reporting — this spec doesn't need to know about individual games, only about Legend Studios as one brand among several), PipeDesk, SkyLinkStarLink, Keystone Acquisitions Group, Samson Grind Coffee, and future companies.

0.2 Relationship to LS-SPEC-001 — Explicit, Not Implied

This spec does not delete LS-SPEC-001 or declare it void. It removes LS-SPEC-001's ownership of the capabilities listed in this document's header, because those capabilities are not gaming-specific and duplicating them at two tiers would violate the exact "no duplicated business logic, no duplicated schemas, no duplicated APIs" principle this whole series has followed. LS-SPEC-001's own header has been updated to reflect this (see that document). What plausibly remains at the LS tier — beta tester tracking tied to game builds — is not redefined by this spec; that determination belongs to whoever next revises LS-SPEC-001.

0.3 Three Programs, One Underlying Model

Affiliate, Ambassador, and Creator are modeled as three program types sharing one member/application/commission schema, not three parallel systems. This is a direct application of the "no duplicated schemas" instruction: an Affiliate and a Creator are both fundamentally "a person with a referral relationship to a brand, receiving some mix of commission and non-monetary reward" — they differ in which grants and requirements apply (§1), not in the underlying data model.

programs (config table)
  id (pk)
  brand_id (nullable — a studio-wide/CHG-wide program is possible)
  program_type (affiliate / ambassador / creator)
  name
  requirements (jsonb)
  benefits (jsonb)

0.4 Brand Adapter Interface

Each consuming brand implements a Brand Adapter responsible for exactly (mirroring CHG-PLATFORM-ARCHITECTURE.md §4):

• Authenticating the user
• Reading program member status and entitlements
• Reporting referral conversions
• Reporting campaign/mission participation
• Reporting analytics events

The adapter must never duplicate this platform's logic — the same hard rule stated in LS-PLATFORM-ARCHITECTURE.md §4.2, restated here because it is exactly as important one tier up. A brand that finds itself recomputing commission amounts or re-deriving fraud signals locally has found a gap in this spec's API surface (§19), not a justification to build its own copy.

0.5 Authentication

Consumed, not owned — same boundary as every other spec in this series (originally LS-SPEC-001 §0.3).

1. Programs

1.1 Program Types and Their Distinguishing Grants

All three share: a members record (§3.2), a referral link (§5), a commission relationship (§6, even if some Ambassador benefits are non-monetary), and a dashboard (§4). A member may hold more than one program membership simultaneously (an Affiliate who is also a Creator) — program_memberships (§3.2) is many-to-many between members and programs, not a single-program-per-member constraint.

1.2 Brand-Specific Configuration, Not Brand-Specific Code

"Review keys" for Diamond Legend means a game key; for Samson Grind Coffee it might mean a product sample credit; for PipeDesk it might mean an extended trial license. This spec's benefits field (§0.3) stores this as brand-configured data ({"type": "product_sample", "fulfillment": "brand_adapter_handled"} vs. {"type": "review_key", "fulfillment": "brand_adapter_handled"}) — fulfillment of a brand-specific benefit is always the consuming brand's Brand Adapter's job, per §0.4; this spec tracks that the benefit was earned and its abstract type, never the brand-specific fulfillment mechanics.

2. Public Program Pages

2.1 Scope

Each program gets a public page (/affiliate, /ambassador, /creator, per-brand) built from: Hero, Benefits, Requirements, FAQ, Application Form, Terms, Privacy, Contact.

program_pages
  program_id (fk)
  hero (jsonb — headline, media_ref)
  benefits_copy (jsonb)
  requirements_copy (jsonb)
  faq (jsonb array)
  terms_ref / privacy_ref (external legal doc references, not owned here)
  contact_info (jsonb)

2.2 Scoped Ownership — Not a CMS

This spec owns only enough content structure to render its own program pages. It is explicitly not a general-purpose publishing system — if a future need arises for Cobalt Horizon Group-wide news, blogs, or documentation across brands (the CHG-tier generalization of LS-SPEC-003), that is a separate future spec, flagged in §18.1, not built here. terms_ref/privacy_ref point to externally-managed legal documents this spec does not author.

3. Applications and Membership

3.1 Application Data

applications
  id (pk)
  brand_id
  program_id (fk)
  name / email / country / discord_handle
  social_platforms (jsonb — youtube, twitch, tiktok, instagram, website)
  audience_size
  favorite_product (brand-configured label — "favorite baseball game" for Legend Studios, brand-specific elsewhere)
  motivation_text ("why do you want to join")
  referral_source ("how did you hear about us")
  status (see §3.3)
  submitted_at

3.2 Membership, Post-Approval

members
  id (pk)
  user_id (fk → external auth identity)
  application_id (fk, nullable — a member may also be manually admin-added)
  internal_rating
  reputation_score
  created_at

program_memberships
  member_id (fk)
  program_id (fk)
  status (see §3.3, tracked per-membership since a member can be Active in one program and Suspended in another)
  joined_at

3.3 Application/Membership State Machine — Corrected From a Linear List

The originally requested flow (Applied → Pending Review → Approved → Rejected → Waitlist → Suspended → Archived) cannot be a single sequential chain — Approved cannot lead to Rejected. This spec models it as an actual state machine, the same correction pattern LS-SPEC-001 §3 applied to its own ambassador lifecycle:

Applied
   ↓ (automatic)
Pending Review
   ↓ (admin decision)
   ├──→ Approved ──→ (program_memberships created, status: Active)
   ├──→ Rejected [terminal]
   └──→ Waitlist ──→ (re-reviewed later) ──→ Approved / Rejected

Active (a program_membership status, not an application status)
   ↓ (policy violation or fraud finding, §13)
Suspended
   ↓ (resolved)        ↓ (unresolved / repeat)
Active                 Archived [terminal for that membership]

Active
   ↓ (self-requested or admin-initiated, no violation)
Archived [terminal]

Every transition is logged (§13.5 audit logs), matching the "nothing is silent" discipline established since DL-SPEC-013 §3.2.

4. Member Dashboard

Read-model contract, not a new source of truth (same pattern as LS-SPEC-001 §10, DL-SPEC-019 §10 wherever dashboards appear in this series): profile, referral links (§5), clicks/signups/subscribers/recurring revenue (§5.3), pending/paid/lifetime commissions (§6), marketing assets (§8), announcements (§12), downloads (§8), leaderboard (§9.4), achievements (§9), support contact (points to CHG-tier or brand-tier support — this spec does not itself own a support ticketing system; if LS-SPEC-004-style Studio Operations generalizes to CHG tier in the future, that is where this would resolve to, per §18.3), settings.

5. Referral Link System

5.1 Link Types

referral_links
  id (pk)
  member_id (fk)
  brand_id
  link_type (affiliate / creator / ambassador / campaign / landing_page / pricing / store / closed_alpha)
  code (unique)
  url (generated)
  campaign_id (fk, nullable — see §14.6)
  created_at
  active (bool)

closed_alpha as a link_type is the direct integration point for DL-SPEC-019 §0.4's alpha invitation flow — that flow already assumed an LS-SPEC-001 referral/campaign mechanism; it now resolves against this spec instead, with no change to DL-SPEC-019's own logic, only to which platform tier it calls.

5.2 Tracked Events

referral_events
  id (pk)
  referral_link_id (fk)
  event_type (click / signup / subscribe / renew / cancel / purchase)
  brand_id
  external_user_id
  occurred_at
  revenue_amount (nullable — sourced from the consuming brand's own billing system via its Brand Adapter, never computed here — same non-duplication boundary LS-SPEC-001 §5.3 held toward DL-SPEC-017)

Immutable, append-only — same discipline as every prior spec in this series.

5.3 Derived Metrics

Clicks, signups, subscribers, recurring revenue, lifetime value, conversion rate, active/inactive referrals, cancelled subscribers — all computed from referral_events, never stored redundantly, identical in spirit to LS-SPEC-001 §5.3, generalized across brands.

6. Commission Engine

6.1 Commission Rules

commission_rules (config table)
  id (pk)
  brand_id (nullable — a CHG-wide default rule is possible)
  program_id (fk)
  trigger_type (referral_conversion / milestone / campaign_goal / manual)
  structure (recurring / one_time)
  calculation (percentage / flat_fee)
  value
  active (bool)

6.2 Commission Ledger

commissions
  id (pk)
  member_id (fk)
  commission_rule_id (fk, nullable for manual/bonus grants)
  referral_event_id (fk, nullable — not every commission traces to a single referral event, e.g. seasonal bonuses)
  type (recurring / one_time / bonus / seasonal / manual_adjustment)
  amount
  status (pending / approved / paid / reversed)
  created_at
  reversed_at (nullable)
  reversal_reason (nullable — chargeback / refund / fraud_finding / admin_correction)

6.3 Chargeback and Refund Handling

When a brand's Brand Adapter reports a chargeback or refund against a referral_events row that already generated a commission, this spec does not delete the original commissions row — it creates a new commissions row of type reflecting the reversal, linked to the original via referral_event_id, and sets the original's status = reversed. This preserves a complete, auditable ledger (append-only, per the pattern used throughout this entire series) rather than editing history to make the books look clean.

6.4 Bonus and Seasonal Commissions

Modeled as commission_rules with trigger_type = campaign_goal or a manual commissions insert with type = bonus/seasonal — no separate bonus engine, since a bonus is structurally just a commission with a different trigger, consistent with §0.3's "one underlying model" decision applied to commissions specifically.

7. Payment Center

7.1 Scope

This section owns payout scheduling and eligibility logic — not payment execution (§7.4).

payout_schedule
  member_id (fk)
  minimum_threshold (brand-configurable, defaults to a CHG-wide default)
  next_scheduled_payout
  preferred_method (paypal / wise / stripe_connect — enum, extensible without engine change)

payouts
  id (pk)
  member_id (fk)
  commission_ids (array — which commissions this payout settles)
  amount
  status (scheduled / processing / paid / failed)
  method
  paid_at (nullable)

7.2 Minimum Payout Threshold

A commission only becomes payout-eligible once a member's unpaid commissions (status approved) sum past their minimum_threshold. This is evaluated at scheduling time, not commission-creation time, so a commissions row can sit in approved status for a while before being swept into a payouts batch — normal and expected behavior, not a bug state.

7.3 Tax Forms

tax_forms
  member_id (fk)
  form_type (e.g., W-9, W-8BEN)
  status (not_submitted / submitted / verified)
  submitted_at

This spec tracks tax form status as a payout-eligibility gate (a member with not_submitted status past a brand-configured deadline is excluded from payout_schedule eligibility) — it does not generate, validate, or file tax forms itself; that is external tax-compliance infrastructure, consumed the same way payment processing is.

7.4 Explicit Non-Ownership of Payment Execution

Identical boundary to every prior spec: this spec computes what is owed (§6) and when it becomes eligible for payout (§7.1–7.2). It does not integrate with PayPal, Wise, or Stripe Connect directly, does not store payment credentials, and does not execute a transfer. payouts.status = 'paid' is set by an external process confirming payment occurred, read back as a status update — the same non-ownership stated in LS-SPEC-001 §7.4 and DL-SPEC-017 §1.4, restated a third time because it remains exactly as important.

8. Marketing and Asset Center

Directly generalizes LS-SPEC-001 §12 to brand_id:

marketing_assets
  id (pk)
  brand_id
  type (logo / screenshot / video / gif / feature_graphic / press_kit / email_template / social_caption / launch_announcement / brand_guideline)
  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)
  member_id (fk)
  downloaded_at

No structural change from LS-SPEC-001's original design — only the ownership tier and the game_id → brand_id rename.

9. Missions and Gamification

9.1 Missions

missions
  id (pk)
  brand_id (nullable)
  program_id (fk, nullable — a mission may be program-specific or open to all)
  title / description
  mission_type (recruit_referrals / create_video / create_stream / write_review / social_post / discord_invite / survey / testing_participation)
  reward_rule_id (fk → §9.3's underlying reward mechanism)
  active (bool)

mission_completions
  mission_id (fk)
  member_id (fk)
  completed_at
  verification_status (auto_verified / pending_review / verified / rejected)

Verification is deliberately not always automatic — "create a YouTube video" needs human or at least link-validation confirmation before a reward fires, unlike "recruit five players," which can auto-verify against referral_events (§5.2).

9.2 Levels, XP, and Badges

member_levels (config table)
  level_key
  program_id (fk, nullable — level ladders can be program-specific)
  xp_required
  benefits (jsonb)

member_xp
  member_id (fk)
  xp_total
  current_level_key (derived, cached for read performance, recomputed on every XP-earning event)

badges (config table)
  badge_key
  name / icon_ref

member_badges
  member_id (fk)
  badge_key (fk)
  earned_at

This is the direct generalization of LS-SPEC-001 §6's Bronze-through-Legend ladder, with XP added as the accumulation mechanism driving level-up (LS-SPEC-001's original design triggered level-up directly off referral/activity events; this version adds an explicit XP layer in between, since Missions §9.1 now need a currency to reward that isn't always a direct commission).

9.3 Reward Rules — Reusing the Commission Engine's Shape

reward_rules (config table)
  id (pk)
  trigger_type (mission_completion / level_up / campaign_goal / manual)
  reward_type (xp / badge / commission_bonus / founder_status / discord_role / early_access / cosmetic_ref)
  value (jsonb)

Reward types that resolve to money (commission_bonus) flow into §6's commission ledger; reward types that don't (xp, badge, discord_role) update the relevant table directly. This mirrors LS-SPEC-001 §7.1's reward-type table, generalized, with the same non-ownership boundary for anything resolving through a brand's own systems (cosmetic_ref still resolves through that brand's own cosmetic catalog — for Legend Studios, that remains DL-SPEC-017 §3, unchanged).

9.4 Founder Status and Hall of Fame — Flagged, Not Resolved Here

Per CHG-PLATFORM-ARCHITECTURE.md §6, "Founder" now has two plausible meanings — a Cobalt Horizon Group-wide founder recognition, or a brand-specific one (Diamond Legend's Founder Tier, DL-SPEC-017 §1.6). This spec's reward_rules.reward_type = founder_status is written generically enough to support either interpretation, but does not decide which one is correct — that's a product decision for Cobalt Horizon Group leadership, not an architectural inference. Hall of Fame and leaderboards (monthly and lifetime) are read views over member_xp/commissions, scoped by brand_id or CHG-wide depending on which leaderboard is being displayed — both are supported by the schema without a structural choice needing to be made now.

10. Creator CRM

Admin-facing, not member-facing:

crm_notes
  member_id (fk)
  author_id (admin user)
  note_text
  created_at

crm_tags
  member_id (fk)
  tag

contact_history
  member_id (fk)
  channel (email / discord / in_app)
  direction (outbound / inbound)
  content_ref
  status (nullable — e.g., sent / opened / bounced / replied, populated when channel = email and the sending system reports delivery status; not meaningful for every channel)
  occurred_at

crm_followups
  id (pk)
  member_id (fk)
  due_at
  note
  status (pending / completed / dismissed)
  created_by (admin user)
  completed_at (nullable)

10.1 Content Submission Tracking (v1.1 addition)

The original draft referenced "content created, streams run" as derivable performance data without an owning table — that was an oversight, not a deliberate omission. Content submissions are exactly as generic across brands as everything else in this spec (a video about Diamond Legend and a video about a PipeDesk feature are the same shape of record), so this spec now owns them directly rather than leaving a gap a brand-native module would be tempted to fill locally:

content_submissions
  id (pk)
  member_id (fk)
  brand_id
  platform (youtube / twitch / tiktok / kick / instagram / x / blog / podcast)
  url
  content_type (video / stream / post / review)
  metrics (jsonb — views, engagement; refreshed periodically from the platform, not owned by this spec)
  submitted_at
  approval_status (pending / approved / rejected)

Search/filter over members by tag, program, performance (referrals generated, revenue generated per §6, content submitted and its approval status per §10.1, follow-ups due per the crm_followups table above) is a query surface over data this spec already owns — no additional source-of-truth table is needed beyond what's listed in this section.

11. Analytics

11.1 Scope — Program Performance, Not General Business Analytics

Applications, approval rate, retention, active members, conversions, revenue (attributed, sourced from §5.2's brand-reported revenue_amount, never independently computed), top performers, top countries, top platforms, top campaigns, creator/ambassador/affiliate performance breakdowns — all derived from data this spec already owns (§3, §5, §6, §9, §10).

11.2 Explicitly Out of Scope

A brand's total business performance unrelated to its affiliate/ambassador/creator program (PipeDesk's overall SaaS metrics, Samson Grind Coffee's total sales) is not this spec's concern — see §18.3 for where that would eventually live.

12. Notifications

12.1 Channels and Categories

Email, Discord, in-app, admin alerts. Categories: payment reminders, approval notifications, mission notifications, announcements.

notifications
  id (pk)
  member_id (fk, nullable for broadcast/admin-alert types)
  channel (email / discord / in_app / admin_alert)
  category (payment_reminder / approval / mission / announcement)
  payload (jsonb)
  sent_at
  read_at (nullable)

12.2 A Deliberate, Flagged Trade-off

This spec builds a self-contained notification module rather than waiting on a hypothetical CHG-wide notification service (the CHG-tier generalization of LS-SPEC-002 §4), because this platform needs working notifications now and no such CHG-wide service currently exists. If and when Cobalt Horizon Group builds a CHG-wide Community/Social or Operations platform with its own delivery infrastructure, this module should be consolidated into it rather than left as a permanent parallel system — flagged explicitly in §18.2 as a known, accepted duplication risk, not an oversight.

13. Security

13.1 Fraud Detection

Extends the exact pattern established in LS-SPEC-001 §17.2, generalized across brands: anomalous click-to-signup ratios, correlated device/IP signup velocity, and commission accrual rates inconsistent with a member's historical pattern.

13.2 Duplicate Account Detection

Cross-references members.user_id against the external Authentication system's own account-uniqueness guarantees, plus device/fingerprint correlation across applications and referral_events — a member cannot hold two active accounts to double-dip on referral/mission rewards.

13.3 Self-Referral and Referral Abuse Prevention

Same inline-check discipline as LS-SPEC-001 §17.3: a referred external_user_id must not resolve to the referring member's own account, checked at referral_events ingestion time, not as a post-hoc audit only.

13.4 Commission Abuse and Manual Review

commissions.status cannot transition to approved while a related referral_events row has an open fraud flag — the same hard gate LS-SPEC-001 §17.4 established, applied here to a generalized commission ledger instead of an ambassador-specific reward grant.

13.5 Audit Logs

Every state transition (§3.3), every commission created/reversed (§6.2), every admin action (§14), and every fraud finding is logged immutably — no exceptions, consistent with every spec in this entire series.

14. Administration

14.1 Member Actions

Approve, reject, suspend, ban — these are program_memberships.status transitions (§3.3), performed by an admin role, always logged (§13.5).

14.2 Commission Adjustments

Manual commissions inserts (§6.2, type = manual_adjustment), never a direct edit to an existing commission's amount — adjustments are new ledger entries, preserving the append-only history.

14.3 Bulk Operations

CSV export, bulk email, bulk messaging (via §12's notification module) — operational tooling over existing data, no new source-of-truth entities required.

14.4 Announcements

A notifications broadcast (§12.1, member_id = null), not a separate announcement system.

14.5 Mission and Reward Creation

Admin-facing CRUD over missions (§9.1) and reward_rules (§9.3) — config, not code, consistent with the data-driven discipline this entire series has followed since DL-SPEC-016 §4.

14.6 Campaign Creation

campaigns
  id (pk)
  brand_id (nullable)
  name
  start_date / end_date
  goals (jsonb)
  linked_missions (array, fk → missions)
  linked_commission_rules (array, fk → commission_rules)

Campaign performance is a rollup over referral_events/mission_completions/commissions scoped by campaign_id and date range — the same non-duplicated-metrics pattern LS-SPEC-001 §13 originally established.

15. Multi-Brand Architecture

Onboarding a new Cobalt Horizon Group company requires exactly (mirroring CHG-PLATFORM-ARCHITECTURE.md §4 and the LS-tier's own §6/§11 patterns already established twice in this series):

1. Registering a new brand_id.
2. Implementing a Brand Adapter (§0.4).
3. Configuring that brand's programs (§1), commission rules (§6.1), and benefit fulfillment mapping (§1.2).

No schema redesign. This directly satisfies the request's Future Expansion section — Diamond Legend, PipeDesk, SkyLinkStarLink, Keystone Acquisitions Group, and Samson Grind Coffee are five rows in a brands config table and five Brand Adapter implementations, not five forks of this system.

16. Mobile and PWA

This spec's APIs (§19) are the entire contract a responsive web client, native mobile client, or PWA needs — this document does not additionally specify client-side rendering, since "fully responsive, PWA-compatible" is a presentation-layer requirement of whatever consumes these APIs, not a backend architecture concern. No API in this spec is designed in a way that would block a mobile-first or PWA client from consuming it.

17. Treat This as a Core Product: The PipeDesk Reuse Case

Per the explicit direction to treat this as reusable infrastructure rather than a marketing page: nothing in §0–§16 contains Legend Studios-specific or Diamond-Legend-specific logic. A hypothetical PipeDesk integration would: register brand_id = "pipedesk", define its own programs (perhaps only Affiliate, no Ambassador/Creator, if PipeDesk has no community/content-creator angle), define its own commission_rules, and implement a Brand Adapter reporting PipeDesk's own signup/subscription events. Nothing about §5's referral links, §6's commission engine, §7's payout logic, §9's missions/gamification, §10's CRM, §11's analytics, §13's fraud detection, or §14's admin tooling assumes gaming at any point — this was a deliberate constraint applied throughout, not a retrofit.

18. Flagged Gaps — Not Built Here, Named for the Record

Consistent with this series' established discipline of naming a gap rather than silently absorbing it into the wrong spec:

18.1 CHG-Wide Content/Publishing Platform

If Cobalt Horizon Group needs cross-brand news, blogs, or documentation beyond this spec's own program pages (§2), that is the CHG-tier generalization of LS-SPEC-003 — not built here, not needed yet.

18.2 CHG-Wide Notification/Community Platform

§12's self-contained notification module is a deliberate, flagged duplication risk against a hypothetical CHG-tier generalization of LS-SPEC-002. Consolidate when that platform exists; don't block this spec on it existing first.

18.3 CHG-Wide Operations Platform

General business analytics, support ticketing, and health/telemetry monitoring across brands (the CHG-tier generalization of LS-SPEC-004) is out of scope here. §4's "support" dashboard entry and §11's analytics scope both explicitly point to this gap rather than pretending it's covered.

18.4 Founder Status Ambiguity

§9.4 — whether "Founder" means a Cobalt Horizon Group-wide status or remains brand-specific (as it currently is in DL-SPEC-017 §1.6) is unresolved and flagged for a product decision, not inferred here.

19. APIs

20. Cross-Spec Consistency Notes

• LS-SPEC-001's header must be (and has been, see that document) updated to reflect the ownership transfer in this spec's header — a stale LS-SPEC-001 claiming ownership of referral tracking or the reward engine would directly contradict this document.
• DL-SPEC-019 §0.4, §1.2–§1.8, and §4.4 all currently reference LS-SPEC-001's Ambassador Profile API, Communication API, and Reward Engine API. Those references now resolve to this spec's Application/Member/Reward APIs instead — DL-SPEC-019 itself does not need logic changes, only a pointer update, flagged here rather than performed silently across a document not currently open for edit in this pass.
• DL-SPEC-017 §1.6's Founder Tier and DL-SPEC-019 §1.6's founder-status aggregation remain valid and unchanged — this spec's §9.4 flags a future ambiguity about whether Founder should also exist at the CHG tier, not a present contradiction.
• DL-DEPENDENCY-MAP.md should be updated with a new top tier reflecting this spec's position — see that document's own update alongside this one.

21. Recommended Next Steps

1. Update LS-SPEC-001's own body (not just its header) to formally remove the sections this spec now owns, converting it into either a thin deprecation notice or a narrowly-scoped spec covering only what remains legitimately Legend-Studios-specific — this document's companion edit begins that process; a full rewrite is the next step, not yet performed.
2. Resolve §9.4's Founder status ambiguity as an explicit product decision.
3. Decide the priority order for §18's three flagged gaps, if any of them are needed before this spec's initial build — none of them block CHG-SPEC-001 itself from being implementation-ready as written.
4. Update DL-SPEC-019's API references per §20 once this spec is reviewed and accepted.
5. Confirm the Brand Adapter contract (§0.4) with a second real brand (not just Legend Studios) before freezing — the PipeDesk reuse case (§17) is currently a design argument, not a validated integration.