A resposta curta
Um catálogo de jogos usado para compras, integração e operações deve ser mais do que uma lista de exibição de nomes de provedores e títulos de jogos. No mínimo, ele precisa responder a cinco perguntas: o que é este registro, de onde ele veio, qual versão ele identifica, qual é seu status atual e quem o revisou, e quando. Idioma, moeda, mercado-alvo, certificação e status de lançamento também precisam de campos separados; eles não podem ser comprimidos em uma sinalização ambígua de “disponível”.
O catálogo de jogos atual é um retrato no nível de nomes, datado de 7 de agosto de 2026. Ele contém 11 provedores e 1.194 nomes de jogos. É útil para descoberta inicial de conteúdo e como ponto de partida para a governança do catálogo, mas não contém códigos de jogos, versões, modelos matemáticos, capas, demonstrações, campos de API, certificações nem disponibilidade em tempo real. Portanto, não pode estabelecer se um jogo específico está disponível para um projeto.
A quantidade e a data não alteram a natureza do retrato. Elas não são evidência de fornecimento em tempo real, ativação em produção, direitos de terceiros ou disponibilidade no mercado-alvo.
Por que uma lista de nomes ainda não é um catálogo de produtos
Os nomes podem mostrar quais entradas foram reunidas, mas não conectam um registro de forma confiável a uma API, mudança de versão, resultado de teste ou mercado-alvo. Nomes duplicados, títulos renomeados, skins diferentes e jogos do mesmo tipo com modelos matemáticos distintos podem tornar a correspondência por nome imprecisa.
Governança de catálogo não significa preencher todos os campos a qualquer custo. Seu propósito é tornar cada decisão rastreável até um registro com fonte, data e responsável. Quando um valor está ausente, o status correto é pendente de verificação — não uma suposição baseada em uma página de terceiros, nome de arquivo ou experiência anterior.
Um modelo mínimo de dados
Estes campos podem estar em diversas tabelas, mas seu significado e sua responsabilidade devem ser preservados.
| Grupo de campos | Campos mínimos | Pergunta respondida | Orientação |
|---|---|---|---|
| Identidade estável | catalog_record_id, provider_id, provider_game_code, game_name, game_type |
O que este registro identifica de modo único? | Use IDs estáveis para evitar colisões de nome |
| Proveniência | source_ref, source_type, source_snapshot_at, source_hash |
De onde veio a informação, quando e ela pode ser verificada? | Preserve a fonte e a data |
| Versão do jogo | game_version, math_model_version, client_build, release_note_ref |
Qual software e modelo matemático foram verificados? | Vincule à build entregue |
| Versão da integração | provider_api_version, aggregator_version, integration_version |
Qual cadeia de interfaces corresponde a esta versão do jogo? | Registre a topologia completa |
| Ciclo de vida do registro | record_status, status_reason, effective_from, effective_to |
Em que ponto do ciclo de vida está o registro? | Use estados controlados |
| Status do ambiente | staging_status, production_status, demo_status, last_verified_at |
O que foi efetivamente verificado em cada ambiente? | Armazene cada ambiente separadamente |
| Dimensões de suporte | language_codes, currency_codes, device_scope |
Quais idiomas, moedas e dispositivos foram verificados? | Não os infira a partir do título |
| Mercado e certificação | market_code, operator_scope, certificate_ref, certificate_scope, certificate_status |
Que evidência se aplica a um objeto, versão e escopo especificados? | Mapeie explicitamente cada mercado-alvo |
| Direitos e restrições | content_rights_scope, territory_restriction, usage_restriction, evidence_ref |
Quais limites se aplicam à exibição, demonstração, distribuição ou uso no mercado? | Armazene os direitos separadamente |
| Responsabilidade e revisão | data_owner, reviewer, updated_at, next_review_at, change_reason |
Quem mantém e confirma o registro, e quando ocorrerá a próxima revisão? | Preserve responsabilidade e prazo |
Não reutilize três IDs diferentes como se fossem um só
catalog_record_idé a identidade interna estável de um registro de catálogo e deve permanecer rastreável quando seu nome de exibição mudar.provider_game_codeé o identificador do jogo usado pelo provedor ou pela interface a montante e deve vir de material de interface ou entrega verificável.- Um slug de página ou alias de marketing serve apenas para apresentação. Ele não deve se tornar a chave primária para transações, certificação ou mapeamento de versões.
Proveniência, status, versão, atualizações e responsabilidade
1. A proveniência deve ser rastreável
Para cada importação, mantenha o tipo de fonte, local ou referência de documento, hora do retrato e lote de importação. Se a fonte for substituída posteriormente, preserve o período de vigência do registro antigo em vez de sobrescrever seu histórico. Uma página de terceiros pode sugerir dados candidatos, mas não deve ser a única evidência para direitos, versão ou disponibilidade atual.
2. O status deve identificar seu objeto e dimensão
Um ciclo de vida de catálogo controlado pode usar:
| Status | Significado | O que pode ser declarado publicamente |
|---|---|---|
draft |
Um registro existe, mas a identidade crítica ou a proveniência não foi revisada | Não publique |
pending_verification |
Existe material candidato, mas a evidência de verificação está incompleta | Declare somente que a verificação está pendente |
verified_current |
Uma versão e um ambiente especificados foram verificados em uma data declarada | Declare somente o escopo verificado |
suspended |
Desativado temporariamente porque a evidência expirou, ocorreu um problema ou uma restrição se aplica | Não o apresente como disponível atualmente |
retired |
Não é mais mantido ou foi substituído por uma versão mais recente | Preserve o histórico; omita do catálogo atual |
“Registrado no catálogo”, “verificado em homologação”, “ativado em produção” e “disponível no mercado-alvo” são estados distintos. Nenhum implica os demais.
3. Mudanças de versão devem acionar uma revisão de impacto
Uma alteração no jogo, no modelo matemático, no RGS ou agregador, no contrato de API, nas regras de moeda, nos recursos de idioma ou nos requisitos do mercado-alvo deve acionar uma revisão de impacto. Vincule o resultado a evidências atualizadas de testes ou certificação. Não presuma que uma conclusão para uma versão antiga é automaticamente mantida.
4. Toda atualização precisa de uma cadeia de responsabilidade
Um fluxo mínimo é:
- Um responsável pelos dados importa ou propõe uma alteração com proveniência e justificativa.
- Verificações automatizadas validam IDs estáveis, campos obrigatórios, duplicidades e estados controlados.
- Responsáveis técnicos, de negócio ou de conformidade revisam os campos dentro de seu escopo.
- A aprovação cria uma nova versão ou atualiza o período de vigência sem apagar a evidência histórica.
- Uma data de revisão, fonte inválida ou mudança crítica de versão devolve o registro a pendente de verificação.
- Páginas públicas leem somente os campos e estados aprovados para exibição.
Prioridades ao aprimorar um catálogo
Não gere centenas de páginas de detalhes diretamente a partir de uma lista de nomes. Construa na ordem do valor para a decisão:
- Adicione IDs estáveis de provedores, códigos de jogos de provedores, proveniência e responsáveis pelos registros.
- Adicione a versão do jogo, versão da interface e status de homologação exigidos para a integração real.
- Para jogos que entram em avaliação de mercado, adicione mercado, entidade operadora, idioma, moeda, objeto de certificação e escopo.
- Adicione capas, demonstrações e descrições somente depois de os direitos e as fontes dos ativos serem confirmados.
- Crie conteúdo de detalhes apenas para jogos com necessidade real de projeto e evidência adequada.
O que o catálogo atual fornece
- Um retrato no nível de nomes, datado de 7 de agosto de 2026, com 11 provedores e 1.194 nomes de jogos.
- Nomes de provedores e jogos para navegação inicial e discussões sobre escopo de conteúdo.
- Nenhum inventário em tempo real, lista de produção, repositório de versões, repositório de direitos ou banco de dados de certificações.
- O arcabouço de governança deste artigo para os campos, estados e responsáveis necessários a seguir.
Limites a considerar
- Nenhum jogo listado tem garantia de poder ser chamado, jogado, lançado ou estar disponível em produção agora.
- O catálogo não comprova autorização do provedor, direitos de uso de ativos, permissão no mercado-alvo nem validade de certificação.
- Idioma, moeda, conectividade da interface e inclusão no catálogo não estabelecem legalidade de mercado.
- Não invente códigos de jogos, RTP, versões, modelos matemáticos, capas, links de demonstração ou IDs de certificados.
FAQ
Um nome de jogo no catálogo significa que ele pode ser integrado imediatamente?
Não. Ele mostra apenas que uma entrada aparece na fonte subjacente. A integração ainda exige verificação do código do jogo do provedor, da interface e da versão do jogo, do status do ambiente, dos direitos comerciais e das condições do mercado-alvo.
Por que registrar separadamente a versão do jogo e a versão do modelo matemático?
Uma atualização de cliente ou visual pode não alterar o modelo matemático, enquanto uma alteração no modelo matemático pode exigir nova revisão de testes e certificação. Campos separados identificam o objeto efetivamente abrangido pelas evidências existentes.
Campos ausentes podem ser preenchidos automaticamente a partir de sites de provedores?
Páginas públicas podem ser indícios candidatos, mas mantenha a fonte e coloque o valor como pendente de verificação. Use-o em uma decisão de projeto somente depois que o material aplicável, a interface ativa ou o responsável competente o confirmar.
Com que frequência um catálogo deve ser atualizado?
Não dependa apenas de uma programação fixa. Uma mudança de fonte, lançamento de versão, incidente de status, expiração de evidência ou alteração de regra do mercado-alvo também deve acionar revisão.
Leituras relacionadas e próximos passos
- Entenda a fronteira da Slots API com múltiplos provedores
- Avalie um provedor de Slots API por meio de evidências
- Construa uma matriz de mercado, jogo, versão e certificação
- Use terminologia consistente para Slots API
- Páginas principais: catálogo de jogos e referência pública da API
Antes de usar a seção “Fale conosco”, prepare o mercado-alvo, os provedores ou escopo de jogos propostos, o modelo de carteira e os ambientes esperados. A AG poderá então retornar os campos de catálogo e as evidências que precisam de verificação para esse escopo. Isso não promete fornecimento, direitos nem admissão em produção.
Fontes e escopo
A contagem do catálogo se aplica somente ao retrato datado de 7 de agosto de 2026. Um projeto específico ainda deve verificar o status do registro, os direitos de exibição e as evidências do mercado-alvo.
Precisa transformar estas orientações em um plano de projeto?
Este artigo apoia a avaliação do projeto e não substitui a validação técnica, contratual, de certificação ou da legislação local.