platform-cert-overview-reference

Overview

A multi-platform title that ships on console plus PC submits to four distinct certification regimes, each with its own requirements document, severity vocabulary, test-bench configuration, and SLA. This skill is the pure reference that maps those four regimes onto a common structure so QA leads can plan a cert calendar without re-learning each portal.

This skill pairs with game-test-categories-reference which defines the six canonical test categories (functional / compliance / compatibility / performance / localization / accessibility) that map across all four regimes.

When to use

• Planning a cert calendar - when to submit, expected SLA, how many parallel passes to budget.
• Mapping a CFR / hold / fail back to internal QA categories.
• Sequencing submissions across platforms - which platform tends to surface which class of issue first.
• Onboarding a new team member to the cert vocabulary without full NDA-portal access on day 1.

Microsoft Xbox Certification

Source of truth

• Process: Certification step-by-step guide on learn.microsoft.com.
• Requirements: Xbox Requirements for Xbox Console Games (currently v16.1, dated 5/01/2026 per the page).
• Test cases: Certification Tested Xbox Requirements and Test Cases.
• PC counterpart: Xbox Network Policies for PC and Mobile.

Stages

Per the Certification step-by-step guide, a submission goes through three stages in order:

1. Submission checks - Submission Validator + malware scan. "Submission Validator gives feedback to developers and allows them to address common problems that would cause titles to fail ingestion into Partner Center and/or Certification."
2. Build verification testing (BVTs) - "a reduced test pass designed to make sure a product is fully testable and configured properly before entering full certification testing".
3. Xbox Requirement (XR) testing - "the bulk of the testing and is where all applicable XR test cases will be validated against your title."

Submission types and SLAs

Per the same guide:

There are two test-pass types:

• Optional submission - paid, tested in CERT.DEBUG sandbox with red-signed content; no pass/fail decision.
• Final submission - last pass before release / RTM; tested in CERT sandbox with green-signed content on retail devices.

XR categories (v16.1)

XRs are organised into the categories enumerated in the XR document:

XRs that are tested in Cert are marked with an asterisk on the source page; not all XRs are tested every submission. See the test cases page above for per-XR Test Steps + Expected Behavior + Pass / Fail examples.

Issue severity vocabulary

Per the Certification step-by-step guide:

CFR severity is determined by Failure Mode Analysis (FMA) which combines severity × probability × repeatability.

Common hold reasons

Per the same guide, titles are most often placed on Hold because of:

• "Missing or non-functioning partner accounts that are required for testing."
• "Partner services do not support the CERT.DEBUG and CERT sandboxes."
• "Multiplayer does not work as expected."

(Multiplayer issues are a particularly common cert blocker - see multiplayer-state-machine-coverage for the test patterns that catch them pre-submission.)

Bench layout (compatibility matrix)

Per the Certification test bench configuration section of the guide:

Reports

Three report types (per same guide):

• Optional complete report - issued at end of Optional Submission; no pass / fail; lists SRIs and CFRs.
• Final pass / fail report - issued at end of Final Submission; the decision report.
• Interim report - mid-pass snapshot; no pass / fail.

Exception requests

Per the guide: "If your title is not fully compliant with any Xbox Requirement (XR), you can request an exception for that XR. This might occur if your title is introducing innovative features or if strong technical limitations would prevent the title from meeting the XR." Work with Microsoft contacts well in advance - "approval of an exception is not guaranteed."

Sony PlayStation Certification (TRC)

Source of truth

• Document: Sony Technical Requirements Checklist (TRC) - gated NDA portal at PlayStation DevNet, cited by stable ID "Sony TRC" per PLUGIN_AUTHORING.md Step 4 fallback. (Same Step-4-fallback note applies to every Sony-specific clause in this section.)
• Per-generation supplements: PS5 TRC supersedes PS4 TRC; PS5 Pro adds 60-Hz / 8K / PS5 Pro Game Boost guidance (NDA - stable-ID cite).

Structure

The Sony TRC is a numbered checklist (NDA-only - cite by stable ID) organised into roughly comparable buckets to the Xbox XR list:

• Functional - title stability, error recovery, save game.
• Trophies - Sony's analogue to Xbox Achievements (cite by stable ID for exact count / point limits).
• Multiplayer - session lifecycle, presence, voice + text chat.
• PSN integration - sign-in, friends, party.
• Content delivery - DLC, patches, packaging.
• Compatibility - generation matrix (PS4 base / PS4 Pro / PS5 / PS5 Pro), Game Boost, backward compatibility.
• Hardware peripherals - DualSense haptics, adaptive triggers, PSVR2 (where applicable).

Submission workflow (public framing)

Sony documents its high-level publishing workflow publicly via playstation.com/en-us/develop; the per-step TRC details below are NDA, cite by stable ID.

1. QA pre-cert - partner runs internal TRC dry pass.
2. Submission upload - Master to Sony's submission system (NDA - stable ID).
3. Format QA - Sony's QA team validates the build against the TRC (NDA - stable ID).
4. Pass / Fail decision - fail tickets list each TRC clause violated (NDA - stable ID).
5. Re-submit - corrected master goes back through the same workflow.

Severity vocabulary

Sony classifies findings on a severity scale comparable to the Microsoft CFR / SRI split (NDA - exact terminology cited by stable ID per Step 4 fallback). Each finding lists the TRC clause it violates and the steps to reproduce.

SLAs

Sony does not publish SLAs publicly. Practitioners budget calendar-weeks for a console-game format QA pass (cite by stable ID; no public source). Patch / minor-update SLAs are shorter than initial-release SLAs (NDA - stable ID).

Nintendo Lotcheck

Source of truth

• Document: Nintendo Submission Guidelines ("Lotcheck") - gated Nintendo Developer Portal, cited by stable ID "Nintendo Lotcheck" per PLUGIN_AUTHORING.md Step 4 fallback. (Applies to every Nintendo-specific clause in this section.)
• Public-facing partner portal: developer.nintendo.com (the developer landing page is reachable without NDA but only general program info; the Lotcheck document itself requires developer-portal access).

Structure

Nintendo Lotcheck (NDA - cite by stable ID) covers analogous buckets:

• Functional and stability - boot, save, error recovery.
• Network play and online services - Nintendo Network authentication, online matchmaking, friend lists, parental controls.
• Profile and user data - Nintendo Account, Mii, save data.
• Storage - microSD / system memory boundaries, save data cloud sync where applicable.
• Compatibility - across Switch hardware revisions (original / Lite / OLED) and Switch 2 where supported, docked vs. handheld mode transitions, joy-con + Pro Controller + detached + paired modes.
• Performance - sustained framerate in handheld vs. docked, thermal behaviour during long sessions.
• eShop metadata + ratings - region-specific (Japan / Americas / Europe / Australia / Korea).

Workflow (NDA - stable ID)

The Lotcheck submission workflow is comparable in shape to Sony TRC: pre-cert dry-run, master upload, Nintendo QA pass, fail ticket list keyed to Lotcheck clauses, re-submission. Exact step names and SLAs are NDA - cite by stable ID per Step 4 fallback.

Notable distinguishing constraints

• Handheld / docked transitions are a Switch-specific test surface that has no analogue on Xbox / PlayStation (NDA - stable ID for exact clauses).
• Cartridge + eShop dual delivery complicates patch / DLC layout (NDA - stable ID).
• Joy-Con drift / detached / single-Joy-Con modes add a controller-state matrix beyond the Xbox / PS controller test surface (NDA - stable ID).

Steam Direct

Source of truth

• Application: partner.steamgames.com/doc/store/application
• Fee: Steam Direct Fee
• Content Survey: partner.steamgames.com/doc/gettingstarted/contentsurvey
• Review Process: partner.steamgames.com/doc/store/review_process

Workflow

Per the App Review Process:

1. Developer purchases the Steam Direct Fee or obtains an app credit; creates the application in Steamworks.
2. Developer completes the Content Survey (age ratings, content warnings).
3. Developer marks the title "ready for review" - two parallel reviews begin:
   • Store Presence Review - 3-5 business days (plan for 7).
   • Product Build Review - 3-5 business days (plan for 7).
4. On approval, the title can be released on its scheduled date.

Per the same page: "Once your game has been reviewed and approved, there is no need to go through review again."

What is reviewed

Per the same page, the Store Presence Review checks:

• "Your store page should only contain features and content that will be available at launch."
• "Capsule images must display readable product titles / logos."
• "Screenshots must show only gameplay, excluding concept art or marketing materials."
• Description quality, no external links.

The Product Build Review checks:

• "Your product will need to start up properly" across all listed OSes.
• "All supported features listed on the store page will need to be implemented."
• "Your product must use Steam Wallet for any in-game transactions."

Special categories

Per the same page:

• Early Access - requires answering all Early Access section questions before review.
• Adult Content - both store-page and build review required; may exceed standard timeframes.
• Trading Cards - separate 3 - 5 business day review for card assets and drop configurations.

Comparison to console cert

Steam Direct is dramatically lighter than the three console regimes: no equivalent of Xbox XR test cases, no equivalent of Sony TRC bench matrix, no equivalent of Nintendo handheld / docked test surface. The bar is "starts up + features match store page + uses Steam Wallet for IAP" rather than a multi-stage cert pass.

Cross-platform comparison summary

Sequencing across platforms

A pattern that surfaces issues earliest:

1. Xbox Optional Submission first. Public requirements + paid pre-pass means partners get the most explicit feedback on the most-numerous XR list before sinking it into Sony / Nintendo submission slots.
2. Sony TRC dry-run (internal, against the partner's most recent TRC version). Patterns the team learned from Xbox port over.
3. Nintendo Lotcheck if the title supports Switch - handheld / docked + Joy-Con state surface is unique and needs its own pass.
4. Steam Direct can usually slot in late; the bar is the lowest.

This is a heuristic, not a mandate - partners with strong in-house TRC expertise often reverse the Xbox / Sony ordering.

Anti-patterns

Limitations

• NDA-only details. Sony TRC and Nintendo Lotcheck exact clause numbers, SLAs, severity vocabulary, and bench matrices are NDA - this skill cites them by stable ID per PLUGIN_AUTHORING.md Step 4 fallback. Partners with portal access should consult the authoritative current revision.
• Microsoft GDK moniker versioning. The XR list ships per GDK release; v16.1 (May 2026) is current at time of writing, but the page header lists gdk-2510, gdk-2604, gdk-2610 monikers - verify the version that applies to your GDK before quoting XR numbers.
• Cloud / streaming variants (Xbox Cloud Gaming, PlayStation Cloud Streaming, GeForce NOW, Nintendo Cloud Streaming) have additional supplementary requirements not enumerated here.
• Region-specific overlays (China's NPPA, Korea's GRAC, EU EAA from 2025-06-28) layer on top of platform cert and are out of scope of this skill - consult per-region documentation.
• Mobile (iOS App Store / Google Play / Galaxy Store) is not a "platform cert" in the console sense; not covered.
• Retired XRs. The May 2026 v16.1 release retired XR-134 (Data Transfer Using Web Protocols) per the Changes in this Release table; XR identifiers churn release-to-release.