Patch-Note Translation for Viewers

# Patch-Note Translation for Viewers

Version: NEW DRAFT 2026-10-25 / Status: experimental science / Credit: Dead Brands

## Purpose

Take a patch or fix note written for the team and translate it into what a viewer watching the game will actually notice, so patch news is watchable instead of technical. The translation must not promise more than the note says: if the note changes a number, the viewer-visible claim is only about that number's effect. A translation that oversells a fix creates viewers who watch for something that never happens.

## Superpower (one line)

A fix note rewritten as what viewers will see — changed, unchanged, and still-unknown, in plain words.

## When to use

- When a fix wave or patch lands and viewers ask what changed in the game they watch.
- In a recap that mentions a patch, to explain it in one viewer-facing paragraph.

## When NOT to use

- Do not translate a note you have not read in full, and do not infer viewer effects the note does not support.
- Do not use it for proposed or unlanded fixes; only landed, verified patches get translated.
- Do not use it to announce a fix before the fix is verified live — a note is not a live result.

## Tools & APIs

The landed patch note itself (existing, real); the game's published rules or mechanics the note touches; the previous viewer-facing description, if one exists. No new tool is required. No live game, scoreboard, or stream state is needed — and none may be invented to fill a gap in the note.

## Inputs

The full patch note; the mechanic it changes; the viewer-facing behavior before the change, as observed or published. If any of the three is missing, the translation stops at "unknown" for the part it covers — it does not guess.

## Outputs

A short viewer paragraph in this fixed template — every line tied to a line of the note:

```
Patch: <note title or id, as written in the note>
Changed — what viewers will notice: <plain words, tied to the changed number>
Unchanged — what stays the same: <so viewers do not expect a wider change>
Unknown — what the note does not say: <listed, never filled in>
Source: <the landed note, read in full>
```

## Worked example

Note (read in full, landed): a vent bonus falls from 20 to 8. The game's published mechanics tie the vent bonus to vent plays only — nothing else in the scoring changes.

Translation:

```
Patch: vent bonus change, 20 to 8
Changed — what viewers will notice: vent plays are now worth less than half what they were, so a bot that leans on vents will climb the scoreboard more slowly than before.
Unchanged — what stays the same: everything else in the scoring is untouched — vent plays still score, and no other bonus or move changes.
Unknown — what the note does not say: whether bots will change how often they use vents, and whether the smaller bonus shifts which strategy wins. The note does not say, so the translation does not say.
Source: the landed vent-bonus note, read in full
```

The oversell version — "completely rebalanced" — would fail this skill: the note changes one number, so the translation claims one number's effect and nothing more.

## Steps

1. Confirm the patch landed and read the full note. If the note is partial, proposed, or only half a fix wave, stop: translate only the notes actually read in full, and say which notes were not translated.
2. Underline exactly what changed, with its numbers, and identify the viewer-visible behavior that number controls, from the game's published mechanics.
3. Write what will look different, in plain words, tied to the changed number — one claim per changed line, no wider claim than the line supports.
4. Write what stays the same, so viewers do not expect a wider change than the note makes.
5. Flag anything the note does not say as unknown, rather than filling it in — including side effects and strategy shifts.
6. If the note itself mentions a regression risk, carry that risk into the translation in plain words; never hide it.
7. Re-read the translation against the note line by line before delivering it: every viewer claim must trace to a specific line.

## Safety limits

Never translate a proposed, unlanded, or partially read fix as if it shipped. Never promise a viewer effect the note does not support. Never hide a regression risk the note itself mentions. Bots and house games only; no internal team details beyond what the note already publishes. Never present a translation as a live verification that the fix works — the note says what changed, not that it was seen working.

## Failure modes

- **Oversell:** a small number change becomes "completely rebalanced" in translation. Mitigation: tie every viewer claim to the note's exact change.
- **Partial notes:** translating half a fix wave misleads about the rest. Mitigation: translate only the notes actually read in full, and name the untranslated rest.
- **Hidden unknowns:** a note silent on side effects invites invention. Mitigation: unknowns are listed as unknown.
- **Note-as-proof:** a translation quoted later as evidence the fix works live. Mitigation: the template's Source line says the note was read, not that the fix was verified live.

## Test checklist

- [ ] Every viewer claim ties to a specific line of the landed note.
- [ ] Only landed, fully read patches are translated.
- [ ] What stays the same is stated beside what changes.
- [ ] Unknowns are listed, never filled in.
- [ ] Any regression risk in the note appears in the translation.
- [ ] The translation does not claim the fix was verified live.