A casino game certification submission should bind one exact release candidate to the source, math, rules, artwork, configuration, environment and test evidence that describe it. A folder of individually correct documents is not ready when the laboratory cannot prove that they all belong to the same game version and target market.
For a studio product owner, compliance lead, test lead, operator onboarding team or procurement buyer, the decision is whether the package is complete and internally consistent before independent testing begins. The useful delivery artifact is a controlled submission index and scope matrix that names every item, version, owner, dependency and applicable market requirement.
Choose the market and testing route before freezing the package
Casino game submission readiness starts with the target jurisdiction, responsible licensee and authorized testing route. Those choices determine which standards apply, who may test, which reports must be filed and whether an existing evaluation can be reused.
The UK Gambling Commission’s procedure for testing requires licensees and their chosen approved test house to agree a scope sufficient for the Commission’s standards. The Commission maintains a current approved test-house list, but that list applies to its own testing framework. It is not a universal directory for every market.
Ontario provides a different example. The Alcohol and Gaming Commission of Ontario’s technology certification policy places obligations on operators and gaming-related suppliers running critical gaming systems, and requires applicable games, random number generators and wagering components to be certified by a registered independent testing laboratory before deployment. Prior testing may be considered only when the laboratory determines that it is relevant to Ontario’s standards.
Write a one-page scope statement before packaging files. Name the game and paytable versions, channels, target markets, operator configuration, platform and RNG dependencies, submission type, applicable standards, laboratory contact, filing owner and intended release boundary. Mark every unknown as an open decision rather than hiding it in a generic checklist.
Build one controlled submission index
The submission index should be the authoritative inventory of everything the laboratory receives and every item still outstanding. It connects business scope to technical evidence and prevents an email thread or upload folder from becoming the accidental record.
Give each item an identifier, title, revision, owner, source location, submitted filename, cryptographic digest where appropriate, delivery date, confidentiality handling and relationship to the release candidate. Include source code, compiled binaries, build instructions, signatures, math documents, rules, artwork, configuration, supported environments, test utilities, prior reports, change records and known exceptions only when they belong to the agreed scope.
GLI’s Composite Submission Requirements Version 2.0 describes documentation and materials that may be requested for evaluations and explicitly warns that jurisdiction-specific requirements can add to them. Treat it as a practical submission baseline, not a promise that one package satisfies every authority.
Assign one accountable submission owner and one technical owner for each evidence family. The index should also name who may answer laboratory questions, approve corrected material and decide whether a query reveals a change to the product or only a clarification of the evidence.
Bind source, binaries and build identity
Build identity should make the submitted executable traceable to the reviewed source and to the candidate intended for release. A filename or semantic version alone cannot prove that relationship.
Record the repository revision, dependency lock state, build environment, compiler or toolchain versions, build command, generated inputs, artifact digests and signing state. Preserve the submitted binaries as immutable artifacts. If the laboratory performs an independent or witnessed compile, record the method and explain how the resulting object is compared with the supplied release candidate.
The GLI submission requirements call for complete source, compiled files, architectural documentation, software signatures and tools necessary for testing. They also say source should be complete and compilable, with the compiled object identical or verifiably functionally identical to the submitted medium through an agreed method.
The casino game supplier security guide explains the adjacent SBOM and provenance evidence. Certification readiness uses those controls to answer a narrower question: exactly which components and build did the laboratory evaluate? An SBOM supports that answer, but it does not replace source review, game testing or the target authority’s approval process.
Make math, rules and artwork describe the same game
Game math, player rules and artwork should use one controlled vocabulary and point to the same paytable and feature configuration. A laboratory should not have to infer whether a symbol name, award table or bonus condition in one file matches a different label in the client.
Submit the applicable math model, theoretical return calculations, random-input mapping, prize tables, feature logic, emulation instructions and rare-outcome methods together with the player-visible rules and all artwork that carries rules or paytable information. Cross-reference each material rule to its math definition, runtime behavior and expected test.
The GLI requirements for game submissions ask for legible game artwork, complete descriptions, winning combinations, pays, betting schemes, bonus details and emulation instructions as applicable to the game type. The same document notes that independent translations may be required for artwork. These are GLI submission inputs, not a substitute for the target market’s own content and language rules.
Use the casino game math model guide to structure the PAR and test evidence, and the casino game rules specification guide to keep player information aligned with code and math. The submission index should reference those controlled sources instead of copying selected values into a separate laboratory summary that can drift.
Reproduce the intended operating configuration
The test configuration should reproduce every production choice that can change game behavior or fairness. Testing a flexible supplier package without the operator’s actual paytable, RNG, platform, channel and feature settings can leave the evaluated product different from the one intended for players.
GLI-19 Version 3.0 states that the production configuration should be communicated to the independent laboratory so it can create a functionally equivalent test environment. The UK testing procedure likewise expects testing in the software and environment intended for live operation, with integration testing where differences could affect fairness.
Create a configuration manifest that records the game and paytable IDs, RNG and RGS versions, supported channels and devices, currency and denomination profile, feature switches, localization package, service endpoints, time source, security controls and test accounts needed for the scope. Replace secrets with a secure delivery mechanism agreed with the laboratory. Never put credentials in the ordinary submission index.
Document deliberate differences between test and production with their reason and test consequence. A test stub, accelerated mode or outcome-emulation tool may be necessary, but the package must explain how it relates to production logic and what it cannot prove.
Separate a new submission from a modification
A modification submission should identify the previously evaluated version, the exact change and the evidence that remains valid. Resending every historical file without a change boundary makes review slower and can obscure which assumptions need retesting.
The GLI submission requirements distinguish first-time prototypes from modifications. For software changes, they request the earlier version, a plain-language description with test scenarios, affected modules and new source, while allowing unchanged documents to be referenced. The UK testing procedure uses a different framework: changes affecting game fairness require external retesting, while all updates remain subject to change-control records and responsibility.
Do not turn either framework into a universal major-or-minor label. Build a change-impact matrix against the actual market and laboratory route. For each change, assess math and fairness, RNG use, rules and artwork, game state, player display, channel, platform integration, security, responsible design, localization and prior report references. Record who accepted the classification and which regression set follows.
Resolve laboratory queries without version drift
Laboratory questions should update a controlled query log before they update any submitted file. A quick replacement attachment can silently create a package that contains two different versions of the same evidence.
Record the query, date, affected item, responsible owner, interpretation, response, revised item version, new digest and impact on scope or previous tests. If the answer changes product behavior, stop treating it as a document clarification. Create a new candidate or approved modification boundary, then let the laboratory decide which tests must be repeated.
Keep questions separated into missing evidence, ambiguous evidence, product defect, environment issue and scope decision. That classification lets the team fix the cause without presenting every query as a failed certification or treating a real product change as clerical cleanup.
Turn the laboratory result into release acceptance
The final test report should be reconciled with the exact release candidate, scope and unresolved conditions before an operator accepts the game. A report title, approval letter or passing summary is not enough when its build identity or configuration differs from the package prepared for launch.
Check the report’s tested versions, digests, standards, jurisdiction, laboratory authority, configuration, environment, exclusions, open observations and referenced earlier reports against the submission index. Confirm that the release candidate is the tested candidate or has followed the approved change route. Preserve the report and index together with the deployment authorization and release evidence.
The package does not guarantee certification, replace a regulator or laboratory, or prove that the game is suitable for every market. It gives a studio and buyer one inspectable record of what was submitted, what was tested, which questions changed the package and whether the intended release still matches the evaluation.
For teams commissioning a new casino game, Wizards game development can turn target-market requirements, game assets and acceptance criteria into a controlled build and laboratory-ready submission package.
Frequently asked questions
What belongs in a casino game certification submission?
A submission should include the agreed scope, exact source and binaries, build identity, math, rules, player-facing artwork, configuration, environment details, test utilities, change records, prior report references and known exceptions required by the target market and laboratory.
Who decides the test scope for a casino game?
The applicable authority, responsible licensee and authorized laboratory determine the required route and scope. A supplier checklist can organize the evidence, but it cannot set universal certification requirements.
How should a studio prove which casino game build was tested?
The studio should bind repository revision, build environment, dependency state, binaries, signatures or digests and test evidence to one immutable release candidate, using an independent or witnessed build comparison where the agreed process requires it.
Can a previous casino game test report be reused?
It may be referenced when the authority and laboratory accept its relevance and the affected product, standards and configuration remain applicable. Changes must be classified against the target market before prior evidence is reused.
What happens when a laboratory question changes the game?
The team should create a new controlled build or modification boundary, update the submission index and let the laboratory determine the affected retest scope. It should not replace a file silently inside the original package.
Does a laboratory report guarantee approval in every market?
No. Jurisdictions define their own requirements, may authorize different laboratories and can require additional filings, testing or operator controls. The report applies only to its stated scope, standards, configuration and release identity.
