We Recovered From a Partner Hash Mismatch in 72 Hours - Receipt, Manifest, and Cold Replay (2026 Case Study)

This write-up is a production-language case study, not a turnaround marketing story. It describes a pattern showing up on micro-studios in Q3 2026 prep: partner intake returns yellow on checksum parity, the email sounds vague, and the real defects are three boring artifact problems desktop QA never exercises.

The scenario is intentionally anonymized. There are no invented studio names, no fake Slack quotes, and no invented pass-rate metrics. What follows is a repeatable isolation sequence, the order we ran it in, and the evidence we collected so the second packet did not feel like guesswork.

If you only read one section, read Why this matters now (2026) and The 72-hour execution map—then bookmark the checklists before your next partner ZIP upload.

Pair this case study with the SHA256 cold-validation drill, BUILD_RECEIPT beginner pipeline, validator tools listicle, and the seven-day cold-hash challenge so your team has both narrative and procedure.

Why this matters now (2026)

Partner and platform cert intake in 2026 increasingly treats evidence packets like immutable releases—not marketing attachments. Three pressures push hash discipline to the critical path for indies.

First, cold review hardware — Reviewers unpack zips on laptops that never compiled your game. CI green badges do not transfer.

Second, overnight pipeline drift — Asia-EU handoffs drop green builds into inbox folders while receipts still cite yesterday’s commit.

Third, mock audit dimension 2 — Teams that score well on FAQ truth still fail when mock audit tabletop reviewers cannot reproduce hashes in the room.

The narrow trend hook: hash mismatch tickets are integration bugs with fast fixes if you run the right isolation ladder—not reasons to delay gameplay polish for a month.

Beginner quick start — what we mean by recovered in 72 hours

Recovered in 72 hours in this case study means:

1. We reproduced the partner note on a cold machine using only files in the returned packet—not our dev workspace.
2. We fixed receipt, manifest, and sums parity without changing gameplay scope.
3. We resubmitted with RESUBMISSION_NOTE.md, bumped build_id, and attached validation/ logs showing empty diff on cold replay.

It does not mean we passed final cert on the second try—partners may still find gameplay issues. This case study stays inside artifact integrity boundary.

Success check before you continue:

• You have a release-evidence/ root per folder taxonomy
• You can run sha256sum or Get-FileHash on a second device
• You know which build_id was uploaded (check upload_log.csv if not)

The failure email (typical wording)

Partners rarely write “your SHA256 is wrong.” They write:

• “Checksum file does not include all attachments.”
• “Manifest references build not present in archive.”
• “Please resubmit with consistent folder labels.”
• “Hash mismatch on resubmission without version bump.”

Our packet hit three of four themes in one thread—classic sign the problem is artifact graph, not executable quality.

Starting state (what was wrong)

None of these required engine changes. All required discipline.

The 72-hour execution map

We did not work round the clock—three focused sessions across two workdays plus one evening.

Symptoms vs root causes (diagnostic table)

Use the table before debating engine bugs in standup.

Before first upload — prevention we now use

If we could rewind to pre-yellow:

1. Run one-evening BUILD_RECEIPT before first zip.
2. Complete seven-day cold-hash challenge the week before portal click.
3. Score mock audit dimension 2 in-room with cold laptop present.
4. Ban manual MANIFEST.json hash typing—script from sums only.
5. Require export-machine git rev-parse in release checklist.

Prevention is cheaper than 72-hour recovery—obvious in hindsight, rare under fest pressure.

Hour 0–8 — Freeze and inventory

Actions:

1. Emailed partner: acknowledging yellow; no new upload until build_id bump.
2. Downloaded our own portal copy where allowed—re-hashed portal bytes vs local zip. Portal copy matched partner complaint (not a transcode issue).
3. Created FREEZE_NOTE.md at evidence root listing frozen commit and forbidden folders until resubmit.

Lesson: Self-download catches “upload succeeded but bytes wrong” before blaming reviewers.

Hour 0–8 communication template

We sent a short partner reply—no defensive essay:

Subject: Re: TCK-88421 — resubmit schedule

We acknowledge checksum parity findings on build_id {OLD}.
We are not submitting replacement bytes until {DATE} UTC.
New build_id will be {PREFIX}_*_{DATE}.
RESUBMISSION_NOTE.md will summarize path and hash fixes.

Professional tone + frozen window prevented duplicate bad uploads.

Hour 8–24 — Cold reproduce on kitchen laptop

Actions:

1. Copied zip via USB—no cloud sync folder.
2. Unpacked to C:\cold-verify\packet-v1\.
3. Ran sha256sum regeneration from README-indicated game root—failed on four paths.
4. Logged diff output to validation/failure_repro.log.

Root cause cluster A: Path prefix drift between README, manifest, and sums file.

Root cause cluster B: Two markdown files had CRLF on dev PC; cold Linux re-hash differed.

We did not fix yet—we proved partner note was reproducible.

Hour 8–24 diff excerpt (anonymized pattern)

Typical diff -u fragment that proved failure:

- e3b0c442...  game/Riftbound.exe
+ e3b0c442...  Riftbound.exe

Path column mismatch—not different game bytes. Partners care about column two matching zip interior.

Why kitchen laptop mattered

The compile PC used OneDrive-synced 01_build/. Cold laptop used USB stick export. Sync had not finished when first sums were generated—file size differed by 4 KB on one DLL. Cold reproduce surfaced partial copy, not hash algorithm disagreement.

Lesson: hash from export folder after copy complete, not from live sync directory.

Hour 24–40 — Path normalization and sums regen

Actions:

1. Chose zip interior convention: paths relative to 01_build/game/ without repeating prefix in sums lines—updated naming standard doc.
2. Ran dos2unix on text manifests before hashing.
3. Regenerated files_to_hash.txt with two-person verify (same trick as cold-hash challenge gate 1).
4. Wrote new SHA256SUMS.txt from clean export folder only.

Tooling: Listicle tools 1, 7, 8—hash, diff, Meld for manifest path edits.

Hour 24–40 PowerShell note

Windows export machine used:

Get-Content files_to_hash.txt | ForEach-Object {
  $h = (Get-FileHash -Algorithm SHA256 $_).Hash.ToLower()
  "$h  $_"
} | Set-Content ..\..\SHA256SUMS.txt -Encoding utf8NoBOM

Matching Linux sha256sum output required utf8NoBOM—saved day 3 jq sanity.

Hour 40–52 — Receipt and manifest parity

Actions:

1. git rev-parse HEAD on export machine—updated receipt.
2. Scripted manifest files[] from sums lines—removed hand-typed hashes.
3. Set readme_version bump; aligned eight README bullets to real folders.
4. Archived receipt to 05-operations/receipts/{new_build_id}.json.

Receipt extensions added:

"extensions": {
  "resubmission_of": "northlake_riftbound_steam_OLD_build_id",
  "failure_class": "hash_manifest_path_drift"
}

Honest metadata speeds partner re-review.

Hour 52–64 — Cold pass and read-aloud

Actions:

1. Cold laptop: empty diff between sums files.
2. jq manifest loop exit 0.
3. Read PARTNER_README.md aloud while clicking paths—found one bullet still wrong; fixed before zip.
4. Logged validation/gate5_pass.log with hostname and UTC.

This is the step we skipped on first upload. It would have caught everything.

Hour 64–72 — Resubmit packet

Actions:

1. New zip name with new build_id per naming schema.
2. 7z t pass logged.
3. RESUBMISSION_NOTE.md three lines at zip root.
4. Appended upload_log.csv—did not overwrite first row.
5. Uploaded; self-download re-hash matched.

Mock audit: Internal dimension 2 marked pass before portal resubmit—tabletop took twelve minutes instead of ninety.

What we deliberately did not do

• Rebuild gameplay binaries “just in case”
• Add features to impress reviewers
• Regenerate marketing trailer
• Blame contractor without path contract update
• Post hash screenshots in chat as proof

Scope control kept the 72-hour window real.

Evidence we attached (internal, not all sent to partner)

validation/
  failure_repro.log
  gate5_pass.log
  SHA256SUMS.recomputed.txt
receipts/
  {new_build_id}.json
RESUBMISSION_NOTE.md

Partners received the zip + note. We kept logs for publisher diligence conversations later.

Checklist — copy for your resubmission week

[ ] Portal self-download hashed
[ ] Cold machine diff empty
[ ] build_id bumped in filename + receipt + manifest
[ ] README bullets match manifest paths
[ ] upload_log.csv new row (not overwrite)
[ ] RESUBMISSION_NOTE.md at zip root
[ ] git.commit from export machine
[ ] text files normalized (CRLF) before hash
[ ] 7z t pass logged
[ ] Mock audit dimension 2 self-score pass

Common mistakes we almost made during recovery

1. Re-hashing without bumping build_id — looks like hiding churn.
2. Fixing only sums, not README — second yellow on path lie.
3. Cold test on same PC — false pass; sync client masked drift.
4. Letting artist drop hotfix into 01_build/ mid-recovery — restarted 72-hour map.
5. Skipping upload_log — could not answer “when was first submit?”

How this case study maps to site workflows

Two-storefront note

This team ships Steam + one secondary SKU. Recovery rerun gates per channel zip—Steam sums file must not reference Epic binaries. See two-storefront rule.

AI annex addendum

Mid-recovery, a contractor added 04_ai/disclosure_matrix.csv without updating files_to_hash.txt. We restarted hour 24–64 block for that annex only—smaller scope than full 72-hour replay, but sums regen was mandatory.

Cross-read AI disclosure challenge if annexes change during resubmit week.

validate-packet.sh born from recovery

After recovery we committed a script (shellcheck-clean) from the listicle skeleton:

• Exit 0 only if jq, diff, and receipt build_id match zip filename
• Called in CI as advisory; required on release owner machine before upload
• extensions.validator_script_commit pinned during RC freeze

The script existed as notes before yellow—it became enforced after.

Operating review changes

Four-Friday operating review Block 3 now asks:

• “Any upload without cold_validation log?”
• “Any receipt without archived copy?”

One honest “yes” triggers challenge week rerun—not shame, just reset.

Handoff envelope update

Asia-EU handoff HANDOFF_NOTE.md now requires:

cold_validation_log: validation/latest_gate5_pass.log
build_id: ...
export_machine: ...

Overnight uploads stopped referencing commits that export machine did not build.

Symbols zip side quest (scope controlled)

We had a separate _symbols.zip. Recovery almost polluted scope by re-hashing gameplay and symbols together. We kept separate sums files per SHA256 drill symbols section—recovery stayed 72 hours because we refused scope creep.

Save repro attachment

Playtest save included for repro—added to files_to_hash.txt on hour 24 after save fuzz resource audit. Extra files added two hours, not two days.

What partners said on second pass (pattern language)

Second thread language shifted:

• From “checksum inconsistent”
• To “please confirm gameplay build in bullet 1 matches demo”

Artifact fight ended. Gameplay questions are a different case study—this one closes when hashes and paths agree.

Metrics we refuse to invent

We will not claim “100% pass rate” or “saved X weeks.” We claim only:

• Second packet passed artifact review stage faster because evidence was structured.
• Internal mock audit dimension 2 went from fail to pass.
• Zero gameplay commits between uploads.

Honest limits build trust with readers and partners.

Reader exercises (do this week)

1. Download your last portal upload if possible—re-hash.
2. Run cold diff on any build you plan to submit in Q3.
3. Add missing upload_log.csv rows retroactively with notes=retroactive if needed.
4. Schedule cold-hash challenge on calendar.

Exercise 2 takes one evening and prevents this entire article from becoming your emergency plan.

Maintenance after recovery

Regression happened once when we skipped cold gate during fest crunch—yellow returned in eight days. Gate 5 is now non-optional.

Key takeaways

• Partner hash mismatch in 2026 is usually path drift, receipt commit drift, or CRLF—not mysterious crypto.
• 72-hour recovery = cold reproduce, normalize paths, regen trilogy (sums, manifest, receipt), cold pass, resubmit with new build_id.
• Self-download and upload_log.csv are as important as SHA256SUMS.txt.
• Do not change gameplay scope during artifact recovery.
• Attach internal validation/ logs for diligence; partners need correct zip.
• Install seven-day challenge before first yellow flag—not after.

FAQ

Did gameplay change between submissions?

No. Only evidence artifacts and folder paths changed.

Is 72 hours realistic for solo devs?

Yes if scope stays artifact-only. Add one day if two storefront zips.

Should we tell partners every fix in email?

Use RESUBMISSION_NOTE.md in zip; email stays short with new build_id and ticket reference.

Does this replace legal or AI review?

No. Hash integrity is necessary, not sufficient for cert.

What if cold pass fails but partner passed?

Still fix drift—next reviewer or resubmit may fail. Log the anomaly.

How is this different from the Deck Verified case study?

Deck recovery case study covers handheld integration. This case study covers partner evidence integrity. Both use timed recovery maps; neither replaces the other.

Can we automate the 72-hour map?

Partially—validate-packet.sh covers hours 40–64 outputs. Hours 0–8 communication and hour 8–24 cold reproduce stay human-owned. Automation should never send partner email or bump build_id without a human signoff row in the receipt.

Solo vs four-person team timing

The map is work hours, not calendar hype. Solo devs should not attempt all blocks in one all-nighter—fatigue causes new path typos.

Friday Block 5 integration

Friday Block 5 now includes:

BLOCK5-HASH: one random line from SHA256SUMS.txt re-verified

Fifteen minutes weekly catches drift before partners do.

Q3 template resource cross-link

Folder skeletons from Q3 submission intake templates gave us filenames; recovery taught us filenames without validators are hollow. Use templates plus listicle tools plus challenge week.

Anti-pattern gallery (what we saw in chat, not evidence)

• Pasting SHA256 in Discord without file path
• “Fixed hash” without new build_id
• Deleting first upload row from CSV
• Running cold test on VM snapshot of dev machine
• Manifest copied from last month’s zip

Each anti-pattern now has a matching line in validate-packet.sh comments—documentation for future release owners.

Closing scope statement

This case study will age when partner portals expose new manifest schemas. The recovery order should remain stable: reproduce cold, fix paths, regen trilogy, log, resubmit with version bump. Update schema versions in receipts; do not reorder the ladder because a tool rebranded.

Post-recovery artifact inventory (what “good” looks like)

After a clean resubmit, our evidence tree contained:

• One primary cert zip with consistent build_id in filename, receipt, and manifest
• SHA256SUMS.txt with forty-seven lines matching forty-seven files on cold unpack
• upload_log.csv with two rows (original yellow + resubmit) and distinct portal tickets
• validation/ folder with failure repro and gate5 pass logs dated three days apart
• RESUBMISSION_NOTE.md with three sentences—no essay

That inventory is now the internal definition of “packet ready” before any producer schedules a portal upload meeting.

When to escalate beyond 72 hours

Escalate to platform support or counsel when:

• Partner requires signed attestations your receipt schema cannot express
• Hash mismatch persists after empty diff on two cold machines
• Portal transcode changes bytes and documentation forbids self-download verification

Those cases are rare on PC cert evidence zips; they are not this case study’s lane. Document portal-specific quirks in 05-operations/portal_notes.md so the next release owner inherits facts instead of rediscovering them in a ticket thread.

Conclusion

The first upload taught us that green CI is not cold truth. The second upload proved that receipts, manifests, sums, and logs are a system—not optional paperwork.

If you are preparing Q3 2026 intake, run the cold-hash challenge before the yellow email—not in response to it. If you already have the email, start at hour 8 of this map: reproduce on cold metal, then fix paths with diffs, not hope.

Bookmark the resubmission checklist section. Print it. Tape it beside the machine that zips packets. The case study only helps if the checklist survives crunch week when nobody re-reads the article.

Recovery in 72 hours is not heroic. It is boring validators used in the right order—the kind of boring partners trust on cold hardware every single time.