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

Document 19 · Gridiron Legend

Engineering Impact Ledger

v2.0 passProvisional

GRIDIRON LEGEND

Engineering Impact Ledger

Running log of engineering implications surfaced during the v2.0 Design Expansion Pass. Not an engineering document itself — a record of what will need reconciliation once the design is stable and the true Design Freeze is declared.

Purpose

Per Expansion Rule 5: engineering implications are recorded here as they're discovered, but the Database, API, Backend, and Frontend Architecture documents are not touched during this pass. This ledger is the single place all of that deferred work accumulates, so nothing is lost between now and the eventual reconciliation (Completion Order, Step 13).

Entry Format

### [Module] — [Date/Pass reference]
Engineering Document(s) Affected: Database | API | Backend | Frontend | Systems Spec
Nature of Impact: New aggregate | Modified aggregate | New event type | New command/query |
  New service | Schema change | Reconciliation needed with existing artifact
Description: what changed in the design and what it implies for that document
Severity: Low | Medium | High | Structural (requires rethinking an existing pattern)

Entries

v1.4 Pass (Modules 11–15, first expansion round) — retroactively logged

Module 11 — Front Office (v1.4, 8 executives)

  • Engineering Document(s) Affected: Database, API, Backend, Frontend
  • Nature of Impact: Modified aggregate — the existing FrontOffice aggregate (one AssistantGM reference) no longer matches the design
  • Description: 8 named executives, each needing an Executive aggregate with shared schema (Ratings, Experience, Loyalty, Personality, Philosophy, Reputation, Career Progression). Career Progression as a StateMachineFramework configuration is new engineering surface — the framework exists (Database Architecture, Section 2.1 equivalent) but has never been instantiated for a non-risk use.
  • Severity: Structural — this is the single largest reconciliation item flagged even before the v2.0 pass's further expansion to 10 executives.

Module 12 — Medical Staff (v1.4, 5 roles + Practice Injuries)

  • Engineering Document(s) Affected: Database, Backend
  • Nature of Impact: Modified aggregate, new event type
  • Description: MedicalStaff aggregate decomposed into 5 role-specific sub-ratings. Practice Injuries is a genuinely new simulation event category needing its own Backend Scheduler trigger (a practice-phase hook the current Simulation Scheduler design doesn't have).
  • Severity: Medium-High.

Module 13 — Draft System (v1.4, Pro Days/Interviews/Wonderlic/Bust-Boom)

  • Engineering Document(s) Affected: Database
  • Nature of Impact: Additive fields on existing aggregates
  • Description: Prospect object needs separate error-band fields per hidden-trait dimension (Character, Leadership, Football IQ, Injury Flags) rather than one undifferentiated band.
  • Severity: Low — smallest engineering footprint of the five v1.4 modules, by design (extends an already-proven pattern).

Module 14 — College Pipeline (v1.4, full simulated college season)

  • Engineering Document(s) Affected: Database, Backend
  • Nature of Impact: New aggregates, new domain surface area
  • Description: CollegeConference, CollegeGame (result-only, no play data), CollegeBowlBracket don't exist in the current schema at all. HeismanEquivalentVoting reuses the HOF voting service pattern but is a new service instance. This is flagged as the largest single reconciliation item in the whole v1.4 pass.
  • Severity: Structural.

Module 15 — Player Development (v1.4, Confidence/Mentorship/Football IQ/Position Coaches)

  • Engineering Document(s) Affected: Database
  • Nature of Impact: Additive fields, new relationship structure
  • Description: Player object gains confidence, separate football_iq trajectory. MentorshipTree reuses CoachingTreeEdge's pattern — low incremental engineering cost since it's explicitly modeled as a reuse, not a new structure.
  • Severity: Low-Medium.

v2.0 Pass — entries added as each module is reworked

Module 11 — Front Office (v1.5, 10 executives, full rework)

  • Engineering Document(s) Affected: Database, API, Backend, Frontend
  • Nature of Impact: Structural — the FrontOffice/Executive aggregate design from v1.4 needs complete rework, not incremental extension
  • Description: 10 executives (up from 8), 3-tier Decision Authority model (AdvisoryOnly/BoundedExecution/StrategicExecution/FullyTacticalDelegable) needs its own field/enforcement layer at the command-authorization level (API Architecture, Section 8's authorization model will need a new tier scheme, not just role-count expansion). Information Access scoping per role is new — several roles now have explicitly partial visibility into hidden data, which the current Database Architecture's access-control model (built around franchise-scoped vs. player-account-scoped visibility) doesn't yet have a category for. Cross-Team Evaluation (Director of Pro Personnel) is a genuinely new service — evaluating hidden attributes of other franchises' players, reusing the Fog-of-War pattern but requiring read access across franchise boundaries in a way no existing service currently does (every existing cross-domain read in the API Architecture, e.g. GetCapSpaceSummary, reads a franchise's own aggregate; this is the first case of reading another franchise's player-hidden-data by design). Pairwise Conflict/Cooperation (5 named pairs) replaces v1.4's single aggregate Cohesion calculation — needs its own data model (a small relationship-matrix structure, not a scalar field) and its effects are domain-specific (touches draft quality, contract quality, Hot Seat threshold — three different existing systems) rather than a single multiplier applied uniformly.
  • Reconciliation also required with Module 10: ScoutingDepartment aggregate's reporting structure changes (Regional Scouts/Position Specialists → Director of College Scouting; Pro Scouts → Director of Pro Personnel); Module 10's original "Scouting Director" role/title is retired.
  • Severity: Structural — the single largest engineering rework item logged in this ledger so far, larger than the v1.4 pass's original Module 11 entry.

(Further entries added as Modules 12, 14, 13, 15, and the Module 8–10 reconciliation are completed, per the Impact Map's dependency order.)

Course Correction — League Structure (Module 3, v1.5)

Module 3 — League Structure (v1.5, 4-of-4 → 3-division 6-5-5 rework)

  • Engineering Document(s) Affected: Database, Backend, Systems Specification (all three previously extracted/built against the old 4-of-4 assumption)
  • Nature of Impact: Structural — this is the exact scenario Resolution Report Finding 7 and the Database/Backend Architecture documents already flagged as "not a one-line fix." It has now actually happened.
  • Description: Division needs a size field rather than an assumed constant. ScheduleGenerator needs division-size-branching logic (10 vs. 8 division games, 2/2 vs. 3/3 rotation games) rather than one fixed formula. PlayoffSeedingCalculator needs 3-auto/4-wildcard logic instead of 4-auto/3-wildcard. The Systems Specification's Phase 0/3 dependency notes (already flagged as provisional pending the wider v2.0 pass) now also carry this change.
  • Severity: Structural — this is the single item every prior engineering document specifically warned would be expensive if it happened. It has happened. Full reconciliation is deferred, per your instruction, to the eventual Systems/Engineering Specification rebuild after Design Freeze — this entry exists so it isn't rediscovered as a surprise at that point.

This ledger grows for the duration of the v2.0 Design Expansion Pass. It is consulted, not rebuilt from, when the true Design Freeze triggers full Systems/Engineering Specification reconciliation.