A slot game has two descriptions of the same event. The math model says that configuration seven of reel set three pays 4.20 on a two-credit stake, and the client shows a player five symbols, two of them wild, a line highlight, a win banner and a new balance. Between those two descriptions sits the only thing a player can actually observe. When a studio delivers art, math and engineering in one commission, that gap is where the expensive defects live: not in either half, but in the seam.
The decision this article is about belongs to the buyer. Before a build is accepted, someone has to decide what evidence proves the client presents the outcomes the model defines, which fixtures that evidence uses, and what change makes it run again. Regulators state the duty in general terms. The UK Gambling Commission’s remote technical standards, for example, require that games be implemented in accordance with the rules and payouts as described to the customer (RTS 7B), and that the system clearly and accurately display the result of the game and the customer’s gamble for long enough for the customer to understand it (RTS 7E). Both are statements about the seam. Neither tells you which test to run.
Parity is an acceptance question, not a QA phase
Settle the parity question while the brief is being written, for the same reason the volatility classes are fixed before simulation. RTS aim 5 is that the gambling system implements the operator’s rules, game rules and betting rules as they are described to the customer, and the implementation guidance names testing of new products against the published rules and monitoring their live performance as the reasonable steps. That is a lifecycle obligation. A demo that looks right on the day of handover answers it once.
Practical consequence: ask for parity evidence as a deliverable, with the same standing as the math package. The package defines probabilities, pay tables and configuration identifiers. The parity evidence shows the client reproducing those outcomes from those identifiers. A studio that can produce the first and not the second has documented a game it has not demonstrated.
The outcome event is the contract
The cheapest way to make parity testable is to make the outcome a data structure both halves agree on, rather than a picture the artist drew. A workable round record carries:
- the round identifier, the bet configuration and the math version it was evaluated against;
- the reel positions and the resulting symbol matrix, by symbol identifier rather than by sprite name;
- every evaluated win, its line or way, the symbols that formed it, the multiplier applied and the amount before and after rounding;
- the feature events inside the round, each with its own trigger and terminal state;
- the total award, the closing balance and the round’s terminal state.
If the client computes any of that locally, it has a second implementation of the paytable, and two implementations drift. The common shape of a shipped defect is a wild that substitutes in the evaluation but is drawn in the client as a plain symbol, or a scatter count that includes a symbol the model excluded. Neither is visible in a screenshot review that only checks the big win is big.
Keep the record in the same lineage as the round observability the platform side already needs, so a player complaint about one round resolves to one identifier rather than to a video. The round tracing analysis covers the operational half of that; parity evidence is what makes the trace trustworthy in the first place.
Five classes of fixture
One fixture per screen state proves nothing. A handover set that has survived contact with a real commission covers five classes, and each class is signed off by a named person rather than by the studio alone.
Symbol and dimension rendering. Feed the client a matrix and confirm it draws the symbols the model named, in the positions the model used, including stacked and expanding symbols and any symbol the model treats as a wild. This is the class that catches art pipelines renaming assets during optimisation.
Win evaluation display. For each fixture, the client’s highlighted lines, ways and amounts must equal the model’s evaluation, in the display currency, after the stated rounding rule. Include the awkward ones: multiple coincident wins, wins capped by a maximum award rule, and a round where the displayed total is the sum of several sub-awards.
Feature and mode transitions. Every bonus mode has its own rules and its own cost multiplier, as the mode scope brief sets out, and the client’s transition must be driven by the feature event rather than by the animation completing. A client that advances state on animation end will desynchronise the moment a device drops frames.
Near-miss and anticipation behaviour. RTS 7C prohibits substituting losing events with near-miss losing events, which constrains how anticipation may be produced. Anticipation that is authored per outcome is fine where the market’s rules and the game’s own description permit it; anticipation implemented by re-timing a randomly chosen losing spin is the defect. Ask directly which mechanism is used, and test it with fixtures that carry no near-miss substitution.
Result display and celebration. RTS 7E requires the result and the gamble to be displayed clearly and accurately for long enough to be understood. RTS 14F adds that a return less than or equal to the total stake must not be celebrated with win audio or visuals. Those two requirements interact with the win-tier ladder: the client needs a tier boundary at “return above total stake” that is not the same as the artist’s excitement curve. The responsible product design checklist covers the control set around this; here the question is only whether the fixture set includes a return exactly equal to the stake.
Where parity actually breaks
Four failures account for most of the ones worth testing for, and none of them is exotic.
The paytable exists twice. The model has one; the client has a lookup table for the win presentation. They agree until a configuration change, a currency change or a market variant lands, and then they disagree in one direction only: the client under-reports.
Rounding moves. Model amounts are evaluated at a precision the display does not use. If the rounding rule is not written into the event contract, the client rounds per line while the model rounds per round, and the difference surfaces in the reconciliation rather than on the screen.
Reels and the outcome matrix diverge. A visual reel strip that cannot produce the outcome the model sent is a mapping defect, and it is the one a screenshot cannot catch, because the client will happily draw something plausible.
The build changes after acceptance. The last studio change to animation, symbol assets or cash-format handling can move a displayed value without touching the model. That is why the fixture set needs a trigger, not only a run.
What to ask for at handover
- The event contract, written down, naming every field the client consumes and which half owns it.
- A fixture set of at least one round per display class, each with the expected client output recorded, and stored so it can be replayed against a later build.
- A deterministic replay route, so a disputed round can be re-rendered from its identifier without the original player session.
- A reconciliation of the simulated RTP against the client-rendered totals, not against the model alone, so the display path is included in the number the test house sees.
- A named change trigger: which repository changes require the fixture set to be re-run, and who signs the result.
- The mode and volatility documentation that the display is supposed to match, so the acceptance compares the client with a version rather than with a memory.
For most commissions this is a small addition to the brief and a large reduction in argument later, because it turns “the game feels wrong” into a fixture with an identifier. Where a publisher is commissioning the build rather than inheriting it, the same set can be written into the scope before production starts. The Engine project brief is the route to request a project quote, with scope, markets and the evidence list settled in writing first.
Frequently asked questions
What does math-to-client parity mean for a slot game?
It means the client presents the outcome the math model produced: the same symbols in the same positions, the same evaluated wins and the same total award, in the display currency and after the stated rounding rule. Parity is demonstrated with fixtures that carry a known outcome and an expected client output, not with a visual review of a session.
Who should own the parity fixtures, the studio or the operator?
The studio that supplies art, math and engineering should produce the fixture set, because it owns both halves of the seam. The operator or publisher buying the commission should approve the classes covered, receive the fixtures as a deliverable and sign the reconciliation. Acceptance by the supplier alone is a self-certification of the supplier’s own integration.
Can a client compute wins locally instead of rendering the model’s evaluation?
It can, but then the paytable exists twice and the two copies have to be kept in step through every configuration, currency and market variant. Where a client computes locally, the fixture set becomes mandatory rather than advisable, and the change trigger must include every paytable and symbol change on either side.
Which published rules make the result display part of acceptance?
The UK Gambling Commission’s remote technical standards require the system to display the result of the game and the customer’s gamble clearly and accurately for a period long enough to be understood (RTS 7E), to implement rules and payouts as described to the customer (RTS 7B), and not to celebrate a return that is less than or equal to the total stake (RTS 14F). Other markets state their own requirements, so the display classes should be reviewed against the target market rather than assumed.
How often should the parity fixtures be re-run?
At least at handover, at every math configuration change, and at every client change that touches symbol rendering, win presentation, currency formatting or round state. The cheap rule is to bind the fixture run to the same change gate as the build, so a release cannot be assembled from a client and a model that were never tested together.
