Start Building

Lesson 45: Cross-Incident Trend Rollup and Leadership Recurrence Heatmap for RPG Live-Ops

Lesson 44 gave you structured recurrence watches. The missing piece is class-level visibility: leadership needs to see whether recurrence risk is shrinking, flat, or compounding across incidents.

In this lesson, you will build a trend rollup that translates watch-level rows into one decision surface for weekly risk review and launch control.

Fish illustration for cross-incident trend rollup lesson

What you will build

By the end of this lesson, you will have:

  1. A cross_incident_trend_rollup.csv contract that aggregates recurrence classes by week
  2. A weighted recurrence score that separates low-noise watch chatter from real risk growth
  3. A leadership heatmap view with clear green, yellow, and red gates
  4. A lane-owner escalation checklist for trend spikes that reopen portfolio-level risk

Step 1 - Define recurrence classes and weighting

Create stable classes so the same signal family is grouped across incidents:

  • crash_runtime
  • vendor_latency
  • payment_or_refund
  • data_compliance
  • player_trust

Assign one default severity weight per class (for example, 1, 2, or 3) and document who can override it. Keep overrides rare and time-bounded.

Step 2 - Author cross_incident_trend_rollup.csv

Use this minimum schema:

column purpose
week_start_utc reporting bucket start
recurrence_class normalized class key
active_watch_count open watches in class
reopen_count reopened incidents in class
new_plus_linkback_count new incidents linked to prior lineage
weighted_risk_score (active_watch_count + reopen_count * 2 + new_plus_linkback_count) * severity_weight
highest_state green, yellow, red
owner_lane accountable lane for this class
action_due_utc next required review timestamp

Pro tip: Keep formulas in plain language beside the table so non-technical reviewers can verify score behavior quickly.

Step 3 - Build the leadership recurrence heatmap

For each class, show four weeks side by side:

  • score trend
  • state trend
  • reopen share
  • unresolved action age

Color rules:

  • green: score stable or declining, no overdue actions
  • yellow: score rising for two weeks or one overdue action
  • red: reopen count spikes and action age breaches your SLA

This prevents "single scary chart" decision making and keeps accountability tied to class ownership.

Step 4 - Add escalation gates and owner routing

Create a short escalation map:

  1. If class becomes yellow, owner posts mitigation plan before next review
  2. If class remains yellow for two cycles, force cross-lane review
  3. If class turns red, block promotion decisions until an explicit reopen or containment call is logged

Link each escalation row to your incident lineage fields (parent_incident_id, watch_id, closure_packet_version) so every trend spike can be traced back to real packets.

Step 5 - Publish a weekly decision packet

Include this packet in your weekly risk ritual:

  • top three class changes
  • one sentence on why each class moved
  • owner and due date for each non-green class
  • launch impact (none, watch, block)

If your patch cadence is busy, keep this packet compact and pair it with How to Build a Weekly Live-Ops Risk Review in 45 Minutes to protect decision time.

Common mistakes

Mistake: Blending unlike classes into one score

Fix: score per class first, then show an overall summary row as a secondary indicator.

Mistake: Treating unresolved actions as neutral

Fix: action age must influence state. Old unresolved items are risk even when raw volume is low.

Mistake: Reporting trend without lineage references

Fix: include watch_id and parent_incident_id drill-down links in every review packet.

Pro tips

  • Keep a fixed four-week view so trend interpretation stays consistent.
  • Cap manual score overrides to one cycle unless re-approved.
  • Review class definitions monthly to avoid taxonomy drift.

Mini challenge

  1. Create three rows in cross_incident_trend_rollup.csv for two classes over one week.
  2. Compute weighted_risk_score using your class weights.
  3. Mark one row yellow and write a one-line owner action with due timestamp.

FAQ

Should this replace individual incident review?

No. This rollup is a portfolio lens. Incident-level packets still drive root-cause and remediation decisions.

How many classes should a small team track?

Start with four to six. Too many classes dilute ownership and hide true risk movement.

What if one vendor affects multiple classes?

Keep class-level rows separate, then add a weekly note tying shared vendor impact across classes.

Lesson recap

You now have a repeatable cross-incident trend rollup that converts recurrence watches into leadership-level risk signals without losing lineage traceability.

Next lesson teaser

Continue with Lesson 46: Quarterly Recurrence Audit Pack for Release Windows and Capacity Planning in RPG Live-Ops to convert weekly trend signals into quarter-level release and staffing recommendations.

Related learning