Game & mathematics
Rules, model, implementation and round evidence.
Coordinate the software assessment.
Independent Testing & Certification Coordination
Prepare the scope, reproducible technical evidence and finding history your appointed assessor needs. Keep every artifact tied to the build it describes.
Define your assessment package
The service, clearly defined
What does independent testing and certification coordination prepare?
Certification coordination prepares a defined platform or game build for independent assessment. It includes scope clarification, technical documents, test access, reproducible evidence, finding remediation and release traceability. Coordination is separate from independent certification itself.
Different objects.
Different evidence.
Component & interface
Defined version, function and integration boundary.
Platform deployment
Configuration, controls and scoped environment.
Define the assessment object, build and evidence manifest
A game, an RNG component, an integration and an operator platform are different assessment boundaries. We work with the customer and appointed assessor to identify the relevant product version, environments, interfaces and evidence requirements. Existing certificates and third-party components must be checked for applicability rather than assumed to cover an altered deployment or a new intended market.
Agree the appointed assessor’s scope before assembling the submission. Identify included and excluded components, source/build references, game rules and mathematics where relevant, interface versions, configuration and deployment environment. Record the requested artifacts and who can authorize their disclosure or provide controlled access. A component certificate, previous game report or unchanged product name does not establish coverage of another build, integration, configuration or jurisdiction; applicability is a question for the appointed assessor and responsible stakeholders.
- Assessment scope and version inventory
- Third-party component evidence
- Environment and access requirements
SCOPE & MANIFESTComponent, game or platform build/configuration
Included artifacts, dependencies and exclusions
Identify the exact software object and environment.
Confirm the appointed assessor's requested scope and evidence. Record source, rules/mathematics and access owners where applicable.
REMEDIATION RECORDReproduction, responsible owner and candidate fix
Regression evidence and independent retest response
Keep the finding, fix and retest together.
Coordinate questions and reproducible responses. A developer-completed fix remains distinct from the appointed assessor's finding disposition.
CHANGE IMPACTCode, mathematics, dependency or setting differences
Assessor applicability and additional evidence decision
Review changes against the assessed baseline.
Retain earlier reports with the versions they cover. Coordinate the requested reassessment or retest without assuming universal certificate reuse.
ASSESSMENT HANDOVERReport scope, software baseline and remaining conditions
Operator release and other readiness workstreams
Carry scope and open conditions into the launch plan.
Hand over the technical dossier and response history. Provider access, production setup and the authorized launch decision remain separately owned dependencies.
Build a reproducible evidence package
The evidence can include game rules and mathematics, transaction flows, access controls, logs, test results and build identifiers, depending on the agreed assessment. We keep the documentation aligned with the actual implementation and provide test accounts or controlled access as required. Questions and findings are tracked to an owner, a proposed resolution and a retest result.
- Versioned technical documentation
- Reproducible test cases and build identifiers
- Finding, fix and retest tracking
Your release package
Assessment scope and reproducible release records
- Assessment readiness and scope register
- Versioned submission evidence pack
- Controlled test environment
- Findings and remediation tracker
- Retest and release traceability
- Certification handover and change procedure
Protect the baseline
the evidence covers.
Review changed code, configuration and dependencies against the actual assessment requirements. The appointed parties determine whether further assessment is needed.
Control fixes, retests and report applicability after changes
A fix made during assessment can affect another part of the system. Change control and regression testing therefore matter as much as the initial submission. Before launch, the team identifies the accepted software baseline and any remaining conditions. Future changes are reviewed against the assessor’s and operator’s requirements, with new submissions coordinated when the relevant stakeholders determine they are necessary.
Freeze the candidate baseline and retain the finding, fix, regression evidence and independent retest correspondence together. If code, mathematics, dependencies or settings change, describe the difference and ask the assessor which evidence or assessment must be repeated. Record the report’s actual scope and unresolved conditions in the release handover. A fix marked complete by developers is distinct from a closed assessor finding, and neither a report nor a certificate automatically activates suppliers or authorizes the operator’s launch.
- Controlled release baseline
- Regression evidence for remediation
- Post-assessment change review process
Questions before the next move.
Software scope, assessment evidence and retest questions
Discuss your requirementsAre you an independent testing laboratory?
No. SwissDice can prepare software and coordinate technical assessment, while the appointed independent laboratory performs its own evaluation and issues any applicable reports or certificates.
Can an existing certificate be reused?
That depends on what it covers and whether the product version, configuration and intended use remain within its scope. The relevant assessor and operator stakeholders should confirm applicability.
What documentation is needed?
The exact request comes from the assessment scope. Typical engineering evidence may include architecture, component versions, transaction flows, controls and test records; game assessments may also require rules and mathematics.
Does passing testing mean the operator can launch?
Not by itself. Independent testing is one readiness workstream. Commercial access, operating approvals, payment onboarding, production configuration and the customer’s final go-live decision remain separate dependencies.
Who supplies source code, game mathematics and assessment access?
The owner or authorized supplier provides the artifacts required by the appointed assessor, subject to the relevant contracts and confidentiality arrangements. We coordinate the request list, versions, access owners and missing evidence. If source, mathematics, test accounts or dependency records are unavailable, the limitation stays visible and is discussed with the assessor rather than assumed away.
What happens when software changes during certification?
Record the changed build, configuration, rules or dependencies against the candidate baseline. Link the fix to its finding and regression evidence, then coordinate the assessor's applicability and retest decision. Keep earlier reports tied to the versions they describe. Neither automatic reuse nor automatic invalidation of every previous result should be inferred without the relevant scope review.
What determines certification coordination cost and timing?
The assessment object, intended scope, evidence readiness, number of findings and retest/change requirements affect the coordination effort. Agree software preparation and coordination fees separately from independent laboratory or authority charges. The submission plan records dependencies, owners and expected review windows; the appointed assessor controls its evaluation and outputs, so approval and completion dates are not guaranteed.
A controlled route to release
Protect the release that is being assessed
Plan the submission
Agree the assessor, scope, build and information requirements. Identify missing evidence and external dependencies before booking the engineering work around a presumed test date.
Support assessment
Provide the requested access and technical explanations. Reproduce findings, implement agreed fixes and preserve a record linking each change to the tested software version.
Close the release record
Collect the assessor’s results and document the accepted baseline. Hand over any conditions, retained responsibilities and future change-review requirements to the operator.
Your ambition. Our next conversation.
Coordinate your independent testing.
Provide the appointed assessor's scope or submission checklist, software and component versions, available test evidence and any outstanding findings. Identify who controls the submitted release and approves remediation so preparation, retesting and version-control work can be scoped accurately.
Let’s build