GRIDIRON LEGEND

Game Design Bible

Third title in the Legend Universe — following Diamond Legend and Bitcoin Speedway

🔓 STATUS: v1.4 — DESIGN REOPENED — FOOTBALL SIMULATION COMPLETION PHASE

Deliberate strategy change, superseding the v1.3 Architecture Lock. The v1.3 lock was correct for its purpose (giving the Comprehensive Stress Test a fixed target), and everything it produced — the Stress Test, Resolution Report, and five-part Engineering Specification — remains valid, real work. But the project's priority has shifted: this Bible is once again the primary, actively-evolving source of truth. The goal now is a complete, deep football simulation, not stability of downstream engineering documents.

What this means concretely:

• The Systems Specification is secondary and may lag behind this document. It will not be updated in lockstep with every Bible change during this phase.
• The five Engineering Specification documents (Blueprint, Database, API, Backend, Frontend) are snapshots, not commitments. They reflect the design as of v1.3 and are expected to require real rework once this phase concludes — that rework is accepted as the cost of getting the simulation right the first time, not avoided by freezing the design prematurely.
• The Future Enhancements Backlog and Expansion Notes remain valid records of ideas not yet folded back in, but any of their entries may now be pulled into the Bible directly as this phase determines they belong in the core design rather than a later expansion.
• The three-category reopen policy from v1.3 (bug / contradiction / architectural flaw) no longer gates changes during this phase. Substantive expansion is explicitly in scope. The categorization discipline is preserved for findings surfaced by stress-testing this phase's new content, not as a gate on adding the content itself.

A true Design Freeze will be declared again once the football simulation is complete, internally consistent, and fully stress-tested — at which point the Systems Specification and all five Engineering Specification documents will be rebuilt from the finished design, not patched incrementally.

Roadmap position:

Document status: 🔓 Actively evolving (v1.4) — Football Simulation Completion Phase. Engineering documents are provisional reference material, not implementation targets, for the duration of this phase. Target reader: Designers and the project owner completing the simulation's depth. Engineers should treat this document as unstable until the next Design Freeze is declared.

Document methodology, unchanged: each module contains a Design Layer (player experience, rationale, tension) and a Systems Layer (formulas, algorithms, state logic). Implementation Notes are retained where useful for future reconciliation but are no longer the primary purpose of writing a module. See Commitments Ledger in Module 1 for tracked history.

TABLE OF CONTENTS

1. Vision ✅ complete (v1.3)
2. Core Philosophy ✅ complete (v2.1)
3. League Structure 🔧 revised (v1.5) — 3 divisions per conference (6-5-5), resolved course-correction
4. Franchise Ownership ✅ complete (v4.1)
5. Financial System ✅ complete (v5.1)
6. Salary Cap ✅ complete (v6.0)
7. Player Contracts ✅ complete (v7.1)
8. Coaches ✅ complete (v8.0)
9. Coordinators ✅ complete (v9.0)
10. Scouts ✅ complete (v10.0)
11. Front Office 🔧 expanded (v1.5) — 10-role executive org chart, Decision Authority/Information Access/Conflict-Cooperation modeling
12. Medical Staff 🔧 expanded (v1.4) — 5 specialized roles + Practice Injuries
13. Draft System 🔧 expanded (v1.4) — Pro Days, Interviews, Wonderlic, Bust/Boom
14. College Pipeline 🔧 expanded (v1.4) — full simulated college football universe
15. Player Development 🔧 expanded (v1.4) — Confidence, Mentorship, Football IQ growth
16. Free Agency ✅ complete (v16.0)
17. Trades ✅ complete (v17.0)
18. Injuries ✅ complete (v18.0)
19. Stadium Management ✅ complete (v19.0)
20. Facilities ✅ complete (v20.0)
21. Fan Loyalty ✅ complete (v21.0)
22. Rivalries ✅ complete (v22.0)
23. Game Simulation Engine ✅ complete (v23.0)
24. AI Decision Logic ✅ complete (v24.2)
25. Story Engine ✅ complete (v25.2)
26. Dynamic League History ✅ complete (v26.0)
27. Hall of Fame ✅ complete (v27.0)
28. Legacy Score ✅ complete (v28.0)
29. Franchise Valuation ✅ complete (v29.0)
30. Economy ✅ complete (v30.0)
31. Online Seasons ✅ complete (v31.1)
32. Anti-Exploitation Systems ✅ complete (v32.1)
33. Balancing ✅ complete (v33.1)
34. UI/UX ✅ complete (v34.0)
35. Technical Architecture ✅ complete (v35.1)

SIMULATION INVARIANTS

The constitution. These rules cannot be broken by any future module, feature, monetization decision, or exception request. If a proposed feature violates one, the feature is wrong — not the invariant.

1. Uniform Cap Law. Every franchise operates under identical salary cap rules, formulas, and exception mechanisms. No team — including the player's — ever receives bespoke cap math.
2. No Hidden AI Advantage. AI-controlled franchises never receive hidden stat bonuses, cap exceptions, scouting accuracy, or information the human player cannot also access in principle. AI may be better resourced (better scouts, more cap space earned through good play) but never exempted from the rules.
3. Single Pipeline. Every player who enters the league does so through the same generation and draft/pipeline logic (Module 13, 14). No bespoke or hand-authored players exist outside that system, including any "legend" or licensed-adjacent figures.
4. Single Contract Logic. Every contract — player-negotiated or AI-negotiated — is produced by the same underlying valuation and negotiation engine (Module 7). There is no separate "story contract" logic that bends the math for narrative convenience.
5. Traceable Economy. Every dollar entering the economy has an explicit, simulated source (ticket revenue, media rights, sponsorships, merchandising, revenue sharing). No currency is created from nothing, including for the player.
6. Single Simulation Engine. Every game result — from Week 1 to a championship — is produced by the same Game Simulation Engine (Module 23). No scripted outcomes, no narrative-driven score overrides, ever.
7. Randomness Influences, Never Dictates. Variance (bounces, injury timing, weather, breaks) may shift outcomes probabilistically, but final results must always be a function of underlying quality/skill inputs, never independent of them. A one-star roster cannot out-roll a five-star roster as a matter of pure chance at any meaningful rate.
8. No Silent Systems. Every mechanic that affects an outcome the player cares about must be discoverable through play or the UI. Nothing that materially affects a franchise's fate is allowed to be permanently hidden from the player.
9. Uniform Time. One in-game season always equals one simulated NFL-length season for all franchises simultaneously. No franchise experiences compressed or expanded time relative to another for narrative convenience.
10. No Decision-Independent Ruin. No system may produce an unrecoverable franchise-ending state that was not the traceable consequence of a legible chain of decisions (see Commitments Ledger C8, Module 1). Bad luck can create a crisis; it cannot alone create a game-over.

Relationship to Module 1's Non-Negotiables (1.10): Non-Negotiables govern what kinds of features and business practices we will build (design/process guardrails). Simulation Invariants govern how the simulation itself behaves once built (runtime guarantees). A feature can violate a Non-Negotiable in concept before it's ever coded; it can violate an Invariant only in implementation. Both are checked at every module.

MODULE 1: VISION

1.1 What This Game Is

Gridiron Legend is a football dynasty ownership simulator. The player occupies the seat that no football game has ever fully committed to: the person who owns the franchise and runs it through a General Manager mandate — not the quarterback, not the head coach on the sideline, not a player controlling a single position.

The player's tools are not a controller stick and a playbook of routes. Their tools are: capital, contracts, drafting, staffing, infrastructure, and time. Their scoreboard is not just wins — it is the health, valuation, and cultural weight of a football institution across a professional lifetime.

The one-sentence pitch: You don't play football. You build the machine that plays football, and you live with what it becomes over 25 to 50 years.

1.2 What This Game Is Not

Stated explicitly, because every future module will be checked against these exclusions:

• Not a stick-skill or twitch-reflex football game. There is no analog-stick throwing mechanic, no manual route-running, no button-mash tackling.
• Not a game where the "best strategy" is discoverable in the first 10 hours and then repeatable forever. If a dominant strategy exists and stays dominant past season 5, that is a design failure, not a feature.
• Not a live-service game that treats the player as a wallet. Monetization (Module 30/31) must never compromise simulation integrity — see Non-Negotiables below.
• Not a game that resets meaningfully at the start of each season. Continuity is the product. A save file's value should be legible in its history, not just its current roster.
• Not a coach-only sim (no Football Manager–style tactical touchline micromanagement as the primary loop) — tactical identity exists but is expressed through staffing and scheme investment, not real-time play-calling override, unless a later module deliberately reintroduces a play-calling layer as an optional sub-system for players who want it. Default loop stays at the ownership/GM altitude.

1.3 The Player's Seat: Owner-GM Fusion

Real NFL front offices split Owner and GM into separate roles with separate incentives — this is deliberate friction we are choosing to compress. The player holds both:

• As Owner: controls capital allocation, franchise-level risk tolerance, stadium/market strategy, hiring and firing authority over the GM function itself (delegable — see 1.6), and long-horizon identity decisions (relocation, legacy, valuation targets).
• As GM: controls roster construction, cap management, draft strategy, trades, coaching staff composition, scouting investment.

This fusion is what allows every decision to "matter for decades" as required — an Owner-only game is too abstract (you'd just watch numbers), and a GM-only game is too disconnected from consequence (you can always blame ownership for not funding you). Fusing them means the player cannot externalize failure. A cap disaster is theirs. A stadium debt they signed off on is theirs. This is the central emotional mechanism of the entire simulation: undivided accountability across an entire adult lifetime of the franchise.

1.4 The 25–50 Season Problem

This is the hardest constraint in the brief, and it deserves to be treated as the organizing design problem of the whole Bible, not a footnote. Most sports management games are engineered for 3–8 season arcs before systems become legible, strategies become solved, and the meta stops moving. We are targeting 5–10x that lifespan. That requires naming, explicitly, why games go stale at scale, so every subsequent module can be checked against these failure modes:

Failure Mode A — Solved Meta. Once the player identifies the optimal cap-allocation curve or draft strategy, every subsequent season becomes execution of a known solution rather than a new decision. Design answer: the league's economic and rules environment must itself evolve on a schedule the player doesn't fully control — CBA renegotiations, rule changes, cap mechanics shifts, media revenue shocks (Module 5, 30) — so the "solved" strategy periodically stops being optimal. This is not randomness for its own sake; it must be telegraphed and negotiable, so it reads as history, not RNG punishment.

Failure Mode B — Roster Homogenization. Once draft classes and player generation settle into a stable statistical distribution, every team converges toward the same optimal archetype. Design answer: procedural generation for players, coaches, and scouts must carry genuine tail variance and regional/era-based skews (Module 13, 14) so archetypes rise and fall in scarcity over time, the way real football eras shift (dead-ball, spread-option, RPO/analytics eras).

Failure Mode C — No Memory. If season 30 feels mechanically identical to season 3, the 27 seasons in between were wasted compute. Design answer: Dynamic League History and Legacy Score (Module 26, 28) must make the game aware of its own past — rivalries compound, front office reputations follow the player, retired players show up as Hall of Fame voters or media narrative figures, stadiums age and require reinvestment. The game must accumulate texture, not just stats.

Failure Mode D — Endgame Flatness. Once a player has "solved" team-building, winning stops being interesting, and there is nothing else to chase. Design answer: the win condition must be plural and shifting — championships, valuation growth, legacy score, era-defining coaching trees, dynasty status — so that a player who has already won five championships still has unclaimed long-horizon goals (Module 28, 29).

Failure Mode E — Player Fatigue with Bookkeeping. Deep simulation risks becoming deep spreadsheet tedium, which kills sessions long before 25 seasons. Design answer: depth must be optional at the interaction layer even when it's mandatory at the simulation layer. Delegation systems (assistant GMs, staff autonomy sliders — Module 4, 11) let a veteran player hand off granular tasks in seasons where they want speed, without the simulation itself getting shallower. This is a UI/UX and Front Office problem as much as a vision problem, and will be treated as a first-class constraint in Module 11 and 34.

1.5 Design Pillars

Every module going forward is checked against these five pillars. A proposed mechanic that doesn't clearly serve at least one, and doesn't actively undermine any other, gets cut or reworked.

1. Consequential Decisions — every meaningful choice (contract, draft pick, coach hire, stadium investment) has a cost structure that is felt seasons later, not just immediately. No decision should be "free."
2. No Solved Strategy — the game must resist convergence on a single dominant approach across a 25+ season horizon through evolving rules, economics, and procedural variance.
3. Emergent Narrative Over Scripted Narrative — stories (rivalries, redemption arcs, dynasties, collapses) should emerge from systems interacting, with the Story Engine (Module 25) surfacing and framing them — not pre-written plot the player is walked through.
4. Grounded Realism — every system should be defensible to someone who actually works in an NFL front office, salary cap department, or scouting department. Realism is a constraint on plausibility, not a demand for real-world licensing or 1:1 real team replication.
5. Legible Depth — complexity must be navigable. Depth that the player cannot perceive or act on is wasted; the interface and delegation systems must make deep systems comprehensible at a glance, with detail available on demand.

1.6 The Owner's Time Horizon and Delegation

Because we are asking one human to run an institution across a simulated professional lifetime (in-game, an owner could plausibly run a franchise for 30–40 years; a real career is finite), the game must support variable engagement depth over its own runtime. Early seasons should reward hands-on granularity (the player is learning the systems and the franchise is small/vulnerable). Later seasons should support a "run the empire" mode where the player sets philosophy and delegates execution to staff whose competence the player has invested in — without that delegation becoming a way to disengage from consequence. Delegated decisions still produce outcomes the player owns. This tension — depth vs. control vs. time — is a standing design problem for every module involving staff (Module 8–12).

1.7 Tone and Fantasy

The emotional fantasy is not "I am a football god." It is "I built something that outlasted me." The aspirational player fantasy is closer to a sports-team version of building a family business or a political dynasty than a power fantasy of athletic dominance. Losing seasons, cap hell, bad hires, and stadium debt are not punishments to be avoided at all costs — they are supposed to be survivable and interesting, because a game where every mistake is fatal produces risk-averse, repetitive play, which directly threatens the 25+ season retention goal.

1.8 Relationship to the Legend Universe

Gridiron Legend shares a simulation philosophy with Diamond Legend (deep franchise ownership, long time horizons) but is not required to share Bitcoin Speedway's tokenized/crypto economic layer — that reads as specific to motorsports' sponsorship-and-speculation identity, not a mandatory universe-wide mechanic. Where the Legend Universe connection should show up mechanically will be addressed directly in Module 29 (Franchise Valuation) and Module 30 (Economy), where we'll evaluate whether a light shared-universe economic thread (e.g., cross-game franchise valuation benchmarking, or a shared "Legend Index" of franchise value across titles) adds value or is fan-service without substance. Flagging now, deciding later, so Module 1 doesn't lock in an assumption prematurely.

1.9 Reserved Design Option: Owner/GM Split in Multiplayer

Single-player deliberately fuses Owner and GM into one seat (1.3) for accountability. This fusion removes a major real-football dramatic engine: ownership overriding football logic for financial, political, or ego reasons. Rather than sacrifice that tension universally, Module 31 (Online Seasons) is required to evaluate a co-op league mode where Owner and GM are separate human-controlled seats on the same franchise, with genuine principal-agent friction (the Owner can override, defund, or fire the GM player; the GM must manage the Owner's patience as a resource). This is a reservation, not a commitment — Module 31 must explicitly accept or reject it with reasoning.

1.10 Non-Negotiables

These are treated as constraints, not preferences — any future module that violates one gets sent back for rework regardless of how good it is on its own terms:

• No pay-to-win. Monetization must never let real money buy competitive advantage (better draft odds, cap exceptions, etc.). It may sell cosmetic, convenience-without-advantage, or content expansion.
• No fully solvable optimal strategy that remains optimal for the life of a save.
• No fatal, unrecoverable states that aren't the result of a legible sequence of player decisions the player could see coming. Randomness may create crises; it may not create unrecoverable game-overs from a single unlucky roll.
• No system without at least one meaningful counterplay or mitigation. If a mechanic can hurt the player, there must be a strategic lever to reduce, hedge, or recover from that harm.
• No mechanic justified only by "realism" if it doesn't also serve replayability or decision depth. Realism is a quality bar, not a blank check for tedium.
• No real-world league IP. Gridiron Legend uses no real NFL franchises, team names, logos, player likenesses, or league branding. It has its own fully fictional professional football universe — explicit as of v1.5, per direct project-owner directive, though this was always the game's implicit posture.

1.11 Commitments Ledger — STATUS AS OF v1.3 (post-Chief-Architect-Review revision cycle)

Originally closed at "all 35 modules complete." The Systems Specification extraction and subsequent Chief Architect Review surfaced four new architectural items, logged below as C15–C18, consistent with this document's standing practice of full traceability rather than quietly revising without a record.

All 18 tracked commitments are formally discharged as of this revision (v1.3). This table remains a permanent, growing record rather than a closed artifact — consistent with Module 26's own principle that a traceable decision history is a design value worth preserving, not just a process formality.

1.12 Implementation Notes

Module 1 is a philosophy/constraint layer, not a data layer — it does not itself define database tables or in-game UI. Flagging that honestly rather than manufacturing fake schema. What it does produce for engineering purposes:

• A validation checklist every future module's Implementation Notes must be run against before it's considered complete (the five Design Pillars + ten Simulation Invariants + Non-Negotiables).
• A recommended dev-process artifact, not a runtime table: a design_constraints_registry (design doc / CI-style checklist, not game data) that a producer or engineer can literally check a new feature ticket against before it's greenlit. This is process tooling, not something the game engine queries at runtime.
• One runtime-relevant implication: because Invariant 2 (No Hidden AI Advantage) and Invariant 7 (Randomness Influences, Never Dictates) are load-bearing for the whole simulation, the eventual Game Simulation Engine (Module 23) and AI Decision Logic (Module 24) will need a shared, auditable "outcome resolution" function that both player and AI franchises pass through identically — this should be flagged to engineering now as a core architecture decision, not something to bolt on later once AI-specific shortcuts have already been built for performance reasons.

1.13 Dependencies

Every subsequent module depends on Module 1 as its constraint layer — this is listed once here rather than repeated in every module's dependency section going forward; each future module's Dependencies section only needs to list modules other than Module 1 that it relies on.

Direct, load-bearing dependents worth naming explicitly:

• Module 2 (Core Philosophy) — direct mechanical translation of the five Design Pillars.
• Module 4 (Franchise Ownership) — implements the Owner-GM fusion (1.3) and must address Commitments Ledger item C8 (defining recoverability).
• Module 11 (Front Office) — implements delegation (1.6) and must discharge C1.
• Module 24 (AI Decision Logic) — must discharge C2 and implement Invariant 2.
• Module 23 (Game Simulation Engine) — must implement Invariant 6 and 7.
• Module 31 (Online Seasons) — must formally accept or reject the reserved Owner/GM split (1.9, C4).
• Module 29/30 (Franchise Valuation / Economy) — must resolve C5 (Legend Index question) and implement Invariant 5.

1.14 Version History

End of Module 1 (v1.2). Proceeding to Module 2: Core Philosophy.

MODULE 2: CORE PHILOSOPHY

2.1 Purpose of This Module

Module 1 established five Design Pillars and ten Simulation Invariants as constraints. This module converts them from principles into operable design rules — the actual tests every future mechanic gets run through before it's allowed into the Bible. Where Module 1 says "every decision should matter," Module 2 defines what "matter" means well enough that two different designers would build the same feature from the same brief.

2.2 Design Layer: What Makes a Decision "Meaningful"

A decision is only meaningful if it satisfies all four of the following. A proposed mechanic that fails any one of them is either cut or reworked until it passes:

1. Cost — choosing one option forecloses another. A decision with no opportunity cost is a preference, not a decision (e.g., cosmetic-only choices are fine to include, but they don't count toward "meaningful decision" quotas anywhere in the design).
2. Uncertainty at decision time — the player cannot know the outcome with certainty when they choose. If a decision is always correct given perfect information, and perfect information is always available, it isn't a decision, it's a checklist item.
3. Delayed or distributed consequence — the result isn't fully resolved in the same action or the same season. This is what separates a franchise sim from an arcade game, and it's the mechanism that makes 25+ seasons possible: consequences that arrive years later are what give later seasons their weight.
4. Path dependency — the decision changes what future decisions are available or wise, not just the current scoreboard. A draft pick doesn't just add a player stat line; it changes cap trajectory, positional need, and trade leverage for years.

2.3 Design Layer: Decision Taxonomy

Every mechanic in the game must be classified into exactly one of three decision tiers. This classification determines UI placement, delegation eligibility (Module 11), and how much simulation depth it deserves.

• Strategic Decisions — multi-season horizon, franchise-identity-defining, never delegable. Examples: rebuild vs. compete-now philosophy, stadium relocation, coaching-tree investment, cap-philosophy (aggressive vs. conservative). The player must always make these personally; the game should never auto-resolve a Strategic Decision even at maximum delegation.
• Tactical Decisions — single-season to few-season horizon, meaningfully affect Strategic outcomes but are individually recoverable. Examples: a specific free agent signing, a specific draft pick, a specific coordinator hire. Delegable at a cost (per Commitments Ledger C1) — delegating these is the main lever for managing 25+ seasons of workload without disengaging from consequence.
• Operational Decisions — week-to-week or day-to-day, individually low-stakes, only meaningful in aggregate. Examples: practice-squad churn, minor roster paperwork, day-to-day medical scheduling. Fully delegable by default; the game should not force manual handling of these even early on, or Failure Mode E (bookkeeping fatigue) from Module 1 reasserts itself immediately.

Rule: any mechanic proposed in a future module must state its tier explicitly in that module's Design Layer. If a designer can't decide which tier a mechanic belongs in, that's a signal the mechanic is underspecified, not that the taxonomy is wrong.

2.4 Design Layer: The Abstraction Threshold

Not everything can be simulated at full depth — Failure Mode E already established that bookkeeping tedium kills long-run engagement. The rule for what gets full simulation depth versus statistical abstraction:

A system is simulated in full detail only if the player can meaningfully act on its internal state. Otherwise, it is abstracted to inputs and outputs.

Example: the Game Simulation Engine (Module 23) must simulate individual plays, because scheme and personnel decisions (inputs the player controls) need to visibly produce different outputs. But a player's off-season conditioning regimen doesn't need play-by-play simulation of individual workouts — the player's investment (facilities quality, medical staff quality — Module 12, 19) is the actionable lever, and the workout itself can be abstracted into a development-roll output. This threshold gets re-tested in every module's Implementation Notes going forward: "what part of this system is a lever the player pulls, and what part is just flavor text around a number?"

2.5 Design Layer: Failure Must Be Survivable, Not Avoidable

Directly extending Invariant 10 (No Decision-Independent Ruin): the philosophy is not "protect the player from bad outcomes." It's "bad outcomes must be legible, gradual, and escapable through further decisions." This produces a specific design requirement for every module involving risk (Injuries, Salary Cap, Trades, Franchise Valuation, etc.):

Every negative-outcome system must define a Crisis state and distinguish it from a Ruin state.

• A Crisis is a bad but survivable position reachable through a legible sequence of decisions or variance (e.g., cap hell from a bad contract cycle, a losing streak from an aging roster). Crises must always have at least one available mitigation path, even if that path is slow or costly.
• Ruin — a state with no mitigation path at all — is only permitted if it was the outcome of a long, visible chain of Strategic Decisions the player made with adequate warning (e.g., a decade of reckless spending genuinely could end in relocation or forced sale). Ruin may never be triggered by a single unlucky roll, a single bad Tactical Decision, or an Operational-tier event.

This gets stress-tested explicitly in every future module going forward, not just noted once — see 2.9.

2.6 Systems Layer: Decision Weight Scoring

To make 2.2 usable as an actual design tool rather than a vibe check, every proposed mechanic is scored before inclusion:

Decision Weight (DW) = Cost × Uncertainty × Horizon × Path-Dependency

Where each factor is rated 0–3 by the design team at proposal time:
  Cost              0 = none, 3 = severe/irreversible-in-short-term opportunity cost
  Uncertainty       0 = fully known outcome, 3 = high-variance/hidden-information outcome
  Horizon           0 = resolves same session, 3 = resolves 3+ seasons later
  Path-Dependency   0 = no effect on future options, 3 = fundamentally reshapes future options

Minimum DW for a Strategic-tier mechanic: 27 (i.e., roughly 3×3×3×3 territory — should score
  high on nearly every factor)
Minimum DW for a Tactical-tier mechanic: 8
Operational-tier mechanics are exempt from DW scoring entirely — they are not meant to be
  individually meaningful, only meaningful in aggregate (see 2.3).

This isn't meant to produce false mathematical precision — it's a forcing function. If a designer proposes a "Strategic" mechanic and it scores a DW of 6, that's a signal the mechanic is actually Tactical, or is underbuilt and needs more real cost/uncertainty/horizon/path-dependency before it deserves Strategic-tier UI real estate and narrative weight.

2.7 Systems Layer: Generalized State Machine Framework (RiskState as a Configuration)

[Revised v2.1, post-Chief-Architect-Review — see 2.13 Addendum for full revision rationale. Section number deliberately unchanged so every existing "(Module 2.7)" citation throughout the Bible remains valid and now points to this expanded, generalized definition.]

Every risk-bearing system (Salary Cap, Injuries, Franchise Valuation, Fan Loyalty, etc.) instantiates a shared pattern. Originally specified narrowly as a Crisis/Ruin template, it is now formalized as a generic, reusable state-machine primitive, with the Crisis/Ruin pattern defined as one named configuration of it — not a bespoke object in its own right:

StateMachineFramework (generic primitive):
  states: []                      — any ordered or unordered set of named states
  transition_rules: []            — conditions governing movement between states
  scoring_dimension (optional)    — a 0-100 severity/progress score, if the states
                                     represent a spectrum rather than discrete categories
  action_hooks (optional)         — player- or system-actionable levers available in
                                     a given state
  decision_log: []                — traceable history of what inputs drove each
                                     transition (supports Invariant 8, No Silent Systems)

RiskState = StateMachineFramework configured as:
  states: [Stable, Crisis, Ruin]
  scoring_dimension: severity_score (0-100)
  transition_rules: (as originally specified — see below)
  action_hooks: available_mitigations[] (Tactical or Strategic tier, player-actionable)

STATE: Stable
  → triggered into CRISIS by: threshold breach (e.g., cap overage, loss streak length,
    valuation decline rate) — threshold values are system-specific, defined per module
  → CRISIS state must expose:
      - at least one Mitigation Action (Tactical or Strategic tier, player-actionable)
      - a visible Severity Score (0-100) trending value, not a hidden pass/fail flag
      - a Time-to-Ruin estimate IF no mitigation is taken (so players get fair warning)
  → CRISIS resolves back to Stable via successful Mitigation Action(s) over time
  → CRISIS escalates to RUIN only if:
      a) Severity Score reaches maximum AND
      b) a defined minimum number of Strategic-tier decision points were available and
         declined/failed across a defined minimum time window (system-specific, but never
         less than 2 full seasons of warning for any Ruin-capable system)
  → RUIN is terminal for that specific system/asset (e.g., forced franchise sale,
    permanent relocation) but must never be terminal for the SAVE FILE itself — the player
    continues as Owner/GM of the consequences (rebuilding under new ownership constraints,
    starting a new franchise arc, etc.) per Invariant 10.

Why generalize now: the Chief Architect Review's directive to elevate this into a reusable framework reflects something the Bible's own pattern already implied but never stated outright — every one of the 7 confirmed RiskState instantiations proved the shape was reusable, which means the underlying state-machine mechanics (not just the risk-specific Crisis/Ruin semantics) are themselves a general capability. This does not mandate new non-risk instantiations now — no new feature is being added — but it formally opens the door for a future module to model a non-risk progression (a coordinator's HC-readiness track, a player's career-arc phase, a franchise's identity-phase transitions) as a StateMachineFramework configuration rather than inventing a parallel bespoke pattern, if a future design need calls for it.

Every future module with a risk system must instantiate the RiskState configuration specifically (not a fresh bespoke Crisis/Ruin system); any future module needing a non-risk staged progression may instantiate StateMachineFramework directly with its own states. This is a direct discharge mechanism for Invariant 10 and Commitments Ledger C8.

2.8 Design Layer: Symmetry of Rules, Asymmetry of Starting Conditions

Directly extends Invariant 1 and 2 (Uniform Cap Law, No Hidden AI Advantage) into a general philosophy: every franchise, player-controlled or AI-controlled, plays by identical rules — but franchises are not required to start from identical positions. A player who takes over a historically bad franchise should face a harder climb than one who takes over a contender, and that asymmetry is a feature (it's what makes "which franchise do I choose" a real Strategic Decision at save creation), not a fairness violation, because the rules generating both franchises' situations were identical. This distinction — rule symmetry vs. condition symmetry — is what every future module should cite when a design question arises about whether an advantage is "fair."

2.9 Stress Test

Can players exploit this? The Decision Weight formula (2.6) is a design-time tool, not a runtime mechanic, so it's not player-exploitable directly. But the Crisis/Ruin template (2.7) has an exploit shape worth naming now: if Mitigation Actions are ever cheaper than the cost that caused the Crisis in the first place, players will deliberately trigger Crises for value (e.g., intentionally blow past the cap because the mitigation penalty is smaller than the short-term talent gained). Rule for all future modules implementing this template: Mitigation Actions must always cost more, in expectation, than avoiding the Crisis in the first place — crisis management is insurance, not arbitrage. Adding this as a standing requirement, not just a note.

Can AI exploit this? More precisely, can AI break this: if AI franchises are allowed to use a simplified/cheaper version of the Crisis/Ruin state machine for performance reasons (a very real engineering temptation once dozens of AI franchises are simulated every season), Invariant 2 is silently violated. Flagging explicitly for Module 24: AI franchises must run the same Crisis/Ruin logic, not a lookup-table approximation of it, even if that costs more compute — this is a hard requirement, not a nice-to-have.

Does this create a dominant strategy? The Abstraction Threshold (2.4) creates a risk: if the line between "simulated in depth" and "abstracted" is drawn wrong, players will find the abstracted systems either irrelevant (ignore them, no cost) or a spreadsheet-optimizable freebie (exploit them, no skill required). Every module that abstracts a system must justify why that system doesn't meet the actionable-lever test, not just assert it — this becomes a required line item in that module's Design Layer going forward.

Does this stay interesting after 30 seasons? The Decision Taxonomy (2.3) is designed explicitly to keep the game playable at year 30 by making delegation of Operational and (partially) Tactical decisions safe — but it depends entirely on Module 11 delivering real, well-tuned delegation quality tiers. If Module 11 makes delegation either too good (no reason to stay hands-on) or too bad (delegation is a trap, player must stay hands-on forever), this entire module's long-horizon promise collapses. Flagging as the single highest-risk dependency in the Bible so far.

2.10 Implementation Notes

• Decision Weight Scoring (2.6) is a design-tool, not shipped game logic — implemented as a design-review spreadsheet/checklist, not a runtime system. No engineering work required.
• Crisis/Ruin State Machine (2.7) is the first genuinely reusable runtime pattern in the Bible. Recommend a shared engineering component: a generic RiskState object (fields: current_state [Stable|Crisis|Ruin], severity_score [0-100], time_to_ruin_estimate, available_mitigations[], strategic_decision_log[]) that every risk-bearing subsystem (Cap, Injuries, Fan Loyalty, Valuation) instantiates and extends rather than reimplementing. Flagging this now so Module 6 (Salary Cap), the first module likely to need it concretely, doesn't build a one-off version.
• Decision Taxonomy tags (2.3) imply every mechanic-level data object eventually needs a decision_tier field (Strategic|Tactical|Operational) — relevant to the eventual Front Office / delegation engine (Module 11) and to UI state (Module 34), which will need to visually distinguish tiers (e.g., Strategic decisions always get full-screen treatment; Operational never interrupt flow).

2.11 Dependencies

(Excludes Module 1, which everything depends on by default — see 1.13.)

• Module 6 (Salary Cap) — first concrete implementation of the Crisis/Ruin template (2.7); must also formally define its Decision Weight–qualifying mechanics per 2.6.
• Module 11 (Front Office) — must deliver delegation quality tiers that make the Decision Taxonomy (2.3) actually work at scale; identified in 2.9 as the highest-risk dependency in the Bible so far.
• Module 12, 19 (Medical Staff, Stadium) — first concrete tests of the Abstraction Threshold (2.4).
• Module 23 (Game Simulation Engine), Module 24 (AI Decision Logic) — must implement identical Crisis/Ruin and rule-symmetry logic for AI franchises per 2.8 and the AI stress-test finding in 2.9.
• Module 34 (UI/UX) — must implement tier-differentiated treatment per the Decision Taxonomy.

2.12 Version History

End of Module 2 (v2.0). Proceeding to Module 3: League Structure.

2.13 Addendum (v2.1): Event Bus Architecture

Added post-Chief-Architect-Review, after Systems Specification extraction surfaced the need for a formal cross-system communication backbone.

Design Layer: every subsystem in the Bible so far communicates with others through direct references — "Module 8 feeds Module 4," "Module 21 feeds Module 4," and so on. That framing is fine for design-level reasoning, but it invites a real engineering risk: subsystems directly reading or mutating one another's internal state, which makes the system's actual behavior hard to trace and, worse, creates exactly the kind of undisciplined cross-wiring that produced the circular dependency identified in 2.14 below. The fix is architectural, not just procedural: subsystems publish events describing what happened; they never directly call into or mutate another subsystem's state. Consumers subscribe to the event types they care about.

This formalizes a pattern the Bible already used implicitly — Module 25's Story Engine EventDetector has always been described as "subscribing to state-change events across every other module" (Module 25.2). That was, in effect, already an Event Bus consumer without a named Event Bus to consume from. This addendum makes the bus itself a first-class, required primitive rather than something only the Story Engine happens to lean on.

Systems Layer:

EventBus (generic primitive):
  publish(event_type, payload, source_module)
  subscribe(event_type, handler)
  — NO subsystem may directly read or write another subsystem's internal state.
    The ONLY sanctioned cross-subsystem interactions are:
      (a) direct parent-child ownership (e.g., a Contract belongs to a Player — this is
          composition, not cross-system coupling, and is unaffected by this rule)
      (b) publish/subscribe via the EventBus

EXAMPLES OF EVENTS ALREADY IMPLIED BY EXISTING MODULES (reclassified, not new):
  - "GameCompleted" [Module 23] → consumed by Fan Loyalty [21], Story Engine [25],
    League History [26]
  - "CoachTerminated" [Module 8] → consumed by Coaching Tree [8], Story Engine [25],
    Organizational Instability [11]
  - "CrisisStateEntered" / "RuinStateReached" [any RiskState instance] → consumed by
    Story Engine [25], League History [26], Owner Trust [4] (where relevant)
  - "SeasonResolutionComplete" [see 2.14] → consumed by every offseason-triggered system
    (Draft [13], Free Agency [16], Contract renegotiation [7])

ENFORCEMENT: Module 25's Story Engine subscribing-only, publish-never rule (protecting
  Invariant 6) is now architecturally guaranteed by the EventBus itself, not just a
  stated policy — the Story Engine module is never granted a publish credential for
  simulation-state event types, full stop.

Relationship to other primitives: the LeagueHistoryLedger (Module 26) is naturally a persistent, append-only subscriber to the bus. The RiskState/StateMachineFramework primitive (2.7) publishes state-transition events (entering Crisis, reaching Ruin) rather than any other module polling its state directly. The End-of-Season Resolution Layer (2.14) both consumes the season's accumulated events and publishes its own resolution-complete events for downstream systems.

Dependencies: every module in the Bible is a de facto publisher and/or subscriber; most directly Module 25 (Story Engine, primary consumer), Module 26 (League History, persistent consumer), Module 35 (Technical Architecture, owns the engineering realization of this pattern).

2.14 Addendum (v2.1): End-of-Season Resolution Layer

Added post-Chief-Architect-Review, directly resolving the circular dependency identified during Systems Specification extraction: Owner Trust (Module 4) reads Fan Loyalty and franchise reputation; Fan Loyalty (Module 21) reads franchise reputation and (indirectly) competitiveness signals tied to Owner Trust; Front Office Reputation (Module 11) and Coach Hot Seat (Module 8) both sit downstream of the other two. None of those four modules, individually, specified how a same-tick mutual read should resolve.

Design Layer: the fix is not a per-module patch — it's a standing architectural rule. Any metric that depends on another Resolution-Layer metric, which in turn depends back on the first (directly or transitively), must resolve through a single, deterministic, once-per-season computation phase rather than through ad hoc same-tick reads scattered across modules. This phase runs after in-season simulation completes (all games, injuries, in-season trades) and before offseason systems begin (draft, free agency, contract renegotiation) — a natural seam that already exists in the season loop implied by Modules 3 and 23.

Systems Layer:

EndOfSeasonResolutionLayer:
  timing: once per season, after in-season simulation completes, before offseason
    systems begin
  mechanism: SNAPSHOT-BASED SIMULTANEOUS RESOLUTION
    - every registered metric reads its inputs EXCLUSIVELY from the PRIOR season's
      finalized snapshot (frozen values) — never from another metric's value as
      computed earlier in the SAME pass
    - all newly-computed values commit together at the end of the pass
    - this guarantees deterministic, order-independent results regardless of which
      order the registered metrics happen to be evaluated in — a standard
      simultaneous-update pattern that eliminates same-tick circularity by construction

REGISTRY (the four systems that surfaced this need, registered as the first members):
  OwnerTrust      reads prior-season: FanLoyaltyIndex, FrontOfficeReputation
  FanLoyaltyIndex reads prior-season: OwnerTrust-driven competitiveness signal,
                                       FrontOfficeReputation
  HotSeat         reads prior-season: OwnerTrust trend, FanLoyaltyIndex trend
  FrontOfficeReputation reads prior-season: transaction behavior log (not circular
                                       itself, but included for consistent pass
                                       ordering with the other three)

STANDING RULE: any future module introducing a metric with a cross-dependency on
  another Resolution-Layer metric MUST register into this layer rather than
  implementing an ad hoc same-tick read. This is now a required check in every future
  module's Implementation Notes, alongside the existing RiskState/StateMachineFramework
  instantiation check.

RELATIONSHIP TO EVENT BUS (2.13): the Resolution Layer consumes the season's
  accumulated events as part of its input gathering, then publishes a
  "SeasonResolutionComplete" event set — offseason systems (Draft, Free Agency,
  Contract renegotiation) should treat this event, not a hardcoded season-transition
  flag, as their trigger to begin.

Implementation Notes: EndOfSeasonResolutionLayer as a scheduled service, distinct from but downstream of the PlayResolutionEngine (Module 23) and upstream of every offseason system. ResolutionRegistry — the list of metrics requiring snapshot-based resolution, extensible by future modules rather than hardcoded to the four founding members.

Dependencies: Module 4 (Owner Trust), Module 8 (Hot Seat), Module 11 (Front Office Reputation), Module 21 (Fan Loyalty) — the four founding registrants; Module 2.13 (Event Bus) — delivery mechanism; Module 3/23 — defines the season-loop seam this layer occupies.

MODULE 3: LEAGUE STRUCTURE

[v1.5, Course Correction — league shape formally changed from 4 divisions of 4 to 3 divisions of 6-5-5 per explicit project-owner directive. This is a structural design decision, not a silent fix — see 3.1a for the full reasoning and consequences, worked through rather than glossed over. Module 3.4's own v3.1 note already predicted this exact reckoning would eventually be needed once the schedule generator's divisibility assumption was tested against something other than 4-of-4.]

3.1 Design Layer

League shape: 32 franchises at launch, 2 conferences of 16, 3 divisions per conference. League Structure remains almost entirely a world-simulation layer — the player experiences its outputs (schedule, standings, playoff picture) but doesn't directly control division assignment, game count, or format at the individual-franchise level. Governance-level changes (realignment, expansion) route through Module 4's Board of Governors mechanic.

3.1a The Division Math, Resolved Explicitly (Not Silently)

16 does not divide evenly by 3. 16 ÷ 3 = 5.33. Rather than silently reverting to 4 divisions of 4 (which the directive explicitly forbids) or padding/cutting the league to a number that divides more cleanly, the resolution is to accept genuine division-size asymmetry and design its consequences deliberately.

Chosen partition: 6-5-5. Among all integer partitions of 16 into 3 parts (6-5-5, 6-6-4, 7-5-4, 8-4-4, 7-6-3), 6-5-5 minimizes the size spread (max−min = 1), which is the cleanest available alignment by construction, not by preference. Both conferences use the identical 6-5-5 shape, for structural symmetry across the league — a conference with a 7-5-4 split while the other ran 6-5-5 would introduce a second, unnecessary asymmetry on top of the one already being accepted.

Consequence 1 — Scheduling. Division games remain full home-and-away round robin regardless of division size, per Module 2.8's existing rule-symmetry/condition-asymmetry philosophy: the rule ("play every division rival twice") is identical for every team; the number of games that rule produces legitimately differs by division size, exactly the same shape of asymmetry the Bible already accepts for market tiers and expansion timing.

• 6-team division: 5 rivals × 2 = 10 division games
• 5-team division: 4 rivals × 2 = 8 division games

To hold every team's total at 17 games, non-division slots flex to absorb the difference (division-size teams get fewer rotation games; smaller-division teams get more) rather than changing the standings-based and neutral-site categories, which stay constant as pure parity/flavor mechanisms unrelated to division size:

6-team division: 10 division + 2 same-conf rotation + 2 cross-conf rotation
                 + 2 standings-based + 1 neutral-site = 17
5-team division: 8 division + 3 same-conf rotation + 3 cross-conf rotation
                 + 2 standings-based + 1 neutral-site = 17

Consequence 2 — Playoff qualification. The existing 7-seed-per-conference bracket (Module 3.1, unchanged) now seats 3 division winners (auto-bids, seeded 1–3 by record) plus 4 wild cards (seeded 4–7), rather than 4-plus-3. The bracket mechanics themselves (top seed byes, 2v7/3v6/4v5 in the opening round) are entirely unaffected — only how the 7 seeds get populated changes.

Consequence 3 — Competitive fairness, stated honestly rather than minimized. A 6-team division is a genuinely harder road to a division title than a 5-team division: one more legitimate rival competing for the same single auto-bid, and two extra guaranteed-tough divisional games eating into schedule variety. This is a real, felt asymmetry, not a rounding error — and it is not hidden behind a euphemism. It's accepted under the same philosophy that already governs market-tier disparity: identical rules, honestly different conditions.

Consequence 4 — Rivalries. A 6-team division supports 15 possible division rivalry pairs (combinatorial: C(6,2)) versus a 5-team division's 10 (C(5,2)) — meaningfully more organic rivalry texture in the larger division, a minor but real emergent difference Module 22's Rivalry Score system will simply reflect, not something requiring correction.

Consequence 5 — Long-term realignment gets a new, explicit job. Module 3's existing realignment mechanism (Board vote, every 10–15 seasons) now also periodically decides which division within each conference carries the sixth team, rotating that burden over the long run rather than letting one division permanently carry the harder road for the life of the league. This is a genuine new use for an already-existing mechanism, not a new one invented to patch the problem — and it directly serves Commitments Ledger C7's decades-scale freshness goal in a way the original evenly-divided structure never needed to.

Regular season, restated for the record: 17 games total per team, composition varying by division size as specified above.

Draft order: unchanged — inverse standings with strength-of-schedule tiebreaker, weighted lottery among the bottom 14 non-playoff teams. Division size does not affect draft order mechanics.

Long-horizon freshness mechanisms: unchanged in kind, expanded in scope per Consequence 5 above — realignment now also rotates division-size burden; expansion remains capped and logged to Module 26 as before.

Expansion ceiling (unchanged from v3.1): total league size capped (provisional default 40, pending Module 33). New note: any future expansion must specify which conference and which division absorbs the new franchise, and whether it changes that conference's 6-5-5 shape (e.g., to 6-6-5 at 17 teams) — this is now a required field on any future ExpansionEvent, not an afterthought.

3.2 Systems Layer

DIVISION_STRUCTURE (v1.5, replaces the prior fixed 4-of-4 assumption):
  per_conference: 3 divisions, sizes [6, 5, 5] — fixed shape, rotatable membership
    via realignment (3.1a, Consequence 5)
  both conferences use the identical [6,5,5] shape — no cross-conference asymmetry
    layered on top of the accepted intra-league one

SCHEDULE GENERATION (per season, v1.5):
  division_games = round_robin(own_division, home_and_away)  → 10 games (6-team
    division) OR 8 games (5-team division) — SIZE-DEPENDENT, not a constant
  same_conf_rotation = fixed_division(same_conf, 3yr_cycle)   → 2 games (6-team
    division teams) OR 3 games (5-team division teams)
  cross_conf_rotation = fixed_division(other_conf, 4yr_cycle)  → 2 games (6-team) OR
    3 games (5-team)
  standings_games = match_by_prior_finish(same_conf, non_division) → 2 games,
    CONSTANT regardless of division size
  neutral_site_game = rotating_assignment(all_teams, multi_yr_cycle) → 1 game,
    CONSTANT regardless of division size
  TOTAL = 17 games/team for every team, by construction — the RULE is symmetric
    (every team's schedule is generated by the identical function), the COMPOSITION
    is not (Module 2.8 compliance)

PLAYOFF SEEDING (v1.5, replaces 4-auto/3-wildcard):
  3 division winners → seeds 1-3, ordered by record
  4 wild cards → seeds 4-7, ordered by record among non-division-winners
  bracket mechanics unchanged: seed 1 byes, 2v7/3v6/4v5 opening round

DRAFT ORDER: unchanged from v3.1, no division-size dependency

REALIGNMENT TRIGGER (v1.5, expanded scope):
  eligible_check = every 10-15 seasons (config), requires Board vote (Module 4) with
    supermajority (75%+) to pass
  NEW: realignment votes may now include a division-size-rotation proposal —
    which division within a conference carries the 6th team for the next cycle —
    logged to Module 26 exactly like a geographic realignment would be
EXPANSION TRIGGER: unchanged from v3.1, with the new required field noted in 3.1a

3.3 Stress Test

Can players exploit this? Unchanged tanking-lottery analysis from v3.1 — division size doesn't create a new exploit surface here. New check specific to this change: could a player game which division they're placed in (at franchise creation or via realignment lobbying) to sit in the easier 5-team division permanently? Realignment votes require Board supermajority (75%+, unchanged) — a single franchise, human or AI, cannot unilaterally secure or avoid the 6-team division; this is a league-wide governance decision, not an individual franchise's lever, which is the direct guard against this exploit.

Will AI break this? AI franchises experience the identical division-size asymmetry and must value/vote on realignment proposals under the same rules — no AI-specific carve-out for which division an AI-controlled franchise sits in.

Will this stay interesting after 40 seasons? Consequence 5's division-size rotation is a genuinely new, additive answer to Commitments Ledger C7 beyond what the original evenly-divided structure offered — a decades-long question of "whose turn is it to carry the tougher division" is real texture the 4-of-4 structure never had to generate.

Does this respect Invariant 1 (Uniform Cap Law) and the broader "same rules for everyone" standard? Yes, explicitly checked: every formula above is a single function applied identically to every team; division size is an input to that function (like market tier already is elsewhere in the Bible), not an exception to it. This is the same category of asymmetry the Bible already tolerates, applied to a new dimension.

Reuse potential: unchanged from v3.1 — the underlying scheduling/standings/playoff-format pattern remains a plausible Legend Engine candidate; this module's specific 6-5-5 resolution is football-Gridiron-specific and would not itself transfer, only the general "handle uneven division sizes honestly rather than forcing even ones" principle would.

3.4 Implementation Notes

• League, Conference, Division objects — Division now carries a size field (6 or 5) rather than assuming a constant, with membership rotatable via realignment.
• ScheduleGenerator service — the divisibility concern flagged in v3.1 is now the module's live, resolved behavior, not a future risk. The service must branch its rotation-game-count logic on division size (2/2 for 6-team-division teams, 3/3 for 5-team-division teams) while keeping standings-based and neutral-site games constant — this is a real, non-trivial change to the service's internal logic, not a config-value tweak.
• StandingsTable, DraftOrderCalculator — unaffected by division-size changes, confirmed.
• PlayoffSeedingCalculator — updated for 3-auto/4-wildcard instead of 4-auto/3-wildcard.
• RealignmentEvent — extended with an optional division_size_rotation field per Consequence 5.

3.5 Dependencies

(Module 1 and 2 excluded per standing rule.)

• Module 4 (Franchise Ownership) — Board of Governors gates both geographic and division-size realignment now.
• Module 13 (Draft System) — unaffected consumer of draft order output.
• Module 22 (Rivalries) — division-size asymmetry (Consequence 4) directly affects rivalry-pair density per division.
• Module 26 (Dynamic League History) — logs division-size rotation events alongside geographic realignment.
• Module 32 (Anti-Exploitation Systems) — unaffected; tanking deterrence logic doesn't interact with division size.

3.6 Version History

MODULE 4: FRANCHISE OWNERSHIP

4.1 Design Layer

This module mechanizes the Owner-GM fusion established in Module 1.3, and is the module that formally discharges Commitments Ledger C8 by defining what "recoverable" actually means at the franchise level.

Ownership archetypes, selected or generated at franchise start, each with different Owner Trust dynamics (see 4.2):

• Legacy Family Ownership — higher Owner Trust floor (patient), lower spending-aggression ceiling (conservative financial risk tolerance).
• Corporate/Group Ownership — higher spending ceiling, faster Owner Trust decay under sustained losing (results-oriented), prioritizes Franchise Valuation growth (ties Module 29) as an explicit success metric alongside wins.
• Self-Made Owner — the player's custom origin option: balanced trust dynamics, narrative flavor tied to the player's own founding story (useful for Legacy System framing in Module 28).

Owner Trust is a persistent score (0–100) that functions as the franchise's core health meter, distinct from cap health or fan approval (though it's influenced by both). Inputs: on-field competitiveness relative to preseason market expectations, financial health (Module 5's NOI), fan approval (Module 21), and decision consistency — a whiplash penalty for erratic Strategic-tier reversals (e.g., declaring a rebuild, then panic-spending into win-now mode the same offseason, then reversing again). This directly operationalizes Module 2's path-dependency requirement at the franchise-identity level: consistent strategic identity is mechanically rewarded, thrashing is mechanically punished.

Governance: all 32 owners (player included) sit on a Board of Governors that votes on realignment (Module 3), expansion (Module 3), and league rule changes (a mechanism this module owns for the first time and hands off to Module 5/6 whenever revenue-share or cap-percentage rule changes are proposed — this is a second concrete discharge point for Commitments Ledger C3, alongside Module 5/6's media-rights cycle).

Succession: at any point past a defined minimum tenure, the player may designate an heir (family member or hand-picked successor) and formally "pass the torch," which does not end the save — it's a Legacy System event (Module 28) that lets a 25–50 season save continue across a nominal in-fiction generational transition without forcing retirement or a hard stop.

4.2 Systems Layer: Owner Trust and the Crisis/Ruin Instantiation

This is the first full instantiation of Module 2.7's generic RiskState template, and directly discharges Commitments Ledger C8 and C9.

OwnerTrust: RiskState instance
  severity_score = f(trust_decline_rate, financial_insolvency_proximity, whiplash_count)
  current_state = Stable | Crisis | Ruin

  CRISIS trigger: OwnerTrust < 35 (config, subject to Module 33 balancing) sustained for
    2+ consecutive seasons, OR a single-season insolvency event from Module 5

  Mitigation Actions (must each cost more in expectation than the trust decline they
    address, per Commitments Ledger C10):
    - Sustained competitive performance (multi-season, Strategic-tier commitment)
    - Financial stabilization plan (voluntary owner capital infusion — reduces future
      spending flexibility, i.e., borrows against the franchise's own future, not free)
    - Fan engagement investment (Module 21 tie-in — costs real marketing/facility budget,
      Module 5)

  Time-to-Ruin estimate: exposed to player once in Crisis state, calculated from current
    severity trend — never less than 2 full seasons of visible warning before Ruin is
    reachable (hard floor, per Invariant 10)

  RUIN outcomes (terminal for the franchise-as-currently-constituted, NOT for the save):
    - Forced sale: new AI ownership group takes over; player either starts a new
      franchise arc (fresh Owner Trust, same league) or, in multi-franchise contexts,
      continues elsewhere
    - Forced relocation: market change, new identity, Fan Loyalty reset per Module 21,
      but roster/cap/draft-capital state carries forward — this is a franchise-identity
      Ruin, not a total-loss Ruin

4.3 Stress Test

Can players exploit this? The clearest risk: could a player game Owner Trust cheaply via minimal "checkbox" fan-engagement spending rather than genuine investment? Mitigation Action costs must scale with current severity (a Trust score of 20 requires a much larger stabilization spend than a Trust score of 40), which prevents cheap top-offs and enforces Commitments Ledger C10 concretely for the first time in a shipped system.

Can AI exploit this — or rather, will AI break this? AI-owned franchises must run identical Owner Trust math, including the possibility of AI franchises hitting Ruin and being sold or relocated. This is explicitly a feature, not a bug to be quietly suppressed for AI — a rival franchise relocating mid-save is exactly the kind of emergent, decades-spanning narrative texture Module 25 (Story Engine) should be built to surface (Invariant 2 compliance).

Will this stay interesting after 40 seasons? Yes, conditionally — the succession mechanic (4.1) is what prevents the "owner's career" from becoming a soft ceiling on save length. Flagging that Module 28 (Legacy System) needs to treat succession as a meaningful milestone with its own scoring, not just a re-skin, or this feature will feel like flavor text rather than a real structural answer to the 25–50 season problem.

Reuse potential: 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. Strong Legend Engine candidate — flagging, deferring.

4.4 Implementation Notes

• Owner object (archetype, trust-dynamics config, tenure length, succession-eligibility flag).
• OwnerTrust as a concrete instance of the Module 2.7 RiskState object — first real proof that the generic template holds up under a specific system's requirements.
• BoardOfGovernors voting object (one vote per CURRENT franchise — dynamically tracks total_franchise_count, no longer a fixed 32; see Module 3.1's Finding 7 fix — supermajority thresholds configurable per vote type — realignment vs. expansion vs. rule change may need different thresholds, flagging for Module 33 to tune rather than hardcoding here).
• SuccessionEvent object, consumed by Module 28.

4.5 Dependencies

• Module 3 — Board of Governors votes gate League Structure changes.
• Module 5, 6 — financial health and cap-percentage rule changes feed/are-fed-by Owner Trust and governance.
• Module 21 (Fan Loyalty) — feeds Owner Trust; is reset on forced relocation.
• Module 24 (AI Decision Logic) — AI ownership behavior must run identical Owner Trust logic.
• Module 25 (Story Engine) — should treat Ruin-state events (sale/relocation) as first-class narrative material.
• Module 28 (Legacy System) — owns scoring/meaning of the succession mechanic.
• Module 29 (Franchise Valuation) — Corporate/Group ownership's valuation-growth priority ties directly here.

4.6 Version History

MODULE 5: FINANCIAL SYSTEM

5.1 Design Layer

This module is the mechanical backbone of Invariant 5 (Traceable Economy) — every dollar in every other system (cap, contracts, buyouts, scouting budgets, facilities) must ultimately trace back to a revenue or expense line defined here.

Revenue streams:

• Local Gate Revenue — attendance × ticket price × market-tier multiplier (Module 3/19 tie-in: market tier is a property of the franchise's city, set at league structure/expansion time).
• Local Sponsorship — scales with market tier and recent win history (a winning small-market team earns real sponsorship upside, preventing market tier from being pure destiny).
• National Media Revenue — split equally across all 32 franchises regardless of market or performance (this is deliberate: it's the league's primary parity mechanism and the direct funding source for the salary cap in Module 6). Grows via a periodic media rights renegotiation cycle (~every 8–10 seasons), which is this module's first concrete discharge of Commitments Ledger C3 — a real, telegraphed, in-fiction economic event (broadcast deal news, a Story Engine hook per Module 25) rather than an arbitrary number bump.
• Merchandising — scales with Fan Loyalty (Module 21) and roster star power.
• Stadium Ancillary Revenue — luxury boxes, concessions, naming rights (Module 19 tie-in).

Expenses: payroll (cap-bound, but tracked here as real cash flow distinct from cap accounting — dead cap is money already spent, not a future liability), staff salaries (Modules 8–12), facility operating costs, stadium debt service (Module 19), and a league revenue-sharing contribution/receipt (large-market teams contribute a portion of local revenue to a pool redistributed to small-market teams — the direct mechanical expression of Module 2.8's rule-symmetry/condition-asymmetry philosophy: everyone plays by the same revenue-sharing formula, but market size still produces real, felt strategic asymmetry).

Net Operating Income (NOI) feeds Owner Trust's financial component (Module 4) and opens a genuine Strategic Decision: reinvest profit into facilities/scouting (long-horizon competitive investment) vs. bank it (financial-stability hedge, relevant to smaller-market or Legacy Family ownership archetypes).

5.2 Systems Layer

LOCAL_REVENUE = (avg_attendance × ticket_price × market_tier_multiplier)
              + (sponsorship_base × market_tier_multiplier × win_history_factor)
              + stadium_ancillary_revenue

NATIONAL_REVENUE = league_media_pool / CURRENT_FRANCHISE_COUNT   [identical for all
                                              franchises at any point in league history;
                                              CURRENT_FRANCHISE_COUNT updates only at
                                              expansion/relocation events, never
                                              mid-season — v5.1, Finding 7 fix, was
                                              hardcoded /32]

MERCH_REVENUE = merch_base × fan_loyalty_index × roster_star_power_index

TOTAL_REVENUE = LOCAL_REVENUE + NATIONAL_REVENUE + MERCH_REVENUE

REVENUE_SHARING_ADJUSTMENT:
  if LOCAL_REVENUE > league_avg_local_revenue × threshold:
     contribute (LOCAL_REVENUE - threshold_value) × share_rate  → pool
  if LOCAL_REVENUE < league_avg_local_revenue × threshold:
     receive from pool, capped at a defined ceiling per team per season

TOTAL_EXPENSES = payroll_cash_outlay + staff_salaries + facility_opex
              + stadium_debt_service + travel_ops (abstracted flat line per 2.4)

NOI = TOTAL_REVENUE - TOTAL_EXPENSES + REVENUE_SHARING_ADJUSTMENT

MEDIA_RIGHTS_CYCLE: every 8-10 seasons (config), league_media_pool undergoes a stepped
  growth event with variance (Invariant 7: influenced, not dictated — growth magnitude
  has a randomized-but-bounded range, telegraphed one offseason in advance as a Story
  Engine event per Module 25)

5.3 Stress Test

Can players exploit this? The clearest tension: a player could minimize spending to bank NOI while fielding an uncompetitive roster — this is a legitimate small-market rebuild strategy, not an exploit, but it must not be a free lunch. Owner Trust's competitiveness-vs-expectation input (Module 4) is the check: sustained profit-hoarding without competitive results eventually triggers an Owner Trust Crisis regardless of financial health, which is the intended tension, not a bug to close.

Will AI break this? AI franchises must spend according to the same NOI-driven logic — an AI GM overspending beyond sustainable NOI must face the same future-season consequences (cap crisis, Owner Trust decline) a human would, not be quietly bailed out by hidden league subsidies (Invariant 2).

Will this stay interesting after 40 seasons? The media rights cycle is the primary answer — periodic, telegraphed, in-fiction economic growth (and rare contraction) events keep the financial backdrop from feeling static across decades, and directly feed Module 6's organic cap growth.

Reuse potential: market-tier/revenue-sharing framework is a plausible Legend Engine candidate (any franchise sim needs this shape of system) — flagged, deferred.

5.4 Implementation Notes

• FinancialLedger object per franchise (revenue line items, expense line items, NOI rollup, historical record for trend analysis).
• MarketTier config table (5 tiers recommended, tied to franchise city at creation/relocation/expansion time — Module 3/4/19 all read from this).
• MediaRightsCycle as a global league-level scheduled event, not a per-franchise object.
• RevenueSharingCalculator service run once per offseason across all 32 franchises simultaneously (parity requirement, same reasoning as Module 3's ScheduleGenerator).

5.5 Dependencies

• Module 3 — market tiers are a property of franchise location, set at structural events.
• Module 4 — NOI feeds Owner Trust; revenue-share/cap-percentage rule changes route through Board of Governors.
• Module 6 — cap is calculated directly from this module's league_media_pool.
• Module 19 (Stadium) — stadium ancillary revenue and debt service.
• Module 21 (Fan Loyalty) — feeds merch revenue and attendance.
• Module 25 (Story Engine) — media rights cycle events are narrative hooks.

5.6 Version History

MODULE 6: SALARY CAP

6.1 Design Layer

The cap is not a fixed number — it is a fixed percentage of the prior season's total league revenue (Module 5's league_media_pool-driven figure, roughly mirroring real-world cap-to-revenue ratios), recalculated annually with a collar to prevent destabilizing swings. This organic linkage is what keeps the cap — and by extension every roster-building strategy built around it — from calcifying into a static, fully-solved number across a 25–50 season save, directly extending Module 5's discharge of Commitments Ledger C3.

Cap accounting includes signing bonus proration (capped at a defined max number of years), dead cap on cuts and trades, and cap-space rollover between seasons (unused space carries forward, rewarding disciplined long-horizon planning — a direct Module 2.2 "path dependency" mechanic).

Franchise Tags and RFA tenders are retention tools that sit outside normal negotiation (Module 7) — a Tactical-tier lever with real Strategic-tier ripple effects (using a tag telegraphs organizational priorities and burns a scarce annual resource).

This module is the first concrete instantiation of the Crisis/Ruin RiskState template that directly discharges Commitments Ledger C9: a Cap Crisis triggers on sustained negative cap space, with Mitigation Actions (restructures, cuts, trades, mutual retirement accords) that must, per Commitments Ledger C10, always cost more in expectation than the crisis they resolve — restructuring borrows cap space from the future, it doesn't erase the obligation.

6.2 Systems Layer

CAP(season t+1) = CAP(season t) adjusted toward [ league_media_pool(t) × CAP_PERCENTAGE ]
                   with a year-over-year collar of ±10% (config, Module 33 to tune)

SIGNING_BONUS_PRORATION: bonus_amount / min(contract_years, MAX_PRORATION_YEARS)
  [MAX_PRORATION_YEARS recommended = 5, mirroring realistic cap-management depth]

DEAD_CAP (on cut/trade):
  standard_designation: all remaining prorated bonus accelerates into current season
  deferred_designation: remaining prorated bonus splits across current + next season
    (limited-use tool, available only within a defined roster-move window per season)

CAP_ROLLOVER: unused_cap_space(t) carries fully into available_cap(t+1)

RESTRUCTURE:
  converts base_salary → signing_bonus (re-proration across remaining contract years,
  bounded by MAX_PRORATION_YEARS)
  HARD LIMIT: max 2 restructures per contract (prevents infinite can-kicking, direct
    response to the exploit named in Module 2's stress test and reaffirmed in 6.3 below)
  effect: frees current-season cap space, INCREASES future dead-cap exposure — always a
    net-negative-expectation trade against future flexibility (satisfies C10)

CapLedger: RiskState instance
  severity_score = f(magnitude_of_negative_cap_space, duration_of_crisis,
                      count_of_available_mitigations_already_exhausted)
  CRISIS trigger: projected_cap_space < 0 for the upcoming league year with no immediately
    available Top-51/53-man compliance path
  RUIN (rare, severe): only reachable after 2+ full seasons of unresolved Crisis with
    Strategic-tier mitigation opportunities visibly available and declined — outcome is a
    multi-season league-mandated cap-ceiling reduction for that franchise, not
    save-ending (Invariant 10 compliance)

6.3 Stress Test

Can players exploit this? Yes, and this is the most important finding in this batch of modules: unlimited restructuring would let a player defer cap consequences indefinitely, effectively defeating the entire Crisis/Ruin system this module exists to instantiate. The hard 2-restructure-per-contract limit (6.2) is a direct, load-bearing fix — without it, Module 2's exploit warning (2.9: "Mitigation Actions must always cost more than the crisis") would be violated in practice even though it's satisfied in formula, because infinite restructures let a player never actually pay the accumulating cost within a single contract's life. Flagging this as the single most important guardrail in Modules 3–10 so far.

Will AI break this? AI franchises must use the identical restructure/cut/tag logic, including hitting the same 2-restructure hard limit, and must be capable of making cap mistakes — a poorly-run AI franchise should be able to genuinely mismanage its cap into Crisis, with variance tied to that AI's GM-competence tier (Module 24). If AI cap management is artificially clean, the league-wide texture of good and bad front offices (a major source of long-horizon narrative, Module 25/26) disappears.

Will this stay interesting after 40 seasons? The organic revenue-linked cap growth (6.1) is the direct answer — a cap number that grows unpredictably-but-boundedly with the league's simulated economic history keeps "what's a good contract" a moving target across decades rather than a value a player memorizes in year 3 and never reconsiders.

6.4 Implementation Notes

• CapLedger object per franchise, extending the Module 2.7 RiskState pattern with cap-specific fields (restructure_count per contract, dead_cap_by_season[]).
• ProrationEngine service (signing bonus + restructure proration math, shared logic).
• DeadCapCalculator (standard vs. deferred designation).
• CapGrowthCalculator — global, run once per offseason from Module 5's league_media_pool, feeding all 32 CapLedger instances identically (Invariant 1 compliance).

6.5 Dependencies

• Module 5 — cap percentage is calculated directly from league revenue.
• Module 7 (Player Contracts) — contract structures are the direct input to every cap calculation here.
• Module 2 — direct RiskState template instantiation.
• Module 24 — AI cap-management competence variance.

6.6 Version History

MODULE 7: PLAYER CONTRACTS

7.1 Design Layer

Every contract — player-negotiated or AI-negotiated — runs through one unified Negotiation Engine (Invariant 4). Contract components: base salary, signing bonus (Module 6 proration), guarantees (full, injury-only, or vesting — a guarantee that locks in on a future date, which creates a genuine annual Strategic Decision: cut before the vest date or commit further), incentives (performance-triggered, converting to real future cap cost when hit — never a free lever), and void years (a pure cap-management tool with no on-field meaning).

Negotiation inputs: Player Value Score (on-field production + age/potential curve from Module 15 + positional scarcity, which shifts dynamically league-wide as archetypes rise and fall in supply — a direct anti-solved-strategy mechanism per Module 1 Failure Mode A/B), Team Leverage (cap space, competing offers — simulated for AI teams too, not just the player), and a Player Priorities Profile — a weighted mix of money-maximizing, role/usage-maximizing, contender-proximity, and loyalty/relationship score built with the current front office over multiple seasons. This last factor is what lets long-tenured GM relationships matter mechanically, not just narratively.

Rookie contracts are slot-based off draft position (Module 13) — largely non-negotiable on base terms, which keeps early-career team-building legible, with escalators/options providing limited Tactical-tier decision space.

Dissatisfaction: when a player's Priorities Profile is chronically mismatched with their actual situation across consecutive seasons, dissatisfaction accrues, eventually producing trade requests or performance drag — a Tactical-tier consequence flowing from a Strategic-tier roster-construction pattern (Module 2.2 path dependency in action).

7.2 Systems Layer

PLAYER_VALUE_SCORE = f(on_field_production, age_curve_position [Module 15],
                        positional_scarcity_index [league-wide, recalculated per offseason])

MARKET_COMPARABLE_INDEX: recalculated every offseason from the prior 1-2 seasons' actual
  signings league-wide — this is what prevents contract "solved values" from calcifying
  across a 25+ season save (direct Failure Mode A mitigation)

PLAYER_MINIMUM_ACCEPTABLE_VALUE = PLAYER_VALUE_SCORE × priorities_weighting_vector
                                   × market_comparable_adjustment

NEGOTIATION_RESOLUTION: counter-offer loop
  acceptance_probability = f(offer_value - player_minimum_acceptable_value,
                              team_leverage, relationship_score)
  loop terminates on acceptance, walk-away (player signs elsewhere/holds out), or a
  defined max-rounds limit

DISSATISFACTION_METER (per player, per season):
  accrues when (actual_situation - priorities_profile_fit) stays negative for 2+
    consecutive seasons
  consequences at threshold: trade request (Tactical) → performance drag (small,
    bounded — never a "player sandbags the whole season" outcome, per Invariant 7's
    "influences, never dictates")

VOID_YEARS (v7.1, Resolution Report Finding 1 — Contradiction): HARD LIMIT of 2 void
  years per contract, mirroring Module 6's restructure limit — same category of
  artificial cap-deferral tool, same Commitments Ledger C13 structural-limit
  requirement applies. Dead cap from void years accelerates into the first season
  following contract expiration exactly as a standard-designation cut would
  (Module 6.2), closing the deferral-chain gap unlimited void years would otherwise
  create alongside the already-limited restructure mechanism.

7.3 Stress Test

Can players exploit this? Yes — repeatedly signing incentive-laden "prove-it" deals to acquire undervalued talent with minimal guaranteed downside risks becoming a dominant strategy with no real cost. Two fixes: (1) incentives that get triggered convert to real future cap charges, not free upside, and (2) repeated lowball/incentive-heavy tactics against the market should accrue a Front Office Reputation cost — agents and players remember a team that consistently underpays relative to production, raising future player_minimum_acceptable_value against that specific franchise. This is a new concept this module needs but doesn't fully own — flagging as a new Commitments Ledger item owed by Module 11 (Front Office), since organizational reputation is a front-office-level system, not a per-contract one.

Will AI break this? AI GMs must run the identical Negotiation Engine, including making real valuation mistakes proportional to their competence tier (Module 24) — an AI that consistently overpays or underpays should feel like a distinct front-office identity, not a uniform bot.

Will this stay interesting after 40 seasons? The Market Comparable Index recalculating from actual in-sim signings each offseason is the direct mechanism — combined with the positional scarcity index shifting as archetypes rise and fall (Module 10/13/14's job to feed that variance), "what's a fair contract" should never fully stabilize.

7.4 Implementation Notes

• Contract object (base salary, prorated bonus reference to Module 6's ProrationEngine, guarantee type/vest date, incentive triggers, void years).
• NegotiationEngine service (counter-offer loop as a pure function of the inputs above).
• PlayerPrioritiesProfile object per player (weighted vector, evolves slowly over a career based on experience — e.g., young players skew money/role, veterans skew contender-proximity).
• MarketComparableIndex — global, recalculated once per offseason.
• DissatisfactionMeter per player.

7.5 Dependencies

• Module 6 — cap consumes contract structure directly.
• Module 13 (Draft) — rookie scale contracts.
• Module 15 (Player Development) — feeds Player Value Score.
• Module 11 (Front Office) — owes the new Front Office Reputation concept surfaced in this module's stress test (see Commitments Ledger C12 below).
• Module 24 — AI negotiation competence variance.

7.6 Version History

MODULE 8: COACHES

8.1 Design Layer

Head Coach attributes: Scheme Identity (an offensive archetype × defensive archetype pairing — e.g., Vertical Passing / Blitz-Heavy, Zone-Run / Read-and-React), Game Management (clock and 4th-down decision quality, a direct input to Module 23's simulation engine), Player Development Multiplier (affects Module 15 growth rates for scheme-fit players specifically, not uniformly), Culture/Discipline (affects Dissatisfaction decay rate and practice-intensity-driven injury risk, Module 18 tie-in), and In-Game Adjustment Rating (halftime/game-flow adaptation quality, another Module 23 input).

Coaching Tree: every HC accumulates a lineage of coordinators who served under them (Module 9 feeds this directly), which becomes long-horizon material for Hall of Fame and Legacy scoring (Modules 26–28) — this gives a player a real reason to develop staff, not just win with them.

Hot Seat: HC job security is tied to Owner Trust trajectory (Module 4) and Fan Loyalty (Module 21) and the multi-season gap between performance and market expectation. This is the module's RiskState instantiation: Crisis = hot seat with visible severity and mitigation paths (sustained improved performance, culture wins), Ruin = termination, which carries a real buyout cost (remaining guaranteed salary, a direct Module 5 cash-flow hit) — firing a bad-fit but expensive coach is a genuine cost-benefit Strategic Decision, never free.

Hiring market: candidates come from internal coordinator promotion (Module 9) or external hire (retreads with a known track record and baggage, or first-time HCs with higher variance and unknown ceiling — a direct Invariant 7 application: real uncertainty at decision time).

Scheme Fit: the roster's positional/skill profile is scored against the HC's Scheme Identity, producing a Fit multiplier on player performance output (Module 23 input). This makes drafting or signing players who don't fit the current scheme a real, costly mistake — a concrete, high-stakes proof point for Module 2.2's "meaningful decision" criteria.

8.2 Systems Layer

FIT_SCORE = cosine_similarity(roster_archetype_distribution_vector, scheme_requirement_vector)
  → applied as a bounded multiplier on relevant player performance outputs in Module 23

HOT_SEAT: RiskState instance
  severity_score = f(performance_vs_expectation_gap over N seasons, OwnerTrust_trend,
                      FanLoyalty_trend)
  CRISIS trigger: severity exceeds threshold for 2+ consecutive seasons
  RUIN (termination): triggers BUYOUT_COST = remaining_guaranteed_salary × discount_factor
    (paid from Module 5's FinancialLedger, real cash impact — NOT a free roster-management
    action)

ORGANIZATIONAL_INSTABILITY (new mechanic, surfaced in stress test 8.3):
  triggered by: 2+ HC changes within a rolling 3-season window
  effect: temporary (1-2 season) penalty to roster Fit Score and Module 15 development
    multipliers — represents real institutional churn cost, not just cash cost

8.3 Stress Test

Can players exploit this? Yes: without a deterrent, a player could cycle through cheap, short-term-contract coaches to chase optimal scheme-fit matchups every season or two, since low guaranteed salary keeps buyout cost trivial. The Organizational Instability mechanic above is a direct, newly-introduced fix — frequent coaching changes cost roster performance and development, not just cash, which makes coaching stability a real strategic value independent of buyout economics.

Will AI break this? AI franchises must hire and fire under the identical Hot Seat RiskState logic, including paying real buyout costs and incurring Organizational Instability penalties for churn — this is what gives the league-wide coaching carousel (Module 26) real texture rather than a uniform AI behavior pattern.

Will this stay interesting after 40 seasons? The Coaching Tree/lineage system is the direct payoff mechanism — legendary coaches producing identifiable "coaching families" that persist and get referenced for decades is one of the strongest concrete answers to Commitments Ledger C7 produced so far.

8.4 Implementation Notes

• HeadCoach object (Scheme Identity vector, attribute set, contract reference to Module 7's Contract object).
• FitScoreCalculator service.
• HotSeat as a RiskState instance per HC.
• CoachingTree graph structure (nodes = coaches, edges = mentor/mentee relationships via coordinator tenure).
• HiringMarket candidate-pool generator, fed by Module 9's coordinator promotion pipeline.
• OrganizationalInstability modifier object, temporary and time-decayed.

8.5 Dependencies

• Module 4 — Owner Trust feeds Hot Seat.
• Module 5/6 — buyout cash cost.
• Module 9 — coordinator promotion pipeline is the primary hiring-market feed.
• Module 23 — Scheme Fit and Game Management are direct simulation inputs.
• Module 21 — Fan Loyalty feeds Hot Seat.
• Modules 26/27/28 — Coaching Tree feeds league history, Hall of Fame, and Legacy scoring.

8.6 Version History

MODULE 9: COORDINATORS

9.1 Design Layer

OC/DC/ST each carry a Scheme Sub-Identity that must be compatible — or creates friction — with the HC's overall Scheme Identity (Module 8). A Synergy Score captures this compatibility and affects the team's performance ceiling.

Coordinator Autonomy Slider — an HC-level decision (itself a Tactical-tier call within the HC's Strategic scheme identity) governing how much play-calling and scheme control is delegated to each coordinator. This is the first concrete, staff-level proof point for Module 2.3's Decision Taxonomy and directly informs Module 11's delegation framework: full autonomy weights the coordinator's own attributes more heavily in Module 23's simulation, and — critically — autonomy reps are how coordinators develop toward HC-readiness. This creates a genuine trade-off: maximize current-season control by keeping a coordinator on a short leash, or invest in their growth (and future trade/promotion value) by delegating real authority.

Player Development Specialty: certain coordinators (QB-focused OCs, DB-focused DCs) carry bonus development multipliers for specific position groups (Module 15 tie-in) — the mechanical basis for the "QB Whisperer" archetype fantasy.

Career progression and poaching: successful coordinators become external HC candidates for other franchises, feeding Module 8's hiring market directly. Rival teams (AI or player) can request permission to interview a coordinator for an HC vacancy — a real asset-retention decision where losing a great coordinator is a Tactical-tier loss with Strategic-tier ripple effects on team identity and the Coaching Tree.

9.2 Systems Layer

SYNERGY_SCORE = cosine_similarity(HC_scheme_vector, coordinator_scheme_vector)
  → modifies team performance ceiling in Module 23; low synergy is a real, felt cost of
    a scheme-mismatched hire

AUTONOMY_SLIDER (per coordinator, HC-set, 0-100%):
  Module_23_input_weight = blend(HC_attributes, coordinator_attributes, slider_position)
  HC_READINESS_SCORE(coordinator) += f(autonomy_reps_over_time, performance_at_that_
    autonomy_level, scheme_diversity_exposure)
    → gates external hiring-market eligibility (Module 8)

POACHING_REQUEST workflow:
  rival team requests interview permission → current team may block ONLY if no HC-caliber
    contract kicker clause exists (mirrors realistic permission-based systems without
    modeling any specific real-world policy) → interview occurs → hire/no-hire resolves
    through Module 8's hiring market

9.3 Stress Test

Can players exploit this? Keeping a top coordinator permanently at 0% autonomy to suppress their HC-readiness (and thus poaching risk) while still benefiting from their base attributes is a real, discoverable strategy. Rather than patching it away, this is being kept as an intentional design tension: low, prolonged autonomy stalls the coordinator's own growth (smaller future value if you ever do want to promote or trade them) and, per Module 7's Dissatisfaction system, accrues real departure-request risk over many seasons — talent hoarding is self-limiting, not free. Logging this interaction explicitly rather than leaving it as an implicit assumption.

Will AI break this? AI head coaches must use the identical Autonomy Slider mechanic, with realistic variance in default delegation tendency tied to their own attribute/personality profile (Module 24) — some AI HCs should be control-heavy, others should delegate freely, purely from their own generated traits.

Will this stay interesting after 40 seasons? The coordinator pipeline is the primary generator of new HC talent league-wide, which is what keeps the coaching carousel (and Coaching Tree, Module 8) dynamic across decades rather than the same generation of HCs recycling through jobs forever.

9.4 Implementation Notes

• Coordinator object (Scheme Sub-Identity vector, attributes, position-specialty tags).
• SynergyScoreCalculator service.
• AutonomySlider (per-coordinator, HC-mutable).
• HCReadinessScore (accumulator, gates Module 8 hiring-market visibility).
• PoachingRequest workflow object.

9.5 Dependencies

• Module 8 — direct feed into HC hiring market and Coaching Tree.
• Module 7 — Dissatisfaction interaction with prolonged low autonomy.
• Module 11 — this module is the concrete precedent for the broader delegation framework Module 11 must generalize.
• Module 15 — development multipliers.
• Module 23 — simulation input blending.
• Module 24 — AI HC delegation-personality variance.

9.6 Version History

MODULE 10: SCOUTS

10.1 Design Layer

Scouting department structure: a Scouting Director (strategy/budget allocation), Regional Scouts (geographic coverage, tied to Module 14's college talent hotbeds), Position Specialists (national-level, deep expertise in a position group), and Pro Scouts (evaluate other league rosters for trade and free agency targets — distinct from the college/draft pipeline).

Scouting accuracy depends on budget invested (Module 5 tie-in — more budget buys more scouting man-hours and tighter error bars), scout skill (attribute-driven, individually rated, improves with experience), prospect scoutability (some prospects — small-school players, JUCO transfers, unusual athletic profiles — are inherently harder to evaluate, a natural source of bust/gem variance), and time invested (multi-year tracking of underclassmen genuinely improves evaluation quality, creating a real early-investment-vs-certainty trade-off).

Fog of War: every prospect carries a hidden true rating and a visible Scouted Grade with an error band. Scouting investment narrows the error band but — per Invariant 7 — never eliminates it entirely; even a maximally-scouted prospect retains real bust/gem variance, mirroring genuine football uncertainty, while a well-scouted prospect's band is meaningfully tighter than a poorly-scouted one, keeping scouting investment a real, felt lever rather than flavor text.

Regional/Era Expertise: scouts carry specialty tags (region, position type, scheme-fit archetype) that shape which prospects a given organization evaluates well — this is the primary mechanical discharge point for Commitments Ledger C6 (anti-archetype-convergence), since organizational scouting identity plus shifting era-level talent pools keep draft classes texturally distinct across a 25+ season save.

10.2 Systems Layer

SCOUTED_GRADE = TRUE_RATING ± ERROR_BAND

ERROR_BAND = decreasing_function(budget × scout_skill × time_invested / scoutability)
  → asymptotically approaches a nonzero floor, NEVER reaches TRUE_RATING exactly
    (Invariant 7 compliance — even elite scouting retains irreducible uncertainty)
  → diminishing returns above a defined budget threshold (prevents scouting spend from
    being a strictly dominant, no-tradeoff investment relative to Module 19 facilities
    or other Module 5 allocation choices)

REGIONAL_SKEW: scout specialty_tag matching prospect's region/position/archetype
  → modifies effective scout_skill by ±X% for that specific evaluation
  → creates persistent organizational identity (e.g., heavy Southeast-region investment
    produces real, felt outperformance evaluating SEC-heavy draft classes)

10.3 Stress Test

Can players exploit this? Maximizing scouting budget every season regardless of need is the obvious lever to pull — the diminishing-returns curve above (error band reduction flattens well before the floor) is the direct fix, making overspending on scouting a real opportunity cost against Module 19 facility investment or Module 5 profit-banking, not a dominant strategy.

Will AI break this? AI franchises must run the identical Scouted Grade / error-band math, including budget-driven accuracy variance — a well-funded AI franchise should genuinely out-draft a poorly-funded one, exactly as it would for a human GM (Invariant 2).

Will this stay interesting after 40 seasons? This module, more than any other in this batch, is the direct mechanical answer to Failure Mode B (archetype homogenization) from Module 1 — regional/era scouting skew plus organizational specialty identity is what keeps draft classes from converging on a single statistically "optimal" archetype across decades.

10.4 Implementation Notes

• ScoutingDepartment object (Director + roster of Scout objects).
• Scout object (skill rating, specialty tags, experience/growth curve).
• Prospect object (hidden TrueRating field, visible ScoutedGrade, ErrorBand — critical that TrueRating is never exposed to any UI surface, including debug/admin views the player could access, per Invariant 7's spirit).
• BudgetAllocationService (department-level and per-prospect-attention allocation).
• RegionalSkewConfig table.

10.5 Dependencies

• Module 5 — scouting budget is a real cash cost.
• Module 13 (Draft System) — the direct downstream consumer of every ScoutedGrade produced here.
• Module 14 (College Pipeline) — generates the prospect pool this module evaluates.
• Module 24 — AI scouting-investment competence variance.

10.6 Version History

End of Module 10. Modules 3–10 complete — foundation batch ready for Chief Architect Review.

MODULE 11: FRONT OFFICE

[v1.5, v2.0 Design Expansion Pass — full rework per the deeper Front Office specification and the v2.0 Impact Map. Expands from v1.4's 8 executives to 10, splits the original single Director of Player Personnel into three roles with a clear reporting hierarchy, resolves the Module 10 Scouting Director reconciliation flagged in the Impact Map, and adds the previously-missing depth: Responsibilities, Decision Authority, Information Access, Organizational Impact, and explicit Conflict/Cooperation modeling per role. All v1.4 content — the Owner-GM fusion resolution, the shared Executive schema, Front Office Reputation, Organizational Instability, Hiring Scarcity — is retained as the foundation this rework builds on.]

11.1 Design Layer

The Owner-GM fusion resolution from v1.4 is unchanged and restated, not reopened: the player's single-player default remains a fused Owner-GM seat (Module 1.3); hiring a General Manager is an optional delegation path reusing the reserved Owner/GM split (Module 1.9/31). Nothing about this resolution needed revision in this deeper pass.

A second reconciliation, flagged in the v2.0 Impact Map and resolved here: Module 10's existing scouting hierarchy. Module 10 currently has one "Scouting Director" overseeing Regional Scouts, Position Specialists, and Pro Scouts. Splitting Director of Player Personnel into three roles (below) makes that single title ambiguous — the resolution: Module 10's Regional Scouts and Position Specialists now report to Director of College Scouting; Module 10's Pro Scouts now report to Director of Pro Personnel. Module 10's own "Scouting Director" title retires as a distinct role — it was always describing the function these two new Directors now split between them, not a role that needs to keep existing alongside them. Module 10's Systems Layer content (scouting budget allocation, error-band formulas, regional skew) is entirely unaffected; only the organizational reporting line changes.

The front office is now a full organizational chart, ten named roles:

1. Team President — the top hired executive, business-operations authority on the Owner's behalf.
2. General Manager — roster construction, cap philosophy, draft strategy, trade philosophy. The role the player fuses with by default.
3. Assistant General Manager — unchanged from v1.4/original: Tactical-tier delegation only, never Strategic.
4. Director of Player Personnel — reframed in this pass: no longer a parallel evaluation-philosophy role alongside the two roles below, but the organizational-oversight role above both. Sets overall team-building philosophy (Best-Player-Available vs. Need-Based vs. Scheme-Fit-First) that Directors of Pro Personnel and College Scouting execute within, and mediates between them when their recommendations conflict (see Conflict/Cooperation below).
5. Director of Pro Personnel (new) — owns evaluation of other league rosters, absorbing Module 10's existing Pro Scout function. Feeds trade-target (Module 17) and free-agency-target (Module 16) identification directly.
6. Director of College Scouting (new) — owns draft-prospect evaluation, absorbing Module 10's existing Regional Scout and Position Specialist functions. Feeds the Draft System (Module 13) and consumes College Pipeline (Module 14) output directly.
7. Salary Cap Manager — executes Module 6's existing cap mechanics; modulates execution quality, not the underlying formula.
8. Contract Negotiator — executes Module 7's NegotiationEngineService; modulates terms/reputation-cost outcomes, not the underlying formula.
9. Director of Football Analytics (renamed from v1.4's "Director of Analytics," same role) — analytics-adoption philosophy, advisory influence across other executives' decision quality.
10. Football Operations Director (renamed from v1.4's "Director of Football Operations," same role) — liaison to coaching staff; advises on or executes Head Coach hiring/firing on the Owner's behalf.

Every role now specifies four dimensions v1.4 left underspecified — Responsibilities, Decision Authority, Information Access, and Organizational Impact — in addition to the shared schema (Ratings, Experience, Loyalty, Personality, Philosophy, Reputation, Career Progression, Hiring-Market Value, Delegation Scope) v1.4 already established and which remains unchanged in mechanism:

Decision Authority — a three-tier model, not a single "delegable/not" flag:

• Advisory-only (Director of Player Personnel, Director of Pro Personnel, Director of College Scouting, Director of Football Analytics): produces recommendations and information; does not execute transactions. The GM (or fused player) makes the final call.
• Bounded-execution (Salary Cap Manager, Contract Negotiator): genuinely executes within parameters the GM sets (a cap philosophy, a negotiation budget) — real authority, but scoped, not open-ended.
• Strategic-execution (GM, Team President): makes final calls within their own domain, subject to Owner override — the GM's domain is roster; the Team President's is business operations.
• Fully Tactical-delegable (Assistant GM): unchanged from the original delegation model (Module 1.6) — Strategic-tier decisions remain permanently non-delegable to this role, full stop.
• Football Operations Director sits partly in Advisory (recommends HC hires) and partly in Strategic-execution (can be delegated full HC hire/fire authority if the Owner chooses) — the one role that spans two tiers, reflecting its real liaison function.

Information Access — not every executive sees the same hidden data:

• Director of College Scouting: full access to Scouted Grade error bands and every evaluation-channel narrowing (Module 13's Pro Days/Interviews/Wonderlic/Medical) for draft-eligible prospects.
• Director of Pro Personnel: full access to public league-wide contract/cap data (transparent by League rule); for hidden attributes of players on other rosters, this role runs its own independent evaluation — the same Fog-of-War error-band pattern (Module 10.2) applied cross-team, since a rival's internal development read on their own player is exactly as private from the outside as a draft prospect's true rating is before anyone scouts them. This is new, and worth stating explicitly: no franchise has privileged insight into a rival's own hidden player attributes — Invariant 8 (No Silent Systems) compliance extended to inter-team information asymmetry specifically.
• Director of Football Analytics: full access to the franchise's own statistical/performance data; limited (public-stats-only) access to rival data, mirroring real front-office information asymmetry.
• Salary Cap Manager: full access to the franchise's own CapLedger internals.
• Contract Negotiator: full access to the franchise's own players' PlayerPrioritiesProfile/relationship data.
• Team President: full business-side access; limited football-side access — sees Director-level recommendations and summaries, not raw Scouted Grades or error bands. This is a deliberate asymmetry: the Team President is a business executive, not a football evaluator, and shouldn't have a clearer picture of a draft prospect than the football executives whose entire job is producing that picture.

Conflict and Cooperation — specific pairwise tensions, not one undifferentiated Cohesion blob:

Front Office Cohesion (v1.4) is retained as the aggregate output, but this pass specifies the actual pairwise relationships that drive it, since a single blended score was exactly the kind of "vague future work" this phase's own instructions warn against:

• GM ↔ Director of Football Analytics: an old-school GM Philosophy paired with an aggressively analytics-forward Director creates friction that specifically degrades draft and free-agency decision quality (the domains where their advice most directly overlaps and can conflict).
• Director of Player Personnel ↔ (Director of Pro Personnel, Director of College Scouting): a Player-Personnel Philosophy pulling toward Need-Based team-building can clash with a College Scouting Director whose evaluation naturally surfaces Best-Player-Available prospects, or with a Pro Personnel Director advocating aggressive trades that undercut a draft-and-develop philosophy — this specific friction degrades draft-board construction quality (Module 13) when unresolved.
• Salary Cap Manager ↔ Contract Negotiator ↔ GM: a fiscally conservative Cap Manager and an aggressive, deal-closing Negotiator create tension the GM must broker — unresolved, it degrades contract execution quality (worse terms extracted, or deals that technically close but strain the cap sooner than the GM's philosophy intended).
• Football Operations Director ↔ Head Coach: an authority tension distinct from the front-office-internal conflicts above — this one touches Module 8's existing Hot Seat mechanic directly (an HC operating under a Football Operations Director who disagrees with their scheme philosophy faces a harsher effective Hot Seat threshold, all else equal).
• Assistant GM ↔ GM: a structural, not philosophical, tension — the Assistant GM's own Career Progression naturally aims upward (toward a GM vacancy, in this franchise or another), creating a standing, low-level loyalty/succession tension worth naming even though it's not a Philosophy clash like the others.

These pairwise tensions each degrade a specific decision-quality domain, not a generic overall modifier — this is the concrete mechanism that makes hiring decisions a real strategic puzzle rather than "maximize the aggregate Cohesion number."

11.2 Systems Layer

[Shared Executive schema, unchanged in mechanism from v1.4 — restated for completeness:]
Executive:
  role: one of the 10 (see 11.1)
  competence_tier: Novice | Competent | Expert
  role_specific_ratings, hidden_potential_ceiling, experience_years, loyalty (0-100),
  personality_vector, philosophy, individual_reputation, career_progression
    (StateMachineFramework configuration) — all unchanged from v1.4

[New — Decision Authority tiers, per 11.1:]
DECISION_AUTHORITY_TIER: AdvisoryOnly | BoundedExecution | StrategicExecution |
  FullyTacticalDelegable
  — assigned per role per 11.1's table, not per-instance-configurable; this is a
    structural property of the role itself

[New — Information Access, per 11.1:]
INFORMATION_ACCESS_SCOPE: per role, which hidden-data categories are visible
  CROSS_TEAM_EVALUATION (new, Director of Pro Personnel): reuses Module 10.2's
    error-band formula, applied to players on OTHER rosters — no franchise has
    privileged access to a rival's own internal hidden-attribute reads

[New — pairwise Conflict/Cooperation, replacing v1.4's single blended Cohesion input:]
PAIRWISE_TENSION(role_A, role_B) = f(philosophy_distance, personality_distance)
  → degrades a SPECIFIC decision-quality domain per pair (see 11.1's five named
    pairs), not a generic aggregate modifier
FRONT_OFFICE_COHESION (aggregate, still exposed as a single player-facing summary
  number) = f(all active PAIRWISE_TENSION values) — the aggregate is now a
  DERIVED display value, not the primary mechanic; the pairwise values are

HIRING_SCARCITY: unchanged from v1.4 — Expert-tier candidates remain a finite,
  league-wide pool per role per season

11.3 Stress Test

Can players exploit this? Two checks, one carried over and one new. Carried over: max-Expert-tier hiring remains closed by Hiring Scarcity (unchanged). New check: could a player deliberately hire only philosophically-identical executives to eliminate all pairwise tension and maximize Cohesion for free? Partially, but not for free — Hiring Scarcity already limits how many Expert-tier candidates of any given philosophy exist in a season, and a front office of uniform philosophy forfeits the complementary-strength benefits a well-managed diverse front office can produce (e.g., an analytics-forward Director of Football Analytics genuinely improves draft-evaluation quality when NOT in conflict with the GM — uniformity avoids the downside tension but also forfeits that upside). This is a real, felt tradeoff, not an unclosed exploit.

Will AI break this? AI-controlled franchises generate their ten executives under the identical Decision Authority, Information Access, and Pairwise Tension rules — an AI franchise with a badly-mismatched front office should visibly underperform in the specific decision domains its internal conflicts touch (bad drafts if Player-Personnel-vs-Scouting tension is high; bad contracts if Cap-Manager-vs-Negotiator tension is high), which is exactly the differentiated, legible AI behavior Invariant 2 requires — a uniform, frictionless AI front office everywhere would be a violation, not a feature.

Will this stay interesting after 40 seasons? The specific, domain-targeted pairwise tensions make front-office management a genuinely ongoing puzzle across decades, not a one-time hiring decision that's then solved — an executive's Career Progression, poaching risk, and philosophy shift over a long career, meaning a well-aligned front office can drift out of alignment over time purely through natural turnover, requiring continued attention exactly the way the 25–50 season design goal requires.

Does the Cross-Team Evaluation mechanic (Director of Pro Personnel) create any new risk? Checked explicitly: this extends an already-proven pattern (Fog-of-War error bands) to a new context (evaluating rivals) rather than inventing new uncertainty machinery — the risk surface is the same as Module 10's existing scouting risk, just pointed at a different target population.

11.4 Implementation Notes

• Executive object, 10 roles, unchanged schema plus new decision_authority_tier and information_access_scope fields.
• PairwiseTension calculator, one instance per active executive pair, feeding both specific decision-quality domains and the derived aggregate FrontOfficeCohesion display value.
• CrossTeamEvaluation service, reusing Module 10's ScoutedGradeService pattern, scoped to Director of Pro Personnel's information access.
• Module 10's ScoutingDepartment aggregate reporting-line updated: Regional Scouts/Position Specialists → Director of College Scouting; Pro Scouts → Director of Pro Personnel.

11.5 Dependencies

• Module 1 — Owner-GM fusion resolution, unchanged.
• Module 2.7 — Career Progression StateMachineFramework configuration, unchanged.
• Module 6, 7 — Cap Manager / Contract Negotiator execution-quality modulation, unchanged.
• Module 8 — Football Operations Director ↔ Head Coach tension directly touches Hot Seat threshold, new in this pass.
• Module 9 — hiring-market/poaching pattern, unchanged.
• Module 10 — reconciled in this pass: Regional Scouts/Position Specialists now report to Director of College Scouting; Pro Scouts now report to Director of Pro Personnel; Module 10's own Scouting Director title retires.
• Module 13, 14 — Director of College Scouting is now the direct organizational owner of the Draft System's evaluation pipeline and the primary consumer of College Pipeline output.
• Module 16, 17 — Director of Pro Personnel's Cross-Team Evaluation directly feeds Free Agency and Trade target identification.
• Module 24 — competence-tier and tail-variance-generation principles, unchanged.
• Module 31 — reserved Owner/GM split, unchanged.

11.6 Version History

MODULE 12: MEDICAL STAFF

[v1.4, Football Simulation Completion Phase — expanded from a single Medical Director abstraction into five specialized roles, and adds Practice Injuries as a new mechanic. Original Diagnosis Accuracy, Rehab Speed, Prevention, and Injury Crisis content is retained, now distributed across named roles rather than one undifferentiated staff.]

12.1 Design Layer

Five specialized roles, each owning a distinct piece of what was previously one undifferentiated "Medical Staff" rating:

• Team Doctors — own Diagnosis Accuracy (how correctly injury severity is assessed — the Fog-of-War pattern from Module 10, applied to injury severity, unchanged in mechanism, now attributed to a named role).
• Athletic Trainers — own real-time, in-game and practice injury prevention, feeding directly into Module 18's per-play injury probability formula and this module's new Practice Injury formula (12.2) as a genuine input, not just a franchise-level abstraction.
• Physical Therapists and Rehabilitation Staff — jointly own Rehab Speed, still bounded by the hard rehab-time floor (Commitments Ledger C13) regardless of how highly-rated either role is.
• Conditioning Staff — a new contribution: directly modulates the rate of fatigue accumulation in Module 23's FatigueAccumulator, not just injury risk. Elite conditioning staff slow late-game fatigue buildup, which indirectly reduces the late-game injury-probability spikes Module 18's formula already produces from high fatigue — a real, felt strategic lever distinct from pure medical risk management.

Practice Injuries (new): a distinct injury-risk category occurring during team practice, outside actual games, formalizing what Module 12.1's original "practice-intensity slider" always implied but never gave real teeth. Higher practice intensity produces more development reps (Module 15's new Practice Reps input, 15.1) but real practice-injury risk — this is the genuine Tactical-tier tension this module exists to create: how hard do you practice, given the tradeoff is now visible and consequential on both sides, not just a vague "load management" gesture.

This module still delivers the RiskState instantiation for team-wide Injury Crisis, unchanged in mechanism (12.2), now with Practice Injuries as an additional contributing input to that Crisis's severity alongside in-game injuries.

12.2 Systems Layer

DIAGNOSIS_ACCURACY: unchanged — reuses Module 10's error-band pattern, owned by
  Team Doctors specifically now rather than an undifferentiated staff rating

InjuryCrisis: RiskState instance (team-wide) — unchanged mechanism, now reads
  practice-injury incidents as an additional severity input alongside in-game
  injuries
  Mitigation Actions: reduced practice intensity, roster depth investment
  STRUCTURAL LIMIT (C13, unchanged): hard rehab-time floor, unaffected by
    Physical Therapist/Rehabilitation Staff rating

PRACTICE_INJURY_PROBABILITY (new):
  = f(practice_intensity_setting, player_durability, athletic_trainer_rating,
      conditioning_staff_rating, age_curve_position)
  severity distribution skews toward Minor/Moderate relative to in-game injuries
    (reflecting football's real practice-injury pattern), but never impossible
    to be Severe — Invariant 7 uncertainty preserved, not removed for flavor

CONDITIONING_STAFF_FATIGUE_MODIFIER (new):
  directly scales Module 23's FatigueAccumulator rate — high conditioning rating
    slows fatigue buildup, indirectly reducing Module 18's late-game injury-
    probability spikes without changing that formula itself

12.3 Stress Test

Can players exploit this? The original exploit (buy away all injury risk via medical spend) remains closed by the unchanged rehab-time floor. New exploit check for Practice Injuries: could a player set practice intensity to zero to eliminate all practice-injury risk entirely, for free? No — doing so forfeits the Practice Reps development bonus (Module 15) and risks a Culture/Discipline penalty from the Head Coach (Module 8) if a team is perceived as not practicing hard enough, making zero-intensity a real, felt cost rather than a free lunch — the same self-limiting pattern already used throughout the Bible for exactly this class of exploit.

Will AI break this? AI franchises must set practice intensity and staff their five medical roles under the identical formulas, including facing the identical Practice Reps-vs-Practice Injury tradeoff.

Will this stay interesting after 40 seasons? Conditioning Staff's fatigue-modifier role is a genuinely new, distinct strategic lever from pure injury-risk management — a franchise can differentiate itself on "how do our players hold up in the fourth quarter across a whole season" independent of how well it manages acute injury risk, adding a second axis to what was previously a single medical-investment decision.

12.4 Implementation Notes

• MedicalStaff object now decomposed into five role-specific sub-ratings (Diagnosis Accuracy, Rehab Speed [shared by two roles], Prevention, Conditioning/Fatigue-Modifier) rather than one undifferentiated rating set.
• InjuryCrisis RiskState instance, unchanged, now reading an additional practice-injury severity input.
• PracticeInjuryEvent, a new event type distinct from Module 18's in-game InjuryEvent, sharing its severity-tier and diagnosis-error-band structure.

12.5 Dependencies

• Module 10 — Diagnosis Accuracy fog-of-war reuse, unchanged.
• Module 15 (Player Development) — Practice Reps input, the direct link between this module's practice-intensity tradeoff and development speed.
• Module 18 (Injuries) — owns in-game injury events; this module now also owns the parallel Practice Injury event category.
• Module 20 (Facilities) — sports science facility tier contributes to Prevention and Conditioning ratings.
• Module 23 (Game Simulation Engine) — Conditioning Staff directly modulates FatigueAccumulator.

12.6 Version History

MODULE 13: DRAFT SYSTEM

[v1.4, Football Simulation Completion Phase — substantially deepened evaluation process. Original pick-trading, compensatory-pick, and draft-class-strength content is retained in full; this expansion adds parallel information-gathering channels feeding the existing Fog-of-War mechanic, rather than replacing it.]

13.1 Design Layer

Consumes draft order from Module 3 and prospects (with Scouted Grades) from Modules 10 and 14. Seven rounds, mirroring realistic depth. Draft picks are tradeable assets (Module 17 tie-in) with genuinely uncertain future value. Compensatory picks are awarded based on net free agency losses (Module 16 tie-in). Draft classes carry era-level strength variance, generated jointly with Module 14's college pipeline and Module 10's regional scouting variance — a direct, ongoing contributor to closing C6. All of this is unchanged and retained.

New: parallel evaluation channels, each narrowing a different dimension of prospect uncertainty rather than all narrowing the same one. Module 14.2's Combine already exists as a public athletic-testing data point (same for every team). This expansion adds:

• Pro Days — team-specific, optional additional athletic testing investment, narrowing that team's own physical-attribute error band further on top of the public Combine data. Unlike Combine, attendance is a real Tactical-tier resource-allocation decision (which prospects get the extra scrutiny), reusing Module 10's scouting-budget diminishing-returns/allocation pattern directly.
• Interviews — a Front Office time investment (Director of Player Personnel and/or GM attention, per Module 11's expanded executive roster) narrowing the Character and Leadership hidden traits specifically — a distinct information channel from Pro Day's physical-attribute focus, not a duplicate of it.
• Wonderlic-style Testing — public, like Combine, administered to all draft-eligible prospects at a fixed point, narrowing the Football IQ hidden trait universally for every team simultaneously.
• Medical Reports — Team Doctors (Module 12's expanded role) evaluate draft prospects' injury history, producing Injury Flags — a distinct uncertainty dimension of its own: a red flag doesn't deterministically mean bust risk, it shifts probability, preserving Invariant 7.

Hidden traits, now explicit and separately tracked: Character, Leadership, and Football IQ each carry their own independent error band, narrowed by a different investment type (Interviews for the first two, Wonderlic for the third) — giving real strategic texture to how a franchise allocates limited pre-draft evaluation resources across physical, makeup, and cognitive dimensions, rather than one undifferentiated "scouting effort" dial.

Bust/Boom Probability, formalized as a player-visible synthesis — not a new hidden mechanic, but a legible presentation-layer output combining the existing TrueRating/ScoutedGrade/error-band machinery with Injury Flags and Character/Leadership uncertainty into a single, honest boom/bust read. It never collapses to certainty; the underlying error-band floor (Module 10.2) still applies. This is what makes "Draft Day should feel like Christmas morning" concretely true: legible uncertainty the player can weigh, not a spreadsheet number pretending to be more precise than the evaluation process actually supports.

13.2 Systems Layer

[Original content retained unchanged:]
DRAFT_PICK as tradeable Asset: FUTURE_PICK_VALUE = f(...) — unchanged
COMPENSATORY_PICK_FORMULA — unchanged
DRAFT_CLASS_STRENGTH — unchanged, inherited from Module 14

[New — parallel evaluation channels:]
PRO_DAY_INVESTMENT (team-specific, per prospect):
  narrows PHYSICAL error band further, on top of public Combine data
  subject to the same diminishing-returns curve as Module 10's scouting budget
  (prevents "just Pro-Day every prospect" from being a dominant, free strategy)

INTERVIEW_INVESTMENT (Front Office time, per prospect):
  narrows CHARACTER and LEADERSHIP hidden-trait error bands specifically
  finite resource: Director of Player Personnel / GM attention is scarce across
    an entire draft class, same scarcity logic as Module 11's Hiring Scarcity

WONDERLIC_TEST (public, universal):
  narrows FOOTBALL_IQ hidden-trait error band for every team simultaneously,
    same role as Combine plays for physical attributes

MEDICAL_REPORT (Team Doctors, Module 12):
  produces INJURY_FLAGS — probabilistic bust-risk modifier, never deterministic
    (Invariant 7)

BUST_BOOM_PROBABILITY (visible synthesis, not a new hidden mechanic):
  = f(TrueRating error band, Injury Flags, Character/Leadership error bands)
  presented to the player as a legible range, never resolving to certainty —
    the error-band floor from Module 10.2 still governs the irreducible
    uncertainty at the bottom of this calculation

13.3 Stress Test

Can players exploit this? The obvious attempt: max every investment type (Pro Day, Interview, Wonderlic already public) on every single prospect, eliminating uncertainty entirely. Closed by finite Front Office attention — Director of Player Personnel and GM time is scarce across an entire draft class (a real resource, not free), the same scarcity logic already proven in Module 11's Hiring Scarcity and Module 10's scouting budget — a team must prioritize which prospects get the deepest investigation, preserving genuine decision-making rather than universal maximization.

Will AI break this? AI franchises face the identical finite-attention constraint, and — per Module 11's Director of Player Personnel Philosophy attribute — different AI franchises should visibly prioritize different investment types (a Character-focused GM interviews heavily; an old-school GM leans on Pro Days) as a discoverable organizational identity, not uniform behavior.

Will this stay interesting after 40 seasons? Unchanged and reinforced — era-walk and regional-skew variance (Modules 10/14) still govern the underlying true-talent distribution; more investment channels give the player more legible ways to engage with that variance, not less of it.

13.4 Implementation Notes

• DraftPick, FuturePickValueCalculator, CompensatoryPickCalculator — unchanged.
• Prospect object extended with separate character_error_band, leadership_error_band, football_iq_error_band, injury_flag_probability fields, each narrowed independently.
• ProDayInvestment, InterviewInvestment allocation services, reusing Module 10's scouting-budget-allocation pattern.
• BustBoomProbabilityCalculator, a presentation-synthesis service, not a new source of hidden information.

13.5 Dependencies

• Module 3 — draft order.
• Module 10, 14 — prospect pool, scouted grades, regional/era variance.
• Module 11 — Director of Player Personnel's Philosophy and Interview-time allocation.
• Module 12 — Team Doctors' Medical Reports and Injury Flags.
• Module 16 (Free Agency) — compensatory pick formula input.
• Module 17 (Trades) — picks as tradeable assets.

13.6 Version History

MODULE 14: COLLEGE PIPELINE

[v1.4, Football Simulation Completion Phase — the single largest expansion in this phase, upgrading College Pipeline from procedural generation into a fully simulated parallel college football universe. Flagged honestly: this is now very plausibly the largest module in the entire Bible, larger in scope than several of the original 35 individually. The original generation-only content (CollegeProgram, era-walk, Combine) is retained in full as the foundation this expansion builds on.]

14.1 Design Layer

The critical scoping decision that keeps this module tractable, stated explicitly up front: college games are simulated at the result level (final score, key stat lines, standout performances) via an abstracted formula, never full play-by-play. This is a direct, deliberate application of Module 2.4's Abstraction Threshold: "a system is simulated in full detail only if the player can meaningfully act on its internal state." The player has no roster control, no play-calling authority, and no coaching influence over any college program — full play-by-play simulation for games the player cannot act on would be exactly the kind of complexity Module 2.4 exists to prevent. Everything below — rankings, bowl games, awards, recruiting — operates on top of abstracted game results, not simulated plays. This single decision is what keeps a second, parallel football universe from requiring a second, parallel PlayResolutionEngine.

Scope ceiling, stated explicitly rather than left implicit: approximately 130 major college programs are simulated (an FBS-equivalent scope), not an unbounded or fully-realistic total college-football universe. This is a deliberate tractability decision, not an oversight — modeling every division of college football would scale simulation cost without adding decision-relevant depth for a player whose actual lever is scouting/drafting the output of this system, not the system itself.

College programs now play real, simulated seasons:

• Conferences, generalized and lightweighted from Module 3's League Structure pattern — their own regular-season schedules, their own Conference Championship games.
• National Rankings, updated on an ongoing basis through the season (not just at season's end), synthesizing record, strength of schedule, and Program Prestige (below) — reusing Module 3's tiebreaker-cascade concept, adapted to a continuously-updated rather than end-of-season-only calculation.
• Bowl Games / national championship structure, a playoff-equivalent bracket at season's end among top-ranked programs, reusing Module 3's playoff-bracket pattern.
• A Heisman-equivalent individual award, voted using the same voting-formula pattern Module 27 already established for Hall of Fame induction — stat weight + team-success weight + narrative/legacy weight + small randomness for genuinely close cases (Invariant 7 compliance) — not a new voting mechanic invented from scratch. A Heisman-equivalent winner becomes a publicly, extensively evaluated prospect: a legitimate, bounded exception that narrows their error band further than an unheralded player's would be at the same true talent level, but — per Invariant 7 — never resolving to full certainty, even for the sport's most decorated prospect.
• Recruiting classes: college programs recruit incoming talent using their existing recruiting_strength and regional_tag fields (Module 14.1's original CollegeProgram object already had both, now actually load-bearing rather than latent) — recruiting success feeds next year's roster, which feeds next year's on-field results, which feeds next year's Program Prestige, a genuinely self-reinforcing (and self-correcting, since success draws recruiting attention from rivals too) multi-season cycle.
• Program Prestige, evolving from on-field success, awards produced, and draft picks sent to the professional league (a program that sends players to the pros boosts its own recruiting appeal — the real dynamic college football exhibits). Deliberately modeled as a simpler bounded-trending score, not a RiskState/StateMachineFramework instantiation — a college program's prestige rising and falling isn't analogous to a professional franchise's existential Crisis/Ruin risk, and forcing every trending value in the Bible into the heavyweight risk-state machinery, where it doesn't fit, would be exactly the kind of complexity Phase 2's own instruction ("avoid adding complexity that does not improve decision making") warns against.

This module is now a major, direct contributor to Commitments Ledger C7 — rising and falling college programs, new Heisman-equivalent legends, and an evolving recruiting landscape are genuine multi-decade texture, arguably the single largest addition to that commitment of anything in the Bible, expansion or original.

14.2 Systems Layer

[Original content retained unchanged:]
CollegeProgram: prestige_score, recruiting_strength, regional_tag — unchanged fields,
  now load-bearing for recruiting (below), not just regional talent-pool composition
PROSPECT_GENERATION — unchanged formula
COMBINE_TESTING — unchanged, still the shared public floor beneath Module 13's new
  team-specific Pro Day investment

[New:]
COLLEGE_GAME_RESOLUTION (abstracted, NOT play-by-play — the load-bearing scoping
  decision, 14.1):
  = f(program_a_rating, program_b_rating, home_field, bounded_randomness)
  → final score + standout individual performances only; no play sequence

NATIONAL_RANKING (continuously updated, not end-of-season only):
  = f(win-loss record, strength_of_schedule, program_prestige_score)

CONFERENCE_CHAMPIONSHIP / BOWL_BRACKET: reuses Module 3's playoff-bracket pattern,
  adapted to a lightweight conference structure distinct from the pro League Structure

HEISMAN_EQUIVALENT_VOTING: reuses Module 27's HOF_VOTING_FORMULA pattern directly
  = stat_weight + team_success_weight + narrative_legacy_weight + small_randomness
  winner_error_band_reduction: bounded exception, narrows further than an unheralded
    prospect's band at equal true talent, NEVER resolves to zero (Invariant 7)

RECRUITING_CLASS_FORMULA:
  = f(program_recruiting_strength, program_prestige_score, regional_talent_pool
      [Module 10's Regional Skew system, read not duplicated])
  feeds next season's roster → feeds next season's on-field results (self-reinforcing
    but self-correcting, since prestige/success also draws recruiting attention away
    from rivals)

PROGRAM_PRESTIGE (bounded trending score, deliberately NOT a RiskState instantiation):
  trends from: on-field success, Heisman-equivalent winners produced, draft picks
    produced (feeds Module 13's draft class directly)

14.3 Stress Test

Can players exploit this? Not directly — unchanged from the original module's reasoning: this is a world-generation-and-simulation layer entirely upstream of all franchises, with no player lever into any college program, so Invariant 1/2 are satisfied by construction.

Does this create excessive simulation cost or scope creep? Flagged honestly rather than glossed over: simulating ~130 programs' seasons, rankings, bowls, and recruiting every year, in addition to the professional league's existing 32–40 franchises, is a real, substantial addition to overall simulation scope — the explicit ~130-program scope ceiling (14.1) is the direct mitigation, and the abstracted (non-play-by-play) game resolution is what keeps the per-game cost low even at that scale.

Will this stay interesting after 40 seasons? This module is now arguably the single strongest contributor to Failure Mode B (archetype/talent homogenization) and Commitments Ledger C7 in the entire Bible — rising and falling college dynasties, a new Heisman-equivalent legend most seasons, and a recruiting landscape that shifts with regional talent pools (Module 10) and era-walk variance (this module's own original mechanic) compound rather than duplicate each other.

Does this respect the Abstraction Threshold it depends on? Yes, by explicit design (14.1) — this is the one check this module's stress test must never fail, since the entire module's tractability rests on college games never escalating to full simulation depth the player has no lever to act on.

14.4 Implementation Notes

• CollegeProgram object, unchanged fields, now also carrying an active-season record/ranking state.
• EraWalkModifier, CombineTestingEvent — unchanged.
• CollegeConference, CollegeGame (abstracted result only, no play data), CollegeBowlBracket — new, lightweight relative to the professional Game/Play structure.
• HeismanEquivalentVoting service, reusing Module 27's HOFVotingService pattern rather than a parallel implementation.
• ProgramPrestige as a simple bounded-trend value — explicitly not wrapped in RiskState/StateMachineFramework.
• RecruitingClassCalculator, run once per offseason per program.

14.5 Dependencies

• Module 10 — consumes and is consumed by Regional Skew (recruiting reads it; scouting reads this module's output).
• Module 3 — Conference/Bowl structure adapts the League Structure pattern, lightweight.
• Module 13 — primary consumer of the generated, now-simulated-not-just-generated prospect pool.
• Module 27 (Hall of Fame) — Heisman-equivalent voting reuses its formula pattern directly.
• Module 2.4 (Abstraction Threshold) — this module's entire tractability depends on respecting it; see 14.1's explicit scoping decision.

14.6 Version History

MODULE 15: PLAYER DEVELOPMENT

[v1.4, Football Simulation Completion Phase — the DEVELOPMENT_ROLL formula's original shape (Bible 15.2) was deliberately built to accept more terms, and this expansion adds them: Practice Reps, Confidence, Leadership, Mentorship, Film Study, Football IQ growth, and Position Coaches. Original age-curve, Potential Ceiling, and hard-ceiling-exploit-prevention content is retained unchanged as the formula's foundation.]

15.1 Design Layer

Every player has an age curve, and development is driven by hidden Potential Ceiling versus Current Ability, closed over time by coaching, medical, and facility quality plus hidden Work Ethic — all unchanged, retained in full (original 15.1 above this note).

New development inputs, each grounded in an existing pattern rather than inventing a parallel one:

• Practice Reps — the direct payoff of Module 12's new practice-intensity-vs-practice-injury tradeoff: higher practice intensity produces more reps, which speeds development, at the real cost (Module 12) of higher practice-injury risk. This is what gives that tradeoff teeth on the benefit side, not just the risk side.
• Confidence — a new, semi-hidden player attribute rising with strong performance and team success, falling with poor performance, benching, or sustained franchise Crisis states (Owner Trust Crisis, Cap Crisis — Module 4/6's RiskState instances now have a felt downstream effect on individual players, not just the franchise). Modulates development speed and, in small, Invariant-7-bounded amounts, in-game performance variance — a confident rookie develops faster; a cratering veteran may plateau or regress ahead of what pure age-curve math would predict.
• Leadership — a player-level attribute distinct from Coach's Culture/Discipline rating (Module 8): some players are locker-room leaders, providing a small team-wide Confidence/Culture boost to teammates, especially rookies. Complements, rather than competes with, the Coach's existing culture ceiling — Coach sets the ceiling, player Leadership contributes from within the roster itself.
• Mentorship (the genuinely novel piece of this expansion) — a Tactical-tier decision: pairing a veteran and a rookie at the same position for a designated mentorship relationship, boosting the rookie's development roll from the veteran's own Leadership and experience. Modeled as a lightweight relational graph, directly reusing Module 8's CoachingTree edge concept rather than inventing new data structure — a "Mentorship Tree" the Story Engine (Module 25) can reference for exactly the kind of decades-scale narrative callback ("Player X, once mentored by a Hall of Famer, now mentors the next generation") that directly serves Commitments Ledger C7.
• Film Study — deliberately not a new independent hidden attribute. It's an expression of the player's existing hidden Work Ethic combined with a Facility-tier contribution (Module 20's sports-science/film facilities) — avoiding proliferating a new parallel hidden dimension where an existing one, combined with an existing facility investment, already covers the same ground. This is a direct application of Phase 2's own instruction to avoid complexity that doesn't improve decision-making.
• Football IQ growth — a distinct trajectory from physical Current-Ability/Potential-Ceiling growth: Football IQ can continue growing with experience and snaps even as physical tools decline with age, producing the realistic "aging veteran who plays smarter, not just weaker" texture — a genuine roster-construction nuance where an aging, cerebral veteran might still start over a raw, more physically gifted rookie in the right scheme.
• Position Coaches — a finer-grained staff layer beneath Coordinators (Module 9), providing position-specific development multipliers that stack with, not replace, a Coordinator's existing broader positional-specialty bonus (Module 9.1). Gives franchises a real staffing decision distinct from Coordinator hiring: do you invest in a great position coach even under a Coordinator who isn't a specialist in that position group?

Consistency check, stated explicitly since it matters: the original hard ceiling on the development formula's randomness term (Commitments Ledger C13, preventing a "stack everything, guarantee elite outcome" exploit) applies to the combined total of every multiplier term, old and new — adding Confidence, Mentorship, Film Study, and Position Coach terms to the formula does not create seven small loopholes around one big rule; the ceiling caps the aggregate effect regardless of how many positive terms feed into it.

15.2 Systems Layer

[Original formula retained, now extended:]
DEVELOPMENT_ROLL(per season) = f(PotentialCeiling - CurrentAbility, CoachDevMultiplier,
  MedicalQuality, FacilityQuality, WorkEthic, AgeCurvePosition, EraRegionalModifier,
  PracticeReps [new, Module 12 tie-in], Confidence [new], MentorshipBonus [new],
  FilmStudy [new — derived from WorkEthic × FacilityTier, NOT an independent hidden
    attribute], PositionCoachMultiplier [new, stacks with CoordinatorSpecialtyBonus])
  + bounded randomness

FOOTBALL_IQ_GROWTH (new, semi-independent trajectory):
  = f(experience_years, snaps_played, CoachGameManagementRating)
  — can continue rising even as physical CurrentAbility/PotentialCeiling declines
    with age, producing the "smarter but slower" veteran-aging texture

CONFIDENCE (new, semi-hidden, per player per season):
  rises with: strong on-field performance, team success
  falls with: poor performance, benching, sustained franchise RiskState Crisis
    (OwnerTrust, CapLedger — a felt individual-player effect from franchise-level
    Crisis states, not previously modeled at this granularity)

MENTORSHIP_TREE (new, reuses Module 8's CoachingTree edge structure):
  veteran-rookie pairing, same position group, Tactical-tier decision
  rookie's DEVELOPMENT_ROLL gains a MentorshipBonus term scaled by the veteran's
    Leadership rating and experience
  feeds Story Engine (Module 25) narrative callbacks across decades

HARD CEILING (C13, unchanged, now explicitly confirmed to apply to the COMBINED
  total of all multiplier terms, old and new): no combination — however many terms
  now feed the formula — can produce a guaranteed-maximum roll in a single season.

15.3 Stress Test

Can players exploit this? The expanded exploit check, restated for the richer formula: could stacking every new positive term (max Confidence, ideal Mentorship pairing, elite Position Coach, high Practice Reps) alongside the original terms bypass the hard ceiling? No — the ceiling caps the aggregate randomness term regardless of how many positive multipliers feed into it (15.1's consistency check), preserving the original C13 fix even as the formula has grown substantially richer.

Will AI break this? AI rosters develop under the identical extended formula, including AI-controlled franchises making their own Mentorship pairing decisions (a Tactical-tier decision, per Module 2.3, delegable through the same Assistant GM / Front Office delegation framework Module 11 already establishes) — AI teams that mentor well should visibly develop rookies faster than ones that don't, exactly the differentiated-outcome standard Invariant 2 requires.

Will this stay interesting after 40 seasons? Confidence's link to franchise-level RiskState Crisis states means individual player development is now felt to be affected by organizational health, not just personal coaching/facility investment — tightening the connection between Module 4/6's franchise-level systems and individual player outcomes, deepening rather than duplicating the Bible's existing interconnection patterns. The Mentorship Tree, specifically, is a strong new contributor to C7 — multi-decade "coaching/mentorship lineage" stories at the player level, complementing Module 8's existing lineage at the coach level.

15.4 Implementation Notes

• Player object extended with confidence (semi-hidden, season-tracked), football_iq (separate trajectory from current_ability).
• MentorshipTree edge structure, reusing CoachingTreeEdge's pattern (Module 8.4).
• PositionCoach object, subordinate to Coordinator, providing a stacking (not replacing) development multiplier.
• DevelopmentRollCalculator service extended with the new terms, hard-ceiling constraint re-verified against the combined total.

15.5 Dependencies

• Module 8, 9 — coaching development multipliers; Position Coaches sit beneath Coordinators; Mentorship Tree reuses Coaching Tree's structure.
• Module 4, 6 — franchise-level RiskState Crisis states now feed individual player Confidence.
• Module 12 — Practice Reps is the direct payoff of the practice-intensity/practice-injury tradeoff established there.
• Module 20 — Film Study derives from Facility tier, not a new independent attribute.
• Module 25 (Story Engine) — Mentorship Tree feeds decades-scale narrative callbacks.
• Module 7 — feeds Player Value Score directly, unchanged.

15.6 Version History

MODULE 16: FREE AGENCY

16.1 Design Layer

Free agent classes emerge organically from expiring contracts league-wide — never scripted. A legal tampering period precedes formal signing, and the actual negotiation reuses Module 7's Negotiation Engine directly (Invariant 4 compliance — no bespoke free-agency-specific negotiation logic). Front Office Reputation (Module 11) meaningfully affects a franchise's asking-price friction and a free agent's willingness to sign at all. Market-wide inflation or deflation tracks the organic growth of the cap (Module 6) and shifting positional scarcity (Modules 7/10), keeping "market rate" a moving target across decades.

16.2 Systems Layer

FREE_AGENCY_MARKET: all 32 franchises (player + AI) bid using the identical
  NegotiationEngine (Module 7), resolved via a simulated priority/timing pass where each
  free agent chooses among competing offers weighted by their PlayerPrioritiesProfile

16.3 Stress Test

Can players exploit this? No new exploit surface beyond what Module 7 already addresses — this module is largely a direct reuse.

Will AI break this? The critical requirement here: AI franchises must genuinely compete for free agents rather than the market functioning as an empty backdrop for the player alone — this is essential for realism and Invariant 2, and a real risk if engineering treats AI free agency as a lower priority than player-facing UI.

Will this stay interesting after 40 seasons? Market inflation/deflation tracking organic cap growth (Module 6) keeps free agency's "going rate" from calcifying.

16.4 Implementation Notes

• FreeAgencyMarket service — orchestrates the simultaneous multi-team bidding pass, reusing NegotiationEngine from Module 7 rather than reimplementing it.

16.5 Dependencies

• Module 7 — direct reuse of the Negotiation Engine.
• Module 11 — Reputation affects asking price/willingness.
• Module 6 — cap growth drives market inflation.
• Module 13 — compensatory pick formula consumes free agency losses.

16.6 Version History

MODULE 17: TRADES

17.1 Design Layer

Every tradeable asset (player, pick) has a Trade Value derived from existing systems — Player Value Score and contract terms (Module 7), age curve position (Module 15), and Future Pick Value (Module 13). AI trade logic must evaluate proposals using these identical formulas and accept or reject based on a fairness-threshold gate rather than being freely exploitable. No-trade clauses (Module 7 contract term) and tampering prevention (Module 32 tie-in) apply. Blockbuster trades are, by construction, high-Decision-Weight (Module 2.6) Strategic events.

17.2 Systems Layer

TRADE_VALUE_CALCULATOR: per asset, using Module 7/13/15 formulas directly (no separate
  trade-specific valuation logic — Invariant-consistent reuse)

AI_TRADE_ACCEPTANCE_THRESHOLD:
  accepts if (value_offered / value_required) exceeds a floor, modulated by team_need_
    urgency and bounded randomness (Invariant 7 — not purely deterministic, but bounded)
  threshold TIGHTENS against a specific counterparty franchise as that counterparty's
    Front Office Reputation (Module 11) declines — direct reuse of the reputation system
    to prevent repeat lopsided-trade farming against the same AI team

17.3 Stress Test

Can players exploit this? Yes — without the reputation-tightening mechanic above, a player could repeatedly target the same AI franchise for trades right at the acceptance threshold. Reusing Module 11's Reputation system to make AI progressively warier of a specific repeat counterparty closes this without needing a new bespoke system.

Will AI break this? AI-to-AI trades must run through the identical threshold logic, producing a league where trade activity between AI franchises is itself realistic and reputation-sensitive — good material for Module 25's Story Engine.

Will this stay interesting after 40 seasons? Trades are one of the strongest generators of season-to-season emergent narrative in the whole Bible — flagging as a priority Story Engine (Module 25) event source.

17.4 Implementation Notes

• TradeProposal object (assets offered/requested on each side).
• TradeValueCalculator (pure reuse of Modules 7/13/15 formulas).
• AITradeAcceptanceEngine, reading Module 11's FrontOfficeReputation per counterparty pairing.

17.5 Dependencies

• Module 7, 13, 15 — direct valuation formula reuse.
• Module 11 — reputation-based AI defense against repeat lopsided trades.
• Module 32 (Anti-Exploitation) — owns tampering/collusion enforcement beyond the acceptance-threshold gate itself.

17.6 Version History

MODULE 18: INJURIES

18.1 Design Layer

Injury probability is a real-time Module 23 simulation input, driven by durability rating, in-game fatigue accumulation, medical staff Prevention rating (Module 12), and bounded randomness. Severity resolves in tiers (minor through career-threatening) with the same Fog-of-War diagnosis pattern established in Module 12 — initial uncertainty narrows over the following weeks. Injury history accumulates into long-term durability decline (Module 15 tie-in), and "playing hurt" is a real Tactical-tier decision with genuine risk/reward, satisfying Module 2.2's meaningful-decision criteria directly.

18.2 Systems Layer

INJURY_PROBABILITY(per play) = f(durability_rating, fatigue_accumulation,
  medical_prevention_rating [Module 12], bounded_random_variance)

SEVERITY_ROLL: diagnosis error band narrows over following weeks (reuses Module 12
  pattern) — RE-INJURY RISK multiplies sharply if a player returns before the Module 12
  hard rehab-time floor is met

18.3 Stress Test

Can players exploit this? Constantly resting star players to near-zero injury exposure is the obvious lever — this must carry a real Fan Loyalty (Module 21) and Owner Trust (Module 4) cost for excessive, unjustified load management, so it's a genuine trade-off rather than a free risk-elimination strategy.

Will AI break this? AI coaching staffs must manage snap counts and injury risk under the identical formula, including facing the same Fan Loyalty/Owner Trust costs for over-resting players.

Will this stay interesting after 40 seasons? Career-altering injuries are prime material for Hall of Fame narrative complexity (Module 27) and Story Engine arcs (Module 25) — a Hall of Fame case shaped by "what if he hadn't gotten hurt" is exactly the kind of decades-spanning texture this Bible is built to produce.

18.4 Implementation Notes

• InjuryEvent object (severity, diagnosis error band, timeline).
• ReinjuryRiskMultiplier, gated against Module 12's hard rehab floor.
• LoadManagementPenalty — ties into Module 4 and Module 21's trust/loyalty formulas.

18.5 Dependencies

• Module 12 — medical infrastructure this module's events consume.
• Module 15 — long-term durability decline.
• Module 4, 21 — load-management cost enforcement.
• Module 23 — per-play probability is a direct simulation input.

18.6 Version History

MODULE 19: STADIUM MANAGEMENT

19.1 Design Layer

The stadium is a Strategic-tier asset: capacity, luxury box count, and condition, which decays over time and requires reinvestment (Module 5 debt-service tie-in). New stadium construction is one of the highest-Decision-Weight (Module 2.6) choices in the game — massive up-front financing, multi-season build time, and a potential relocation trigger point (Module 4's Ruin-adjacent outcome, though a voluntary relocation-for-a-better-stadium is a Strategic choice, not a forced Ruin one). Stadium condition directly affects Fan Loyalty (Module 21) and revenue ceiling (Module 5).

19.2 Systems Layer

STADIUM_CONDITION: decays per season, requires periodic RENOVATION investment
  (Module 5 cash cost) to maintain revenue ceiling and Fan Loyalty contribution

NEW_CONSTRUCTION: multi-season build timeline (cannot be instantly bought — structural
  limit consistent with the C13 pattern used elsewhere), financed via debt
  (Module 5 debt-service line item)

19.3 Stress Test

Can players exploit this? No major exploit surface — this is a large strategic capital sink by design. The main requirement is ensuring AI franchises invest in or neglect their stadiums realistically, tied to their ownership archetype (Module 4) — a frugal Legacy Family owner should genuinely let a stadium age more than an aggressive Corporate ownership group would.

Will this stay interesting after 40 seasons? The build-age-renovate-rebuild stadium lifecycle is a naturally multi-decade rhythm — one of the cleanest direct fits for a 25–50 season game's pacing of any system in the Bible.

19.4 Implementation Notes

• Stadium object (capacity, condition, age, luxury box count, debt reference).
• ConstructionTimeline — enforces the multi-season build floor.
• RenovationROICalculator.

19.5 Dependencies

• Module 5 — financing and debt service.
• Module 4 — relocation ties, ownership archetype spending behavior.
• Module 21 — condition feeds Fan Loyalty.

19.6 Version History

MODULE 20: FACILITIES

20.1 Design Layer

Training facilities, practice facilities, sports science labs, and team facilities across quality tiers, feeding development multipliers (Module 15), medical Prevention rating (Module 12), and a bounded free-agent attractiveness factor (Module 16). Investment is a genuine multi-season Strategic Decision (high Decision Weight per Module 2.6) with a real cost curve.

20.2 Systems Layer

FACILITY_TIER: 1-5, each tier's cost scales steeply (not linearly) and requires a
  multi-season construction/upgrade timeline — deliberately NOT instantly buyable at max
  tier, applying the same C13 structural-limit lesson used in Modules 6, 12, and 15

FACILITY_CONTRIBUTIONS: DevelopmentMultiplier (Module 15), MedicalPrevention (Module 12),
  bounded FreeAgentAttractiveness factor (Module 16 — real but capped, per Abstraction
  Threshold reasoning, to avoid facilities becoming a dominant free-agency lever on
  their own)

20.3 Stress Test

Can players exploit this? Immediately maxing facility tier would trivialize both development and medical systems if it were instantly available — the steep cost curve plus mandatory multi-season timelines prevent this directly.

Will this stay interesting after 40 seasons? Facilities age and require reinvestment much like the stadium (Module 19) — another natural decades-scale rhythm rather than a "buy once, done forever" purchase.

20.4 Implementation Notes

• FacilityTier config table (5 tiers, steep cost curve, timeline-gated upgrades).
• Contribution values read directly by Modules 12 and 15's formulas.

20.5 Dependencies

• Module 15 — development multiplier contribution.
• Module 12 — medical prevention contribution.
• Module 16 — bounded free-agent attractiveness factor.
• Module 5 — investment cost.

20.6 Version History

MODULE 21: FAN LOYALTY

21.1 Design Layer

Fan Loyalty Index (0–100) per franchise, driven by win history, roster star power, ticket-pricing fairness, stadium experience (Module 19), and franchise reputation/trust narrative (Module 4/11). This module delivers the fourth RiskState instantiation among Modules 11–21: a Fan Crisis (attendance and merchandising collapse), directly discharging another piece of C9, with a hard structural recovery floor per C13 — Fan Loyalty cannot be bought back with a single marketing spend; it requires a real, multi-season minimum of competitive results. Fan Loyalty resets or partially resets on forced relocation (Module 4's Ruin outcome).

21.2 Systems Layer

FAN_LOYALTY_INDEX = f(win_history, roster_star_power, ticket_pricing_fairness,
  stadium_experience [Module 19], franchise_reputation [Module 4/11])

FanCrisis: RiskState instance
  Mitigation Actions: competitive results, pricing adjustment, marketing investment
  STRUCTURAL FLOOR (C13): marketing investment alone cannot resolve a Fan Crisis — a
    minimum number of real competitive seasons is required regardless of spend,
    preventing a cash-only fix

21.3 Stress Test

Can players exploit this? Cheap marketing spend spam to instantly resolve a Fan Crisis is the obvious attempt — the hard structural floor (a real minimum time-and-competitiveness requirement, not just cash) directly closes it, consistent with the pattern established across cap restructures, facility construction, and stadium builds.

Will AI break this? AI franchises' Fan Loyalty affects their own revenue and Owner Trust identically to the player's.

Will this stay interesting after 40 seasons? Fan Loyalty accumulating real generational identity over decades is a direct, substantial contributor to closing C7.

21.4 Implementation Notes

• FanLoyaltyIndex per franchise.
• FanCrisis as a RiskState instance with the hard structural floor enforced as a minimum-seasons counter, not a formula term alone.

21.5 Dependencies

• Module 4, 11 — reputation/trust inputs.
• Module 19 — stadium experience input.
• Module 5 — merchandising and attendance revenue consume this index directly.

21.6 Version History

MODULE 22: RIVALRIES

22.1 Design Layer

A Rivalry Score between team pairs, generated from division-play frequency (Module 3), playoff meeting history, close-game history, and coach/player crossover history (a coach who left Team A to lead rival Team B). Rivalry effects are deliberately small and bounded — a modest performance-variance bump in rivalry games (Module 23 input) and a Fan Loyalty boost/penalty (Module 21) tied to rivalry outcomes, never a mechanical override of underlying team quality (Invariant 7 compliance by design). New rivalries emerge organically over decades — a direct, ongoing contributor to C7.

22.2 Systems Layer

RIVALRY_SCORE = weighted_sum(division_play_frequency, playoff_meeting_history,
  close_game_history, coach_crossover_history) — decays slowly if not renewed by
  new meetings

RIVALRY_GAME_MODIFIER: small, bounded variance adjustment in Module 23's simulation —
  explicitly capped to remain a flavor influence, not a determinative one

22.3 Stress Test

Can players exploit this? No significant exploit surface — the effects are small and bounded by design, consistent with Invariant 7.

Will AI break this? Rivalry effects apply symmetrically to AI-vs-AI matchups, which creates emergent AI-side storylines (a recurring AI-vs-AI rivalry becomes real Story Engine material without any player involvement).

Will this stay interesting after 40 seasons? This module, alongside Module 8's Coaching Tree and Module 21's Fan Loyalty, is one of the three primary generators of decades-long texture answering C7.

22.4 Implementation Notes

• RivalryScore per team-pair, slow-decaying if not renewed.
• RivalryGameModifier — bounded, read by Module 23.

22.5 Dependencies

• Module 3 — division play is the primary rivalry seed.
• Module 21 — Fan Loyalty effects.
• Module 23 — bounded in-game modifier consumer.
• Module 25, 26 — narrative surfacing and historical record.

22.6 Version History

MODULE 23: GAME SIMULATION ENGINE

23.1 Design Layer

The core play-by-play simulation: each play resolves from the offensive-vs-defensive scheme/personnel matchup (Modules 8/9's Fit Score), individual player attributes (Module 15), coach Game Management and In-Game Adjustment ratings (Module 8), fatigue and injury risk (Module 18), and small bounded rivalry/weather modifiers (Module 22), combined with randomness that influences but never dictates the outcome (Invariant 7's most load-bearing implementation in the entire Bible). Full play-by-play depth is justified under the Abstraction Threshold (Module 2.4) precisely because scheme and personnel are direct, actionable player levers that need visibly differentiated output. Output feeds Module 25's Story Engine directly.

23.2 Systems Layer

PLAY_RESOLUTION = f(matchup_differential [scheme fit, personnel, attributes],
  coach_game_management, fatigue_state, bounded_rivalry_weather_modifier)
  + bounded_randomness

CALIBRATION GUARDRAIL (hard requirement, tunable magnitude only in Module 33):
  a significantly favored team (on paper, via the above inputs) MUST win at a rate
  meaningfully above 50% in aggregate simulation — if the randomness band is wide enough
  to erode this, Invariant 7 and the entire premise that roster-building matters are
  both broken. This is a correctness requirement, not a balancing preference.

GAME_FLOW: down/distance/clock/score state machine
FATIGUE_ACCUMULATOR: per player, per game, feeding Module 18's injury probability

23.3 Stress Test

Can players exploit this? Not directly player-facing, but a mistuned variance band is the single biggest correctness risk in the whole Bible — if variance is too wide, skill and roster quality stop mattering, which would quietly invalidate every other module's premise that decisions matter. Flagging the Calibration Guardrail above as non-negotiable, distinct from tunable balance values.

Will AI break this? AI-coached teams' play-calling must draw on the identical Game Management and Fit Score inputs a human-coached team would (Module 24 overlap for AI-specific decision logic).

Will this stay interesting after 40 seasons? The engine itself doesn't need to structurally change over decades, but it's continuously fed by evolving rosters and rules (Module 3/6 CBA-driven changes) — flagging for Module 33 to periodically revisit whether rule changes (e.g., a CBA-driven penalty-rate adjustment) are having their intended simulation-level effect.

23.4 Implementation Notes

• PlayResolutionEngine — the highest-computational-cost service in the Bible; must be deterministic-with-seed for replay/debugging while presenting as live to the player.
• GameFlowStateMachine.
• FatigueAccumulator, feeding Module 18 directly.

23.5 Dependencies

• Module 8, 9 — scheme/personnel/coaching inputs.
• Module 15 — player attribute inputs.
• Module 18 — fatigue/injury feedback loop.
• Module 22 — bounded rivalry modifier.
• Module 24 — AI play-calling logic.
• Module 25 — output consumer.

23.6 Version History

MODULE 24: AI DECISION LOGIC

24.1 Design Layer

Process clarification (added v24.1, Chief Architect Review): this module's placement at position 24 in the Bible's reading order has a real risk of being misread as a build order — implying AI-parity logic gets implemented as a pass added after each subsystem is already built. That is explicitly not the intent, and is called out here directly so it cannot be missed: AI-parity logic must be implemented inline, within each subsystem's own build, from that subsystem's first line of code. Module 24's own deliverables — the AIPersonality vector, CompetenceTier taxonomy, and DecisionCycleScheduler — are the shared infrastructure those inline implementations plug into; they are not a substitute for building parity into Modules 3–23 as those modules are built. This module's "consolidated discharge" framing (see 24.5) describes when the Bible's design work is confirmed complete for this requirement across every prior module — it does not describe an engineering phase, and must not be scheduled as one.

Every AI franchise carries a Personality profile (risk tolerance, spending aggression, scheme preference, loyalty-weighting) and a Competence tier per staff role (GM, HC, Scouting Director, etc. — deliberately reusing the same Novice/Competent/Expert tier concept from Module 11's delegation system for consistency). This module is the formal, consolidated discharge point for every "AI must break this too" flag raised across Modules 1–23 — it doesn't introduce new mechanics so much as it guarantees, system by system, that AI franchises run through identical logic paths as the player, satisfying Invariant 2 as a whole-Bible property rather than a scattered set of per-module promises.

AI competence tiers produce realistic mistakes — bad contracts, cap mismanagement, poor draft evaluations — bounded by competence and personality, which is what creates a league of genuinely differentiated, well-run and poorly-run franchises rather than 31 identical bots.

24.2 Systems Layer

AI_PERSONALITY: risk_tolerance, spending_aggression, scheme_bias, loyalty_weighting
  — generated with genuine tail variance (not clustered around a bland average),
  refreshed as AI executives retire/get replaced via the same Hot Seat/Ruin systems
  (Modules 4, 8) that govern player-adjacent staff — this is a NEW, previously
  unlogged contributor to C7: AI executive turnover across decades is itself a major
  source of league-wide narrative freshness

COMPETENCE_TIER: per staff role, reuses Module 11's tier concept

DECISION_CYCLE_SCHEDULER: runs all CURRENT_FRANCHISE_COUNT franchises' Strategic/
  Tactical/Operational decisions on the identical offseason/in-season/draft-day/
  trade-deadline cadence, in parallel — no franchise gets extra decision-cycle time or
  privileged sequencing [v24.2, was hardcoded "all 32 franchises" — Finding 7]

AI_DIFFICULTY_CALIBRATION_GUARDRAIL (v24.2, Resolution Report Finding 3 — Architectural
  Flaw): the aggregate AICompetenceTier distribution across all AI franchises must be
  tuned, via Module 33's AutoSimTestHarness, such that an average-skill human player
  achieves a win rate and competitive standing within a defined band of AI-vs-AI
  baseline performance over a multi-season sample — neither so easy that competent AI
  is a myth, nor so hard that average human play is structurally non-competitive. This
  is a correctness requirement for Module 33's tuning process, exactly as Module 23's
  Calibration Guardrail is — rule parity (Invariant 2) guarantees AI plays by the same
  rules, but says nothing on its own about whether the resulting difficulty is fair.

24.3 Stress Test

Can players exploit this? Not directly, but there's a real system-level risk: if AI Personality/Competence generation converges toward a bland statistical average over time, Failure Modes A and B resurface at the AI layer even if the player-facing systems are working correctly. The fix (tail variance in generation, refreshed via executive turnover) is written into 24.2 directly rather than left as an aspiration.

Will AI break this? This module is the AI — its own internal correctness is the test. The consolidated audit role it plays (checking every prior module's AI-parity promise) is arguably more valuable than any single new mechanic it introduces.

Will this stay interesting after 40 seasons? AI executive turnover — AI GMs and HCs getting fired and hired through the same Hot Seat and Ruin systems that govern the player's own staff — is a substantial, previously-unlogged contributor to C7. Adding this to the Ledger below.

24.4 Implementation Notes

• AIPersonality vector, generated with explicit tail-variance requirements (not a narrow bell curve).
• AICompetenceTier per role, reusing Module 11's tier taxonomy.
• DecisionCycleScheduler — must run all 32 franchises' logic through genuinely identical code paths, not team-specific shortcuts, per Invariant 2. This is likely the single most consequential engineering requirement in the entire Bible for maintaining the game's core promise, and should be flagged to engineering as non-negotiable architecture, not a performance-optimization target.
• Build-process requirement (v24.1): flag explicitly to engineering leads at the start of each subsystem's build (Phases 1–9 of the Systems Specification's dependency order), not just once at whatever point Module 24's own infrastructure gets built: every subsystem's AI-facing logic must be the same code path the player-facing logic uses, parameterized by AIPersonality/CompetenceTier, from that subsystem's initial implementation — never a follow-up pass, never a simplified stand-in scheduled "for later." Treat this as a per-subsystem Definition-of-Done checklist item, not a Module 24 deliverable alone.

24.5 Dependencies

• Every module 3–23 — this module is the consolidated AI-parity discharge point for all of them.
• Module 4, 8 — AI executive Hot Seat/Ruin turnover.
• Module 11 — shared competence-tier concept.

24.6 Version History

MODULE 25: STORY ENGINE

25.1 Design Layer

[Note added v25.1, Chief Architect Review: the EventDetector described below is now formally a subscriber to the shared Event Bus (Module 2.13) rather than a bespoke subscription pattern unique to this module. The one-directional, read-only architectural constraint described here was always the intent — the Event Bus makes it structurally enforced rather than a stated convention, since the Story Engine is simply never issued a publish credential for simulation-state event types.]

The Story Engine surfaces emergent narrative from underlying systems — it never scripts outcomes and never writes back into simulation state (a hard, one-directional architectural requirement protecting Invariant 6). It monitors league-wide state changes — trades, injuries, coaching changes, rivalry games, milestones, Crisis/Ruin transitions, media rights cycles — and generates narrative framing (headlines, storylines) via in-game media. A Narrative Weight score determines which of many simultaneous events surface prominently versus get buried in a ticker. Long-form threads (a building rivalry, a coach's redemption arc, a rookie's rise) persist and get referenced across seasons, feeding directly into Module 26's permanent record.

25.2 Systems Layer

EVENT_DETECTOR: subscribes to state-change events across every other module
NARRATIVE_WEIGHT = f(recency, rarity, stakes, player_relevance)
StoryThread: persists across seasons, references originating events, can be recalled
  by later modules (Module 26 history, Module 27 HOF narrative context)

TEMPLATE_VARIETY_POOL (v25.2, Resolution Report Finding 10 — Architectural Flaw): for
  each recurring narrative event category (coach termination, blockbuster trade,
  career-ending injury, Crisis/Ruin transitions, etc.), the Story Engine draws from a
  pool of multiple distinct phrasing/framing templates rather than one fixed template
  per category, with pool size scaling to that category's expected frequency over a
  25–50+ season save. Selection weights toward variety — avoiding immediate repetition
  for the same franchise or player — rather than pure randomness. NOTE: this has a real
  content-production cost distinct from its engineering cost — writing enough distinct
  template variants to actually avoid repetition over decades is a writing task, not
  something engineering resolves alone.

25.3 Stress Test

Can players exploit this? Not player-facing in a way that creates exploit surface — the risk here is architectural, not mechanical: the Story Engine must have read-only access to simulation state, never write access, or a narrative-driven "cheat" could silently violate Invariant 6. This is stated as a hard requirement, not a soft preference.

Will AI break this? The engine surfaces AI-vs-AI events with equal weight to player-relevant ones, for full league texture.

Will this stay interesting after 40 seasons? This module is the primary connective tissue that makes an otherwise mechanically-consistent 40-season save feel like a lived history rather than a spreadsheet — arguably the single highest-leverage module for the felt experience of everything Modules 1–24 built mechanically.

25.4 Implementation Notes

• EventDetector — subscriber pattern across all modules' state-change events.
• NarrativeWeightCalculator.
• StoryThread object, persistent, cross-season.
• Hard architectural constraint: one-directional data flow only (simulation → Story Engine, never the reverse).

25.5 Dependencies

Consumes events from nearly every prior module; feeds directly into Module 26 (Dynamic League History).

25.6 Version History

MODULE 26: DYNAMIC LEAGUE HISTORY

26.1 Design Layer

A permanent, queryable, append-only historical record: every season's standings, every draft class (retrospectively graded once careers resolve), every trade, coaching change, Crisis/Ruin event, realignment, and expansion. This module is the formal, direct discharge of C7 — everything Modules 8, 11, 21, 22, and 24 have been building toward as partial contributors converges here into one permanent record, feeding Hall of Fame voting (Module 27), Legacy scoring (Module 28), and Story Engine callbacks (Module 25).

26.2 Systems Layer

LeagueHistoryLedger: append-only event log, aggregated across every module
HistoricalQueryService: powers retrospectives, all-time leaderboards, franchise records,
  HOF eligibility checks

26.3 Stress Test

Can players exploit this? No — this is a largely read-mostly record. The key requirement is integrity: no retroactive edits, even by the player, or the entire "this game has real memory" promise collapses.

Will AI break this? History tracks AI franchises with full parity.

Will this stay interesting after 40 seasons? This module is the direct proof of the entire 25–50 season design promise from Module 1 — if it works, the game has genuine memory; if it doesn't, every other module's decades-scale ambition is undermined regardless of how well those modules individually function.

26.4 Implementation Notes

• LeagueHistoryLedger — append-only, event-sourced (flagging as a strong candidate for Module 35's architecture recommendation).
• HistoricalQueryService — needs smart search/filter, not just chronological scroll, given the data volume a 25–50 season save will accumulate (cross-reference Module 34's UI requirement).

26.5 Dependencies

Aggregates from every prior module; feeds Modules 27, 28, 25 (callbacks).

26.6 Version History

MODULE 27: HALL OF FAME

27.1 Design Layer

Retired players and coaches become eligible based on career achievement thresholds (statistical, team success, longevity). A simulated media panel votes using a weighted formula that includes narrative/legacy factors from Modules 25/26, not pure statistics — mirroring the real, sometimes-contentious texture of actual Hall of Fame debates, with genuine uncertainty on borderline cases (Invariant 7).

27.2 Systems Layer

HOF_ELIGIBILITY_CHECK: career thresholds (stats, team success, longevity)
HOF_VOTING_FORMULA = stat_weight + team_success_weight + narrative_legacy_weight
  [Module 25/26 sourced] + small_randomness [borderline-case uncertainty]

27.3 Stress Test

Can players exploit this? Not directly actionable beyond building genuinely HOF-caliber careers, which is the intended long-horizon goal.

Will AI break this? Applies identically to AI-team players and coaches.

Will this stay interesting after 40 seasons? HOF classes accumulating across decades are a major payoff moment and a direct Legacy/C7 contributor.

27.4 Implementation Notes

• HOFEligibilityCheck, HOFVotingFormula, HOFClass (generated per season, consumed by Module 25 for induction-ceremony narrative).

27.5 Dependencies

• Module 25, 26 — narrative/legacy voting input.
• Module 15 — career statistical record.
• Module 28 — feeds Legacy Score composite.

27.6 Version History

MODULE 28: LEGACY SCORE

28.1 Design Layer

A composite Owner/GM-level score across championships, Hall of Fame inductees developed, franchise valuation growth (Module 29), fan/cultural legacy, coaching tree influence (Module 8), and successful succession events (Module 4). This is the direct, formal delivery of the plural win-condition promised in Module 1 as the fix for Failure Mode D (endgame flatness) — it gives a player who has already won multiple championships genuinely new goals to chase deep into a 40+ season save.

28.2 Systems Layer

LEGACY_SCORE = weighted_composite(championships, HOF_inductees_developed,
  franchise_valuation_growth [Module 29], fan_cultural_legacy [Module 21],
  coaching_tree_influence [Module 8], succession_events [Module 4])
  — weights must be balanced (Module 33) so no single factor dominates

28.3 Stress Test

Can players exploit this? A player could try to min-max via a single narrow axis (e.g., championships only, ignoring everything else) — the multi-factor weighted composite is designed to resist single-axis optimization, but flagging explicitly for Module 33 to verify no factor mathematically dominates the others once real numbers are tuned.

Will AI break this? AI owners accumulate Legacy Score too, creating a natural "legendary AI owners" leaderboard/comparison point.

Will this stay interesting after 40 seasons? This module is the direct, formal answer to Failure Mode D.

28.4 Implementation Notes

• LegacyScoreCalculator, MilestoneTracker (statue, franchise museum, retired numbers — flavor-tier but emotionally resonant recognition).

28.5 Dependencies

• Module 4, 8, 21, 27, 29 — all feed the composite directly.
• Module 33 — must verify weight balance.

28.6 Version History

MODULE 29: FRANCHISE VALUATION

29.1 Design Layer

Franchise Value is derived from NOI trajectory (Module 5), market tier (Module 3), stadium/facility asset value (Modules 19/20), competitive success trend, and Fan Loyalty (Module 21). Valuation growth is the explicit success metric for Corporate/Group ownership archetypes (Module 4). This module delivers a valuation-specific RiskState instantiation — Financial Ruin, distinct from Owner Trust's more holistic crisis — completing the remaining piece of C8/C9 for economic collapse specifically.

This module formally resolves Commitments Ledger C5 (the Legend Index question, deferred since Module 1.8): the decision is to build a light-touch, flavor-only cross-game benchmark — a normalized 0–100 "Legend Index" comparing a franchise's valuation-growth trajectory against typical trajectories observed in Diamond Legend and Bitcoin Speedway saves, surfaced only as an optional leaderboard/bragging-rights stat with zero mechanical effect on gameplay. This satisfies the spirit of a shared-universe thread without becoming fan-service-only (it has one concrete, bounded use) and without violating the Non-Negotiables (it cannot become a backdoor pay-to-win or forced-crossover mechanic, since it does nothing but display a number).

29.2 Systems Layer

FRANCHISE_VALUE = f(NOI_trailing_average [multi-season, NOT single-season — prevents
  short-term NOI manipulation from swinging valuation, a direct C13-lesson application],
  market_tier, stadium_facility_asset_value, competitive_success_trend, fan_loyalty)

FinancialRuin: RiskState instance (valuation-specific variant of the franchise-level
  Crisis/Ruin system Module 4 already established for Owner Trust)

LEGEND_INDEX (flavor-only, non-mechanical):
  normalized_score = franchise_valuation_growth_trajectory vs. cross-game benchmark
    distributions (Diamond Legend, Bitcoin Speedway)
  explicitly: NO effect on cap, contracts, AI behavior, or any other system —
  display/leaderboard only

29.3 Stress Test

Can players exploit this? Short-term NOI manipulation (e.g., a single blowout profitable season) swinging valuation dramatically would be an exploit — using a multi-season trailing average directly closes this, consistent with the C13 pattern.

Will AI break this? AI franchise valuations are tracked identically and visible to the player for context/comparison.

Will this stay interesting after 40 seasons? Valuation growth as a decades-long trajectory is a core plural win-condition alongside Module 28's Legacy Score.

29.4 Implementation Notes

• FranchiseValueCalculator — trailing multi-season average, not single-season.
• FinancialRuin RiskState instance.
• LegendIndex — explicitly scoped as a display-only, cross-game comparison feature; should be architecturally isolated from any gameplay-affecting system to guarantee it can never accidentally become mechanical.

29.5 Dependencies

• Module 5, 19, 20, 21 — direct valuation inputs.
• Module 4 — ownership archetype success-metric tie-in.
• Module 28 — feeds Legacy Score composite.

29.6 Version History

MODULE 30: ECONOMY

30.1 Design Layer

This module ties Modules 5, 6, 7, and 16's individual economic threads into one coherent macroeconomic layer: aggregate cap growth, media rights cycles, player market inflation/deflation, stadium construction cost trends, and long-cycle boom/bust "economic eras" that create league-wide meta shifts. This is the final, complete discharge of C3 — every prior partial contribution (Module 5's media cycle, Module 6's revenue-linked cap) is unified here under one macro-level system with its own long-period variance.

30.2 Systems Layer

MACRO_ECONOMIC_CYCLE: long-period (15-20 season) boom/bust wave, affecting media rights
  growth rate, sponsorship base rates, and stadium construction costs SIMULTANEOUSLY
  league-wide — telegraphed in advance via Module 25's Story Engine, never a silent
  modifier (Invariant-consistent: influences trajectories, never dictates specific
  franchise-level outcomes)

30.3 Stress Test

Can players exploit this? Not directly — this is a global, non-player-actionable macro layer, only reactively navigable.

Will AI break this? Applies identically to all 32 franchises simultaneously (Invariant 1).

Will this stay interesting after 40 seasons? This module is the top-level, complete closure of Failure Mode A (solved meta) — the entire economic backdrop genuinely moves across a full save's lifetime, not just individual sub-systems within it.

30.4 Implementation Notes

• MacroEconomicCycle — global state, telegraphed via Story Engine events ahead of taking effect.

30.5 Dependencies

• Module 5, 6, 7, 16 — unifies their individual economic threads.
• Module 25 — telegraphing mechanism.

30.6 Version History

MODULE 31: ONLINE SEASONS

31.1 Design Layer

Multiplayer league mode: human-controlled franchises alongside AI, synchronized season cycles. This module formally resolves the reservation from Module 1.9 (C4): the decision is to build the Owner/GM seat split — a co-op franchise mode where one human holds the Owner seat (Board votes, financial risk tolerance, hire/fire authority over the GM) and another holds the GM seat (roster, cap, draft, trades), with genuine principal-agent friction. This restores the dramatic axis Module 1 deliberately removed from single-player, specifically in the mode built to carry it.

Owner Patience, a new RiskState instance, governs this friction — the GM must manage the Owner's patience as a real resource, similar in shape to Fan Loyalty or Owner Trust, but scoped to the Owner-GM relationship specifically rather than the whole franchise.

31.2 Systems Layer

CoOpFranchiseSeat: Owner seat + GM seat, separate permission sets
OwnerPatience: RiskState instance (new) — GM decisions that conflict with Owner
  philosophy erode patience; Owner override/firing authority is the Ruin-equivalent
  outcome (GM seat is vacated, franchise reverts to AI-GM or new human GM)
LeagueSyncScheduler: turn timers / async season resolution for asynchronous multiplayer

COMMISSIONER_ROLE (v31.1, Resolution Report Finding 5 — Architectural Flaw): every
  multiplayer league has a designated Commissioner — a human player role, or, in
  leagues without one, an automatic-enforcement default. Holds veto/reversal authority
  over transactions flagged by Module 32's COLLUSION_DETECTOR, subject to that module's
  anti-weaponization safeguard.

GM_REPUTATION_PERSISTENCE (v31.1, Resolution Report Finding 6 — Architectural Flaw): a
  human player's GM-level track record — cumulative Legacy Score contributions, Front
  Office Reputation history, and OwnerPatience Ruin events — persists with that PLAYER
  ACCOUNT across franchise seats within the same league, not just with the franchise
  currently seated. Closes the "get fired on purpose, walk away clean" exit hatch: a
  player who triggers an OwnerPatience Ruin carries a visible seat-history flag into any
  future seat they take in that league. FAIRNESS REFINEMENT: this flag distinguishes
  honest failure from negligent abandonment by reading RiskState's own
  strategic_decision_log (Module 2.7) for that Ruin event — a Ruin reached after
  genuinely attempting available Strategic-tier mitigations reads differently in seat
  history than one reached by declining every available mitigation. The system already
  tracks the data needed for this distinction; this fix only requires surfacing it.

SIMULTANEITY_GUARANTEE (v31.1, Resolution Report Finding 9 — Architectural Flaw): any
  competitive action carrying real information value if revealed early — free agency
  bids, pending trade offers — resolves within a blind, simultaneous-reveal window
  managed by LeagueSyncScheduler. All participating human players' submissions are
  locked and hidden until the window closes, then revealed and resolved together — the
  same snapshot-based simultaneous-resolution pattern the End-of-Season Resolution
  Layer (Module 2.14) already uses at the season timescale, applied here at the
  transaction-window timescale.

31.3 Stress Test

Can players exploit this? Two friendly real players (Owner + GM) could simply agree never to invoke the friction mechanics, making the split cosmetic — this isn't treated as an exploit, since not every group wants forced conflict; recommending a configurable friction intensity setting per league rather than forcing the tension.

A separate, real risk: could human-controlled franchises collude on trades to unfairly benefit one save's "meta" team? This is explicitly not this module's problem to solve — flagging it directly to Module 32 (Anti-Exploitation Systems), which must own human-vs-human collusion/tampering detection specifically, since it doesn't apply to single-player or AI-vs-AI contexts.

Will AI break this? AI franchises fill empty seats in multiplayer leagues identically to single-player, with no special-cased logic.

Will this stay interesting after 40 seasons? The co-op Owner/GM friction directly restores the dramatic axis flagged as lost in Module 1, in exactly the mode designed to carry it.

31.4 Implementation Notes

• CoOpFranchiseSeat, OwnerPatience (RiskState instance), LeagueSyncScheduler.
• FrictionIntensityConfig — per-league toggle, addressing the collusion-by-agreement stress-test finding.

31.5 Dependencies

• Module 4 — Owner Trust/governance mechanics this module extends into a two-seat structure.
• Module 32 — owes human-vs-human collusion detection.

31.6 Version History

MODULE 32: ANTI-EXPLOITATION SYSTEMS

32.1 Design Layer

This module is explicitly an integration and audit module, not a source of original mechanics — it consolidates and formally owns every anti-exploit flag raised across Modules 1–31: tanking deterrence (Module 3), lopsided-trade defense (Module 17, though largely closed via Module 11's reputation reuse), human-vs-human collusion detection (Module 31), tampering-period violations (Module 16), and ongoing monitoring for emergent cap-circumvention loopholes beyond Module 6's hard restructure limit.

32.2 Systems Layer

TANKING_DETECTOR: flags benching a healthy starter late in a lost season WITHOUT
  legitimate development justification. Explicit carve-out: benching a veteran for a
  rookie at the same position, in a lost season, with the rookie's snap count trending
  upward over prior weeks, does NOT trigger the penalty — this is legitimate development,
  not tanking
  → triggers Owner Trust penalty (Module 4) when flagged

ROSTER_INVESTMENT_DETECTOR (v32.1, Resolution Report Finding 2 — Contradiction): flags
  a franchise whose Scouting Budget, Facility Tier, and Coaching/Coordinator
  competence-tier hiring are ALL simultaneously below their MARKET-TIER-ADJUSTED
  expected level (not flat league-median — a flat median would falsely flag legitimate
  small-market rebuilds, which Module 5.3 explicitly protects as intentional design,
  not an exploit) for 2+ consecutive seasons, while accumulated draft capital over that
  same window is not being converted into measurable on-field competitiveness
  improvement (tracked via Franchise Valuation's competitive_success_trend, Module 29).
  Triggers the same Owner Trust penalty as TANKING_DETECTOR. Runs alongside, not instead
  of, the bench-based detector — together they fulfill Module 3.3's "full anti-tank
  enforcement" commitment to Module 32.

COLLUSION_DETECTOR (multiplayer-specific): statistical anomaly detection on trade-value
  ratios between specific human-controlled franchise pairs over time, flagging
  suspicious patterns for commissioner review — does not apply to single-player or AI

COLLUSION_ENFORCEMENT (v32.1, Resolution Report Finding 5 — Architectural Flaw): a
  transaction flagged by COLLUSION_DETECTOR enters a review window (default: one
  in-game week, or 48 real-world hours — whichever the league's LeagueSyncScheduler
  pacing makes more natural), during which the league's designated Commissioner
  (Module 31.2) may reverse it. If no Commissioner is designated, flagged transactions
  are AUTOMATICALLY reversed pending review by default — detection without a human
  reviewer must fail safe toward prevention, not silent approval. ANTI-WEAPONIZATION
  SAFEGUARD: because automatic reversal is itself a lever a bad-faith actor could abuse
  to grief honest trading partners via repeated false-positive triggers, a franchise
  that has 2+ of its OUTGOING trade proposals reversed by this system within a single
  season loses standing to trigger further automatic reversals that season (falls back
  to flag-for-review only) — the detector protects against collusion, but the
  reversal mechanism itself must not become a new griefing tool.

CAP_LOOPHOLE_MONITOR: periodic audit pass (tied to Module 33's tuning cycle) to catch
  emergent exploit combinations arising from interactions BETWEEN systems that no single
  module's stress test could have anticipated in isolation

32.3 Stress Test

Can players exploit this? The main risk within this module itself: false-flagging legitimate development-focused benching as tanking. The explicit carve-out above (rookie at same position, trending snap count, lost season) directly addresses this.

Will AI break this? Penalties apply to AI franchises exhibiting identical behavior patterns.

Will this stay interesting after 40 seasons? This module is meant to be revisited on an ongoing basis, not completed once — new exploit combinations may emerge from interactions between the other 34 modules over a project's real production lifetime, tied directly to Module 33's tuning cycle rather than being a one-time deliverable.

32.4 Implementation Notes

• TankingDetector (with explicit legitimate-development carve-out logic).
• CollusionDetector (multiplayer-scoped only).
• CapLoopholeMonitor — recommend this run as a periodic automated audit against the AutoSimTestHarness from Module 33, not just a manual review process.

32.5 Dependencies

• Module 3, 4 — tanking deterrence enforcement point.
• Module 11, 17 — reputation-based trade defense (already largely closed there).
• Module 31 — collusion detection is exclusively relevant here.
• Module 33 — ongoing audit cadence.

32.6 Version History

MODULE 33: BALANCING

33.1 Design Layer

This module doesn't invent new mechanics — it formally owns every "config, subject to Module 33 balancing" flag scattered across Modules 1–32 (cap collar percentage, realignment cadence, HOF voting weights, Legacy Score weights, every RiskState threshold, and more) as a single, consolidated tuning-variable registry. The balancing philosophy: no mechanic should have a single dominant path to victory, verified via simulated many-season auto-played leagues that detect statistical dominance of any one strategy archetype over a long time horizon, feeding results back into config tuning both pre-launch and via post-launch patches.

33.2 Systems Layer

TuningVariableRegistry: master config table referencing every flagged variable across
  Modules 1-32 (a literal cross-reference index, not a new mechanic)

AutoSimTestHarness: runs many simulated seasons/saves with varied AI Personality/
  Competence distributions (Module 24) to detect statistical strategy dominance,
  both pre-launch and as an ongoing post-launch patch-validation tool. [v33.1,
  Resolution Report Finding 3] Must include a human-proxy-skill benchmark mode —
  a defined "average-skill" decision policy simulated against AI-vs-AI baselines —
  to verify Module 24.2's AI_DIFFICULTY_CALIBRATION_GUARDRAIL, distinct from this
  harness's existing dominant-strategy-archetype detection.

33.3 Stress Test

This module is the formalized stress-testing process for the rest of the Bible, so its own stress test is a single hard constraint: balancing changes must never violate Invariant 1 or 2 in service of a fix — a hidden AI-only buff disguised as a "balance patch" would be a direct constitutional violation, not an acceptable trade-off, no matter how elegantly it solved a dominance problem.

Will this stay interesting after 40 seasons? Ongoing, transparent balance patches — modeled in-fiction as periodic league rule-committee adjustments (tying back to Module 4's governance mechanic) — are themselves a legitimate, telegraphed meta-shift mechanism supporting Failure Mode A's fix, as long as they're always visible and explained, never silent.

33.4 Implementation Notes

• TuningVariableRegistry — should be built as engineering work begins on each module's Engineering Specification, not deferred to the end; recommend populating it incrementally as each module's Implementation Notes get extracted (see Module 35).
• AutoSimTestHarness — a genuinely significant engineering investment in its own right; flagging it as a priority early build target since every other module's real-world balance depends on it existing before launch, not after.

33.5 Dependencies

Every module in the Bible, in the sense that every module contributes at least one tunable variable to the registry.

33.6 Version History

MODULE 34: UI/UX

34.1 Design Layer

Must implement the Decision Taxonomy's tier-differentiated treatment (Module 2.3): Strategic decisions get full-screen dedicated moments, Tactical decisions get contextual panels, Operational decisions never interrupt flow. Requires a delegation dashboard (Module 11) with clear drift-risk visibility, and — given how many modules independently instantiate the RiskState pattern (Owner Trust, Cap, Hot Seat, Fan Loyalty, Injury, Valuation, Owner Patience) — a single reusable RiskState visualization component (severity meter, time-to-ruin countdown, available mitigations) rather than seven bespoke UI treatments. The Story Engine (Module 25) needs a presentation layer (media hub, press conferences, headlines). Critically, this module must deliver scalable complexity — veteran-mode versus streamlined-mode UI density — as the direct interface-layer answer to Failure Mode E, since even a perfectly-designed mechanical system fails the 25–50 season goal if the UI makes managing it exhausting by hour 40.

34.2 Implementation Notes

(This module is naturally implementation-heavy at the Design Layer already — merging rather than separating the two for this module.)

• RiskStateWidget — one reusable component instantiated seven-plus times across the Bible; building this once, well, is disproportionately high-leverage relative to almost any other single UI element.
• DecisionTierRouter — UI flow control keyed off Module 2.3's decision_tier field.
• DelegationDashboard (Module 11).
• MediaHub (Module 25 presentation layer).
• Hard requirement: smart search/filter over Module 26's League History ledger — a chronological-scroll-only interface will not remain navigable across a 25–50 season save's accumulated data volume.

34.3 Stress Test

Can players exploit this? Not an exploit-relevant layer — the real risk is usability-driven attrition, not exploitation. Flagging explicitly: UI complexity is arguably the single biggest risk to the entire 25–50 season promise, independent of how well-designed every underlying system is. A mechanically perfect Bible with an exhausting interface fails the core goal just as surely as a shallow one would.

34.4 Dependencies

Consumes from nearly every module; most directly Module 2 (Decision Taxonomy), Module 11 (delegation), Module 25 (Story Engine), Module 26 (History).

34.5 Version History

MODULE 35: TECHNICAL ARCHITECTURE

35.1 Design Layer / Scope Note

Per the earlier agreement in this document (see the Document Methodology note at the top of the Bible), the full Engineering Specification was deliberately deferred, not skipped — the plan was to extract it once every module touching a given subsystem was complete. All 35 modules are now complete, which means this module's real job is to (a) confirm that condition is met, (b) lay out the high-level architecture shape that every module's Implementation Notes have been pointing toward, and (c) formally kick off the extraction process — not to retroactively invent full database schemas for 34 modules of mechanics in this module's few paragraphs, which would produce false precision rather than real engineering value.

35.2 High-Level Architecture Recommendations

[Updated v35.1, Chief Architect Review — two items added below reflecting Module 2.13/2.14's new primitives.]

• Event-sourcing for League History (Module 26): the append-only ledger requirement is a natural fit for event-sourcing rather than a mutable-state database table — this should be a foundational architecture decision, not a later retrofit.
• Shared Event Bus (Module 2.13): the primary cross-subsystem communication backbone — subsystems publish, never directly mutate one another's state. LeagueHistoryLedger is a natural persistent subscriber; the Story Engine (Module 25) is subscribe-only by construction, never issued a publish credential for simulation-state events, which structurally guarantees Invariant 6 rather than relying on convention.
• Generalized State Machine Framework / shared RiskState service (Module 2.7): instantiated independently by at least seven systems (Owner Trust, Cap, Hot Seat, Injury, Fan Loyalty, Valuation, Owner Patience) — should be built once as a shared internal service, not seven parallel implementations, mirroring the same reuse logic already applied at the design layer throughout Modules 4–31. Build it as the generalized primitive, not the narrower Crisis/Ruin-only version, since the generalization is now part of the design spec, not just an engineering nicety.
• End-of-Season Resolution Layer (Module 2.14): a required scheduled service sitting between in-season simulation (Module 23) and offseason systems (Draft, Free Agency, Contract renegotiation) — implements snapshot-based simultaneous resolution for the four founding cross-dependent metrics (Owner Trust, Fan Loyalty, Front Office Reputation, Hot Seat) and any future metric registered into it.
• Parallelized AI franchise simulation: Module 24's Invariant-2 compute-parity requirement (no AI shortcut logic) means all 32 franchises' decision cycles should be architected as identical-logic-path parallel workers from the start — treating this as a performance-optimization afterthought risks quietly reintroducing the AI-shortcut problem Module 24 explicitly warned against. Per Module 24.1's build-process clarification, this also means AI-parity code paths ship with each subsystem, not as a follow-up integration pass.
• Save-file schema versioning: a 25–50 season save will very plausibly outlive multiple real-world game patches. Save architecture needs to support forward-compatible schema migration from day one, not be retrofitted after the first breaking content update.

35.3 Stress Test / Honest Scope Statement

Full database schema and API design for all 35 modules is a substantial follow-on engineering effort in its own right, beyond what this Bible can responsibly produce inline — but every module's Implementation Notes section across this document gives an engineer a legitimate, real starting map, not a vague pitch-deck gesture at "there will be a database."

35.4 Next Step: The Extraction Pass

This is the formal trigger point promised earlier: with all 35 modules complete, the next step is a dedicated Systems Specification extraction pass (pulling every module's Systems Layer into one standalone document with full formulas/algorithms), followed by an Engineering Specification built subsystem-by-subsystem, starting with the shared services identified above (RiskState, League History event store, AI parallel simulation) since they're depended on by the largest number of other systems.

35.5 Version History

END OF GAME DESIGN BIBLE — ALL 35 MODULES COMPLETE