Lesson 30: Multi-Patch Rolling Stability Dashboard for Release-Train Aggregation
Lesson 29 gave you a two-week tracker per promoted build.
Shipping AI-heavy RPGs rarely stops at one patch. You get a train of small releases: hotfixes, balance passes, dialogue prompt tweaks, and dependency bumps. If each patch only exists inside its own fourteen-day sheet, you lose the cross-patch story: recurring yellows, slow-burn regressions, and dialogue drift that only shows up after the second or third change.
This lesson adds a multi-patch rolling stability dashboard that aggregates tracker rows without replacing your Lesson 28 go or yellow or red briefing packet. Briefing stays per promotion. The dashboard answers a different question: is the release train healthy across time?
What You Will Build
By the end of this lesson, you will have:
- A column-per-build grid that imports the closing state from each Lesson 29 tracker
- A rolling window rule (for example, last three promotions) so the sheet does not grow forever
- A yellow recurrence detector that flags the same mitigation theme twice in one window
- A one-page executive strip that never duplicates Lesson 28 evidence, only summarizes train health
Step 1 - Separate briefing from aggregation
Keep these artifacts distinct:
| Artifact | Owned by | Cadence |
|---|---|---|
| Lesson 28 briefing packet | Release captain | Each promotion decision |
| Lesson 29 fourteen-day tracker | Live-ops owner | Each promoted build |
| Lesson 30 rolling dashboard | Product plus engineering | Continuous across builds |
If you merge them, stakeholders will confuse decision-time evidence with trend monitoring. That confusion creates either too many meetings or false calm.
Step 2 - Define the minimum row set you aggregate
From each closed Lesson 29 file, copy only:
- build ID or semantic version
- promotion date
- final yellow count (open versus closed)
- top stability signal (crash-free sessions proxy or your chosen KPI)
- dialogue or AI health signal (error rate, moderation flags, or human QA score)
- one-line train note (what changed in this patch)
Do not paste full log links into the dashboard body. Link outward once per column to your evidence store.
Step 3 - Build the rolling window mechanically
Pick a window length your team will actually maintain:
- Three promotions is a good default for small teams
- Stretch to four only if your release cadence is slower than two weeks between ships
When a fourth column appears, archive the oldest column to a cold tab or CSV so the main view stays readable.
Step 4 - Add yellow recurrence rules
Create a simple rule engine you can scan in ten seconds:
- Repeat same mitigation label twice in the window -> flag
recurrence risk - Yellow count increases two columns in a row while player sentiment is flat -> flag
measurement drift - Dialogue health improves but stability worsens -> flag
tradeoff review
These flags are not accusations. They are scheduling hints for the next Lesson 28 packet focus areas.
Step 5 - Publish the executive strip
Across the top of the dashboard, maintain five cells only:
- Train status (green, yellow, red) for the whole window, not per build
- Open yellow themes (max three bullets)
- Next hard gate (date plus decision type)
- AI-specific risk (model or prompt change in flight)
- Owner for the next update
This strip should be paste-safe into email or chat without editing.
Mini Exercise
Create rolling_stability_train.csv with:
- header row:
build_id,promotion_date,yellow_open_close,stability_signal,dialogue_signal,train_note,recurrence_flag - three mock builds with one intentional recurrence flag set to true
Compare your executive strip against the mock data. If the strip is longer than five bullets total, trim until it fits.
Troubleshooting
The dashboard becomes a wall of numbers
You added too many raw metrics. Roll up to at most two numeric signals per build column plus flags.
Teams stop updating Lesson 29 because the dashboard exists
Make Lesson 29 completion a merge gate for column entry. No closed tracker, no new column.
Executives ask for the briefing packet again
Point them to Lesson 28 for decision evidence. Offer the executive strip plus one link bundle, not a second packet.
FAQ
How is this different from a generic BI dashboard
This dashboard is opinionated to the Lesson 29 row contract, so you cannot silently swap metrics mid-train without noticing.
Do we need tooling beyond spreadsheets
No. A shared spreadsheet or Notion table is enough until you outgrow three rolling columns.
What if we ship two builds inside one Lesson 29 window
Treat them as one logical column with two build IDs in the cell, or reset Lesson 29 per the hotfix rule from Lesson 29 FAQ, then add one aggregated column.
Lesson Recap
You can now:
- aggregate post-patch stability across a release train
- spot recurring yellow themes before they become emergencies
- keep Lesson 28 briefing packets single-purpose
- communicate train health in one short strip
Next Lesson Teaser
Continue with Lesson 31: Rolling Stability Dashboard CSV Export and Webhook Ingest Automation to add scheduled CSV ingest and optional signed webhooks without losing the Lesson 29 row contract.
Related Learning
- Lesson 26: Analytics Confidence Review and Live-Ops Handoff
- Lesson 27: Release-Week Incident Retro Template for Telemetry and Owner Alignment
- Lesson 28: Patch-Readiness Briefing Packet for Go Yellow Red Sign-Off
- Lesson 29: Two-Week Post-Patch Confidence Tracker for Yellow Mitigation Closure and Live Stability
- How to Run a Launch-Day Command Center Without Burnout
Bookmark this dashboard template the first week you run overlapping patches on a live RPG branch.