La respuesta breve

Un catálogo de juegos utilizado para compras, integración y operaciones debe ser más que una lista de visualización de nombres de proveedores y títulos de juegos. Como mínimo, debe responder cinco preguntas: qué es este registro, de dónde procede, qué versión identifica, cuál es su estado actual y quién lo revisó y cuándo. El idioma, la moneda, el mercado objetivo, la certificación y el estado de lanzamiento también necesitan campos separados; no pueden comprimirse en una ambigua marca de «disponible».

El catálogo de juegos actual es una instantánea a nivel de nombres fechada el 7 de agosto de 2026. Contiene 11 proveedores y 1.194 nombres de juegos. Es útil para el descubrimiento inicial de contenido y como punto de partida para la gobernanza del catálogo, pero no contiene códigos de juego, versiones, modelos matemáticos, portadas, demostraciones, campos de API, certificaciones ni disponibilidad en tiempo real. Por tanto, no puede establecer si un juego concreto está disponible para un proyecto.

El recuento y la fecha no cambian la naturaleza de la instantánea. No son evidencia de suministro en tiempo real, habilitación de producción, derechos de terceros ni disponibilidad en el mercado objetivo.

Por qué una lista de nombres todavía no es un catálogo de productos

Los nombres pueden mostrar qué entradas se han recopilado, pero no conectan de forma fiable un registro con una API, un cambio de versión, un resultado de prueba o un mercado objetivo. Los nombres duplicados, los títulos renombrados, las distintas apariencias y los juegos del mismo tipo con modelos matemáticos diferentes pueden hacer que la coincidencia por nombre sea inexacta.

La gobernanza del catálogo no consiste en completar todos los campos a cualquier precio. Su finalidad es hacer que cada decisión sea trazable hasta un registro con una fuente, una fecha y un responsable. Cuando falta un valor, el estado correcto es pendiente de verificación, no una suposición basada en una página de terceros, un nombre de archivo o una experiencia anterior.

Un modelo de datos mínimo

Estos campos pueden residir en varias tablas, pero se deben conservar su significado y su responsable.

Grupo de campos Campos mínimos Pregunta que responde Orientación
Identidad estable catalog_record_id, provider_id, provider_game_code, game_name, game_type ¿Qué identifica de forma única este registro? Use ID estables para evitar colisiones de nombres
Procedencia source_ref, source_type, source_snapshot_at, source_hash ¿De dónde proviene la información, cuándo y se puede verificar? Conserve la fuente y la fecha
Versión del juego game_version, math_model_version, client_build, release_note_ref ¿Qué software y modelo matemático se verificaron? Vincule la compilación entregada
Versión de integración provider_api_version, aggregator_version, integration_version ¿Qué cadena de interfaces corresponde a esta versión del juego? Registre la topología completa
Ciclo de vida del registro record_status, status_reason, effective_from, effective_to ¿En qué punto de su ciclo de vida se encuentra el registro? Use estados controlados
Estado por entorno staging_status, production_status, demo_status, last_verified_at ¿Qué se ha verificado realmente en cada entorno? Almacene cada entorno por separado
Dimensiones de soporte language_codes, currency_codes, device_scope ¿Qué idiomas, monedas y dispositivos se han verificado? No los infiera a partir del título
Mercado y certificación market_code, operator_scope, certificate_ref, certificate_scope, certificate_status ¿Qué evidencia se aplica a un objeto, una versión y un alcance especificados? Asigne explícitamente cada mercado objetivo
Derechos y restricciones content_rights_scope, territory_restriction, usage_restriction, evidence_ref ¿Qué límites se aplican a la visualización, demostración, distribución o uso en el mercado? Almacene los derechos por separado
Responsabilidad y revisión data_owner, reviewer, updated_at, next_review_at, change_reason ¿Quién mantiene y confirma el registro, y cuándo es la próxima revisión? Conserve la responsabilidad y los plazos

No reutilice tres ID diferentes como si fueran uno solo

  • catalog_record_id es la identidad interna estable de un registro del catálogo y debe seguir siendo trazable cuando cambie su nombre de visualización.
  • provider_game_code es el identificador de juego utilizado por el proveedor o la interfaz ascendente y debe proceder de material de interfaz o de entrega verificable.
  • Un slug de página o alias de marketing sirve únicamente para la presentación. No debe convertirse en la clave primaria para transacciones, certificación o asignación de versiones.

Procedencia, estado, versión, actualizaciones y responsabilidad

1. La procedencia debe ser trazable

Para cada importación, conserve el tipo de fuente, la ubicación o referencia documental, la hora de la instantánea y el lote de importación. Si la fuente se sustituye posteriormente, conserve el período de vigencia del registro anterior en lugar de sobrescribir su historial. Una página de terceros puede sugerir datos candidatos, pero no debe ser la única evidencia de derechos, versión o disponibilidad actual.

2. El estado debe identificar su objeto y dimensión

Un ciclo de vida controlado del catálogo puede utilizar:

Estado Significado Lo que puede declararse públicamente
draft Existe un registro, pero no se ha revisado una identidad o procedencia crítica No publicar
pending_verification Existe material candidato, pero la evidencia de verificación está incompleta Declarar únicamente que la verificación está pendiente
verified_current Una versión y un entorno especificados se verificaron en una fecha indicada Declarar únicamente el alcance verificado
suspended Desactivado temporalmente porque la evidencia caducó, surgió un problema o aplica una restricción No presentarlo como disponible actualmente
retired Ya no se mantiene o ha sido reemplazado por una versión más reciente Conservar el historial; omitirlo del catálogo actual

«Registrado en el catálogo», «verificado en staging», «habilitado en producción» y «disponible en el mercado objetivo» son estados distintos. Ninguno implica los demás.

3. Los cambios de versión deben activar una revisión de impacto

Un cambio en el juego, el modelo matemático, el RGS o agregador, el contrato de API, las reglas de moneda, los recursos de idioma o los requisitos del mercado objetivo debe activar una revisión de impacto. Vincule el resultado con evidencia actualizada de pruebas o certificación. No suponga que una conclusión sobre una versión anterior se traslada automáticamente.

4. Toda actualización necesita una cadena de responsabilidades

Un flujo de trabajo mínimo es:

  1. Un responsable de datos importa o propone un cambio con procedencia y un motivo.
  2. Las comprobaciones automatizadas validan los ID estables, los campos obligatorios, los duplicados y los estados controlados.
  3. Los responsables técnicos, de negocio o de cumplimiento normativo revisan los campos dentro de su ámbito.
  4. La aprobación crea una nueva versión o actualiza el período de vigencia sin borrar la evidencia histórica.
  5. Una fecha de revisión, una fuente no válida o un cambio crítico de versión devuelven el registro a pendiente de verificación.
  6. Las páginas públicas solo leen campos y estados aprobados para su visualización.

No genere cientos de páginas de detalle directamente a partir de una lista de nombres. Construya por orden de valor para la decisión:

  1. Añada ID estables de proveedores, códigos de juego de proveedores, procedencia y responsables de los registros.
  2. Añada la versión del juego, la versión de la interfaz y el estado de staging necesarios para la integración real.
  3. Para los juegos que entren en evaluación de mercado, añada el mercado, la entidad operadora, el idioma, la moneda, el objeto de certificación y el alcance.
  4. Añada portadas, demostraciones y descripciones solo después de confirmar los derechos y fuentes de los activos.
  5. Cree contenido de detalle únicamente para juegos con una necesidad real de proyecto y evidencia suficiente.

Qué ofrece el catálogo actual

  • Una instantánea a nivel de nombres fechada el 7 de agosto de 2026, con 11 proveedores y 1.194 nombres de juegos.
  • Nombres de proveedores y juegos para la exploración inicial y las conversaciones sobre el alcance del contenido.
  • No ofrece inventario en tiempo real, lista de producción, repositorio de versiones, repositorio de derechos ni base de datos de certificaciones.
  • El marco de gobernanza de este artículo para los campos, estados y responsables que se necesitan a continuación.

Límites que conviene tener presentes

  • No se promete que ningún juego listado pueda invocarse, jugarse, lanzarse o estar disponible ahora en producción.
  • El catálogo no demuestra la autorización del proveedor, los derechos de uso de activos, el permiso del mercado objetivo ni la validez de la certificación.
  • El idioma, la moneda, la conectividad de la interfaz y la inclusión en el catálogo no establecen la legalidad en el mercado.
  • No invente códigos de juego, RTP, versiones, modelos matemáticos, portadas, enlaces de demostración ni ID de certificados.

Preguntas frecuentes

¿Que un nombre de juego figure en el catálogo significa que puede integrarse inmediatamente?

No. Solo muestra que una entrada aparece en la fuente subyacente. La integración todavía requiere verificar el código de juego del proveedor, la interfaz y la versión del juego, el estado por entorno, los derechos comerciales y las condiciones del mercado objetivo.

¿Por qué registrar por separado la versión del juego y la del modelo matemático?

Una actualización del cliente o de los elementos visuales puede no modificar el modelo matemático, mientras que un cambio en el modelo matemático puede requerir nuevas pruebas y una revisión de certificación. Los campos separados identifican el objeto que cubre realmente la evidencia existente.

¿Se pueden completar automáticamente los campos que faltan a partir de los sitios de los proveedores?

Las páginas públicas pueden ser pistas candidatas, pero conserve la fuente y coloque el valor en pendiente de verificación. Úselo para una decisión de proyecto solo después de que el material aplicable, la interfaz en vivo o el responsable competente lo confirmen.

No dependa únicamente de un calendario fijo. Un cambio de fuente, el lanzamiento de una versión, un incidente de estado, el vencimiento de evidencia o un cambio en las reglas del mercado objetivo también deben activar una revisión.

Lecturas relacionadas y próximos pasos

Antes de utilizar la sección «Contáctenos», prepare el mercado objetivo, los proveedores propuestos o el alcance de juegos, el modelo de monedero y los entornos previstos. AG podrá entonces proporcionar los campos del catálogo y la evidencia que deben verificarse para ese alcance. Esto no promete suministro, derechos ni admisión en producción.

Fuentes y alcance

El recuento del catálogo se aplica únicamente a la instantánea fechada el 7 de agosto de 2026. Un proyecto específico aún debe verificar el estado del registro, los derechos de visualización y la evidencia del mercado objetivo.

¿Quiere convertir esta guía en un plan de proyecto?

Esta guía apoya la evaluación y no sustituye la validación técnica, contractual, de certificación ni de requisitos locales.

Contactar