The list comes first
Every major platform holder publishes a formal requirements document — Nintendo's Lot Check guidelines, Sony's Technical Requirements Checklist, Microsoft ↗'s Title Requirements — and the document is not advisory. Each line item is a binary pass or fail. A studio submits a candidate build; the certification team runs it against the list; the build either clears every gate or it comes back with a failure report specifying which items broke and which submission number this is. First-time pass rates across the industry are low enough that a second or third submission is routine rather than embarrassing. The calendar builds in the time, because it has to.
What the list actually tests surprises people who assume certification is primarily about content ratings or violent imagery. The rating boards — PEGI in Europe, the ESRB in North America, CERO in Japan — sit in a parallel process and are handled separately. Certification, strictly defined, is about behaviour: how the software responds to the hardware it runs on, how it identifies itself to the system, and whether it handles every state the machine can enter without breaking.
Naming, identity and error handling
The first tier of requirements is almost bureaucratic. The title identifier must match the registered product exactly. Version strings must be correctly formatted. Store listings, product codes and the metadata embedded in the build must be consistent with one another and with what the platform holder has on record. These checks exist because the storefront, the update pipeline and the telemetry systems are all keyed to those identifiers; a mismatch anywhere creates downstream failures that are difficult to diagnose and expensive to fix in the field.
Error handling is checked with equal thoroughness, and this is where many builds first stumble. The platform holder specifies exactly what the software must do when storage is full, when a network connection drops mid-session, when a peripheral is disconnected, when a second user signs in on a shared console, when a download is interrupted. Each scenario has a required response — a defined error message, a defined recovery path — and the test rig triggers every one of them deliberately. A game that crashes gracefully is not good enough; the crash must produce the correct screen, with the correct text, within the correct time window.
Save behaviour is tested to a similar level of granularity. The requirements specify when the system may not write to storage, what the software must do if a save attempt fails mid-write, and what state the player's data must be in if power is cut during that window. The underlying concern is data integrity ↗: a corrupted save that destroys hours of progress is a support call, a refund request and a platform reputation problem, so the platform holder codifies exactly how to prevent it.
Suspend, resume and the system layer
Suspend and resume testing has become the densest part of the modern checklist. Contemporary consoles expect software to yield to the system shell instantly — incoming messages, notifications, voice-chat overlays, and power-saving sleep states all require the running title to pause correctly, release or correctly retain the resources the system needs, and then restore its own state cleanly when focus returns. The requirements specify maximum response times, permitted memory footprints during suspension, and exactly which audio channels must be silenced. A build that takes two seconds too long to yield, or that corrupts its own state across a suspend cycle, fails here.
The day-one patch problem sits directly downstream of all this. Because certification takes weeks and disc manufacturing takes additional time, any bug found during the submission process — or fixed after the submission was sent — cannot reach disc. It arrives instead as a mandatory download on launch day, which is why the patch pipeline is itself subject to certification rules: the update must not break any behaviour the base build had already passed. Studios therefore maintain parallel branches, one frozen for certification and one continuing to receive fixes, and the discipline of keeping those branches coherent is its own form of production overhead.
What the process reveals, once a studio has been through it several times, is that the requirements document is a precise map of every place a console platform can fail in the field. Passing it does not mean the game is good. It means the game will not break the box.
