What are the 40 checks?

The checks below are the desk’s proposed acceptance specification. Substitute buyer-specific thresholds before issuing the brief, not after testing.

A. Does the catalogue cover what the publisher actually needs? — 25 points

Award one point for each:

1. A1 — Priority coverage: at least 90% of the buyer’s priority-weighted requirements have documented eligibility for the intended scope.
2. A2 — Essential titles: every designated must-have title is authorised and passes the agreed usable-game test in its required environments.
3. A3 — Portfolio requirements: each required studio, mechanic or editorial category meets its pre-agreed minimum coverage.
4. A4 — Reconciled inventory: titles, studios and material variants are matched to stable identifiers; duplicates and uncertain matches are separately recorded.
5. A5 — Controlled availability: a removal or territory-exclusion change correctly updates the publisher’s catalogue and presentation in a witnessed test.

Use the buyer’s requirement list as the denominator, not the supplier’s catalogue. Assign priorities before seeing proposals—for example, 5 for essential coverage, 3 for planned editorial coverage and 1 for optional additions.

Define requirements at the necessary level of detail: title/configuration × audience × domain scope. A title that is eligible for one property but not another should not silently satisfy both.

First Look Games explicitly says participating studios are not required to provide demo code. Its August 2026 setup guidance also distinguishes available demos from the wider game library. That supports a concrete procurement request: obtain the actual account-level demo export rather than treating a platform’s studio relationships as playable coverage. (firstlookgames.com)

B. Can visitors reliably launch and play? — 20 points

Award one point for each:

1. B1 — Launch success: at least 98% of eligible launch attempts reach the agreed game-ready state within 20 seconds in every mandatory browser/location/network cohort.
2. B2 — Time to ready: each mandatory cohort meets the agreed latency budget; a starting specification is p75 no more than 8 seconds and p95 no more than 15 seconds among successful launches.
3. B3 — Session continuity: at least 98% of successfully launched test sessions complete ten ordinary demo rounds without a blocking error.
4. B4 — Interaction quality: required device tests pass for sizing, orientation, touch controls, audio controls and returning to the publisher page.
5. B5 — Failure presentation: tested expiry, denied territory, unavailable title and quota cases produce the approved message or fallback, without an unintended redirect.

These percentages and timings are proposed purchasing targets. They are not claims about typical supplier performance.

Do not use an iframe’s load event as proof of success. MDN documents that the event fires even when iframe content fails to load, while an iframe error event is not a dependable failure signal. (developer.mozilla.org)

C. Is the integration maintainable and observable? — 15 points

Award one point for each:

1. C1 — Reproducible deployment: a second engineer can deploy the approved integration from the documentation without undocumented assistance.
2. C2 — Credential lifecycle: secret storage, rotation, expiry and cache behaviour pass the security and deployment tests.
3. C3 — Catalogue synchronisation: pagination, incremental updates, removals, retries and rate-limit handling work using the supported mechanism.
4. C4 — Meaningful telemetry: the publisher can distinguish launch request, game-ready, timeout and relevant session failure, with an identified measurement method.
5. C5 — Change control: staging, release versioning and rollback are demonstrated against the publisher’s CMS and delivery stack.

For cross-origin messaging, validate the expected sender, message structure and intended target. MDN specifically recommends checking message origin and, where appropriate, source, and using a specific target origin rather than a wildcard when known. (developer.mozilla.org)

Do not assume API access means live-page delivery. Slots Launch documents its API as a synchronisation service: store records locally and periodically retrieve changes rather than querying it for every visitor page load. Assess the proposed architecture against the supplier’s actual usage model. (docs.slotslaunch.com)

D. Are metadata and demo versions fit for editorial use? — 10 points

Award one point for each:

1. D1 — Required fields: at least 98% completeness for the buyer’s mandatory fields across the proposed publishable set, with missing values explicitly represented.
2. D2 — Provenance: sampled claims can be traced to studio material, a licensed source or another identified primary record.
3. D3 — Freshness: the last ten relevant, eligible releases—or all available if fewer—meet the agreed feed-to-publish target; record sample size and timestamps.
4. D4 — Configuration fidelity: every sampled review-critical demo is mapped to its build/configuration, or editorial claims are narrowed to reflect what remains unknown.
5. D5 — Correction handling: a changed date, withdrawn title and corrected field flow through the CMS without overwriting separately owned editorial work.

Keep release date, publisher availability date and last metadata update separate. A schema containing rtp, markets or restrictions is not evidence that every returned record is complete or resolves your permission question; Slots Launch’s endpoint documentation illustrates these as distinct fields. (docs.slotslaunch.com)

For version assessment, request the game’s stated configuration and supporting documentation rather than inferring equivalence from a short play session. As a UK—not US—regulatory reference, the Gambling Commission’s RTS 6 addresses faithful play-for-free representations and labelling of demonstrations designed to show bonus features. It is a useful reason to ask about demonstration mode, not a legal standard automatically applicable to a US publisher. (gamblingcommission.gov.uk)

E. Do the implemented controls match the approved design? — 10 points

Award one point for each:

1. E1 — Data inventory: sampled network and storage observations are reconciled with the declared vendors, purposes, retention and contractual roles.
2. E2 — Privacy choices: applicable consent and opt-out scenarios produce the reviewed behaviour, including third-party requests and storage.
3. E3 — Embed security: domain restrictions, message validation, credential handling and required iframe permissions pass engineering review.
4. E4 — Presentation: approved non-wagering labels, disclosures, age controls and outbound destinations remain correct on required devices.
5. E5 — Incident controls: the team demonstrates revocation, content disabling and escalation without exposing sensitive information in logs or shared reports.

Test browser defaults rather than asking users to weaken privacy protections. WebKit documents default third-party-cookie blocking through Intelligent Tracking Prevention, making cookie-dependent embedded flows an explicit compatibility test. (webkit.org)

Where California requirements apply, include a preference-signal test and the associated confirmation behaviour. Where FTC disclosure guidance applies, inspect the visible relationship disclosure alongside the recommendation. These are separate checks, not interchangeable benefits of installing a consent tool. (cppa.ca.gov)

F. Will support and change management work under pressure? — 8 points

Award one point for each:

1. F1 — Service commitment: agreed support hours, severity definitions and response targets identify the services and upstream failures covered.
2. F2 — Escalation test: an authorised test ticket reaches the correct owner within the agreed response target.
3. F3 — Incident evidence: the supplier provides suitable incident/status evidence or completes a witnessed incident exercise if historical evidence is unavailable.
4. F4 — Change notice: notice, migration documentation and escalation arrangements for breaking changes are contractually or otherwise acceptably documented.
5. F5 — Removal workflow: a game withdrawal is communicated and actioned through a tested publisher workflow.

Current diligence trigger: Slots Launch’s documentation names 15 November 2026 as its signed-request migration deadline, with unsigned access rejected after the deadline unless account-specific legacy mode applies. As of 28 October 2026, this is an upcoming change. Confirm the exact cutover time, account treatment and deployment plan; do not treat possible legacy access as an entitlement. (docs.slotslaunch.com)

Its embed instructions also warn against storing signed URLs in page caches beyond their lifetime and require secrets to remain server-side. Include cache-expiry testing in the migration acceptance record. (docs.slotslaunch.com)

G. Is the total cost understandable and acceptable? — 7 points

Award one point for each:

1. G1 — Complete quote: setup, recurring fees, minimums, domains, usage, hosting, support and relevant taxes are identified or explicitly excluded.
2. G2 — Billable-unit definition: repeat launches, retries, bots, previews, staging and rejected requests have documented billing treatment.
3. G3 — Twelve-month model: internal integration, content operations, monitoring, permissions administration and planned exit work are costed.
4. G4 — Stress cases: the plan remains within the approved budget under agreed traffic and maintenance scenarios, or has an enforceable cap.
5. G5 — Commercial flexibility: renewal, cancellation, price changes, unused commitments and migration assistance have acceptable terms.

Slots Launch’s pricing page defines a request as a game load. This illustrates why page views, visitors, launches and billable requests must not be treated as the same unit. Obtain the account-specific treatment of edge cases rather than extrapolating from the headline plan. (slotslaunch.com)

H. Can the publisher survive withdrawal or leave? — 5 points

Award one point for each:

1. H1 — Dependency map: essential content is mapped to its studio, distributor, hosting route and publisher integration.
2. H2 — Termination treatment: notice, emergency withdrawal, removal duties and permitted retention/export are documented.
3. H3 — Export test: the buyer can export the mappings and records it is entitled to retain and use them in a migration rehearsal.
4. H4 — Safe fallback: disabling a supplier produces approved editorial or unavailable-content pages without broken controls or unauthorised substitutes.
5. H5 — Recovery rehearsal: the team demonstrates replacement or safe withdrawal for a representative essential-content group within its chosen recovery objective.

An alternative distributor should count as resilience only after its rights, catalogue and underlying dependencies are checked. Do not award a point simply because two sales contracts exist.