GRIDIRON LEGEND

Phase 2.5 — Resolution Report

Purpose

This document resolves every issue identified during the Comprehensive Stress Test. It is not a redesign. It introduces no new gameplay unless absolutely necessary. Its purpose is to produce a Bible ready for Engineering Specification.

Status: all Accept decisions below have been applied directly to the locked Bible and the Systems Specification, under the Bible's own three-category reopen policy (bug / contradiction / architectural flaw). Every affected module carries a version bump and a categorized version-history entry. This is not a proposal document — it's a record of what was done.

Finding 1

Stress Test Summary Void years — a pure cap-deferral tool with no on-field meaning — had no stated limit, while the functionally equivalent restructure mechanism was hard-capped at 2 per contract. Same category of tool, inconsistent treatment.

Classification Contradiction

Decision Accept

Resolution Hard limit of 2 void years per contract, mirroring the restructure limit. Dead cap from void years accelerates into the first season following contract expiration, exactly as a standard-designation cut would.

Bible Modules Updated Module 7 (v7.1)

Systems Specification Changes Contract object: void_years field annotated with the hard-max-2 constraint. CapLedger primitive updated to include void_year_count alongside restructure_count.

Engineering Impact Low

Regression Risk Low. Self-contained to Contract/Cap accounting; no other module reads void_year_count.

Status Resolved

Finding 2

Stress Test Summary Module 3 explicitly promises "full anti-tank enforcement is Module 32's job," but Module 32's TANKING_DETECTOR only catches one method (benching a healthy starter without development justification). A sophisticated tanker — underspending on scouting, facilities, and coaching without ever benching anyone — pays no penalty at all.

Classification Contradiction

Decision Accept

Resolution Added ROSTER_INVESTMENT_DETECTOR: flags sustained (2+ season) underinvestment across Scouting Budget, Facility Tier, and Coaching competence-tier, combined with no competitive improvement despite accumulated draft capital. Refined during application to use a market-tier-relative threshold rather than a flat league-median one — a flat median would have false-flagged legitimate small-market rebuild strategies, which Module 5.3 explicitly protects as intentional design.

Bible Modules Updated Module 32 (v32.1)

Systems Specification Changes No new primitive; TankingDetector scope note expanded wherever cited.

Engineering Impact Medium

Regression Risk Medium, mitigated. The unmitigated version of this fix would have regressed against Module 5.3's small-market design intent — caught and corrected before application, not after. Residual risk is low with the market-tier-relative threshold in place, but the threshold's exact calibration is still deferred to Module 33.

Status Resolved

Finding 3

Stress Test Summary Module 23's Game Simulation Engine has an explicit, hard calibration guardrail (a favored team must win meaningfully above 50%). Module 24's AI Decision Logic has no equivalent — rule parity (Invariant 2) guarantees AI plays by the same rules, but nothing guarantees the resulting difficulty is fair to an average-skill human.

Classification Architectural Flaw

Decision Accept

Resolution Added AI_DIFFICULTY_CALIBRATION_GUARDRAIL: requires Module 33's AutoSimTestHarness to verify an average-skill human player's win rate falls within a defined band of AI-vs-AI baseline performance, as a correctness requirement rather than a tunable preference.

Bible Modules Updated Module 24 (v24.2), Module 33 (v33.1)

Systems Specification Changes Section 2.3 (AI Rule Parity) — added a line distinguishing rule-parity (guaranteed) from difficulty-calibration (now also required, verified via harness).

Engineering Impact Low

Regression Risk Low. Purely a testing/tuning requirement addition; no runtime behavior changes as a result of this fix alone.

Status Resolved

Finding 4

Stress Test Summary Front Office Reputation deliberately tracks multi-season trends, not single deals, to prevent gaming reputation upward with one clean transaction. That same design choice means a single severely predatory trade barely moves a trend average — a team can burn a relationship once for real value and pay almost no reputation cost.

Classification Architectural Flaw

Decision Accept

Resolution Added SEVERITY_WEIGHTING: a single transaction exceeding a severe-outlier value-asymmetry threshold applies an immediate, larger one-time penalty alongside the trend update. Refined during application to add an explicit rebuild carve-out — a transaction is exempt if the disadvantaged side's own Strategic Decision log shows a declared rebuild pattern, so the fix catches predation against an unwitting counterparty without penalizing legitimate rebuild-motivated sales.

Bible Modules Updated Module 11 (v11.1)

Systems Specification Changes FrontOfficeReputation object: added severe_outlier_penalty_log[] field.

Engineering Impact Low

Regression Risk Medium, mitigated. Unmitigated, this would have penalized legitimate rebuild trades that look lopsided by raw value. The carve-out reuses Module 2.7's existing strategic_decision_log rather than inventing new tracking, keeping the fix consistent with established patterns.

Status Resolved

Finding 5

Stress Test Summary Module 32's COLLUSION_DETECTOR flags suspicious human-vs-human trade patterns for "commissioner review" — but no Commissioner role was ever defined anywhere in the Bible, and detection with no enforcement mechanism behind it is not actually a deterrent.

Classification Architectural Flaw

Decision Accept

Resolution Defined a COMMISSIONER_ROLE in Module 31 (human-held, or automatic-enforcement default if undesignated) with veto/reversal authority over flagged transactions within a review window. Refined during application to add an anti-weaponization safeguard: a franchise whose outgoing trades get reversed 2+ times in a season loses standing to trigger further automatic reversals that season, falling back to flag-only — otherwise the enforcement mechanism itself becomes a new griefing tool.

Bible Modules Updated Module 31 (v31.1), Module 32 (v32.1)

Systems Specification Changes Added Commissioner role reference to Front Office/League object family. Event Bus (2.8) — added TransactionFlaggedForReview / TransactionReversed event types.

Engineering Impact High

Regression Risk Medium-High, mitigated. The auto-reversal mechanism, unmitigated, would have been directly exploitable as a griefing tool against honest players via repeated false-positive triggers — caught during application and closed with the anti-weaponization safeguard. Transaction reversal itself is a nontrivial capability (see Engineering Impact) that needs first-class design in the Engineering Specification, not a bolt-on.

Status Resolved

Finding 6

Stress Test Summary In multiplayer, a human GM who mismanages a franchise into Owner Patience Ruin has their seat vacated with no specified consequence that follows them personally — a potential "get fired on purpose, walk away clean" exit hatch with no single-player analog (a fused Owner-GM can't fire themselves).

Classification Architectural Flaw

Decision Accept

Resolution Added GM_REPUTATION_PERSISTENCE: a human player's GM-level track record (Legacy Score contributions, Front Office Reputation, OwnerPatience Ruin history) persists with their player account across franchise seats in the same league, not just with the franchise. Refined during application to distinguish honest failure from negligent abandonment by reading the Ruin event's own strategic_decision_log (Module 2.7) — a Ruin reached after genuinely attempting available mitigations reads differently in seat history than one reached by declining every mitigation offered. The data needed for this distinction already existed; the fix only required surfacing it.

Bible Modules Updated Module 31 (v31.1)

Systems Specification Changes Owner/Front Office objects — added explicit distinction between franchise-scoped and player-account-scoped reputation data.

Engineering Impact Medium

Regression Risk Medium, mitigated. Unmitigated, this would have unfairly stigmatized honest failure (a genuinely difficult rebuild that fails despite real effort) the same as negligent abandonment. Resolved by reusing existing RiskState infrastructure rather than adding a new, cruder tracking mechanism.

Status Resolved

Finding 7

Stress Test Summary Module 5's national revenue formula is literally hardcoded as league_media_pool / 32; the Board of Governors is hardcoded to "32 votes"; Module 24's scheduler assumes "all 32 franchises." Module 3's expansion mechanic permits new franchises indefinitely with no stated ceiling and no contraction mechanic. At a 100-season horizon, the math directly breaks — this is a literal contradiction between two parts of the same document, not a judgment call.

Classification Contradiction

Decision Accept

Resolution Added an explicit franchise-count ceiling (config, provisional 40) to Module 3, tied to the existing realignment mechanism rather than inventing a new one. Converted the hardcoded /32 formula (Module 5) and "32 votes" (Module 4) to dynamic CURRENT_FRANCHISE_COUNT references. Updated Module 24's scheduler description to match. Flagged, not silently minimized, during application: Module 3's ScheduleGenerator has a deeper structural assumption (4-teams-per-division × 4-divisions × 2-conferences) that a formula-level fix doesn't resolve — this is called out explicitly as a required Engineering Specification design item, not swept under the same fix.

Bible Modules Updated Module 3 (v3.1), Module 4 (v4.1), Module 5 (v5.1), Module 24 (v24.2)

Systems Specification Changes League object — added current_franchise_count and franchise_count_ceiling fields. Economy Ledger (2.5) — updated NATIONAL_REVENUE formula to match.

Engineering Impact High

Regression Risk High, partially unresolved by design alone. The formula-level fix is clean, but ScheduleGenerator's divisibility assumption is a genuine structural risk that this Resolution Report deliberately does not claim to have fully closed — it's flagged as a required Engineering Specification task instead of papered over with a false sense of completeness.

Status Resolved (design-layer fix applied; one sub-component — Schedule Generator's divisibility assumption — explicitly carried forward as a flagged Engineering Specification requirement, not silently closed)

Finding 8

Stress Test Summary Nothing confirms whether compounding cap/revenue growth across many media-rights cycles (12+ by season 100) is bounded/mean-reverting or monotonically increasing. This is a validation gap, not a demonstrated design defect.

Classification (Not classified as Bug / Contradiction / Architectural Flaw — this is an unvalidated assumption, not a confirmed defect, per your own original classification.)

Decision Defer

Resolution No Bible change. Logged as a new Open Engineering Question (#11) in the Systems Specification, requiring a dedicated long-horizon auto-simulation validation pass — reusing Module 33's AutoSimTestHarness — before Module 6/30's engineering implementation is finalized. If validation fails, that becomes a genuine new finding at that point, handled through the normal reopen process — not addressed preemptively now.

Bible Modules Updated None

Systems Specification Changes Added as Open Engineering Question #11.

Engineering Impact Low (validation task only — no build cost now)

Regression Risk None — no change was made.

Status Deferred to Engineering Validation

Finding 9

Stress Test Summary LeagueSyncScheduler is named but never specifies whether competitive asynchronous actions (free agency bids, trade offers) resolve with a simultaneous-reveal guarantee — a player submitting late could see what others already committed to.

Classification Architectural Flaw

Decision Accept

Resolution Added SIMULTANEITY_GUARANTEE: competitive actions with real information value resolve within a blind, simultaneous-reveal window — the same snapshot-based simultaneous-resolution pattern the End-of-Season Resolution Layer already uses at the season timescale, applied here at the transaction-window timescale.

Bible Modules Updated Module 31 (v31.1)

Systems Specification Changes Section 2.9 (End-of-Season Resolution Layer) — cross-referenced; Event Bus (2.8) — added BiddingWindowClosed event type.

Engineering Impact Medium

Regression Risk Low. Architecturally consistent with an already-specified pattern rather than a novel mechanism; doesn't touch single-player at all.

Status Resolved

Finding 10

Stress Test Summary The Story Engine fully specifies event detection, weighting, and threading, but says nothing about text-generation variety. Over a 25–50+ season save, recurring event categories (coach firings, blockbuster trades) could feel textually repetitive even though the underlying data is fresh.

Classification Architectural Flaw

Decision Accept

Resolution Added TEMPLATE_VARIETY_POOL: multiple distinct phrasing templates per recurring event category, pool size scaled to expected frequency, selection weighted toward variety rather than pure randomness.

Bible Modules Updated Module 25 (v25.2)

Systems Specification Changes Section 2.6 (Story Ledger) — added TemplatePool as an explicit component.

Engineering Impact Low (engineering only — flagged separately: this finding has a real content-production cost that engineering alone doesn't resolve, distinct from and in addition to the engineering estimate)

Regression Risk Low. Purely additive at the presentation layer; no mechanical interaction risk.

Status Resolved

Final Architecture Review

Are all contradictions eliminated? Yes. Three findings were classified as Contradiction (1, 2, 7); all three are Resolved. Finding 7's fix is the most significant in the report and was flagged, not hidden, as carrying one unresolved sub-component (Schedule Generator's divisibility assumption) forward into the Engineering Specification as an explicit task — this is a conscious scoping decision, not an oversight.

Is every exploit addressed? Yes, with two of the nine Accept fixes (Findings 2 and 5) requiring mid-application refinement after this review caught real regression risk in the first-draft fix itself — a false-flag risk against legitimate small-market rebuilds in Finding 2, and a griefing vector in Finding 5's own enforcement mechanism. Both were corrected before being applied, not after.

Is every architectural flaw resolved? Six findings were classified as Architectural Flaw (3, 4, 5, 6, 9, 10); all six are Resolved. Finding 4 and Finding 6 also required regression-driven refinement during application (rebuild carve-out; honest-failure distinction), applying the same scrutiny as Findings 2 and 5.

Is the Bible internally consistent? Yes, verified structurally — all 35 modules present and sequential, every version table's leading version number matches its module number, every fix carries an explicit [CONTRADICTION] or [ARCHITECTURAL FLAW] tag in its version-history entry per the lock policy's own requirement.

Is the Systems Specification synchronized? Yes. Every Bible change with a data-model or formula implication has a corresponding Systems Specification update: Contract and League object fields, the Economy Ledger's national revenue formula, three new Event Bus event types, and Open Engineering Question #11 for Finding 8.

Is the project ready for Engineering Specification? Yes, with one explicit carve-out already on record rather than hidden: Finding 7's Schedule Generator divisibility problem is real, flagged, and intentionally deferred to the Engineering Specification itself rather than falsely resolved here at the design layer. That's a scoping decision, not a gap in this report.

Engineering Readiness

Design Bible                          PASS
Systems Specification                 PASS
Architecture                          PASS
Stress Test                           PASS

Ready for Engineering Specification   YES