DOC-1 Certification is a dependency, not a gate

Most release plans treat certification as the last box before launch — a QA step with a rubber stamp on the end. That framing is the single most common reason iGaming schedules slip. Certification is an external dependency with its own queue, its own lead time, and its own failure modes. It belongs in the plan from the first sprint.

Here is how I schedule around it, and the architectural decisions that decide whether your catalogue ships four titles a year or forty.

What the lab is actually checking

Independent test houses — Gaming Laboratories International, BMM Testlabs, iTech Labs, eCOGRA, Gaming Associates — are not doing your QA. They are verifying a much narrower set of claims, and knowing which claims tells you which parts of your build are schedule-critical.

• The random number generator behaves randomly. Labs run statistical batteries across millions of outputs looking for correlation, bias, or predictable state. This is usually the least risky part, because most studios license a pre-certified RNG module rather than writing their own — and a pre-certified module skips an expensive from-scratch audit.
• The advertised return matches the actual math. If your paytable says 96.5% and the model delivers 96.1%, you fail. Not "get a note" — fail. This is where the documentation burden lives: probability analysis, payline calculations, bonus feature probabilities, progressive contribution rates.
• The system recovers. Transaction reconciliation and failure recovery are where platform submissions most often fail on the first pass. Not because the core is broken, but because nobody documented what happens when a spin is interrupted mid-transaction and the wallet call times out.

Notice what is not on that list: art, sound, UI polish, marketing copy. That asymmetry is the lever the rest of this post is about.

The number that should drive your schedule

Published ranges vary by lab and complexity, but the shape is consistent. A single slot in a single jurisdiction runs roughly four to twelve weeks. Complex table games with side bets run longer. Multi-jurisdiction submissions and platform-level certification stretch into the four-to-nine-month range, and the practical advice from people who do this for a living is to begin technical compliance preparation twelve to eighteen months ahead of a target launch when a full platform is involved.

State-level variance is real and worth putting in the plan as separate line items. Nevada's testing window sits around twelve to sixteen weeks after initial submission. Pennsylvania layers its own player-protection requirements on top of the New Jersey framework and runs longer, roughly sixteen to twenty. Ontario's first-time submissions are generally quoted at a ninety to one-hundred-twenty day minimum.

Fees track the same curve: single-title, single-jurisdiction submissions in the low tens of thousands, full platform certification across multiple markets an order of magnitude above that. If you are planning a catalogue rather than a title, that arithmetic decides your roadmap.

Full submission versus modification: the distinction that buys you throughput

This is the part most producers learn too late. Labs distinguish between a new prototype submission and a modification to something already certified, and the difference in turnaround is substantial — modifications commonly land in the four to six week range against four to twelve for a fresh submission.

What triggers which:

• Bug fixes that do not touch outcome logic generally do not require recertification at all.
• Changes to bonus feature logic, payout calculation, or the RNG implementation always do.
• Changing advertised RTP requires new certification even when the RNG is untouched, because the lab has to re-verify that the new mathematics match the new paytable.
• Altering the mapping layer — the bridge translating random numbers into reel positions — can pull a partial review even when the RNG itself is unchanged.

Read that list as a production instruction rather than a compliance note. It says: build so that the things you want to iterate on are not the things that trigger resubmission.

Architecture that protects the schedule

Three decisions do most of the work.

Separate the art pipeline from the certified math engine. If symbols, UI animation, and bonus effects live behind a boundary the math never crosses, you can refresh a title's look without touching anything the lab certified. Studios that maintain this split can iterate visually without opening a recertification window, and it is the single highest-leverage structural choice in a regulated catalogue.

Make RTP, volatility, and feature parameters configurable rather than coded. Different jurisdictions and different operators want different return profiles. If those are configuration rather than branches, you are managing a variant family instead of a set of separate games. Labs often price and test variants sharing the same core math as a single submission — a five-line and a twenty-line version of one slot can go through together — which collapses both cost and calendar.

Build the documentation as you build the game, not after. Incomplete submission packages are the most frequently cited cause of delay, and the failure mode is brutal: miss a required document and the clock does not pause, it resets. Audit-friendly logging, commented RNG integration, a clean compliance matrix mapping each regulatory requirement to the feature that satisfies it — these are deliverables with due dates, not paperwork to generate at the end.

Simulate before you submit

Run your own large-scale simulation before the package leaves the building. Studios routinely execute ten to a hundred million spins to confirm the model is stable and the observed return converges on the advertised figure. Catching a volatility problem in your own sim farm costs a sprint. Catching it in a lab report costs a resubmission, the fee again, and a slot in the queue you no longer have.

Plan for recertification, not just certification

Certification attaches to a specific software version, and it expires. Some jurisdictions mandate periodic review on a twenty-four to thirty-six month cycle; some tribal jurisdictions run a three-year clock. Standards themselves move — the GLI series has been folding in cybersecurity requirements that previously sat in separate guidance, and while an existing certificate generally stays valid until expiry, a material modification pulls the product onto the current standard.

For a producer this means a recurring calendar item, not a one-time project. If you are carrying a hundred live titles, some fraction of them are aging out every quarter, and that recertification load competes directly with new development for the same lab relationships and the same internal compliance bandwidth. Budget it as ongoing capacity.

How I put it in the plan

Concretely, on a portfolio schedule:

1. Certification is a milestone with a duration, owned by a named person, sitting on the critical path — not a status column.
2. Math lock lands well before art lock. Art can move afterwards; math cannot.
3. Every title carries a submission type from day one. Knowing early whether something is a modification or a prototype is the difference between a six-week and a twelve-week tail.
4. Jurisdictions are separate line items with separate durations. "Certified" is not a binary state when you are shipping into several markets.
5. A standing recertification allocation, sized against the live catalogue, comes off the top of capacity before new work is committed.

None of this makes certification faster. It makes it predictable, which is the only thing a release plan actually needs from it. The studios that ship on schedule are not the ones with a shortcut through the lab. They are the ones who stopped treating the lab as a surprise.

References

• Gaming Laboratories International — GLI standard series, including GLI-19 for interactive gaming systems and GLI-33 for mobile.
• Gamix Labs — certification workflow, submission and modification turnaround ranges.
• SlotCertify — RNG documentation requirements and recertification triggers.
• TechMast — state-by-state testing windows and common first-submission failures.
• SDLC Corp — timeline and fee ranges by submission scope.