A branded game is ordered long before it is played. The design that ships is the design somebody described in writing months earlier, and the decisions that cause the most trouble later — what the brand is allowed to change, which players are meant to see it, what “exclusive” actually means, and how anyone will know whether it worked — are almost never technical decisions. They are the commissioning decisions, and they belong to the operator rather than to the studio.
That is why the brief is worth treating as a contract annex rather than a mood board. A studio can invent mechanics and a lab can test mathematics, but neither can decide what a licensed operator is willing to put in front of its players under its own brand, in which markets, and against which promise. Those choices are made once, near the beginning, and they are expensive to revisit afterwards.

The brief is the part of the commission a studio cannot write for you
It is tempting to hand over a brand deck and a competitor list and let the studio propose. That works for licensing an existing title, where the operator is choosing from finished products. It does not work for a commission, because a commission is built to order and every unstated decision is filled in by whoever is doing the building.
The test is simple. For each line of the brief, ask who is accountable if it is wrong. If the answer is the operator — the brand was misrepresented, the wrong market saw the game, a promise was made about it that cannot be evidenced — then that line is the operator’s to write, not the studio’s to infer.
Four of those lines cause most of the rework: what the brand may and may not do to the game, what the player will be told about it, which markets it must serve at launch, and what the launch is supposed to prove.
Decide what the brand is allowed to do to the game
A brand brings recognition, and it also brings pressure. The obvious failure mode is cosmetic — a logo dropped onto an unrelated engine — and the more dangerous one is behavioural: a themed feature that quietly pushes the game towards more repeat play because the theme makes it feel like part of the show.
A licensed operator does not get to invent that boundary from scratch, because part of it is already fixed. The Gambling Commission’s remote gambling and software technical standards state it as a product requirement rather than a style note: “Gambling products must not actively encourage customers to chase their losses, increase their stake or increase the amount they have decided to gamble, or continue to gamble after they have indicated that they wish to stop.” The same document’s guidance is unusually concrete about what that rules out in a themed build — it gives as an example “customers who have chosen to exit a game should not be encouraged to continue playing by, for example, being offered a free game.”
That is a commissioning constraint, not an implementation detail, because it is the kind of thing a brand campaign will ask for naturally: “come back tomorrow for a free spin on the brand’s machine” is a marketing idea before it is a software requirement. If the brief does not say where the brand’s promotion stops and the game’s behaviour begins, the request arrives after the build is finished.
The line to write is therefore narrow and checkable. The brand may own the world, the characters, the sound and the presentation. It may not own anything that changes how often a player is prompted to play again, how a result is celebrated, or what happens when a player has indicated they want to stop. Those are design surfaces with their own acceptance guide, and the commission should point at it rather than restate it: the responsible product design release checklist is where the market-specific version of that work lives.
Decide what the player will be told, because somebody has to publish it
The second operator-owned line is the information surface. A game does not only play correctly; in a regulated market it also has to explain itself, and that obligation lands on the operator’s brand, not on the studio’s build notes.
The standards make the timing explicit. An explanation of the applicable rules “must be easily available to the customer before they commit to gamble”, and separately, information that may reasonably be expected to enable a customer “to make an informed decision about his or her chances of winning must be easily available before the customer commits to gamble” — a list that includes the house edge or margin and the return to player percentage.
The commissioning consequence is that the player-facing explanation is a deliverable of the commission, not a page somebody writes at the end. It has to be authored in the operator’s languages, it has to match the mathematics that were actually built, and it has to survive the next paytable change. A branded game whose help content describes the theme but not the odds is unfinished, however good it looks.
That is why the rules and the mathematics deserve to be frozen as versioned artefacts before implementation rather than described in prose in a slide deck. The rules specification guide and the math model and PAR sheet guide cover that handover; the brief’s job is to say, in advance, that player-facing information is in scope and who signs it off in each language.
Name the markets and their presentation before the build starts
“Which players is this for?” sounds like a marketing question and behaves like an engineering one, because the answer changes the build.
Three different answers are commonly confused:
| The answer sounds like | What it actually commits the build to |
|---|---|
| “Our players” | One presentation, and a decision later about everyone else |
| “These five markets” | Five locale sets, five currency presentations and the testing that goes with them |
| “Every market we might enter” | A localization architecture, not a localized game |
Currency presentation is a good example of how concrete this gets. Currency is not a free-text label: ISO 4217 exists precisely because the representation needs to be unambiguous — “This standard establishes internationally recognized codes for the representation of currencies that enable clarity and reduce errors.” A game that shows a currency symbol drawn by an artist, rather than a formatted value produced from a code the platform supplies, is one change away from being wrong in a market nobody tested.
The same applies to dates, numbers and plural forms. The Unicode standard behind the Common Locale Data Repository puts the rule plainly: “The best practice for internationalization is to store and communicate language-neutral data, and format that data for the client.” A commissioned game that formats money and time inside the build has moved a decision out of the platform and into an artefact that will need re-certifying whenever it moves market.
The brief does not need to answer all of this. It needs to state which of the three answers above applies, and to say that the market set is a launch scope rather than an aspiration. The localization architecture guide is where that decision is turned into structure.
Name the launch target and how the game is reached
A finished game that nobody can open is not a launch. The commission should name the destination before production starts: which platform, through which integration, under which brand entity, and what the player sees in the first second after the lobby tile is tapped.
The integration boundary is the subject of its own RGS integration requirements guide, and the reason it belongs in the commission rather than in a later workstream is that some of its decisions are irreversible in practice. Whether a round belongs to the game server or to the platform, how a launch is parameterised, and whether the game is reachable through an aggregator or a direct connection determine what can be tested, and testing is what the next section is about.
For an operator working with a studio and platform partner, the useful form of this section is a single named target with a fallback, not a list of possible destinations. “Direct integration into our platform for launch; aggregator distribution considered for a later market” is a decidable statement. “Multi-channel ready” is not.
Write down what “exclusive” means
Exclusivity is the word that does the most work in a commission and receives the least definition. It is also the part of the brief that is not an engineering document at all: the answers belong in the agreement and should be reviewed by the operator’s own counsel and compliance function, because the same word describes several different commercial arrangements.
What the brief can do is make sure the questions are asked early, in writing, while they are still cheap to answer. At minimum:
- Scope of the exclusive element. Is the exclusivity in the game’s theme, its mathematics, its mechanic, or only in a cosmetic skin over a mechanic that exists elsewhere?
- Term and territory. Exclusivity for a defined period in defined markets is a different product from exclusivity forever and everywhere.
- Distribution limits. Whether the operator may sub-license, and whether the studio may release a near-identical game to competing brands in the same market.
- Derivatives. Sequels, seasonal re-skins and feature ports are usually where an exclusivity clause is quietly eroded.
- End of term. What the operator retains, what it must remove, and what happens to players’ history and to any content already published.
- Brand assets. Who owns the commissioned art and copy that was produced for the operator’s brand, as distinct from the game engine.
None of that is legal advice, and none of it should be settled by a supplier. The value of putting it in the brief is that it forces the conversation to happen before the build, when the operator still has leverage, rather than at contract signature when the scope has already been delivered against.
Write the hypothesis the launch can test
The most useful sentence in a commission is the one that says what the game is supposed to change. It is also the sentence most often replaced by a goal, which is a different thing: “increase retention” is a goal, and it cannot be tested by one launch.
A commission can be given a hypothesis instead, and a hypothesis is decidable. It names the population, the moment, the measure and the comparison:
Among players who see the branded tile in the lobby during the campaign window, the share who register and then make a first deposit within the campaign period can be compared against the equivalent share for a comparable, non-branded tile shown over the same period.
That sentence commits nobody to an outcome, which is the point. It says the register-to-first-deposit path can be tested for the branded launch, that the comparison needs to exist before the campaign starts, and that the measure is a share of a defined population rather than a bank-wide number that will be attributed to whatever shipped last.
Two disciplines make the difference between a test and a story afterwards. The first is writing the comparison down in advance: which tile, which period, which definition of a deposit. A comparison chosen after the numbers arrive is a narrative, not a measurement. The second is keeping the claim proportionate. A branded tile plausibly changes who tries a game and how they arrive; it is not evidence about whether the game is better, and a launch that reports a causal lift in player value without a controlled comparison has published a conclusion it did not purchase.
Responsible-gaming reporting belongs in the same plan rather than in a separate document, because a campaign that pushes registrations also moves the population past the point where limits, checks and reality checks apply. If the game is aimed at a market with its own product requirements, those requirements are part of what the launch has to satisfy at the same moment it is being measured — the certification submission guide covers the pack that gets a build through that gate.
What the commission should hand back
Read as a whole, the brief is short, and almost none of it is technical. It is worth ending it with the deliverable list, so that “done” is a checklist rather than a judgement:
- The brand-fit boundary: what the brand owns, what it may not change, and the acceptance guide for the behavioural surfaces.
- The player information set, in each launch language, and the name of the person who signs it off per language.
- The market set at launch, with the presentation decisions that follow from it, including currency and time formatting supplied by the platform.
- The named launch target and integration path, with one fallback.
- The exclusivity questions, answered or explicitly deferred to counsel with a date.
- The hypothesis, the comparator and the measurement window, agreed before the campaign opens.
- The evidence pack the build will hand over: the versioned rules, the mathematics, the configuration and the test results for the exact release.
A commission that can produce that list has already done the hard part. What remains is engineering, and the engineering has guides of its own — which is the right division of labour. Operators are unusually good at deciding what their brand may promise and unusually exposed when nobody wrote it down.
Questions operators ask
Does a branded game need its own rules and odds pages, or can it reuse the platform’s?
It needs its own, in the operator’s launch languages. The standards require an explanation of the applicable rules to be easily available to the customer before they commit to gamble, and separately require information about the chances of winning — including the house edge or margin and the return to player percentage — to be available before the customer commits. A generic platform page that describes a different mathematics set does not satisfy that for this game, and a page in one language does not cover a multi-market launch. Treat the player-facing information as a deliverable of the commission and name its sign-off owner per language.
How much of the brand’s promotional idea can go inside the game?
Less than the campaign usually asks for. The design boundary is behavioural rather than visual: a themed feature is fine, a feature that encourages a player to chase losses, to stake more than they decided to, or to keep playing after they have said they want to stop is not. The published guidance is concrete enough to use as a filter in a brief review — offering a player who chose to exit a free game to return is given as an example of what must not happen. Write the boundary into the brief so the promotion is redirected to the platform layer instead of being discovered at build review.
What does “exclusive” need to say to be worth anything?
It needs to name the element that is exclusive, the term, the territory, whether the operator may sub-license, what happens to sequels and seasonal re-skins, and what the operator keeps at the end. An exclusivity clause that names only the theme is usually satisfied by a re-skin elsewhere in the same market, and a clause without a term is a different commercial product from one with it. These are agreement questions for counsel; the brief’s contribution is to make sure they are asked before the build rather than at signature.
Can we test whether a branded launch worked?
You can test a defined part of it, and it is worth writing that part down before the campaign opens. A register-to-first-deposit comparison between the branded tile and a comparable non-branded tile over the same window is measurable, provided the comparator, the period and the definition of a deposit are fixed in advance. What that comparison does not support is a claim about the game being better or about player value rising, because those need a controlled design the launch does not have. Say what can be tested, and report the rest as an observation.
What is the smallest useful version of this brief?
One page, written before the studio starts, answering four questions in writing: what the brand may not change, what the player will be told and in which languages, which markets the launch covers, and what the launch is supposed to show. Those four lines are the ones that decide whether the later engineering work has a target. Everything else in this article is a longer version of the same page.








































