A commissioned slot is usually bought with an assumption attached: that the operator will be able to tune it. The bet ladder, the language set, the currency, the help text, the small visual fixes that surface after launch — all of that reads as configuration, and configuration reads as free.
The published testing rules do not sort changes that way. They sort them by whether the change can affect fairness, and the answer determines whether a build may ship tonight, after notice, or after an approved test house has looked at it again. That distinction belongs in the commission brief, not in the support queue eighteen months later.
This article sets out the three surfaces a slot build actually has — what arrives as a launch parameter, what is studio configuration the certificate covers, and what is a change to the certified object — and turns them into language a buyer can put in a contract.
The settings that arrive with the session
Some of what looks like configuration never touches the build. On a platform such as Engine, the launch URL carries a session identifier, the RGS host, a language code, a currency, a device class and flags for the demo and social-casino modes. The front end reads those values when it loads, and the platform documentation is explicit that the RGS host must not be hardcoded because it can change.
Those parameters are genuinely operator-side. They change per session and per operator without a new build, and a client that mishandles them is a delivery defect rather than a certification question. Two of them carry more weight than they appear to.
The language value is an ISO 639-1 code, and the documented behaviour for a code outside the supported list, or an empty value, is a fallback to English. So “the platform supports many languages” is not the same statement as “your market’s language is in the delivered build”. The documented list covers seventeen languages; Italian is not one of them. Whether Italian copy exists is a scope line in the brief.
The currency value affects the display layer, not the game logic — amounts on the RGS are integers with six decimal places of precision. The documented currency table mixes two-decimal, three-decimal and zero-decimal currencies. A build that formats whatever code the wallet returns with no fallback for an unusual currency breaks on the first operator whose market is not in the language runtime’s default tables.
The bet ladder sits in the same category but has a longer tail. Minimum bet, maximum bet and step are returned at authentication, so the ladder is a session parameter. What the ladder is allowed to contain is not: stake ceilings and game-cycle measurement are market rules that constrain the build, which is why the British cap reshapes the ladder rather than the launch call. The stake cap analysis covers that constraint in detail.
The cosmetic change that is not cosmetic
Great Britain’s testing strategy is the clearest published statement of the sorting problem, because it states the principle and then gives examples on both sides of it.
A major update, which requires external retesting by an approved test house, is defined as any software change that may affect the fairness of a game — and fairness is spelled out as any change to the random number generator, to scaling and mapping, or to game rules, including how the rules are processed by the software.
The examples are what make the definition useful, because one of them looks like housekeeping. A studio reworks how the game symbol arrays are constructed to cut CPU load and improve performance. No rule changed, no paytable changed — and it is still a major update, because the software implementation of the rules changed. Against that sits the minor list: a sound format change to support a device, a character’s hat colour and background graphics changed because an IP licence expired, a bonus round display fix that touches nothing about winnings, a stake-selection dialog that renders badly in one browser, a home-button lobby URL added, a button slightly out of alignment.
The guidance is honest about the boundary. It notes that one of the minor examples — several small defects in one release — could easily fall into the major definition, and that where doubt exists the expected move is consultation with the original test lab. It also defines “game rules” for this purpose as the underlying maths and design: paytables, symbol distribution, feature rules. A clarification to the wording of the rules as presented to the player is not, by itself, a major change.
That footnote is the most valuable sentence in the document for a publisher, because it separates two things that arrive in the same ticket: the disclosure text can change as copy, while the mechanic it describes cannot change without the fairness question being asked.
The tiering used where a change programme exists
Great Britain’s major/minor split is one regulator’s method. A second method appears wherever a jurisdiction has adopted a change management programme, and the interactive gaming standard defers to it directly: where the regulatory body has adopted a programme such as the GLI Change Management Program Guide, that programme decides which changes to previously evaluated components require modification testing, with the scope depending on the nature, extent and potential impact of the change.
That guide sorts changes into three levels, and the examples are again the useful part.
Level 1, no impact. Backup software and hardware, adding or removing users, non-critical database maintenance, infrastructure outages, operating system security patches, and — the entry that matters here — background images, colour schemes and similar ancillary front-end client updates. Deploy without notification.
Level 2, low impact. Firewall rule changes, database maintenance, movement of regulated backup data, added or changed hardware.
Level 3, high impact. A new gambling feature, or a change to any logic that affects wagering or game logic; a change affecting required regulatory reports or reconciliation data; a substantial change to geolocation services; a change to the handling or storage of personally identifiable information; a change made to accommodate updated regulatory requirements.
Two operational requirements attach to levels 2 and 3: at least three business days’ advance notice to the regulator and to the test laboratory that performed the prior certification, and, where pre-deployment certification is not demanded, laboratory testing completed within ninety days of the change going into production. A regulator or delegated laboratory can pull a change into pre-deployment testing inside that notice window. The programme also requires a change log recording, at minimum, the internal approval time, the components and version identifiers changed, the reason, the person authorising, the person performing, the anticipated release date and the change level.
That last list is the practical artefact. A studio that cannot produce those fields for a launch build cannot operate inside a change programme, and an operator who has not asked for them is buying a build it will have to freeze.
What the operator actually owns
Put the three sources together and the configuration surface of a commissioned slot divides cleanly.
Session parameters. Language, currency, device class, session identity, RGS host, demo and social flags. Operator-side, per session, no build change.
Presentation and disclosure copy. Help text wording, term glossaries, translated rule explanations, lobby links, the phrasing of a tournament or promotion blurb. These are content, and in most markets they are the operator’s or publisher’s to change — with one condition: the words must keep describing the certified object accurately. A help screen edited to promise a feature the maths does not pay is a fairness problem wearing a copy ticket.
Cosmetic and device fixes. Sound formats, layout alignment, asset replacement forced by a licence expiry, a dialog that renders badly on one browser. Minor in the British scheme, level 1 or low level 2 in a change programme.
Everything the certificate names. Math version, front version, RTP setting, feature logic, paytable, symbol distribution, win presentation tied to the economic outcome. These are the certified object. Changing one is not a setting; it is a new build with its own evidence. The variant analysis makes the point for return settings, and the localised certification evidence guide covers what a certificate has to name before a shelf decision.
The trap is in the middle zone. A “small” change to how the client computes a displayed win, a rounding tweak in the coin display, a new animation that changes when the outcome is revealed — each of those is cosmetic in appearance and a fairness change in substance. The test to apply is not how large the diff is but whether any outcome a player could receive is computed or presented differently.
Turning it into brief language
Four clauses carry most of the protection, and none of them requires a lawyer to draft.
A configuration register as a deliverable. One table listing every parameter the operator may set, where it is set, whether it ships as a launch value or a build constant, and the change classification for each in the markets the game is aimed at.
The change discipline, named. Which change programme, if any, applies to each target market; the notice window the studio will work to; and who notifies — because in the guide the supplier records changes and the platform provider maintains the log, and a small operator buying a game from a studio plus a platform has three parties and often no owner for that duty.
Evidence per level. For level 1 and minor changes, a log entry and a reasoned classification. For level 3 and major changes, the modification submission: identification of the previously certified version, the description of the change with test cases, the modules affected, and the source of the new version. That is the submission shape the laboratories publish, and asking for it is not an unusual request.
A freeze clause with a price attached. What happens if the operator wants a change the studio classifies as certified-object. The answer should be a scope change with a stated cost and a stated certification path, agreed before the change is made — not a negotiation after the launch campaign has been booked.
Where localisation sits in all of this
A localised build is the commonest place to meet the boundary, because translation touches text, layout and often artwork at once.
New locale copy is content. A translated help screen that has to describe the game’s rules accurately is content that creates an obligation: the explanation has to stay equivalent across the languages offered. What is not content is the set of languages the build supports, the currency formatting rules it implements, and any artwork whose symbols carry meaning in the maths. Those are in the build and in the certificate.
Practical consequence for a brief covering Spanish, Portuguese and Italian: name the locales, name the fallback, and name who signs off that each translation still describes the certified rules. Then treat any later locale addition as its own review, not as another row in a translation tool.
What this article does not decide
It is not a compliance opinion for a specific market, and the two frameworks described apply where a regulator has adopted them — the British major/minor split is the Commission’s testing strategy for its own licensees, and the change programme tiers apply where a jurisdiction has taken the programme up. The right move for a named market is to ask the test house that certified the build.
What the published rules do establish, across every market that has written one down, is that the classification is a property of the change’s effect on fairness rather than of the change’s size. A studio that can classify a change and evidence it is a cheaper partner than one that treats every request as a new project or, worse, ships it silently.
If you are writing a brief and want the configuration surface, the change classification and the market set settled before the quote, request a project quote. The commissioning guide covers how the brief is assembled, and the submission package guide covers what the evidence looks like at the other end.
Questions buyers ask
Can the operator change the bet ladder after the game is certified?
The values are supplied at authentication, so the ladder is read per session. What those values may be is constrained by market rules — stake ceilings and how a game cycle is measured — and those constraints live in the build and its documentation. Ask for the register that states which limits are session values and which are build constants, because a ladder that can be edited past a certified ceiling is a compliance defect rather than a feature.
Is fixing a broken sound file or a misaligned button a certification change?
In the British framework that is the minor category, which covers updates that do not affect game fairness, with sound format changes and display defects given as examples. A change management programme places the same kind of work at its lowest level. It is not the same as unlimited freedom: the fix has to leave the rules, the maths and the way outcomes are presented untouched, and it still belongs in the change log.
Why does a performance change count as a major update?
Because the fairness definition covers how the rules are processed by the software, not just what the rules say. The published example is a rebuild of the symbol arrays to cut CPU load: no rule changed, and the implementation of the rules did, so the update needs external retesting. Any optimisation that changes how outcomes are drawn, mapped or evaluated should be treated the same way until a test house says otherwise.
How much notice does a change need before it goes live?
Where a change management programme applies, at least three business days’ advance notice to the regulator and the laboratory that performed the prior certification for the two higher levels, with post-deployment testing completed within ninety days if certification was not required beforehand. The notice window is a floor, and a regulator can require testing inside it. Markets without an adopted programme set their own process, so the schedule has to be built per market rather than once.
Does adding a new language mean a new certificate?
The text itself is content, but a new locale touches the language set the build supports, the formatting the client applies and any artwork carrying meaning — which is where it becomes a build change. The safe procurement position is to have every intended locale in the original submission, and to treat a later addition as a scoped review with its own evidence.
