Start Building

Lesson 74: Waiver Renewal Promotion Decision Packet Template for Scorecard, Playbook, Corrective Acceptance, and Executive Exceptions in RPG Live-Ops

Lessons 72 through 73 gave you a scorecard and a playbook matrix. Neither artifact is enough for a promotion room if reviewers still chase links across five tools during the same meeting.

In this lesson, you will build one promotion decision packet template that merges the scorecard snapshot, playbook completion, corrective packet acceptance, and any executive exception into a single reviewer-facing bundle.

Pixel workspace illustration representing one consolidated decision surface for promotion reviewers

What this lesson solves

You need a packet that answers four questions without opening side chats:

  1. What closure reliability state did we believe at decision time, and for which window?
  2. Which escalation playbook rows were executed, and which gates cleared?
  3. Which corrective action packs reached accepted closure, with ids attached?
  4. If anything was promoted under exception, who approved it and where is the rationale stored?

Prerequisites: Lessons 71, 72, and 73.
Expected time: 95-115 minutes including one dry-run promotion review.

Start from the consolidated escalation framing in Lesson 73: Waiver Renewal Intervention Escalation Playbook Matrix for Closure Reliability Failure Modes Before Release-Gate Promotion in RPG Live-Ops so your packet fields stay aligned with playbook row ids.

What you will build

By the end of this lesson, you will have:

  1. A promotion_decision_packet_policy.md contract
  2. A promotion_decision_packet.csv row schema for one promotion decision
  3. A short packet assembly checklist your release ops can run in order
  4. Explicit rules for when an executive exception is allowed to appear in the same file as a green recommendation

Step 1 - Define packet policy scope

Create promotion_decision_packet_policy.md and lock:

  • which promotion types require this packet (production deploy, store submission, live toggles)
  • maximum age of attached scorecard snapshot relative to decision timestamp
  • whether executive_exception_present = true always forces promotion_decision = hold unless a named approver row exists
  • required minimum fields before the packet may be labeled complete

If "complete" is undefined, teams will mark packets done early to unblock calendars.

Step 2 - Design promotion_decision_packet.csv

Use one row per promotion decision event (not per lane). Suggested columns:

column purpose
promotion_packet_id stable id
promotion_window_id release or review anchor
closure_scorecard_snapshot_id Lesson 72 reference
closure_reliability_worst_band green, yellow, or red across reviewed lanes
dominant_failure_modes_summary short text or structured list
escalation_playbook_row_ids comma-separated Lesson 73 ids applied this window
playbook_gates_cleared machine-readable list matching Lesson 73 block_promotion_until
corrective_packet_ids_accepted Lesson 71 ids in accepted state
corrective_packet_acceptance_utc_latest latest acceptance timestamp among those ids
executive_exception_present true or false
executive_exception_approver_role empty unless exception is true
executive_exception_rationale_uri link or doc anchor, empty unless exception is true
executive_exception_expires_at_utc optional time box
promotion_reviewer_panel roles or names allowed to sign
promotion_decision promote, hold, or rollback_recommendation
promotion_decision_at_utc verdict timestamp
packet_template_version version stamp
packet_owner_ack accountable owner plus timestamp

This shape is intentionally wide so you cannot "forget" exception metadata when exceptions exist.

Step 3 - Assembly order (release ops checklist)

Publish a numbered assembly list:

  1. Freeze closure_scorecard_snapshot_id for the window under review.
  2. List playbook rows triggered by that snapshot and attach completion evidence per row.
  3. Attach corrective packet ids only if state is accepted; otherwise keep decision at hold.
  4. If any gate is bypassed, require executive exception fields before promote is allowed.
  5. Record promotion_decision_at_utc only after steps 1-4 are satisfied.

Order matters: skipping steps is how yellow branches become "verbal green."

Step 4 - Exception discipline

If executive_exception_present is true:

  • executive_exception_approver_role must be a single named role from your governance doc
  • executive_exception_rationale_uri must resolve to text, not a thread title
  • default promotion_decision should be hold until rationale and expiry are present

If your org forbids exceptions entirely, set policy to false always and delete the columns from your template in tooling, but keep the policy sentence so future teams do not reintroduce silent bypasses.

Step 5 - Dry-run one meeting

Take a historical yellow week:

  1. Fill the csv row from memory or archives.
  2. Identify one missing field that would have blocked promotion.
  3. Compare to what actually shipped.

If the dry-run does not surface at least one near-miss, your columns are too loose.

Success check

You are done when:

  • Reviewers open one packet and see scorecard, playbook, corrective acceptance, and exceptions in one traceable row
  • promote cannot be recorded without promotion_decision_at_utc and snapshot id
  • Exception metadata is either complete or decision stays hold

Common mistakes

Mistake: Treating the packet as a slide deck

Fix: the csv row (or equivalent record) is the system of record; slides are optional readouts.

Mistake: Allowing exceptions without expiry

Fix: add executive_exception_expires_at_utc or require a follow-up packet id for the next window.

Mistake: Mixing draft corrective packets into accepted lists

Fix: filter strictly on accepted; keep in_review ids in a separate "open risk" section outside the promotion row.

Pro tips

Mini challenge

  1. Pick one past week with a yellow lane.
  2. Draft the promotion packet row honestly, including one deliberate gap.
  3. Fix the gap and record how many minutes it would have saved in a live review.

FAQ

Should this packet live in a wiki or a database?

Either works if the csv schema fields exist as queryable facts. Wikis without structured fields regress into narrative risk.

What if scorecard and playbook disagree?

Hold promotion, reconcile in writing, then refresh snapshot and row list before a new decision timestamp.

Do we need a new packet for hotfix-only pushes?

If the hotfix touches waiver or closure lanes, yes. If policy says no, document that exclusion in promotion_decision_packet_policy.md to avoid silent scope creep.

Lesson recap

You now have a promotion decision packet template that merges closure reliability evidence, escalation playbook execution, corrective acceptance, and executive exceptions into one auditable promotion record.

Next lesson teaser

Next, continue with Lesson 75: Waiver Renewal Post-Promotion Audit Export for Rollback Evidence and Incident Lineage in RPG Live-Ops, which snapshots the decision packet into long-retention storage and ties exports to rollback or incident records when execution diverges from the promote verdict.

Related learning