Steam Review Keys and Press Demo Scope Labeling - Next Fest 2026 Checklist for Micro-Studios

You sent fifty review keys with the email subject "Full beta access." The zip is the Next Fest demo on branch fest_demo_2026_10. Coverage quotes co-op because the press kit still says it. Partners compare key emails to FAQ row 1 beside build_id—the same store-demo mismatch pattern with a different screenshot.

This Process & Workflow checklist governs Steam review keys, curator keys, and influencer installs as store-adjacent truth tied to hour-one proof—not a separate hype channel. It pairs with branch naming, hub announcements, and demo build identity. Anchor requests to Steamworks review keys documentation. No invented studios or metrics.

Time to read: ~35 minutes. Time to run first key audit: ~2 hours with receipt update and template rewrite.

Players who read outlets before installing your public demo inherit press vocabulary—if three reviews say "co-op beta," your solo fest zip fights an expectation you mailed out. Keys are therefore an upstream cause of refund language and partner screenshots, not a logistics footnote.

Why this matters now (May–October 2026)

1. Coverage precedes public fest traffic — Press installs days before players.
2. Key emails are contractual tone — "Beta" and "full game" language sticks in articles.
3. Review queue pressure — Demo review revalidation includes mode lists keys unlock.
4. Branch drift — Keys point at wrong branch while library labels say demo.
5. May fixes cheap keys — October key blasts inherit May template lies.

Direct answer: Build review-key-proof.md (one row per key batch), standardize email and README labels to DEMO scope, map each batch to build_id and branch in BUILD_RECEIPT, and block new keys until proof table green.

Who this is for

Prerequisites

Review key proof table (core artifact)

release-evidence/05-press/review-key-proof.md:

Pass rule: Key redeems to branch and build_id in receipt; hour-one experience matches FAQ DEMO boundary; email and PDF use same labels as library naming.

Key classes (separate rows)

Never mix classes in one email template.

Standard email template (copy-paste)

Subject: <Game> — Next Fest DEMO (build_id <id>) — review key

Body:
This key installs the **Next Fest demo** (solo, Act 1, ~90 minutes)—not the full game.
Branch: fest_demo_2026_10
build_id: <id>
Store FAQ: <url>
Please do not describe co-op / <excluded modes>—not in this build.

Customize exclusions from proof table—do not improvise per send.

Press kit README bullets

Attach to partner ZIP:

1. Install identity: DEMO — build_id <id>
2. Branch string: <branch>
3. Hour-one scope: bullet list from FAQ row 1
4. Not in build: explicit negatives
5. Link: review-key-proof.md summary

BUILD_RECEIPT extension

"review_key_batches": [
  {"id": "CUR-02", "build_id": "4521", "branch": "fest_demo_2026_10", "status": "pass"}
],
"review_keys_locked": false,
"press_readme_path": "release-evidence/05-press/README.md"

Pre-send gate (six steps)

Triangle diff (keys leg)

Red-team questions

1. "Which build does this key install?"
2. "Email said beta—why no online?"
3. "Is this the fest demo or main game?"
4. "Can we quote multiplayer from the kit?"
5. "Why does key redeem to default?"

Common mistakes (twelve)

1. "Beta" in subject for solo demo.
2. Keys generated before promotion.
3. No test redemption.
4. Press kit from last year.
5. Mixing playtest and press keys.
6. Branch default in email.
7. Promising achievements not in demo.
8. Ignoring content descriptors.
9. Influencer custom emails without proof.
10. No batch log.
11. October blast without template refresh.
12. Coverage quotes stronger than FAQ.

Worked example (anonymous)

Before: 40 keys sent as "open beta."
Audit: All redeemed to fest demo solo.
Fix: Correction email to outlets; updated kit; CUR-02 batch only until green.
Result: Next articles used DEMO language.

Integration with metadata cluster

Run key audit after branch naming and before fest marketing cap unpauses outreach.

Evidence folder layout

release-evidence/05-press/
  README.md
  review-key-proof.md
  email-templates/
    press-demo-standard.md
    curator-fest-2026.md
  redemption-log-YYYY-MM-DD.txt
  press-kit-readme.md
  engineer-signoff.txt
  producer-signoff.txt

Zip into publisher diligence when partners ask what reviewers received.

Ninety-minute first key audit

Start with batches tied to active outreach—highest reputational risk.

Achievements and stats in press kits

Demo review queue warns about achievements not in demo. Press bullets must not promise:

• Steam achievements unlock in demo unless engineer proves hour one
• Leaderboards if backend offline
• Cloud saves if demo is local-only
• Trading cards or inventory features absent from zip

Cross-check tags for Stats or competitive tags.

validate-packet key dimension

Optional guards:

• review-key-proof.md has no Fail for batches in last 60 days
• email-templates/ hash matches last send
• Test redemption log younger than 7 days when build_id changed
• review_keys_locked false only when table green

Pair with validate-packet hub and store dimensions.

Wednesday ritual extension

Add Keys row to Wednesday ritual: confirm no keys sent since last promotion without new proof row—five minutes.

Revocation and correction protocol

When batch fails after send:

1. Email recipients with correction template (within 24h)
2. Mark batch Fail with recall note
3. Issue new batch only after redemption test
4. Archive offending email in recalls/
5. Update hub correction if public post referenced wrong modes

Influencer vs press discipline

Contractors must use git templates—no Gmail improvisation.

Team RACI

Comparison to reactive recovery

Articles published with wrong mode lists are harder to fix than FAQ typos—prevention wins.

Mock audit tabletop

Facilitator reads email subject from last batch; team states branch, build_id, and excluded modes without notes. Fail if any hesitation—fix templates before October key waves.

Localization and regional keys

Regional outlets need translated emails that do not strengthen claims—localization QA on templates before send. Same build_id globally unless separate depots documented.

Two-storefront press

Two-storefront rule: itch HTML5 keys or links in press kit need separate proof row—do not imply Steam demo includes browser features.

Ads and UTM

Do not run UTM campaigns targeting "beta access" while keys install DEMO—landing copy must match email templates.

Asia–EU handoff

Overnight key sends forbidden without updated proof table—Asia–EU handoff morning review checks review-key-proof.md first.

Operating review

Four Friday five-block review Block 5 (press): metric = batches proofed / batches sent — target 1:1.

Intake compression script

Partner question: "What did reviewers install?"

Answer path: receipt batch → redemption log → FAQ row 1 → branch screenshot. Under two minutes.

October freeze

September lock email templates. October: only new batches with same-day redemption test; no new adjectives in subject lines.

Snippet-friendly answers

Do Steam review keys install the demo or full game?
Whatever branch the key is tied to—your process must ensure fest keys redeem to the fest demo branch documented in BUILD_RECEIPT.

What should the email subject say?
Include DEMO or Next Fest demo plus build_id—avoid "full beta" unless the zip is actually a full-game beta.

How often to re-test keys?
After every promotion that changes build_id or branch name.

Glossary

Schedule template rewrite the week BUILD_RECEIPT first goes green for fest demo.

Curator Connect and festival key waves

Festival organizers often request bulk keys. Treat each festival wave as its own batch row—even if Steamworks UI lumps them. Document:

• Organizer name
• Requested quantity vs sent
• Deadline vs your build_id promotion date
• Whether organizer email used your template or theirs (if theirs, diff for scope lies)

Never let organizer marketing copy override your DEMO template attachment.

Playtest keys vs press keys

First playtest branch keys are for QA communities—not press. Separate:

Sending playtest passwords to press guarantees wrong quotes.

Cold-hash and key coupling

After cold-hash week, pause key sends until receipt shows matching hash—press installing wrong binary while email cites right build_id is a classic mismatch.

Hub and event alignment before keys

Green hub posts and event posts before large key waves—reviewers read all three surfaces.

Vertical slice vocabulary ban

Per vertical slice opinion, ban "vertical slice" in press emails unless five gates documented in proof table annex—use Next Fest demo instead.

Deck and hardware claims in kits

If press kit mentions Steam Deck, include Deck tools capture path and spec honesty rows—keys do not excuse false handheld claims.

AI disclosure in press sends

When generative features exist, attach AI disclosure challenge summary—reviewers ask AI questions first in 2026 intakes.

Demo patch notes after key send

If demo patch notes ship post-send, email outlets with build_id bump—do not assume they auto-update.

Additional common mistakes (six)

13. Sending keys from personal Steam account notes without batch ID.
14. Using "preview build" without branch string.
15. Press kit screenshots from main game depot.
16. Skipping mock audit press question.
17. Ignoring tag drift after keys sent.
18. Evidence cycles batching key template updates—scope changes cannot wait.

Beginner path

1. Promote fest demo; log receipt.
2. Redeem one test key.
3. Copy standard email template.
4. Send to single friendly outlet as pilot batch.
5. Log PASS row.
6. Scale batches with six-step gate.

Publisher diligence FAQ

Post-fest maintenance

Friday Block 5 press row; re-test keys after promotions; archive templates per fest season.

Coverage correction letter (template)

When articles already published with wrong modes:

Subject: Correction — <Game> Next Fest DEMO scope (build_id <id>)

We sent an earlier key email that overstated online features.
The fest demo is solo, Act 1 only. Updated kit attached.
Please amend co-op references if possible.

Log outreach IDs in proof table recalls/ column.

Steamworks UI discipline

When generating keys in Steamworks:

• Note package and branch in spreadsheet immediately—UI does not remind you later
• Never generate while default branch still points at main game
• Export key CSV to release-evidence/05-press/ with batch ID in filename
• Restrict key count to requested quantity—extra keys float into wrong hands

Security and leak response

Leaked key batches require:

1. Disable or expire if platform allows
2. New batch with new template only after proof
3. Hub correction if leak came from influencer post
4. Receipt note under security-events.md

Do not silently rotate without telling outlets that already installed.

Metrics honesty

Do not claim "50 outlets covered" in hub posts unless review-key-proof.md lists them—vanity metrics invite partner questions without evidence.

Integration with 5-day metadata freeze

Assign press keys to day five of 5-day metadata freeze so templates lock with other surfaces.

Trailer and screenshot kit assets

Press ZIPs often include trailer MP4 and PNGs—run trailer frame audit and screenshot gates on kit assets separately from store page—kits are a common loophole for co-op frames.

When to re-audit keys only

Store copy surfaces cross-walk (before first batch)

If any column disagrees, do not generate keys—fix the outlier surface first.

Internal spreadsheet minimum columns

Track in review-keys-tracker.csv:

batch_id, date, recipient_class, quantity, build_id, branch, template_hash, redemption_tester, pass_fail, recall_sent

Import row summaries into review-key-proof.md weekly—spreadsheets are where producers catch drift engineers miss.

Key takeaways

• Review keys are install contracts for press—label like FAQ.
• review-key-proof.md per batch with redemption test.
• Standard email + press README tied to build_id.
• Separate key classes; ban default in templates.
• Triangle-diff keys vs store and hub.
• BUILD_RECEIPT batch log.
• Six-step pre-send gate.
• Cheaper than coverage-driven mismatch recovery.
• Separate playtest passwords from press review keys.
• Festival bulk waves get their own batch rows.
• Redeem test keys after every branch promotion.
• Metadata sprint should add keys as ninth surface.
• Cross-walk store surfaces before first batch send.
• Track batches in review-keys-tracker.csv with template hashes.
• Resend equals new audit.

FAQ

How many test keys before a batch?
At least one redemption per branch change.

Curator Connect vs manual keys?
Same proof rules—document batch ID either way.

Can keys grant main game depots?
Not for fest cycle—separate batch class with FULL GAME label.

October policy?
Freeze templates; new batches need new proof rows.

What if outlet loses key email?
Resend same template version from git—do not rewrite features in resend.

How tie to publisher diligence?
Attach review-key-proof.md and latest redemption log to diligence ZIP store section.

Conclusion

Review keys are silent marketing. One subject line saying "full beta" becomes the quote in three outlets before your short description gets read. Curators and influencers repeat your adjectives in video titles—those adjectives must match hour one, not roadmap dreams.

Rewrite templates in May. Redeem every batch on a floor account. Log build_id like you log hashes. Press coverage should embarrass you with truth, not fixable lies. Keep playtest passwords out of press inboxes—mixed keys are how co-op myths enter launch week without a single lying FAQ row.

Send the next key batch only after the proof table row is green. Redeem on a floor account every time the branch moves—press forgiveness is thinner than player forgiveness. Archive every CSV export Steamworks gives you; spreadsheets become the audit trail partners trust when forums argue about which build reviewers played.

When metadata sprint completes, add review keys as the ninth surface—outreach truth is part of store parity. If you only fix store copy and ignore keys, you are polishing the brochure while mailing the wrong contract. Generate the next CSV export only after the redemption tester signs the batch row. One honest subject line beats ten outlet corrections. Proof keys before you pitch outlets. Treat every resend like a new batch audit.