Feature Flags Don't Make an Update Minor

Short answer: the UKGC classifies a change by its effect on fairness, RNG, scaling, mapping or game rules, not by whether it sits behind a flag. First step: run every open flag ticket through Annex A's major/minor test before it reaches a sprint. Goal: every flagged change already carries the right classification, and test house sign-off where it needs one, before it goes anywhere near a player.

Tips: Write the Annex A classification into the ticket description before a line of code is written, not after QA asks; retrofitting a classification after a flag has shipped is exactly the moment an unplanned recertification gets discovered.

Key takeaways

Annex A sorts a software change into major or minor by what it can do to fairness, RNG, scaling, mapping or game rules. That test is deployment-agnostic: a feature flag, a canary release or a full rollout all leave the underlying classification exactly where it was. The practical consequence for a product manager is that the sorting has to happen at the backlog stage, before engineering reaches for a switch that feels like a safety net but isn't one under UK gambling regulation.

Point	Detail
The rule	Annex A classifies a change by its effect on fairness, RNG, scaling, mapping or game rules, regardless of the deployment mechanism used to ship it.
The mistake	Treating a feature flag as a compliance boundary imports a SaaS assumption that has no equivalent in the UKGC's testing strategy.
The trigger	A test house or your own change-control process has to classify the underlying code change, not the percentage of players currently exposed to it.
The safe path	Self-certification exists for genuinely minor, non-fairness changes, but major changes still require an approved test house before release.
The record	Licensees must keep change-control documentation regardless of how carefully a rollout was staged, so the paper trail has to exist before the flag flips.

Contents

• Does a feature flag count as a minor update under UKGC rules?
• What actually separates a major update from a minor one?
• Why does the SaaS 'ship it dark' habit break down in gambling software?
• Do canary releases and progressive rollouts change the compliance picture?
• How should a PM sort a flag backlog before engineering builds it?
• What does self-certification cover, and when do you need a test house?
• What happens if a flagged change gets challenged after launch?
• Frequently asked questions
• Sources

Does a feature flag count as a minor update under UKGC rules?

No. A feature flag is a release mechanism. Annex A doesn't classify release mechanisms, it classifies changes, and it does so by asking what the change can affect, not how carefully it was staged for rollout. The UKGC's testing strategy for major and minor game and software updates sets out this test in terms of effect: does the change touch the random number generator, does it alter scaling or mapping between RNG outputs and game outcomes, does it change the rules of the game itself. If the answer is yes, the change is major, full stop, and that answer doesn't change because a switch somewhere decides which players see it this week.

This is the part that trips up product people arriving from SaaS or fintech. In those worlds, a feature flag genuinely is a risk boundary. Ship a change dark, expose it to 1% of traffic, watch the metrics, roll back if something looks wrong. The flag is the control. Nothing about that pattern is wrong in an unregulated product, and it is a perfectly good engineering habit to bring into iGaming for operational reasons. What doesn't transfer is the assumption that the flag also functions as a compliance control. It doesn't, because Annex A was never written with deployment mechanics in mind. It was written to answer one question: can this change affect what a player experiences as a fair, correctly-paying game.

That means the classification work has to happen against the code, not against the release plan. A change that alters how a bonus round calculates its multiplier is major whether it ships to 100% of players on day one or to 2% of players behind three layers of flags. A change that swaps a button's colour is minor whether it ships instantly or gets staged over three weeks. The flag tells you who is exposed and when. It tells a test house nothing about whether the change was safe to expose at all.

For a product manager, the practical upshot is that the question "is this behind a flag?" belongs nowhere near the classification conversation. The question that belongs there is the one Annex A actually asks, and the next section breaks that question down into something you can hold against your own backlog.

What actually separates a major update from a minor one?

Annex A draws the line by effect, and its own examples split cleanly into two camps. Anything that touches how outcomes are generated, scaled or governed by the game's rules sits on the major side and needs external retest. Anything cosmetic, platform-level or otherwise disconnected from fairness sits on the minor side. The same Annex A page is worth reading in full before you finalise any backlog triage, but the working version most teams need day to day looks like this.

Change type	Example	Classification
RNG behaviour	Any change to how random outcomes are generated or seeded	Major
Scaling and mapping	Changes to how RNG outputs map onto reels, cards, symbols or paytable outcomes	Major
Game rules	Changes to payout structure, win conditions, or how a game is played	Major
Cosmetic and UI	Visual redesign, copy changes, layout adjustments that don't touch outcome logic	Minor
Platform	Infrastructure, performance and non-fairness backend changes	Minor

The pattern in that table is worth naming directly: the left-hand criteria are all about what the code decides, not what the player sees or how it reaches them. A visually dramatic redesign of a slot's front end is minor if the RNG, the scaling, the mapping and the rules underneath are untouched. A visually invisible backend change is major the instant it alters how outcomes get generated, even if a player would never notice the difference on screen. This is the opposite of how most product intuition works, where visible changes feel riskier than invisible ones. In gambling software, the fairness-critical layer is precisely the layer players can't see.

Tips: If a ticket description can't answer "does this touch RNG, scaling, mapping or game rules" in one sentence, that's the sign it needs an engineer and a compliance-literate reviewer in the same conversation before it gets estimated, not after.

Why does the SaaS 'ship it dark' habit break down in gambling software?

The instinct to reach for a flag as a safety mechanism comes from somewhere real, and it's worth naming where before dismissing it.

• Trunk-based development treats the main branch as always releasable, with flags used to keep unfinished or risky work invisible until it's ready. This works well when "ready" is a product decision the team can make unilaterally.
• Dark launches ship code to production switched off, often specifically so a team can test infrastructure behaviour under real load before exposing anything to users. The code being live and the feature being visible are treated as two separate, independently manageable risks.
• Canary releases expose a small percentage of traffic to a change and expand only if metrics hold, treating exposure level as the primary risk dial.

All three patterns share one assumption: that the risk being managed is a product or infrastructure risk, and that the team doing the managing has full authority to decide what "safe enough" means. That assumption holds in most SaaS and fintech contexts. It does not hold here, because the authority to decide whether a fairness-affecting change is safe doesn't sit with the product team at all. It sits with an approved test house, under a testing strategy that was written before feature flags were a common pattern and doesn't reference them.

A feature flag controls who sees a change. It does nothing to what the change is, and Annex A only ever asks the second question.

The code exists in the certified build the moment it merges, whether or not a switch is currently exposing it to a single player. If that code touches RNG, scaling, mapping or game rules, it needed test house sign-off before it merged into a build that could reach production, regardless of how the rollout was planned. A team that ships the change dark and plans to flip the flag next sprint hasn't deferred the compliance question. It has skipped it, and the gap sits there until someone, usually a test house or an auditor, notices.

Do canary releases and progressive rollouts change the compliance picture?

Percentage-based rollouts extend the same flag logic and hit the same wall. Staging a change from 5% to 25% to 100% of traffic is a release-management decision about operational risk: server load, error rates, player-support volume. It is not a certification decision, and Annex A doesn't scale its major/minor test by exposure percentage.

• A canary at 5% is still the certified build. The code a fifth of your players are running is the same code the rest will run once the rollout finishes, and if that code is major, it needed sign-off before any player, canary or otherwise, touched it.
• Progressive rollouts manage blast radius, not classification. They're a genuinely good way to catch an infrastructure bug before it hits everyone. They're not a way to catch a fairness problem before it becomes a certification problem, because the classification question was already answered (or skipped) at merge time.
• This seam shows up repeatedly wherever engineering practice meets a licence-bound platform. Luminbrane has written before about a related case: the 10x wagering cap the UKGC introduced for bonus terms, where a rule written in regulatory language has to be translated into exact engineering behaviour, not interpreted loosely at the point of implementation. The same translation gap appears in wallet architecture: a single wallet spanning casino and sportsbook looks like a straightforward engineering decision until the regulatory obligations attached to each product line turn out not to be identical.

The common thread across all three cases, flags, wagering caps and shared wallets, is the same: an engineering pattern that is sound on its own terms runs into a regulatory framework that wasn't written with that pattern in mind, and the gap has to be closed by a human decision, not assumed away by the tooling. A product manager who treats percentage rollout as a compliance lever is making the same category error as one who treats a flag that way. Both mistake a release-management tool for a certification boundary.

How should a PM sort a flag backlog before engineering builds it?

The fix is procedural, not technical: run the classification question before the ticket reaches a sprint, not after a test house asks about it. This is the same discipline the UKGC's own procedure for testing describes for licensees managing change control: classify first, route second.

1. Pull every open flag ticket into one list. Include anything with a toggle, a canary plan or a staged rollout attached, regardless of which team owns it or how small it looks.
2. Ask the Annex A question against the code, not the plan. For each item: does it touch RNG behaviour, scaling or mapping between outcomes, or the rules of a game? Answer against what the change does, ignoring entirely how it will be released.
3. Sort into two lanes. Fairness-critical items go into a lane that assumes external test house involvement before merge. Routine items go into a lane that can self-certify under your own change-control process.
4. Attach the classification to the ticket, not to a separate document. Whoever picks up the ticket in a sprint should see the classification and its justification without having to ask.
5. Route fairness-critical items to compliance and test house scheduling before estimation. Test house turnaround has to be a known input to the sprint plan, not a surprise discovered when someone tries to release.
6. Keep the routine lane's self-certification records current. Even minor changes carry a record-keeping obligation, so the paper trail needs to exist as the change goes out, not reconstructed afterwards.

This is exactly the kind of structural triage work that benefits from an outside set of eyes the first time a team sets it up, particularly for teams whose engineers arrived from unregulated products and haven't had to build this instinct before. It's the kind of gap Luminbrane's architecture consulting work exists to close: designing the system boundaries, including the release and classification process, so the team building on top of them doesn't have to relearn this the hard way.

What does self-certification cover, and when do you need a test house?

Annex A's classification decides which of two very different processes a change goes through. The UKGC's procedure for testing sets out both, and the boundary between them is the one your triage process in the section above needs to route against correctly.

Route	Applies to	What's required
Self-certification	Minor updates that don't touch fairness	The licensee attests to the change internally, with change-control records kept as evidence
Approved test house	Major updates affecting RNG, scaling and mapping, or game rules	External retest by an approved test house, with sign-off required before release

The record-keeping obligation is the part teams underestimate. It doesn't disappear because a change went through self-certification rather than a test house. A licensee still has to be able to show, on request, what changed, when, why it was classified the way it was, and what evidence supports that classification. That obligation exists regardless of how the rollout was staged, and it exists whether the change went through a flag, a canary or a straight deploy. A team that has been diligent about staging a rollout carefully but has no written classification decision behind it has solved the wrong problem.

Tips: Keep the classification decision and its justification in the same system your test house or auditor will actually ask to see, not in a Slack thread that will have scrolled away by the time anyone needs it.

What happens if a flagged change gets challenged after launch?

The failure mode is specific and avoidable: a change ships behind a flag, someone later realises it touched RNG, scaling, mapping or game rules, and the team is now looking at an unplanned recertification for something already live to players. Here's the practical response sequence.

1. Freeze the flag immediately. Turn the change off for all players while the classification question gets resolved properly, even if this reverses a rollout that was going well operationally.
2. Reconstruct the classification decision. Establish exactly what the change does against RNG, scaling, mapping and game rules, using the actual code rather than the original ticket description, which may have been written before the full scope of the change was known.
3. Engage the test house before re-enabling anything. If the reconstruction confirms a major classification, the change needs the external retest it should have had before it ever reached players, regardless of how well it performed while live.
4. Document the gap and the remediation. Regulators and auditors respond very differently to a licensee that caught and corrected its own classification error versus one where the gap surfaces externally first.
5. Fix the process, not just the incident. A single missed classification is a mistake. A repeated one is a process gap, and the fix belongs upstream of the next flag ticket, not downstream of the next incident.

The durable fix is giving certification its own visible place in planning, rather than treating it as something that gets discovered when a release goes wrong. Luminbrane has written about why certification needs its own lane on the roadmap rather than living as an assumed side effect of feature work, and the flag backlog triage described above is one concrete way to put that lane into practice before the next release, not after the next incident.

Frequently asked questions

Does turning a feature flag off avoid UKGC recertification? No. Annex A classifies the underlying change, not its current visibility to players. A major change that has been flagged off still needed test house sign-off before it reached a certified build, and turning the flag off afterwards doesn't retroactively satisfy that requirement.

What is Annex A of the UKGC's testing strategy? Annex A is the section of the UKGC's testing strategy that defines how a software or game change is classified as major or minor, based on whether it can affect fairness, RNG behaviour, scaling and mapping, or game rules. It sets the criteria that determine whether a change requires external retest.

Can I self-certify a minor update instead of using a test house? Yes, for changes that genuinely don't touch fairness, such as cosmetic or platform-level updates, the UKGC's procedure for testing allows a licensee to self-certify. Major changes affecting RNG, scaling, mapping or game rules still require an approved test house regardless of how minor they might seem operationally.

Do canary releases or percentage rollouts count as major updates? A canary release or staged rollout doesn't itself trigger a major classification. What matters is what the underlying code does. If that code touches RNG, scaling, mapping or game rules, it's major whether it's exposed to 5% of players or 100%.

How long do change-control records need to be kept? The specifics of retention period sit within a licensee's own change-control process built around the UKGC's testing strategy, and licensees should maintain records regardless of whether a change went through self-certification or external test house retest. The obligation applies to every change, not only ones that were later challenged.

What belongs on a certification roadmap lane versus a flag backlog? A certification roadmap lane should carry any change that Annex A's test flags as major, along with the test house scheduling and lead time it needs, tracked separately from routine feature work. A flag backlog can hold anything else, including major changes once they've cleared certification and are simply being staged for rollout.

Sources

• Gambling Commission
• Gambling Commission

Recommended

• Bonus Abuse Control After the UKGC's 10x Cap
• Single Wallet for Casino and Sportsbook: What It Costs
• Certification Needs Its Own Lane on Your Roadmap
• Luminbrane services