LEGEND STUDIOS

Core Simulation Framework — Architecture Proposal

0. A Scoping Problem, Stated First, Not Buried

You asked me to review the completed work on Diamond Legend, Bitcoin Speedway, and Gridiron Legend, and to avoid simply copying sections from Gridiron Legend into a shared core. I can't fully do either of those things right now, and saying so upfront is more useful than producing a confident-looking document that quietly can't back up half its claims.

What I actually have: exhaustive knowledge of Gridiron Legend — the Bible, Systems Specification, Stress Test, Resolution Report, and five-part Engineering Specification, all produced in this conversation. What I don't have: any design or engineering documentation for Diamond Legend or Bitcoin Speedway. I know Bitcoin Speedway is a motorsports franchise simulator, roughly 40% built in Lovable, with some kind of crypto/token economy layer. I know Diamond Legend is a baseball franchise simulator. That's genre labels and a completion percentage, not architecture.

Why this matters for exactly this task: "determine what belongs in shared core" and "do not simply copy sections from Gridiron Legend" both require genuine comparison across at least two independently-designed systems. Without Diamond Legend's or Bitcoin Speedway's actual documentation, any "universal vs. domain-specific" judgment I make is really just "things Gridiron Legend happens to do, labeled universal because Gridiron Legend is the only system I can actually see." That's not a feasibility study — it's Gridiron Legend's architecture wearing a costume, which is precisely the failure mode you and I already named as the thing to avoid, months of documentation ago.

What I'm doing instead: this document has two real parts. Part A is high-confidence — a rigorous separation of Gridiron Legend's own architecture into what's structurally sport-agnostic by construction versus what's football-specific, backed by direct citations to Gridiron's own text, including three places where Gridiron's own development process already flagged something as a cross-game candidate. Part B is a specific, concrete list of questions whose answers I need from Diamond Legend and Bitcoin Speedway before Part A's candidates can be trusted as actually universal rather than just Gridiron-shaped. This is not a refusal to do the work — it's the same discipline this whole project has run on since the first stress test: don't declare something validated when it hasn't been checked.

PART A: High-Confidence Findings (Gridiron Legend-Derived)

A1. Already-Flagged Cross-Game Candidates — Direct Citations from Gridiron's Own Development

Three places in the Bible's own text already identified a pattern as a likely shared-engine candidate, independent of this proposal:

Module 3 (League Structure): "the scheduling/standings/playoff-format pattern is generic enough to be a strong Legend Engine candidate later (Diamond Legend and Bitcoin Speedway both need season structure and standings logic)."

Module 4 (Franchise Ownership): "the ownership-archetype + Owner Trust + Crisis/Ruin pattern is close to a direct match for what Diamond Legend would need for franchise ownership, and Bitcoin Speedway's team-owner layer likely rhymes with it too."

Module 5 (Financial System): "market-tier/revenue-sharing framework is a plausible Legend Engine candidate (any franchise sim needs this shape of system)."

These are the only three places Gridiron's own text makes this claim explicitly. I'm not extending the list beyond what's actually written, even though other patterns feel similarly reusable (see A2) — feeling reusable and being independently confirmed as reusable are different claims, and this section is reserved for the latter.

A2. Structurally Sport-Agnostic by Construction (High Confidence, Newly Identified Here)

These weren't flagged during Gridiron's own development, but I can verify directly from the engineering documents that their core mechanism contains no football-specific logic — only their example instantiations do:

Event Bus (publish/subscribe, domain-boundary enforcement, credential-based access control) — the mechanism itself references no football content; only its example event names (GameCompleted, CoachTerminated) are football-flavored.
StateMachineFramework/RiskState (Stable/Crisis/Ruin, the C10/C13 exploit-prevention rules) — a generic finite-state-machine primitive; football only appears in its 7 specific instantiations (Owner Trust, Cap Crisis, etc.).
End-of-Season Resolution Layer (snapshot-based simultaneous resolution for circularly-dependent metrics) — a generic solution to a generic problem (any season-based sim with interdependent metrics needs this pattern).
Decision Taxonomy (Strategic/Tactical/Operational) — a pure design philosophy, not content.
Abstraction Threshold (simulate only what the player can act on) — a design philosophy, not content.
AI parity philosophy (identical code path for AI and human actors) — an engineering principle, not content.
Fog-of-War error-band evaluation engine (hidden true value, narrowing error band via investment, irreducible floor) — a generic uncertainty-modeling pattern; any game with scouting, evaluation, or hidden-quality assessment needs a version of this.
Aggregate-root / Repository / Domain-boundary architecture (the Database and Backend Architecture's organizing pattern) — standard software architecture, verified to contain no football-specific logic in its structural rules.
CQRS read/write model split, hybrid snapshot+event-log persistence, authoritative-server multiplayer model — all generic, all verified content-free at the mechanism level.

A3. Confidently Football-Specific (Should Not Move to Shared Core As-Written)

Every formula's specific input variables and thresholds — cap percentages, positions, downs/distance, scheme identities.
The Draft System / College Pipeline's entire content — this is drawing on structures (a college pipeline feeding a professional draft) that may or may not have any equivalent in baseball or motorsports at all.
Front Office's ten specific executive titles — a real, non-trivial risk here, not just naming: NFL football has a hard salary cap; real MLB does not (it has a luxury tax instead). If Diamond Legend followed real baseball's economic structure rather than the NFL's, a "Salary Cap Manager" role and a CapLedger RiskState instantiation might not transfer at all — the category of role ("someone who manages the team's spending constraints") might generalize, but the specific mechanism underneath it might not, and I cannot tell which without seeing Diamond Legend's actual economic model.

PART B: What I Need From Diamond Legend and Bitcoin Speedway Before Part A Can Be Trusted

Specific, answerable questions — not a vague request for "more information":

Does Diamond Legend have a hard salary cap, a luxury tax, or something else entirely? This single answer determines whether Gridiron's CapLedger/Cap-Crisis RiskState instantiation is a real shared-core candidate or a football-specific artifact that happens to look generalizable from one example.
What is Bitcoin Speedway's actual unit of ownership — a full team with a multi-person roster (closer to Gridiron's shape), or a single driver/car (which would mean the entire Roster/Contract domain doesn't transfer at all)?
Does Bitcoin Speedway's crypto/token economy replace the Financial Ledger / Valuation pattern, or sit alongside it as additive flavor? This determines whether Module 5/29's economic architecture is a shared-core candidate or whether Bitcoin Speedway's economy is structurally different in a way no amount of Gridiron-side generalization would anticipate.
Does Diamond Legend have any equivalent of a college pipeline / draft system, given real MLB's amateur/international signing process looks nothing like the NFL draft?
What has Bitcoin Speedway's Lovable implementation already built independently? At ~40% complete, it has very likely already made its own architectural choices — for persistence, for its own event/state patterns — that may already duplicate, conflict with, or simply differ from what Gridiron engineered. A shared core built without accounting for this risks asking Bitcoin Speedway to retrofit itself onto a framework designed without any awareness of what it already is.

I cannot answer any of these from inside this conversation. They require either the actual design/engineering documentation for both other titles, or, at minimum, detailed working summaries at a depth comparable to what exists for Gridiron Legend.

Provisional Inheritance Sketch (Hypothesis, Not a Recommendation)

Offered as a starting shape to react to and correct once Part B is answered — explicitly not a final architecture:

Legend Studios Core Simulation Framework (hypothesis)
  ├─ Shared Kernel: Event Bus, StateMachineFramework, Resolution Layer pattern
  ├─ Shared Engineering Philosophy: AI parity, Decision Taxonomy, Abstraction
  │    Threshold, aggregate/repository/domain architecture, CQRS, save/persistence
  │    pattern, testing-tier strategy
  ├─ Candidate Shared Domain Patterns (PENDING Part B validation, not confirmed):
  │    League/Schedule/Standings shape, Ownership/RiskState shape,
  │    Market-tier/Revenue-sharing shape
  └─ Sport-Specific Children (each owns its own content, formulas, and any
       domain-specific systems the Shared Kernel doesn't cover):
         ├─ Diamond Legend
         ├─ Bitcoin Speedway
         └─ Gridiron Legend

I want to flag one thing about even this hypothesis honestly: your original inheritance diagram showed a linear chain (Core → Diamond → Gridiron → Bitcoin Speedway → future titles). I've drawn it instead as one Core with three independent children, because a linear chain would mean each game inherits from the previous game, not from a genuinely shared parent — and Bitcoin Speedway being 40% built already, independently of Gridiron, is itself evidence that a linear inheritance model doesn't match how these three projects actually came to exist. This is exactly the kind of assumption worth challenging now rather than after a Core Framework is built around the wrong shape.

Recommendation

Don't finalize this proposal yet. Part A is real and citation-backed; treat it as a strong starting hypothesis, not a conclusion. Before committing to any shared-core module structure, get Part B answered — ideally by bringing Diamond Legend and Bitcoin Speedway through even a lightweight version of the documentation depth Gridiron Legend has (they don't need the full 35-module treatment, but they need enough that a real comparison is possible, not a guess dressed up as one).

This is the same dependency I flagged in Gridiron's own Engineering Package Freeze declaration months of work ago. It was true then and it's still true now — this document doesn't resolve it, it just makes the specific, answerable shape of it visible.

Legend Studios Core Simulation Framework — Architecture Proposal, Part A/B structure. Awaiting Diamond Legend / Bitcoin Speedway input before Part A's candidates can be confirmed rather than hypothesized.