The short answer
A game catalog used for procurement, integration and operations should be more than a display list of provider names and game titles. At minimum, it must answer five questions: what is this record, where did it come from, which version does it identify, what is its current status, and who reviewed it when. Language, currency, target market, certification and release status also need separate fields; they cannot be compressed into an ambiguous “available” flag.
The current game catalog is a name-level snapshot dated 7 August 2026. It contains 11 providers and 1,194 game names. It is useful for early content discovery and as a starting point for catalog governance, but it does not contain game codes, versions, math models, covers, demos, API fields, certifications or real-time availability. It therefore cannot establish whether a specific game is available to a project.
The count and date do not change the nature of the snapshot. They are not evidence of real-time supply, production enablement, third-party rights or target-market availability.
Why a list of names is not yet a product catalog
Names can show which entries have been collected, but they do not connect a record reliably to an API, version change, test result or target market. Duplicate names, renamed titles, different skins and games of the same type with different math models can all make name matching inaccurate.
Catalog governance is not about filling every field at any cost. Its purpose is to make every decision traceable to a record with a source, date and owner. When a value is missing, the correct status is pending verification—not a guess based on a third-party page, filename or prior experience.
A minimum data model
These fields may live in several tables, but their meaning and ownership should be preserved.
| Field group | Minimum fields | Question answered | Guidance |
|---|---|---|---|
| Stable identity | catalog_record_id, provider_id, provider_game_code, game_name, game_type |
What does this record identify uniquely? | Use stable IDs to avoid name collisions |
| Provenance | source_ref, source_type, source_snapshot_at, source_hash |
Where did the information come from, when, and can it be verified? | Preserve source and date |
| Game version | game_version, math_model_version, client_build, release_note_ref |
Which software and math model were verified? | Link to the delivered build |
| Integration version | provider_api_version, aggregator_version, integration_version |
Which interface chain corresponds to this game version? | Record the complete topology |
| Record lifecycle | record_status, status_reason, effective_from, effective_to |
Where is the record in its lifecycle? | Use controlled states |
| Environment status | staging_status, production_status, demo_status, last_verified_at |
What has actually been verified in each environment? | Store each environment separately |
| Support dimensions | language_codes, currency_codes, device_scope |
Which languages, currencies and devices have been verified? | Do not infer them from the title |
| Market and certification | market_code, operator_scope, certificate_ref, certificate_scope, certificate_status |
What evidence applies to a specified object, version and scope? | Map each target market explicitly |
| Rights and restrictions | content_rights_scope, territory_restriction, usage_restriction, evidence_ref |
What limits apply to display, demo, distribution or market use? | Store rights separately |
| Ownership and review | data_owner, reviewer, updated_at, next_review_at, change_reason |
Who maintains and confirms the record, and when is the next review? | Preserve responsibility and timing |
Do not reuse three different IDs as if they were one
catalog_record_idis the stable internal identity for a catalog record and should remain traceable when its display name changes.provider_game_codeis the game identifier used by the provider or upstream interface and must come from verifiable interface or delivery material.- A page slug or marketing alias is for presentation only. It should not become the primary key for transactions, certification or version mapping.
Provenance, status, version, updates and ownership
1. Provenance must be traceable
For every import, retain the source type, location or document reference, snapshot time and import batch. If the source is later replaced, preserve the old record’s effective period instead of overwriting its history. A third-party page may suggest candidate data, but it should not be the only evidence for rights, version or current availability.
2. Status must identify its object and dimension
A controlled catalog lifecycle may use:
| Status | Meaning | What can be stated publicly |
|---|---|---|
draft |
A record exists, but critical identity or provenance has not been reviewed | Do not publish |
pending_verification |
Candidate material exists, but verification evidence is incomplete | State only that verification is pending |
verified_current |
A specified version and environment were verified on a stated date | State only the verified scope |
suspended |
Temporarily disabled because evidence expired, an issue occurred or a restriction applies | Do not present as currently available |
retired |
No longer maintained or replaced by a newer version | Preserve history; omit from the current catalog |
“Recorded in the catalog,” “verified in staging,” “enabled in production” and “available in the target market” are distinct states. None implies the others.
3. Version changes must trigger impact review
A change to the game, math model, RGS or aggregator, API contract, currency rules, language resources or target-market requirements should trigger an impact review. Link the result to updated testing or certification evidence. Do not assume a conclusion for an old version carries forward automatically.
4. Every update needs a responsibility chain
A minimum workflow is:
- A data owner imports or proposes a change with provenance and a reason.
- Automated checks validate stable IDs, required fields, duplicates and controlled states.
- Technical, business or compliance owners review the fields in their scope.
- Approval creates a new version or updates the effective period without erasing historical evidence.
- A review date, invalid source or critical version change returns the record to pending verification.
- Public pages read only fields and states approved for display.
Priorities when upgrading a catalog
Do not generate hundreds of detail pages directly from a name list. Build in order of decision value:
- Add stable provider IDs, provider game codes, provenance and record owners.
- Add the game version, interface version and staging status required for actual integration.
- For games entering market evaluation, add market, operating entity, language, currency, certification object and scope.
- Add covers, demos and descriptions only after asset rights and sources are confirmed.
- Create detail content only for games with a real project need and adequate evidence.
What the current catalog provides
- A name-level snapshot dated 7 August 2026 with 11 providers and 1,194 game names.
- Provider and game names for early browsing and content-scope discussions.
- No real-time inventory, production list, version repository, rights repository or certification database.
- This article’s governance framework for the fields, states and owners needed next.
Boundaries to keep in mind
- No listed game is promised to be callable, playable, launched or available in production now.
- The catalog does not prove provider authorization, asset-use rights, target-market permission or certification validity.
- Language, currency, interface connectivity and catalog inclusion do not establish market legality.
- Do not invent game codes, RTP, versions, math models, covers, demo links or certificate IDs.
FAQ
Does a game name in the catalog mean it can be integrated immediately?
No. It shows only that an entry appears in the underlying source. Integration still requires verification of the provider game code, interface and game version, environment status, commercial rights and target-market conditions.
Why record the game version and math model version separately?
A client or visual update may not change the math model, while a math model change may require new testing and certification review. Separate fields identify the object actually covered by existing evidence.
Can missing fields be filled automatically from provider sites?
Public pages can be candidate leads, but retain the source and place the value in pending verification. Use it for a project decision only after the applicable material, live interface or responsible owner confirms it.
How often should a catalog be updated?
Do not rely on a fixed schedule alone. A source change, version release, status incident, evidence expiry or target-market rule change should also trigger review.
Related reading and next steps
- Understand the multi-provider Slots API boundary
- Evaluate a Slots API provider through evidence
- Build a market, game, version and certification matrix
- Use consistent Slots API terminology
- Core pages: game catalog and public API reference
Before using the “Contact us” section, prepare the target market, proposed providers or game scope, wallet model and expected environments. AG can then return the catalog fields and evidence that need verification for that scope. This does not promise supply, rights or production admission.
Sources and scope
The catalog count applies only to the snapshot dated 7 August 2026. A specific project must still verify record status, display rights and target-market evidence.
Need to turn this guidance into a project plan?
This article supports project evaluation and does not replace technical, contractual, certification or local-law confirmation.