Start Building

Lesson 109: Cross-Store Submission Evidence Delta Log for Steam Epic and Mobile (2026)

Direct answer: In this lesson, you build one cross-store delta log that tracks what changed, where it changed, and who approved it, so Steam, Epic, and mobile submission packets stay aligned inside one release window.

Why this matters now (2026 cross-store pressure)

In 2026, many indie teams ship the same build across store ecosystems with different portal rules and review timing. The top failure pattern is not missing files; it is mismatch between metadata, build references, and policy answers across portals. A delta log prevents silent drift before submissions are locked.

Isometric building cluster representing synchronized release evidence checkpoints

What you will produce

  1. lesson78_cross_store_submission_delta_log.csv
  2. lesson78_cross_store_delta_readback.md
  3. lesson78_cross_store_exception_register.csv

Prerequisite path: Lesson 108, Lesson 107, and Lesson 99.

Step 1 - Define the release tuple

Create one tuple used across all stores:

  • release_window_id
  • candidate_build_id
  • artifact_digest_sha256
  • metadata_revision_id
  • approval_owner

If one field changes, you must either (a) update all store rows in the same window, or (b) open an exception row and block promotion.

Step 2 - Build the delta-log schema

Use one row per store + artifact group:

column purpose
store steam, epic, google_play, app_store
field_group binary, metadata, legal, age-rating, commerce
previous_value_ref last approved reference
current_value_ref candidate reference
delta_type add, update, remove, no-change
verification_owner who confirms parity
verification_status pending, pass, fail
exception_id optional pointer when mismatch is accepted temporarily

Keep references small and deterministic. Use ids or hashes, not long prose.

Step 3 - Run same-window evidence readback

For each store, read back:

  1. build reference id
  2. store metadata revision
  3. policy questionnaire revision (if applicable)
  4. checksum evidence
  5. signer identity

Mark row fail if any value points outside the active release_window_id.

Step 4 - Add exception discipline

Mismatch may be temporarily allowed only if:

  • reason is documented
  • expiry timestamp is set
  • fallback owner is assigned
  • rollback plan is attached

No expiry means no approval. No fallback owner means no distribution.

Step 5 - Add portal-specific checks

Short checks before final submit:

  • Steam: branch/depot references match candidate build id
  • Epic: artifact channel and release metadata match changelog revision
  • Google Play: release notes, Data Safety, and bundle version fields align
  • App Store: privacy, export compliance, and build pointer align

These checks prevent "same code, different story" incidents between portals.

Step 6 - Run a 20-minute pre-submit simulation

Pick two rows at random per store:

  1. verify tuple continuity
  2. verify metadata parity
  3. verify owner can produce evidence within SLA

Write outcomes in delta_readback.md and block promotion until all critical rows pass.

Step 7 - Freeze and sign

Before submission clicks:

  • freeze delta_log version
  • freeze exception register
  • capture final signers
  • archive with one immutable hash pointer

Any late edit requires a new delta-log revision id and a fresh readback.

Pro tips

  • Keep one owner per store, plus one cross-store coordinator
  • Review deltas in sorted order: binary -> metadata -> policy -> commerce
  • Auto-generate a "no-change" row so missing rows are visible

Common mistakes to avoid

  • Updating one store row without opening a delta entry
  • Treating exception rows as permanent policy
  • Using free-text evidence instead of stable refs/hashes
  • Passing parity check without store-specific questionnaire review

FAQ

Do we need this if binaries are identical

Yes. Most cross-store incidents come from metadata and policy drift, not binary drift.

Should each store have a separate spreadsheet

No. Keep one delta log with store column segmentation, then export filtered views.

What if one store submission is delayed

Open an exception row with expiry and rollback instructions, then re-run readback before delayed submit.

Lesson recap

You now have a cross-store submission delta system that keeps release evidence synchronized across Steam, Epic, and mobile. The key discipline is one release tuple, one delta log, and explicit exception controls.

Next lesson teaser

Next, Lesson 110 runs a regional incident bridge packet dry-run so attachments, routing, and rollback authority stay aligned with this delta log during real multi-region outages.