Lesson 82: Borrow Outcome Patch Comms Packet for Controlled Player-Facing Notes in RPG Live-Ops

Direct answer: A borrow outcome patch comms packet links each resolved or escalated borrow_row_id from Lesson 80 and its scorecard decision from Lesson 81 to approved player-visible language for patch notes, optional in-game banners, and short social stubs. You store policy once, emit one append-only or generation-friendly CSV per release candidate, and require explicit checks so public copy never contradicts the Lesson 78 readout posture.

Shippers already know that borrows change who can finish what before a date. Players only experience delays, fixes, or scope shifts. This lesson closes the gap with governance-friendly wording instead of improvisation in Slack ten minutes before publish.

Stylized haunted house illustration suited to controlled messaging when release posture shifts mid-quarter

What this lesson solves

You need:

  1. A policy that says when a comms row is mandatory versus optional
  2. A waiver_borrow_outcome_patch_comms_packet.csv that ties each external line to borrow_row_id, approval, and embargo
  3. A contradiction gate that blocks publish if marketing copy disagrees with the latest Lesson 78 slide set on divergence governance

Prerequisites: Lessons 80 and 81, plus familiarity with your store submission and in-game messaging tooling.
Expected time: about 95 minutes including one tabletop that walks a recall scenario into three channel variants.

What you will build

  1. waiver_borrow_outcome_patch_comms_packet_policy.md
  2. waiver_borrow_outcome_patch_comms_packet.csv (generated or manually appended per your release train; schema below stays stable)
  3. A publish checklist stub your release captain attaches to the patch build record

Step 1 - Decide when the packet is mandatory

Open a comms packet row when any is true:

  • A borrow moves to returned or renewed and that movement changes a public milestone (patch window, season content, or certification target) within the next 30 days
  • Donor recall or merge from Lesson 81 alters which features stay in the candidate build versus defer
  • return_status hits disputed and you still intend to ship a build while mediation continues (yellow posture language only)

Stay silent in the packet when the borrow closes without customer-visible schedule impact and your policy marks that path as internal-only. Silence is a decision: record explicit waive in policy so teams do not invent quiet promises elsewhere.

Step 2 - Author the policy document

In waiver_borrow_outcome_patch_comms_packet_policy.md, capture:

  • Naming ban list: no internal lane codenames, personal attributions, or “we borrowed cap from Team X” phrasing in any customer channel
  • Truth sources: borrow_row_id from Lesson 80 and scorecard_cycle_id from Lesson 81 when the borrow appeared on the scorecard
  • Approval ladder: which roles must sign player_visible_headline (example: product counsel for regulatory-touch lines, executive sponsor when risk_banner_level is red)
  • Embargo rules: default no store text before embargo_until_utc unless incident command expands the window
  • Contradiction rule: if contradicts_lesson_78_slide = yes, require a named executive ack recorded next to the CSV row before external publish

Step 3 - Define the CSV schema

Each row is one externally shippable bundle tied to borrow semantics. Use one row per borrow outcome event even if three channels reuse the same headline.

column purpose
comms_row_id monotonic id
release_train_id ties to your build or RC tag
borrow_row_id_ref foreign key to Lesson 80 ledger
scorecard_cycle_id_optional blank if never surfaced on Lesson 81
outcome_trigger merge_priority_shift, donor_recall_complete, borrower_return_complete, dispute_pause_hold, renewal_window_extended
player_visible_headline short line for patch index; no internal names
player_visible_body_stub 2-4 sentences max; plain symptoms and timing
internal_lane_note_doc_id pointer to private doc; never paste the note into player fields
risk_banner_level none, yellow, red for in-game banner routing
approval_roles comma-separated required approvers
publish_channels store_patch, in_game_system, social_teaser (subset allowed)
embargo_until_utc coordinated clock
contradicts_lesson_78_slide yes or no

Treat player fields as regulated speech: if legal wants alternate wording, add a new comms_row_id rather than editing history in place when your tooling is append-only.

Step 4 - Shape channel variants without duplication drift

Use one canonical player_visible_body_stub in the CSV, then derive:

  • Store patch: headline plus stub; follow first-party character limits
  • In-game system: headline plus one shorter sentence; map risk_banner_level to art and frequency caps your UX policy already defines
  • Social teaser: headline only unless policy permits a single fixed hashtag line unrelated to borrow mechanics

If a channel needs extra nuance, attach an appendix row sharing the same borrow_row_id_ref with publish_channels narrowed—avoid forked Google Docs that diverge from the CSV.

Step 5 - Run the approval and embargo workflow

For each row before publish:

  1. Confirm the borrow ledger shows the outcome you are describing (returned, renewed, still disputed with yellow language, etc.)
  2. Run Lesson 78 consistency: if the latest readout still shows green on divergence governance, yellow or red player banners need an explicit bridge sentence approved by the same forum that owns Lesson 78 slides
  3. Collect signatures implied by approval_roles in order; block CI or CMS publish steps until the list is complete
  4. Respect embargo_until_utc; if the build slips, regenerate IDs rather than backdating timestamps

If your studio runs parallel storefront certifications, duplicate the row per release_train_id only when headline facts diverge (example: one first-party store accepts a hotfix while another holds submission). Otherwise keep one row and list multiple trains in a dedicated column you add later—avoid silently publishing one headline globally when only one SKU moved.

Worked example - donor recall without naming lanes

Assume outcome_trigger = donor_recall_complete ends a borrow early because the donor lane must reclaim capacity for a certification blocker.

  • player_visible_headline: “Patch window adjusted for stability work ahead of the season milestone.”
  • player_visible_body_stub: “We are moving one featured encounter out of this patch to finish reliability fixes requested during certification. The encounter returns in the next planned update; saves remain compatible.”
  • risk_banner_level: yellow if the RC already advertised the encounter publicly; none if marketing never promised it dated to this patch.
  • contradicts_lesson_78_slide: yes if last month’s readout slide still listed that encounter under committed scope—then attach executive revision language internally before external publish.

This pattern keeps truthful urgency while omitting borrow mechanics players cannot act on.

Step 6 - Close the loop after ship

After release:

  • Archive the CSV snapshot with the build record
  • If players react to ambiguity, open a Lesson 81 follow-up only when new disputes appear—do not rewrite shipped copy without a new comms row
  • Feed recurring friction into policy: maybe your studio caps social teasers when outcome_trigger = dispute_pause_hold

Pro tips

  • Tip: Pre-write three neutral shells (delay, stability focus, content reorder) that compliance pre-approves so teams slot facts faster under pressure.
  • Tip: Pair risk_banner_level with support macros so player support uses the same verbs as the patch notes.
  • Tip: When contradicts_lesson_78_slide = yes, attach the slide ID in the internal doc referenced by internal_lane_note_doc_id for audit clarity.

Common mistakes

  • Mistake: Patch notes become the borrow ledger. Fix: players get outcomes and dates; borrows stay internal.
  • Mistake: Marketing drafts in a doc without row IDs. Fix: CSV or equivalent structured source precedes CMS entry.
  • Mistake: Ignoring donor recall velocity. Fix: recall events almost always deserve a comms row even when the scorecard rank was mid-tier—recall changes posture fast.

Mini challenge

  1. Pick one fictional borrow_row_id from your tabletop notes with outcome_trigger = donor_recall_complete.
  2. Draft player_visible_headline and player_visible_body_stub with zero internal lane words.
  3. Mark whether contradicts_lesson_78_slide should be yes if the recall removes a headline feature from the RC named on last month’s readout deck.

FAQ

How does this relate to Lesson 72 reliability scorecards?

Lesson 72 tracks intervention closure quality. This lesson handles customer language after borrow mechanics change schedules. Both can reference the same quarter label without merging schemas.

Can we skip the CSV and use our CMS only?

You still need frozen snapshots per build. A CSV (or JSON export with identical columns) keeps legal review diffable.

What if translation lengthens headlines past store limits?

Policy should require headline variants per locale as optional columns in a future lesson or as annex rows sharing comms_row_id lineage—never silently truncate compliance-reviewed text.

Lesson recap

You now have a borrow outcome patch comms packet that maps structured borrow resolutions to approved player-facing language, with embargoes, approvals, and explicit protection against contradicting the Lesson 78 executive narrative.

Next lesson teaser

Continue with Lesson 83: Multi-Region Localization and Ratings Freeze Alignment for Borrow Patch Comms to tie Lesson 82 rows to per-region cert clocks, loc freezes, and ratings submissions without cross-territory contradictions.

Related learning

Bookmark this lesson when borrow resolutions start showing up in player-facing channels. Share it with comms and release captains before the next RC freeze.