GGridiron LegendDesign Bible · v1.4
▶ Play QB ChallengeFranchise ModeSeason Recaps

Document 18 · Cobalt Horizon Group

DL-DEPENDENCY-MAP — Specification Dependency Graph

Draft v1.0Provisional

DL-DEPENDENCY-MAP.md — Diamond Legend Specification Dependency Graph

Status: Draft v1.0 Purpose: One authoritative record of what each Diamond Legend specification owns, consumes, and exposes, so future development never duplicates a responsibility that already has a home.

Important caveat on source material: The entries for DL-SPEC-001 through DL-SPEC-012, DL-SPEC-014, and DL-SPEC-015 below are reconstructed from the project synopsis's summary-level descriptions of those specs, not from the specs' full text — this document has not yet had those files uploaded to verify against. Treat those entries as a best-effort placeholder scaffold, not a verified record. The entries for DL-SPEC-013, DL-SPEC-016, DL-SPEC-017, and DL-SPEC-018 are drawn directly from this project's own full spec text and are accurate as of their current draft status. Before this document is treated as authoritative, every placeholder entry should be checked against its actual spec file.

How to Read This Document

For each spec:

  • Owns — the one responsibility this spec is the single source of truth for.
  • Consumes — other specs whose owned systems this spec relies on without reimplementing.
  • Exposes — the interface(s)/data this spec makes available for other specs to consume.

A well-formed dependency graph has no cycles at the "Owns" level — if two specs claim to own the same thing, or A consumes B while B consumes A for the same responsibility, that's a defect to fix, not a fact to record.

Architecture Layer

Per CHG-PLATFORM-ARCHITECTURE.md and LS-PLATFORM-ARCHITECTURE.md, there are now three tiers, not two:

Cobalt Horizon Group Platform (CHG-SPEC series)
        ↓ consumed by, via Brand Adapter
Legend Studios Platform (LS-SPEC series)   PipeDesk   SkyLinkStarLink   Keystone Acquisitions Group   Samson Grind Coffee   Future CHG companies
        ↓ consumed by, via Game Adapter
Diamond Legend (DL-SPEC series)   Gridiron Legend (future)   Bitcoin Speedway (future)

CHG tier (CHG-SPEC): owns affiliate/ambassador/creator program management, referral & commission tracking, marketing assets, campaigns, missions/gamification, creator CRM, program analytics, notifications, and fraud detection — for every Cobalt Horizon Group company, not just Legend Studios. This is the direct generalization of what LS-SPEC-001 originally owned, one tier up, once it became clear those capabilities weren't gaming-specific.

Platform tier (LS-SPEC): as of CHG-SPEC-001, substantially narrowed — see LS-SPEC-001's own supersession notice. What plausibly remains: beta-tester tracking tied to game builds, and any other genuinely Legend-Studios/gaming-specific concern not yet identified. LS-SPEC-002 (Community & Social), LS-SPEC-003 (Content & Knowledge), and LS-SPEC-004 (Studio Operations) are not superseded by CHG-SPEC-001 — their scope (social graph, publishing, support/analytics) is distinct from CHG-SPEC-001's affiliate/ambassador/creator scope, though CHG-PLATFORM-ARCHITECTURE.md §6 flags that they may eventually generalize to the CHG tier too, unresolved for now.

Game tier (DL-SPEC): unchanged — owns simulation, rosters, identity, statistics, multiplayer state, franchise/financial logic, specific to Diamond Legend.

Still open, unresolved by any document: whether DL-SPEC-017 belongs in the platform tier or stays game-tier (LS-PLATFORM-ARCHITECTURE.md §8), and whether "Founder" status means something CHG-wide now that a CHG tier exists (CHG-PLATFORM-ARCHITECTURE.md §6, CHG-SPEC-001 §9.4).

Verified Entries — CHG Tier (Cobalt Horizon Group)

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

  • Owns: Programs (affiliate/ambassador/creator as one underlying model), applications & membership, member dashboards, referral link generation & tracking, the commission engine (including chargeback/refund reversal), payout scheduling (not execution), the marketing/asset center, missions & gamification (XP/levels/badges), the creator CRM (including content submission tracking and follow-up reminders as of v1.1), program analytics, notifications, fraud/security, and administration — for every Cobalt Horizon Group company.
  • Consumes: an external Authentication system, an external Payment/Payout provider, each consuming brand's own billing system (for revenue_amount on referral events — attributed here, never computed here).
  • 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, Analytics API, Notification API, Security/Fraud API, Administration API — consumed by every CHG company via its own Brand Adapter, or, for the first brand (Diamond Legend), implemented natively in-codebase per DL-SPEC-020 rather than via a separate deployed service.
  • Governed by: CHG-PLATFORM-ARCHITECTURE.md.
  • v1.1 update: added content_submissions and crm_followups to §10 Creator CRM, surfaced by DL-SPEC-020's Outreach Center requirement.
  • Supersedes: LS-SPEC-001's ownership of referral tracking, the reward engine, campaigns, the marketing asset library, training/certification, communications, and fraud detection — see LS-SPEC-001's supersession notice.
  • Flagged gaps, not built here (CHG-SPEC-001 §18): a CHG-wide content/publishing platform, a CHG-wide notification/community platform, and a CHG-wide operations/analytics platform — each would be the CHG-tier generalization of LS-SPEC-003, LS-SPEC-002, and LS-SPEC-004 respectively, none built or committed to yet.

Verified Entries — Platform Tier (Legend Studios)

LS-SPEC-001 — Ambassador & Community Platform

  • Status: Ownership substantially superseded by CHG-SPEC-001 — see that document's header and LS-SPEC-001's own supersession notice. The entries below describe its original v1.0 scope, retained for historical traceability.
  • Owns (originally; mostly superseded): Ambassador/community accounts, referral & affiliate tracking, marketing asset library, campaign management, training/certification, the reward engine (computation only, not payment execution), ambassador communications, ambassador-specific and studio-wide analytics, fraud detection.
  • Owns (still plausibly current, pending LS-SPEC-001's full rewrite): Beta tester program specifics, content creator program specifics — neither reassigned yet, both flagged for review against CHG-SPEC-001 §1.1's Creator program type.
  • Consumes: DL-SPEC-017 (originally), CHG-SPEC-001 (as of this update, for everything superseded).
  • Exposes: Ambassador Profile API, Referral Tracking API, Reward Engine API, Campaign API, Asset Library API, Training API, Communication API, Analytics API, Fraud/Security API — superseded by CHG-SPEC-001's equivalents; see that spec's §19.
  • Governed by: LS-PLATFORM-ARCHITECTURE.md, transitively CHG-PLATFORM-ARCHITECTURE.md.
  • Recommended refactor (not yet performed): ambassador_profiles should become a 1:1 extension of LS-SPEC-002's base community_profiles rather than duplicating identity fields — see LS-SPEC-002 §1.4. This recommendation predates and is independent of the CHG-SPEC-001 supersession above.

LS-SPEC-002 — Community & Social Platform

  • Owns: Base community profile, friends, following, direct messaging, notifications, community feed, clubs/groups, presence, status, blocking, reporting, moderation/trust & safety, cross-game identity, cross-game reputation.
  • Consumes: an external Authentication system.
  • Exposes: Community Profile API, Friends/Following API, Messaging API, Notification API, Feed API, Clubs API, Presence API, Moderation/Trust & Safety API.
  • Governed by: LS-PLATFORM-ARCHITECTURE.md. Is itself depended on by LS-SPEC-001 (recommended refactor), LS-SPEC-003 (author identity), and LS-SPEC-004 (player identity for tickets/surveys) — this is the identity foundation the rest of the platform tier builds on.

LS-SPEC-003 — Content & Knowledge Platform

  • Owns: News, blogs, patch notes, roadmaps, videos, tutorials, documentation/knowledge base, live-operations announcements, scheduled publishing, localization, search, content versioning.
  • Consumes: LS-SPEC-002 (authorship identity).
  • Exposes: Content API, Scheduled Publishing API, Localization API, Search API, Live-Ops Announcement API.
  • Boundary to watch: distinct from LS-SPEC-001's ambassador-facing Marketing Asset Library — this spec is player/public-facing published content, LS-SPEC-001 §12 is ambassador-facing promotional material. Flagged in LS-SPEC-003 §0.3 as worth a joint review, not yet resolved.

LS-SPEC-004 — Studio Operations Platform

  • Owns: Customer Success (support tickets, feature requests, satisfaction surveys), Studio Analytics (cross-game rollups), Operations (health monitoring, telemetry, crash reporting, audit aggregation, admin tooling).
  • Consumes: LS-SPEC-001, LS-SPEC-002, LS-SPEC-003, DL-SPEC-017 (all as analytics data sources — never recomputed, only aggregated, per LS-SPEC-004 §0.1/§3.1), and by extension every game's own analytics event stream.
  • Exposes: Support Ticket API, Feature Request API, Survey API, Operations API, Audit Reporting API, Studio Analytics API.
  • Boundary to watch: general-player support tickets (owned here) vs. beta-tester bug/suggestion tracking (owned by LS-SPEC-001 §8) — the two systems are structurally independent by design, see LS-SPEC-004 §1.3.

LS-SPEC-005 — Legend Knowledge (World & Era Intelligence Layer) (v1.2)

  • Owns: Location hierarchy (country→region→subregion→settlement→site, no population floor), candidate site generation (§1.3a, authoritative — deterministic, guaranteed non-empty), the provenance/confidence model (6 tiers), the visual-year/era system and region-scoped era-integrity rules, the Build-My-Hometown reconstruction workflow (extraction, never reproduction, per copyright safeguard), procedural generation when verified data is insufficient (formally deterministic, §5.3), community environment sharing/versioning (moderation consumed from LS-SPEC-002, not owned), the historical-data curation pipeline, and licensing/copyright safeguards for historical reference material.
  • Consumes: an external Authentication system.
  • Exposes: Location API (including candidate site generation), Era API, Provenance API, Hometown Reconstruction API, Community Content API, Curation API — consumed exclusively by LS-SPEC-006, never directly by a game, including candidate site generation, with no exception.
  • Governed by: LS-PLATFORM-ARCHITECTURE.md. Game-agnostic and sport-agnostic — has no concept of venues at all.
  • Invariants: INV-6 (full determinism, no runtime randomness anywhere in this spec), INV-7 (candidate site generation never returns empty).

LS-SPEC-006 — Legend World Engine (v1.4)

  • Owns: The Environment Builder (Quick/Guided/AI-Assisted), environment zone modeling, the Venue Integration Interface (including §1.1a, the Candidate Site Request pass-through — confirmed architecture, the mechanism preserving the one-door rule now that LS-SPEC-005 owns candidate site generation), Living World vs. Frozen Era modes, the World↔Franchise bidirectional influence model (world facts inform, franchise success drives a development overlay — never alters underlying geography), the UE5 World Manifest schema (formally deterministic, §6.4; cache key confirmed as (settlement_id, visual_year, site_id, orientation_bucket), §8.2), multiplayer world-state consistency (via DL-SPEC-013's League Event Log), and world-generation performance/scalability strategy.
  • Consumes: LS-SPEC-005 (the sole source of location/era truth, including candidate sites).
  • Exposes: The Venue Integration Interface (§1.1, plus §1.1a), the UE5 World Manifest.
  • Governed by: LS-PLATFORM-ARCHITECTURE.md.
  • §1.1a boundary, confirmed: this engine is only an access gateway for candidate sites — it does not independently generate, rank, filter, reinterpret, or persist them. LS-SPEC-005 remains sole owner of that logic and data.
  • §8.2, confirmed: the internal inconsistency between §3.2 (orientation-dependent zone placement) and the original cache key (which omitted orientation) is resolved and authoritative. orientation_bucket only — no broader footprint component included unless a future pass demonstrates it affects generation.
  • First game-tier consumer: DL-SPEC-014 (Diamond Legend Stadium & Franchise Facilities) — written this session as a full draft implementing this engine's Venue Integration Interface for baseball. See DL-SPEC-014's own entry below for its one unresolved conflict with DL-SPEC-004.

LEGEND-WORLD-VERTICAL-SLICE-001.md (v2.0)

  • Status: Fully reconciled and promoted — no unresolved ownership conflicts remain. Companion implementation-contract document, not a numbered spec.
  • Owns: Nothing new — a translation layer only. Explicitly does not redesign any LS-SPEC-005/006/DL-SPEC-014 ownership.
  • Consumes: LS-SPEC-005 (v1.2), LS-SPEC-006 (v1.2), DL-SPEC-014 (v1.4).

LEGEND-WORLD-VERTICAL-SLICE-002-FACILITY-COMMITMENT.md (v1.1)

  • Status: Fully reconciled and finalized — no unresolved ownership conflicts remain. Companion implementation-contract document covering the renovation/expansion/replacement/facility-upgrade lifecycle: existing stadium → proposed change → pending queue → validation → Step 11 atomic commitment → World Manifest update if required → persistent history.
  • Owns: Nothing new at the LS-SPEC-005/006 tier — resolves one imprecise boundary within DL-SPEC-014's own existing ownership (renovation vs. expansion category definitions, §3.1) and formalizes the queue-then-commit workflow DL-SPEC-014 §8.2 already established in outline.
  • Consumes: DL-MASTER (v1.1, Step 11), DL-SPEC-014 (v1.4, §7–§10), LS-SPEC-005 (v1.2), LS-SPEC-006 (v1.4), LEGEND-WORLD-VERTICAL-SLICE-001 (v2.0).
  • Minor clarity note (not a conflict): DL-SPEC-014's stadium lighting_type field and LS-SPEC-006's World Manifest lighting field are different concepts (stadium infrastructure vs. ambient/environmental lighting) sharing a similar name — flagged for a future rename, not a functional issue.

LEGEND-WORLD-VERTICAL-SLICE-003-LIVING-WORLD-ERA-TRANSITION.md (v1.0)

  • Status: Draft, two items flagged pending confirmation (§0.1 Visual Year↔season mapping, §0.2 landmark transition rule). Companion implementation-contract document covering Living World mode's automatic era progression: season advance → era transition check → Legend Knowledge re-query → landmark persistence evaluation → World Manifest regeneration → persistent era history.
  • Owns: Nothing new at the LS-SPEC-005/006 tier — proposes concrete rules within LS-SPEC-006's own existing §4.2/§4.3 ownership, both flagged rather than silently decided.
  • Consumes: LS-SPEC-005 (v1.2), LS-SPEC-006 (v1.4), DL-SPEC-014 (v1.4, boundary only — explicitly excluded from automatic transition), LEGEND-WORLD-VERTICAL-SLICE-001 (v2.0), LEGEND-WORLD-VERTICAL-SLICE-002 (v1.1).
  • Key invariant: a franchise's own stadium is never auto-modified by an era transition — only by an explicit, owner-initiated Facility Commitment (VERTICAL-SLICE-002). World-driven change and franchise-driven change are strictly separate mechanisms.
  • Remaining stadium/world items not yet resolved, smaller than a full vertical slice: DL-SPEC-014's unconfirmed concessions/parking-to-DL-SPEC-008 link (open since DL-SPEC-014 v1.0), and DL-SPEC-014 §2.1's stale "World Manifest" cross-reference (found in this session's consistency check, not yet corrected).

Verified Entries — Game Tier (Diamond Legend)

DL-MASTER — Master Simulation Flow (v1.1) — VERIFIED, REVISED THIS SESSION

  • Status: Formally revised per approved studio decision. Added Step 11 — Facility Commitment (renumbering former Steps 11/12 to 12/13), corrected Step 4's obsolete "180-230" language to reference LeagueConfig.organizationalTargets, added DL-SPEC-014 to Tier 3 of the System Dependency Order (bidirectional with DL-SPEC-008), added a scope note excluding LS-SPEC-005/006 from its DL-only tier list, added previously-absent DL-SPEC-015 to Tier 6, updated the Specification Cross-Reference table and Data Flow Diagram accordingly. Full change log in the document's own Document History table (v1.1 entry).
  • Owns: The authoritative 13-step offseason-to-season sequence (was 12), the Specification Cross-Reference table, the six-tier System Dependency Order, and six studio-wide invariants — all as before, now with Facility Commitment included.
  • Consumes: DL-SPEC-001 through DL-SPEC-007, DL-SPEC-009, DL-SPEC-012, and now DL-SPEC-014 (Step 11).
  • Exposes: The authoritative step ordering — DL-SPEC-014 §8.5/§8.2 now cite Step 11 directly and precisely, superseding v1.3's approximate season-boundary rule.
  • Resolved: the confirmed gap from the prior session (no stadium step existed) is closed. No new conflicts were discovered reconciling DL-SPEC-014 against the revised sequence — see DL-SPEC-014 §15.2.
  • Still open, unrelated to stadiums: DL-SPEC-009's "(planned)" tags at Steps 5 and 7 in the cross-reference table are stale (DL-SPEC-009 is verified elsewhere in this project) but were left uncorrected this session, out of scope for a stadium-focused revision — flagged for a future pass.

DL-SPEC-011 — Trades & AI General Managers (v3.0)

  • Owns: Tradeable asset definitions (MLB players, prospects, current/future draft picks, cash, PTBNL), multi-asset package construction and valuation, player/prospect/draft-pick valuation formulas (reconciled against DL-SPEC-009's actual age/scarcity/market-value formulas), AI organizational strategy classification, deadline buyer/seller behavior, AI accept/reject/counteroffer logic (including scouting-quality-dependent perceived value, §8.6), anti-exploit protections, post-trade roster/payroll validation (corrected to 209/222/244), draft-pick ownership/lineage tracking (corrected to the confirmed 5-round/36-franchise structure), and single-player trade transaction logging.
  • Consumes: DL-SPEC-001 (organizational roster targets), DL-SPEC-003 (player schema — confirmed), DL-SPEC-004 (schedule/deadline timing), DL-SPEC-006 (determinism/logged-decision principle, extended and precision-scoped), DL-SPEC-008 (salary cap — confirmed hard cap), DL-SPEC-009 (contracts/no-trade rights — confirmed, corrected the no-trade model), DL-SPEC-010 (scouting grades/uncertainty — confirmed, added new §8.6 requirement), DL-SPEC-013 §5.5/§6.4 (multiplayer trade review and event logging — consumed, not duplicated).
  • Exposes: Trade evaluation/decision engine, draft-pick ownership ledger, trade transaction log (locally in single-player; via DL-SPEC-013's League Event Log in multiplayer).
  • Companion document: DL-SPEC-011-ACCEPTANCE-TESTS.md — updated alongside the v3.0 reconciliation.
  • Reconciled this session against the actual uploaded text of DL-SPEC-003/008/009/010. Full change log in DL-SPEC-011 §23. Two items remain genuinely open even after reconciliation: the injury/current-status data model (likely owned by DL-SPEC-006, not yet provided) and a deliberate design choice in §8.6 (deterministic vs. stochastic scouting-accuracy modeling) flagged for your decision, not resolved unilaterally.

DL-SPEC-013 — Multiplayer League Governance

  • Owns: League governance, league creation/visibility, organization roles & permissions, commissioner tools, scheduling, AI takeover, networking, league lifecycle, multiplayer security, multiplayer statistics reporting, multiplayer event handling (League Event Log).
  • Consumes: DL-SPEC-001, -003, -004, -005, -008, -009, -010, -011, -012 (baseball/franchise systems, used as-is), DL-SPEC-015 (GameEventStream, reused for spectator mode), DL-SPEC-016 (player identity), DL-SPEC-017 (entitlements, advertising gating), DL-SPEC-018 (custom player records).
  • Exposes: Multiplayer API, League Events, Commissioner Events (all backed by the League Event Log).

DL-SPEC-016 — Player Identity & Name Generation Engine

  • Owns: Player identity generation — names, nationality, birthplace, birth date/era weighting, language, family lineage, namesake/legacy generation.
  • Consumes: DL-SPEC-012 (Hall of Fame registry, for namesake generation), DL-SPEC-003 (career_status, for lineage eligibility timing).
  • Exposes: Identity records (consumed by DL-SPEC-018 for custom players), structured story hooks (consumed by DL-SPEC-007), global identity registry (duplicate-checking service).

DL-SPEC-017 — Advertising & Monetization Engine

  • Owns: Subscription tiers, entitlement logic, advertising engine (placement/timing/frequency), cosmetics, league-hosting entitlement rules, revenue analytics.
  • Consumes: none (foundation spec).
  • Exposes: Entitlement Check API (consumed by DL-SPEC-013, DL-SPEC-018), Ad Placement API (consumed by client/UE5 presentation surfaces per DL-SPEC-015), Revenue Analytics dashboards (linked from DL-SPEC-013 Commissioner reports).

DL-SPEC-018 — Player Creator & Customization System

  • Owns: Custom player attribute authoring, point-budget balancing, strengths/weaknesses, archetypes, template saving.
  • Consumes: DL-SPEC-003 (attribute schema, authored against but not owned), DL-SPEC-016 (identity for custom players), DL-SPEC-017 (creation entitlement gate).
  • Exposes: Finished, validated custom player records (consumed by DL-SPEC-013 for league-entry governance).

Placeholder Entries (Pending Verification Against Full Spec Text)

DL-SPEC-001 — Organizational Rosters & Workload

  • Owns (placeholder): Roster size targets and organizational structure across all levels of a franchise (MLB/AAA/AA/A).
  • Consumes (placeholder): DL-SPEC-003 (player career_status, the field roster membership is filtered by).
  • Exposes (placeholder): LeagueConfig.organizationalTargets — referenced directly in DL-SPEC-003 as the sole source of roster-size truth.

DL-SPEC-002 — Graphics & Presentation Phases

  • Owns (placeholder): Presentation phase sequencing distinct from DL-SPEC-015's UE5 rendering — likely the 2D/interim presentation layer preceding full UE5 integration.
  • Consumes (placeholder): DL-SPEC-006 (simulation events to present).
  • Exposes (placeholder): Presentation phase state, consumed by client UI.

DL-SPEC-003 — Player Lifecycle & Organizational Equilibrium (v1.1, Frozen) — VERIFIED

  • Status: Promoted from placeholder to verified this session — full text uploaded and read directly.
  • Owns: The player/person schema — career_status lifecycle (9 states: active, released, minor_league_fa, major_league_fa, retired, independent_league, foreign_league, return_to_college, unsigned_prospect; never deleted), LeagueConfig.organizationalTargets (the single source for all roster sizes: MLB 26/AAA 30/AA 30/High-A 30/A 30/Rookie 38/DSL 38, summing to min 209 / target 222 / max 244 — corrects the "180–230" figure used throughout earlier sessions of this project, which traced to the original synopsis, not the frozen spec), depth-aware release scoring, age-based exit rules, the 5-round/36-franchise amateur draft structure, and career-ending Diamond Times article generation.
  • Consumes: DL-SPEC-001 (organizationalTargets as the sizing input — confirmed, not placeholder).
  • Exposes: The attribute schema (overall, potential, age, primary_position, trend, mlbServiceTime, careerWAR, etc.) that DL-SPEC-011's valuation formulas, DL-SPEC-018's custom-player authoring, and DL-SPEC-016's lineage system all depend on.
  • Correction propagated this session: the 209/222/244 figures replace "180–230" in DL-SPEC-011 (§10.1, this session's reconciliation). Not yet propagated to other documents in this project that may also cite "180–230" (e.g., DL-SPEC-019, LS-SPEC-001) — flagged as a follow-up sweep, not yet performed.

DL-SPEC-004 — Schedule Generation System (v1.0) — VERIFIED

  • Status: Promoted from placeholder to verified this session — full text uploaded and read directly.
  • Owns: The in-season game calendar exclusively — per-level game counts and season day-ranges (MLB 162/Days 1–182, AAA 150, AA 140, High-A 132, A 132, Rookie 66, DSL 60), series generation, All-Star break (Days 89–93), trade deadline (Day 110 — confirms and corrects DL-SPEC-011's prior "roughly two-thirds" estimate), September expansion (Day 134), playoff seeding/bracket format. Contains no stadium, facility, or "stadium lifecycle" content of any kind — direct evidence resolving DL-SPEC-014 §0.1's flagged conflict from a prior session (see DL-SPEC-014's entry below).
  • Consumes: DL-SPEC-003 (organizationalTargets, September expansion trigger).
  • Exposes: season_schedules.season_start_day/season_end_day/trade_deadline_day/september_expansion_day — now confirmed inputs to DL-SPEC-011 §7.1 (trade deadline) and DL-SPEC-014 §8.5 (stadium-change timing gate).
  • New gap surfaced this session: DL-SPEC-004 does not itself sequence offseason processing steps (cleanup, contract processing, stadium changes) — that ordering is referenced by DL-SPEC-009 §11 as living in a "Master Simulation Flow (DL-MASTER)" document, not yet uploaded to this project. See DL-SPEC-014 §15.2.

DL-SPEC-005 — Statistics Engine

  • Owns: Atomic stat accumulation, career-stats-as-view architecture, rate-stat recomputation.
  • Consumes (placeholder): DL-SPEC-006 (game events to accumulate from).
  • Exposes: The stats engine DL-SPEC-013 §8 explicitly extends rather than duplicates for multiplayer.

DL-SPEC-006 — AI Decision Agents (Every Pitch Matters engine)

  • Owns: All in-game baseball decision logic — CatcherAgent, PitcherAgent, ManagerAgent, BullpenCoachAgent, BatterAgent, BasecoachAgent, UmpireAgent, BroadcastDirectorAgent; the shared PitchContext object. Likely also owns the current-injury-status data model DL-SPEC-011 §12 needs and could not confirm this session — still placeholder, full text not yet uploaded.
  • Consumes (placeholder): DL-SPEC-003 (player attributes driving agent decisions).
  • Exposes: Simulation outcomes — consumed by DL-SPEC-005 (stats), DL-SPEC-011 (its "nothing is random, every decision has a logged reason" principle, extended and precision-scoped in DL-SPEC-011 §18.1 this session), DL-SPEC-013 (AI takeover fallback, §3.3; full-sim control mode, §4.1), DL-SPEC-015 (rendering source of truth).

DL-SPEC-007 — Story Engine (Diamond Times, rivalries, milestones)

  • Owns (placeholder): Narrative generation from structured game/identity/franchise data. DL-SPEC-003 confirms career-ending article generation is at least partly specified there (significance thresholds, headline/body templates) — DL-SPEC-007 itself still not uploaded.
  • Consumes: DL-SPEC-016 (identity story hooks, explicitly per DL-SPEC-016 §12), DL-SPEC-006/005 (game/stat events), DL-SPEC-008 (financial events as narrative moments, confirmed via DL-SPEC-008 §15), DL-SPEC-009 (FA signings and extensions as news events, confirmed via DL-SPEC-009 §13), DL-SPEC-010 (development events as news, confirmed via DL-SPEC-010 §13).
  • Exposes (placeholder): Diamond Times content, consumed by DL-SPEC-017 §2.1 as a sponsorable surface (news feed sponsorships).

DL-SPEC-008 — Financial & Owner Simulation (v1.0) — VERIFIED

  • Status: Promoted from placeholder to verified this session.
  • Owns: Revenue model (gate/media/sponsorship/merchandise/concessions/playoff/revenue-sharing), attendance formula, market size, brand formula (0-100, mean-reverts to 62 — confirms the synopsis's original description), hard salary cap with floor enforcement (confirmed: "Hard cap enforced — no transactions allowed that exceed it"), luxury tax, franchise valuation (six components, revenue multiple 3.8x→5.0x over 25 seasons), dead money tracking, owner goals/grading.
  • Consumes: DL-SPEC-001, DL-SPEC-003 (payroll reads players.salary, dead money tracked on players table), DL-SPEC-009 (contract obligations feeding financial state — confirmed, not placeholder).
  • Exposes: Franchise value explicitly stated (DL-SPEC-008 §15) as an input to DL-SPEC-011 trade valuations and DL-SPEC-012 awards context — DL-SPEC-011 v3.0 does not yet fully incorporate franchise-value/ownership-style as a trade-strategy input; flagged as a possible future refinement, not built this session. Financial events feed DL-SPEC-007. Confirms DL-SPEC-017's monetization revenue is a strictly separate system from this in-fiction franchise finance (no shared vocabulary collision found on inspection).

DL-SPEC-009 — Contracts, Arbitration & Free Agency (v1.0) — VERIFIED

  • Status: Promoted from placeholder to verified this session.
  • Owns: Contract types (10 variants including rookie_scale, arbitration, guaranteed, qualifying_offer), service-time/control model (6-year path: pre-arb → arbitration at 3.0 years/Super Two → free agency at 6.0 years), arbitration salary formula, free-agent market value formula (age-curve + positional scarcity, now directly reused by DL-SPEC-011 §3.3/§3.7), contract extensions (loyalty discount), dead money, and no-trade clauses as a contractual field (full/partial/none, with partial_ntc_approved_teams) — corrects DL-SPEC-011 v2.0's binary-consent assumption.
  • Consumes: DL-SPEC-003, DL-SPEC-005, DL-SPEC-008 (confirmed, not placeholder).
  • Exposes: market_value and arbitration-salary baseline explicitly named (DL-SPEC-009 §13) as inputs to DL-SPEC-011 trade valuations — DL-SPEC-011 v3.0 now honors this precisely (§3.6) rather than approximating it.

DL-SPEC-010 — Scouting & Player Development (v1.0) — VERIFIED

  • Status: Promoted from placeholder to verified this session.
  • Owns: True-vs-scouted rating gap (20–80 scale, confirmed), scouting noise model (function of scout quality + viewing count, stored per report), scout organization/budget tiers, draft board construction, draft class generation (5 rounds × 36 franchises, with confirmed mean-potential-by-round table now used directly by DL-SPEC-011 §5.1), international signing pool, the daily player-development engine (explicitly stochastic — Gaussian noise, confirmed), and pro-scouting-investment-dependent trade evaluation accuracy (elite: true value known within 5%, average within 15%, minimal within 30% — a requirement DL-SPEC-011 v2.0 entirely missed, now added as DL-SPEC-011 §8.6).
  • Consumes: DL-SPEC-001, DL-SPEC-003, DL-SPEC-005, DL-SPEC-009 (confirmed, not placeholder). Also consumes DL-SPEC-016 (birthplace/nationality/amateur source/languages, per DL-SPEC-016 §12) — this cross-reference from before this session's upload is confirmed correct on inspection.
  • Exposes: Scouting reports (consumed by DL-SPEC-013's Scout role and live-draft fallback), development events (feed DL-SPEC-007), and now the accuracy-tier model DL-SPEC-011 §8.6 depends on.
  • Possible terminology gap flagged, not resolved: DL-SPEC-018 (this project's Player Creator spec) uses an attribute vocabulary — contact/power/discipline/vision/bunting/clutch, etc. — that does not obviously match DL-SPEC-010's actual scouting-grade field names (hitting/raw_power/game_power/speed/fielding/arm/stuff/command/movement). DL-SPEC-018 was written without access to DL-SPEC-010's real text and flagged this exact risk in its own §11. Worth a reconciliation pass the same way DL-SPEC-011 just got one, not performed this session.

DL-SPEC-011 — Trades & AI General Managers

Promoted to Verified Entries — Game Tier as of DL-SPEC-011 v2.0 (this session). See below; no longer a placeholder.

DL-SPEC-012 — Awards & Hall of Fame

  • Owns: Award determination, Hall of Fame voting (5-year wait, vote formula).
  • Consumes (placeholder): DL-SPEC-005 (career stats feeding award/HOF eligibility).
  • Exposes: The Hall of Fame registry, explicitly consumed by DL-SPEC-016 §11 for namesake/legacy-player generation.

DL-SPEC-014 — Stadium & Franchise Facilities (v1.4, Draft — Not Frozen)

  • Status: DL-MASTER revised and reconciled this session (approved studio decision). The DL-MASTER gap from the prior session is fully resolved, not merely recommended — Step 11 (Facility Commitment) is now authoritative, and DL-SPEC-014 §8.5/§8.2 cite it directly. No new conflicts discovered during reconciliation.
  • Owns: Unchanged in scope from v1.3, with one workflow revision: §8.2's renovation workflow is now queue-then-commit (approved changes queue throughout the offseason, all commit atomically at Step 11) rather than the previously-implied apply-on-confirmation model.
  • Consumes: LS-SPEC-006, DL-SPEC-008, DL-SPEC-010, DL-SPEC-004, DL-MASTER (v1.1, confirmed — Step 11 is this document's exact, authoritative commitment point).
  • New invariants: INV-7 revised (commitment must occur at Step 11 specifically, not an approximate season boundary), INV-8 added (atomic, not per-change, commitment).
  • Open item 1 — possible unseen DL-SPEC-004 v1.4 addendum: unchanged, still the only remaining open item of any consequence.
  • Closed this session: the DL-MASTER step-ordering gap (was open item 2 in v1.3).

DL-SPEC-015 — UE5 Rendering & Broadcast System

  • Owns: UE5 visualization, the GameEventStream API, modular stadium rendering architecture.
  • Consumes: DL-SPEC-006 (simulation as source of truth — the Golden Rule), DL-SPEC-014 (stadium facility data to render).
  • Exposes: GameEventStream — explicitly reused by DL-SPEC-013 §5.3 for spectator mode rather than building a second event contract; also the presentation hook point for DL-SPEC-017 §2.1 stadium signage and broadcast sponsorships.

DL-SPEC-017 — Advertising & Monetization Engine

  • Owns: Subscription tiers and entitlement logic (including Founder Tier and Lifetime Membership as of v1.1 — see below), the advertising engine, cosmetics, league-hosting entitlement rules, revenue analytics.
  • Consumes: none.
  • Exposes: Entitlement Check API, Ad Placement API, Revenue Analytics dashboards.
  • v1.1 update: Founder Tier (a limited-availability tier variant) and Lifetime Membership (a billing_model field orthogonal to tier) added as pure configuration, per DL-SPEC-019 §4.4's identified dependency. No new entitlement mechanism was introduced. This resolves the open dependency previously tracked in this document's Known Open Questions.
  • Still open: whether this spec should eventually become a Legend Studios-tier spec (LS-PLATFORM-ARCHITECTURE.md §8) remains undecided — see Known Open Questions below.

DL-SPEC-019 — Closed Alpha & Growth Integration

  • Owns: Diamond-Legend-specific alpha cohort model, version/release channel assignment, live event content (season launches, holiday events, progression boosts, themed drafts — all as scheduling/content wrappers around unmodified DL-SPEC-013 mechanics), and the Diamond-Legend analytics event taxonomy.
  • Consumes: LS-SPEC-001 (ambassador/beta tester lifecycle, referral tracking, reward engine — all unmodified), DL-SPEC-013 (leagues, drafts, governance — unmodified, no multiplayer mechanics introduced), DL-SPEC-016, DL-SPEC-017 (entitlements, cosmetics, Founder/Lifetime per v1.1).
  • Exposes: Alpha cohort/graduation events (to LS-SPEC-001's Reward Engine), the Diamond-Legend analytics event stream (to LS-SPEC-004 §3, LS-SPEC-001 §16, DL-SPEC-017 §5), version/release channel state.
  • Identified platform gaps (now resolved): originally flagged the need for Community & Social (§3), Content & Knowledge (§6), and Customer Success/Analytics (§8) platform services rather than owning them locally — these are now LS-SPEC-002, LS-SPEC-003, and LS-SPEC-004 respectively. DL-SPEC-019's own "consumption contract" sections should be revisited to reference these specs' actual APIs now that they exist, per each new spec's Recommended Next Steps.

DL-SPEC-020 — Affiliate, Ambassador & Creator Module (Diamond Legend Native Implementation)

  • Owns: Route structure, UI/UX integration, native Supabase schema placement (partner_ prefix), affiliate-specific auth entry points, the Outreach Center's Diamond-Legend-specific invite-status extension, and the module-boundary discipline enabling future extraction.
  • Consumes: CHG-SPEC-001 (the full data model/logic this module implements natively rather than reimplements), DL-SPEC-019 (release channels/alpha cohorts, for invite-status tracking), DL-SPEC-013 (permission-pattern consistency only — explicitly does not share role logic, see DL-SPEC-020 §3.2).
  • Exposes: The same logical surface as CHG-SPEC-001 §19, implemented as native routes/functions rather than a separately hosted service, until extraction (DL-SPEC-020 §7).
  • Relationship to CHG-SPEC-001: Does not change ownership — this is a deployment decision (logic lives in Diamond Legend's codebase for now), not an ownership decision (CHG-SPEC-001 still owns what the system does). See DL-SPEC-020 §0.1.
  • Outstanding: DL-SPEC-019's references to "LS-SPEC-001's Communication/Ambassador APIs" should be updated to point to this module — flagged in both CHG-SPEC-001 §20 and DL-SPEC-020 §8, not yet performed.

Known Open Questions From This Pass

-8. Two new items from LEGEND-WORLD-VERTICAL-SLICE-003 require confirmation: the Visual Year↔season mapping (proposed 1:1, LS-SPEC-006 §4.2) and the landmark status transition rule (proposed deterministic architecture-family-lifespan function, LS-SPEC-006 §4.3). Both are gaps within LS-SPEC-006's own existing ownership, not missing-owner situations, and both are load-bearing for the entire Living World document. -7.5. DL-SPEC-014 §2.1 has a stale cross-reference, found during this session's cross-spec consistency check, not yet corrected. It describes candidate site options as "surfaced through the World Manifest," which predates and contradicts the now-authoritative LS-SPEC-006 §1.1a flow (candidate sites arrive via a dedicated request, before any World Manifest exists). Flagged, not silently fixed, per explicit instruction.

-7. RESOLVED — LS-SPEC-006 §8.2's cache-key correction (orientation_bucket) confirmed as authoritative. Retained here only as a record that it was closed, not still pending.

-6. RESOLVED — LS-SPEC-006 §1.1a (Candidate Site Request pass-through) confirmed as authoritative. Retained here only as a record that it was closed, not still pending.

-5. DL-MASTER's stadium gap: RESOLVED this session by approved studio decision, not left open. Step 11 (Facility Commitment) formally added. No longer an open question — retained here only as a record that it was closed, not still pending. -4.5. The "180–230" figure: DL-MASTER's own instance corrected this session. DL-MASTER's Step 4 now references LeagueConfig.organizationalTargets instead of restating a number. The broader project-wide sweep (DL-SPEC-019, LS-SPEC-001, and any other document that may still cite "180–230") remains open — DL-MASTER was one instance among possibly several, now closed. -4.4. New, minor, out-of-scope-for-this-session: DL-MASTER's Specification Cross-Reference table still tags DL-SPEC-009 as "(planned)" at Steps 5 and 7, despite DL-SPEC-009 being verified elsewhere in this project. Left uncorrected deliberately — this session's DL-MASTER revision was scoped to the stadium gap and the 180–230 fix, not a full staleness audit of that table. -3.5. Two new confirmed DL-SPEC-008 field contracts found this session, absent from DL-SPEC-014's prior drafts: stadium.assessed_value (franchise valuation) and stadium.annual_debt_service (cash flow), plus a third field, stadium.lifecycle_stage, distinct from DL-SPEC-014's existing status field. All three now added to DL-SPEC-014 v1.2 §4.5/§11. -3. DL-SPEC-014 vs. DL-SPEC-004: resolved against available evidence, one smaller item remains. DL-SPEC-004's actual uploaded text (v1.0) contains no stadium content at all, resolving the ownership conflict flagged last session — DL-SPEC-014 stands as the confirmed stadium-lifecycle owner. What remains open: DL-SPEC-008 cites a "v1.4 addendum" to DL-SPEC-004 that doesn't exist in what's been uploaded — either an unseen revision exists, or that citation in DL-SPEC-008 is stale and should be corrected later. -2. "180–230" roster figure needs a sweep across this project. DL-SPEC-003's actual frozen figures are 209 min / 222 target / 244 max. This session corrected DL-SPEC-011's references but did not check DL-SPEC-019, LS-SPEC-001, or any other document in this project that may have cited the synopsis-derived "180–230" number. Worth a dedicated find-and-correct pass. -1.5. DL-SPEC-018's attribute vocabulary may not match DL-SPEC-010's real field names. DL-SPEC-018 (Player Creator) used contact/power/discipline/vision/bunting/clutch-style naming, written without DL-SPEC-010's real text available. DL-SPEC-010's actual scouting grades use hitting/raw_power/game_power/speed/fielding/arm/stuff/command/movement. DL-SPEC-018 flagged this exact risk in its own §11 at the time — now confirmed worth checking, not yet reconciled. -1. A third tier (CHG-SPEC) now exists above the platform tier, introduced by CHG-SPEC-001. LS-SPEC-001 is substantially superseded as a direct consequence — its full rewrite is not yet performed (see LS-SPEC-001 §21, step 0). This is the most structurally significant open item in this document's history and should be resolved (the rewrite performed) before any further LS-SPEC or CHG-SPEC work builds on an ambiguous LS-SPEC-001. 0. Whether DL-SPEC-017 belongs in the platform tier or the game tier is undecided (see LS-PLATFORM-ARCHITECTURE.md §8). It currently owns subscription/entitlement/advertising logic that is architecturally adjacent to LS-SPEC-001's studio-wide scope, but is numbered and frozen-track as a Diamond Legend spec. This is the most consequential open question introduced by adding the platform tier, and should be resolved before a second Legend Studios game needs its own monetization spec.

  1. DL-SPEC-003 verification is the highest-priority follow-up. Four newer specs (013, 016, 017, 018) all assume its attribute/lifecycle field names without having the actual file to check against.
  2. DL-SPEC-008's in-fiction franchise finance vs. DL-SPEC-017's real-world revenue should be explicitly confirmed as two unrelated systems that happen to both use financial vocabulary — a natural place for accidental confusion later if not stated plainly in both specs.
  3. DL-SPEC-002 (Graphics & Presentation Phases, Diamond Legend) vs. DL-SPEC-015 (UE5 Rendering) — the synopsis lists both; their boundary (interim presentation vs. UE5) should be confirmed rather than assumed once both are available. Note this is unrelated to LS-SPEC-002 (Community & Social Platform) — the DL- and LS- numbering series are independent and now both have a "002," which is a naming collision worth being deliberate about in conversation even though the namespaces prevent any actual ambiguity in the documents themselves.
  4. This document should be regenerated (not hand-patched) once DL-SPEC-001 through -012, -014, and -015 are uploaded in full, so every placeholder entry above can be replaced with a verified one.