Diseñando un modelo de datos de derechos musicales: identificadores, entidades y patrones de relación para desarrolladores

Un modelo de datos de derechos musicales robusto requiere identificadores con autoridad y procedencia, entidades canónicas con plazos definidos, y relaciones muchos a muchos explícitamente modeladas. Este diseño evita errores silenciosos de conciliación, permite auditorías defensibles y soporta cálculos de regalías reproducibles mediante la separación de registros autorizados, cargas útiles sin procesar y afirmaciones de propiedad inmutables.

Un modelo de datos de derechos musicales robusto es la base para flujos de trabajo precisos de edición, licencias y regalías en cualquier sistema de producción. Esta guía ofrece a desarrolladores, arquitectos de datos y profesionales de la música un proyecto alineado con los estándares y listo para la producción de identificadores, entidades canónicas, patrones de relación y técnicas prácticas para la conciliación, la procedencia y los derechos con plazos definidos. Encontrarás esquemas concretos, ejemplos de SQL y Neo4j, y asignaciones a DDEX, ISWC/ISRC e IPI para ayudar a implementar y validar flujos de trabajo del mundo real.

1. Panorama de los identificadores y cuándo confiar en cada identificador

Punto directo: Trata los identificadores como atributos con ámbito, no como claves absolutas. Cada identificador conlleva una autoridad delimitada, un perfil de fiabilidad y modos de fallo; tu registro canónico debe registrar qué fuente emitió el identificador y cuán seguro estás de que se aplica.

Identificadores centrales, autoridad y productores típicos

• ISWC - Emitido por CISAC y agencias de registro; el ámbito es la obra musical o composición. Utilizar para los registros de obras canónicas. Ver Documentos de ISWC de CISAC.
• ISRC - Emitido bajo la guía de la IFPI a los sellos discográficos y titulares de derechos; el ámbito es la grabación de sonido. Utilizar para los registros de grabación y la conciliación de la entrega. Ver Guía de ISRC de la IFPI.
• IPI/CAE - Identificadores de partes asignados a través de las PRO para los compositores y editores musicales; lo mejor para la coincidencia de partes entre sistemas.
• ISNI - Registro de identidad de colaborador más amplio, útil para los colaboradores que no son de interpretación y la vinculación de metadatos.
• GRid - Identificador para lanzamientos y paquetes de lanzamiento; utilizado por distribuidores y agregadores.
• DDEX ERN / RIN - Identificadores a nivel de mensaje y referencias de recursos utilizados en los intercambios de metadatos; autorizados para la procedencia de la fuente. Ver Estándares DDEX.
• CWR - Formato de registro de obras en bloque utilizado entre los editores musicales y las PRO; fuente de datos de ISWC y de participación en bloque cuando están disponibles.

Cómo fallan estos en la práctica: Los identificadores faltan, se aplican incorrectamente o se duplican. Los sellos discográficos a veces emiten ISRC a versiones de pistas incorrectas. Las obras a menudo no están registradas y carecen de ISWC. Las partes están representadas por ID locales conflictivos a través de las exportaciones de las PRO. Confiar ciegamente en cualquier identificador único causa la corrupción silenciosa de las divisiones y los flujos de pago.

Consejos de validación y normalización: Siempre valida el formato - por ejemplo, ISWC tiene un dígito de control y un patrón de prefijo - y almacena la autoridad emisora y la marca de tiempo. Enriquece los identificadores con registros autorizados siempre que sea posible en lugar de confiar en lo que venga en la fuente. Registra el resultado del enriquecimiento y limita la velocidad de los errores para evitar desajustes silenciosos.

Estrategia de clave canónica y heurísticas de reserva

Regla de clave canónica: Utiliza una clave canónica compuesta por workId más recordingId y sourceRecordId para la trazabilidad. No hagas de un único identificador externo la única clave primaria para tus tablas de obras o grabaciones.

Jerarquía de reservas y coincidencias: Prefiere la coincidencia exacta del identificador. Si no está presente, realiza una búsqueda en el registro autorizado, luego una coincidencia de metadatos de alta confianza utilizando el título normalizado + el IPI del colaborador, luego la huella acústica, luego la revisión humana. Cada paso debe escribir una puntuación de confianza y un puntero de procedencia a la carga útil sin procesar.

Ejemplo concreto: Un DDEX ERN entrante llega sin ISWC. Tu pipeline debe intentar una búsqueda de CISAC/PRO de ISWC por IPI y título del colaborador, luego consultar MusicBrainz para buscar grabaciones y huellas dactilares coincidentes, y si aún no se resuelve, crear un registro de obra provisional etiquetado como provisional con el ERN como sourceRecordId. Marca el registro para la adjudicación manual si la confianza está por debajo del umbral.

Prioriza la procedencia del identificador sobre la presencia del identificador: registrar quién emitió el ID y cuándo es tan importante como el ID en sí.

Conclusión: construye tu canonicalización en torno a la autoridad y la procedencia, no en torno a la ilusión de un ID universal. La siguiente consideración: diseña la propiedad y las afirmaciones con plazos definidos para hacer referencia a esos registros de identificadores compuestos.

2. Entidades canónicas para modelar y sus atributos centrales

Comienza con las entidades, no con los documentos. Un modelo de datos de derechos musicales robusto trata las entidades canónicas como la fuente de verdad para las licencias, los informes y la conciliación posteriores, no los formatos de archivo entrantes. Diseña cada entidad en torno a sus responsabilidades operativas: identificación, procedencia y afirmaciones con plazos definidos.

Entidades canónicas centrales (qué almacenar y por qué)

• Obra — workId, title, ISWC, originalLanguage, firstReleaseDate, contributors (partyId, role, IPI), canonicalTitles (variantes normalizadas)
• Grabación — recordingId, title, ISRC, duration, audioFingerprint, derivedFromWorkIds, releaseIds (muchos)
• Lanzamiento — releaseId, title, catalogNumber, releaseDate, labelId, trackListings, recordingId
• Parte — partyId, name (persona|organización), ipi, isni, role (compositor, editor musical, intérprete), punteros de contacto y contractuales mantenidos en los registros locales
• Acuerdo — agreementId, partyId, workId, effectiveFrom, effectiveTo, terms (enlaces a RightInstance)
• Instancia de derecho — rightInstanceId, rightType (performance|mechanical|synchronization|distribution), territory, exclusiveFlag, effectiveFrom, effectiveTo
• Participación de propiedad — ownershipShareId, ownerPartyId, workId, shareNumerator, shareDenominator, effectiveFrom, effectiveTo, sourceRecordId
• Territorio — Códigos ISO, agregaciones y agrupaciones comunes utilizadas por la lógica empresarial
• Evento — eventos de uso o registro (eventId, eventType, timestamp, sourceSystem) para la procedencia y la auditoría

Información práctica: Modela OwnershipShare como numerador/denominador, no como un porcentaje flotante. Los campos fraccionarios evitan la deriva de redondeo durante la agregación de divisiones y preservan la aritmética exacta para los cálculos y auditorías de regalías.

Compensación de diseño: Normaliza Party y Agreement para evitar la repetición de datos de contacto y contrato, pero desnormaliza una vista optimizada para la lectura (registro canónico en caché) para consultas de pago rápidas. En la práctica, mantenemos tablas normalizadas estrictas para las actualizaciones autorizadas y una vista materializada desnormalizada para las ejecuciones de regalías por lotes.

Ejemplo concreto: Al ingerir un DDEX ERN, crea o actualiza un Work con ISWC y enlaces de Contributor del colaborador, crea filas de Recording para cada grabación de sonido con ISRC e audioFingerprint, y emite registros de OwnershipShare de los campos de participación del colaborador de ERN que hacen referencia al ERN como sourceRecordId. Ejemplo de JSON mínimo: {"workId": "W123", "title": "Song Title", "iswc": "T-123.456.789-0", "contributors": [{"partyId": "P456", "role": "composer", "ipi": "00123456789"}]}.

Veredicto final: La mayoría de los problemas provienen de un modelado insuficiente del tiempo y la procedencia, o del colapso de Lanzamiento y Grabación. Modela la validez temporal y las referencias de origen desde el primer día; te lo agradecerás cuando necesites responder quién era el propietario de qué en un período de informe anterior.

3. Patrones de relación y reglas de cardinalidad

Punto directo: las relaciones en un modelo de datos de derechos musicales rara vez son uno a uno; diseña para muchos a muchos por defecto y haz que las excepciones sean explícitas y se cumplan.

Arquetipos de relación comunes

Reglas de cardinalidad que debes codificar: haz cumplir que para cualquier RightInstance único con ámbito a una obra/territorio/ventana de tiempo, el conjunto de registros de OwnershipShare activos representa la división autorizada. No confíes en los porcentajes de texto libre en los acuerdos como la fuente de verdad.

• Regla de suma activa: para cada (work_id, right_type, territory, time-window) las participaciones activas deben sumar 1 (o el total acordado) — validar en la ingesta.
• Regla de no superposición: las participaciones de propiedad que son exclusivas no deben superponerse en el tiempo para el mismo derecho y territorio; modela las superposiciones como transiciones explícitas con procedencia.
• Regla de tipo de borde: los bordes de relación necesitan un calificador tipado (por ejemplo, derived_from, interpolated, contains_sample) para que la lógica de regalías descendente pueda tratarlos de forma diferente.

Compensación: hacer cumplir la aritmética y la no superposición a nivel de restricción de la base de datos es seguro pero frágil al ingerir fuentes externas desordenadas. En la práctica, valida y autorrechaza solo los registros claramente no válidos; marca los conflictos ambiguos para la revisión humana y almacena las cargas útiles sin procesar para permitir la corrección posterior.

Ejemplo concreto: una grabación de popurrí contiene tres composiciones. Representa eso con tres filas de work_recording_map que enlazan la Grabación R123 con las Obras W1, W2, W3 y crea registros de OwnershipShare para cada compositor con rangos efectivos ligados a la fecha de lanzamiento de la grabación. Cuando un componente revierte posteriormente a un editor musical anterior, añade un nuevo OwnershipShare con un effectiveTo posterior y sourceRecordId apuntando al acuerdo de reversión.

Juicio de gráfico vs relacional: utiliza tablas relacionales y JSONB para registros y restricciones canónicos y auditables; añade un índice de gráfico o una réplica de Neo4j para recorridos rápidos como encontrar todas las grabaciones derivadas o redes de editores musicales transitivas. No modeles la procedencia solo como propiedades de gráfico: mantén los campos autorizados con plazos definidos en el almacén canónico para la contabilidad.

Importante: trata los atributos territoriales y de exclusividad como partes de primera clase de las claves de relación; no hacerlo crea dobles pagos silenciosos y dolores de cabeza de conciliación.

Siguiente consideración: una vez que codifiques estas reglas de cardinalidad, crea pruebas automatizadas que simulen casos extremos comunes (popurrís, samples, derechos de editor musical revertidos y exclusivas limitadas por territorio) y afirma tanto la aritmética de las participaciones como los enlaces de procedencia a mensajes de origen como DDEX ERN. Para obtener orientación sobre referencias y asignaciones, consulta los estándares DDEX y almacena las cargas útiles sin procesar como se describe en la lista de verificación de ingesta canónica en UniteSync.

4. Modelado de divisiones de propiedad, procedencia y derechos con plazos definidos

La propiedad debe modelarse como afirmaciones inmutables y auditables que son válidas para una ventana de tiempo y se remontan a una fuente. Trata cada participación como un registro de primera clase en lugar de un campo mutable en una obra o parte.

Diseño de registro práctico: crea un registro de OwnershipShare con ownershipShareId, ownerPartyId (compositor/editor musical/propietario), workId, shareNumerator, shareDenominator, effectiveFrom, effectiveTo, territory (códigos ISO o lista de cobertura), rightType, sourceSystem, sourceRecordId, y eventId que enlaza a un evento de cambio. El uso de un numerador/denominador entero evita errores de redondeo repetidos al dividir aún más o agregar a través de múltiples titulares de derechos.

Procedencia y cadena de auditoría

Almacena las cargas útiles de origen sin procesar, pero mantenlas separadas de las uniones canónicas. Persiste la carga útil entrante de DDEX ERN/CWR/PRO en un almacén sin procesar o en un archivo comprimido de rawPayload y haz referencia a ella con sourceRecordId. Mantén una tabla de AuditLog que registre quién ingirió o cambió la participación, por qué (id de acuerdo, revocación, corrección) y un hash de la carga útil sin procesar para que puedas probar el mensaje exacto utilizado para calcular una división.

Compensación a aceptar: la retención de la carga útil sin procesar aumenta el almacenamiento y respalda las preocupaciones de privacidad; comprime y clasifica las cargas útiles más antiguas en almacenamiento en frío, pero nunca elimines el puntero de la fila canónica. Eliminar la procedencia mata la conciliación forense y la defensa legal.

Cálculo de divisiones pagaderas: para calcular una división para una fecha de reproducción y un territorio determinados, consulta las participaciones donde effectiveFrom <= playDate < effectiveTo y el territorio coincida, luego suma las fracciones aplicables agrupadas por función del beneficiario. Prefiere las fuentes autorizadas por tipo de derecho: utiliza las divisiones registradas por la PRO para las regalías por ejecución pública y los contratos de los editores musicales para las regalías mecánicas cuando aparezcan discrepancias.

Ejemplo concreto: un compositor asignó la edición musical al Editor A (exclusivo) desde 2018-01-01 hasta una reversión en 2020-06-15. Mantienes dos filas de OwnershipShare: una con effectiveTo 2020-06-14 procedente del acuerdo de edición musical original y una segunda a partir de 2020-06-15 procedente del aviso de reversión (ERN o acuerdo). Una reproducción el 2019-05-01 elige la primera fila; una reproducción el 2021-03-01 elige la segunda.

Modo de fallo común: sobrescribir la participación anterior en lugar de cerrarla. En la práctica, esto hace que las consultas de regalías históricas sean irreproducibles y crea disputas de auditoría. Siempre añade una nueva fila con plazos definidos y marca la fila antigua como cerrada.

• Resolución de conflictos: implementa un mapa de autoridad de origen clasificado (PRO > Editor musical > Sello discográfico > Agregador) y utiliza confidenceScore más el rango de origen para elegir en qué fuente confiar para cada tipo de derecho.
• Indexación: crea un índice compuesto en (workId, effectiveFrom, effectiveTo) y considera la posibilidad de particionar por territory o rightType para catálogos grandes.
• Campos derivados: almacena un decimal normalizado computedShare para las matemáticas de pago rápidas, pero vuelve a calcular cuando cambie la procedencia o el numerador/denominador.

5. Asignación a los estándares de mensajes de la industria y patrones de ingesta

La asignación directa a los estándares de mensajes no es opcional, es la forma más práctica de reducir el trabajo de conciliación y capturar la procedencia. Diseña tu ingesta para tratar los DDEX ERN/RIN, CWR y las exportaciones de las PRO como documentos de origen autorizados, no solo filas de datos para ser analizadas y descartadas.

Distinción clave: utiliza ERN para el registro de recursos y los metadatos, RIN para las actualizaciones de derechos y uso, y las exportaciones de CWR/PRO para el registro de obras en bloque donde DDEX no está disponible. En la práctica, RIN lleva afirmaciones relevantes para los derechos, mientras que ERN proporciona los metadatos de recursos canónicos; ambos deben conservarse como cargas útiles sin procesar para las auditorías. Consulta DDEX, Guía de ISWC de CISAC e IFPI sobre los identificadores de grabación en IFPI.

Etapas prácticas del pipeline de ingesta

1. Validar: comprobaciones de esquema y firma de mensaje donde estén disponibles; rechazar ERN/RIN mal formados al principio.
2. Normalizar: canonicalizar los formatos de identificador (eliminar separadores, poner en mayúsculas ISWC/ISRC), normalizar los nombres y los códigos de territorio.
3. Enriquecer: buscar ISWC/ISRC/IPI faltantes en los registros; adjuntar huellas acústicas cuando las grabaciones estén presentes.
4. Coincidir y puntuar: coincidencia primero por identificador, recurrir a la coincidencia difusa de metadatos con puntuación de confianza.
5. Reglas de fusión: aplicar la prioridad de origen y el control de versiones; mantener los registros anteriores como afirmaciones con plazos definidos en lugar de sobrescribir.
6. Persistir la carga útil sin procesar: almacén sin procesar de solo anexión o columna JSONB con messageId, timestamp, y sourceSystem.
7. Emitir registros derivados: crear filas canónicas de Obra/Grabación/OwnershipShare e indexar para las consultas.

Compensación y limitación: las actualizaciones de RIN de streaming funcionan bien para la conciliación casi en tiempo real, pero aumentan la complejidad en torno a la idempotencia y el ordenamiento. Los archivos CWR por lotes son más sencillos de procesar, pero llegan obsoletos y carecen de granularidad a nivel de grabación. La mayoría de los sistemas de producción utilizan híbridos: streaming para las actualizaciones, conciliación periódica por lotes con archivos en bloque.

Ejemplo concreto: un agregador envía un ERN que carece de ISWC pero con funciones de colaborador y porcentajes de participación. Tu pipeline debe validar el ERN, enriquecerlo consultando los registros de CISAC/IPI e ISWC, crear registros de OwnershipShare haciendo referencia al sourceRecordId del ERN original y almacenar la carga útil del ERN en una tabla sin procesar JSONB para que un auditor pueda reproducir las decisiones de enriquecimiento y coincidencia más tarde.

Campo canónico -> Asignación DDEX (campos comunes)

No confíes solo en los campos de porcentaje. Convierte a numerador/denominador y conserva la cadena de porcentaje original del mensaje para evitar disputas de redondeo durante los cálculos de regalías.

Veredicto: prioriza la preservación de los mensajes de origen y la procedencia sobre el intento de una resolución automatizada perfecta en el momento de la ingesta. Los ID mal aplicados y las funciones de colaborador inconsistentes son los modos de fallo habituales; mantener el mensaje sin procesar y un registro de coincidencia determinista basado en la puntuación te permite corregir las asignaciones sin perder la trazabilidad. Siguiente consideración: define la tabla de prioridad de origen y las claves de idempotencia antes de procesar tu primera fuente.

6. Patrones de implementación: modelos relacionales, de documentos y de gráficos con ejemplos

Punto directo: elige el modelo de almacenamiento que coincida con la carga de trabajo: utiliza un núcleo relacional para la contabilidad y los registros canónicos, documentos JSONB para la ingesta y la procedencia, y un gráfico para la exploración de relaciones, y acepta que una arquitectura híbrida es el resultado realista para los sistemas de derechos musicales de producción.

Núcleo relacional (qué almacenar y por qué)

Fuerza relacional: Las garantías ACID, las uniones predecibles y la auditabilidad hacen de RDBMS el almacén primario adecuado para Work, Recording, OwnershipShare, RightInstance, y tablas tipo libro mayor. Define OwnershipShare con numerador/denominador, effectiveFrom/effectiveTo, sourceRecordId y confidenceScore para preservar la procedencia. Ejemplo de línea DDL: CREATE TABLE ownership_share (id UUID PRIMARY KEY, work_id UUID NOT NULL, owner_party_id UUID NOT NULL, share_numerator INT, share_denominator INT, effective_from DATE, effective_to DATE, source_record_id TEXT, confidence_score DECIMAL, created_at TIMESTAMP);

Capa de documento (Postgres JSONB para la ingesta y la desnormalización)

Fuerza del documento: JSONB gestiona el DDEX ERN sin procesar, las cargas útiles de origen completas y los registros canónicos desnormalizados para lecturas rápidas. Almacena las cargas útiles sin procesar en raw_payload y las instantáneas canónicas en canonical_snapshot como JSONB. Utiliza un índice de GIN en raw_payload e índices de ruta para sourceRecordId para acelerar el enriquecimiento. Esto mantiene el modelo relacional canónico pequeño al tiempo que preserva los detalles forenses.

Capa de gráfico (Neo4j para el recorrido y el descubrimiento)

Fuerza del gráfico: utiliza un gráfico para las consultas transitivas de múltiples saltos que son incómodas en SQL: encuentra todas las grabaciones que samplean una obra, descubre redes de editores musicales o calcula el alcance del colaborador. Almacena las divisiones de propiedad en los bordes: (:Party)-[OWNS {shareNumerator, shareDenominator, effectiveFrom}]->(:Work). Ejemplo de Cypher: MATCH (p:Party)-[owns:OWNS]->(w:Work) WHERE owns.effectiveFrom <= date() AND (owns.effectiveTo IS NULL OR owns.effectiveTo > date()) RETURN p.name, w.title, owns.shareNumerator, owns.shareDenominator;

• Índices para añadir: btree en (workId, effectiveFrom), btree en (ownerPartyId, effectiveFrom), GIN en sourceRecordId, índice parcial en OwnershipShare donde effectiveTo IS NULL para las búsquedas de propiedad actuales
• Patrón de sincronización: escribir primero en relacional para las operaciones financieras, reflejar JSONB desnormalizado para las API de lectura y enviar asíncronamente los cambios de relación al gráfico con un flujo de eventos

Ejemplo concreto: para responder a dónde deben fluir las regalías para una grabación sampleada, une recordings -> work_recording_map -> ownership_shares en SQL para calcular las divisiones para el período de pago, mientras que utiliza un recorrido de gráfico para mostrar todas las obras sampleadas ascendentes y sus redes de editores musicales para la revisión humana. En la práctica, este patrón de consulta híbrida reduce los errores de conciliación y mantiene los pagos auditables.

Siguiente consideración: define contratos de sincronización claros y eventos idempotentes entre los sistemas antes de implementar la pila híbrida: los registros de propiedad no coincidentes en los almacenes son el mayor modo de fallo operativo.

7. Conciliación, heurísticas de coincidencia y consideraciones operativas

Afirmación directa: La conciliación no es un algoritmo único, es un pipeline operativo con etapas medibles, modos de fallo y puntos de control humanos. Trata la coincidencia como un flujo de trabajo diseñado: rutas rápidas deterministas, rutas lentas probabilísticas y un bucle de revisión manual auditable.

Prioridad y umbrales de coincidencia

• Coincidencia exacta del identificador: ISWC para obras, ISRC para grabaciones, IPI para partes. Aceptar y enlazar automáticamente cuando los identificadores y la autoridad de origen coincidan.
• Coincidencia de metadatos de alta confianza: Título normalizado + conjunto de colaboradores (preferir IPI) + ventana de duración. Utilizar para la aceptación automática solo cuando la confianza > 0,95.
• Huella acústica: Confirmar o desambiguar las grabaciones cuando faltan los ID. Las huellas dactilares son potentes, pero pueden confundir las versiones cover o remasterizadas.
• Coincidencia difusa / ML: Utilizar como una señal de clasificación de último recurso; siempre mostrar la confianza y la procedencia y poner en cola por debajo de un umbral estricto.
• Revisión manual: Para popurrís, samples o participaciones en conflicto; asegurar que los revisores vean las cargas útiles de origen completas (almacenar ERN/CWR sin procesar) y el historial de fusión anterior.

Información práctica: La normalización del título importa más de lo que crees. Normaliza unicode, elimina el ruido textual (feat, etiquetas de remix), colapsa los espacios en blanco y compara con la similitud de trigramas más la ponderación del colaborador. Esto reduce los falsos positivos de las diferencias menores de puntuación sin activar el ML costoso.

Modo de fallo operativo: confiar en la similitud de cadenas sola para los títulos. Los títulos pueden diferir en mayúsculas, puntuación y caracteres diacríticos; normaliza primero, luego compara. Utiliza una métrica de distancia de Levenshtein normalizada o similitud de trigramas, no una comparación de igualdad de cadenas.

Ejemplo concreto: dos fuentes llegan con "Song Title (Remix)" y "Song Title Remix". Normaliza ambas a "song title remix", compara con trigramas, obtén una puntuación de similitud de 0,98 y enlaza automáticamente. Almacena la puntuación y el método de coincidencia en el registro de relación para la auditoría posterior.

Manejo de conflictos y procedencia de autoridad

Implementa un mapa de autoridad de origen clasificado: PRO > Editor musical > Sello discográfico > Agregador. Cuando dos fuentes afirmen divisiones diferentes para la misma obra/territorio/período, prefiere la fuente de mayor rango. Registra la decisión y la puntuación de confianza en el registro de OwnershipShare.

Ejemplo concreto: una PRO afirma que el Compositor A posee el 50% de una obra; un agregador afirma el 60%. Crea dos filas de OwnershipShare con sourceSystem y sourceRecordId diferentes, marca la fila de PRO como confidenceScore 0,99 y la fila de agregador como 0,70. Las consultas de pago prefieren la fila de PRO. Marca la fila de agregador para revisión humana.

Resolución de conflictos de tiempo: cuando las participaciones se superponen en el tiempo, valida que la suma sea 1 (o el total acordado) para cada ventana de tiempo. Si no, marca para revisión. Almacena las transiciones explícitamente: la fila anterior cierra con effectiveTo, la nueva fila abre con effectiveFrom en la misma fecha.

Pruebas y validación

• Pruebas de aritmética: para cada (work_id, territory, right_type, date), suma las participaciones activas y afirma que suman 1 o el total acordado.
• Pruebas de procedencia: para cada OwnershipShare, verifica que sourceRecordId apunta a una carga útil sin procesar válida y que el sourceSystem está en la lista de autoridades conocidas.
• Pruebas de casos extremos: popurrís (una grabación, muchas obras), samples (una grabación derivada de muchas obras), reversiones (cambios de participación en el tiempo), exclusivas limitadas por territorio.
• Pruebas de idempotencia: ingiere el mismo mensaje dos veces; afirma que los registros canónicos no cambian.

Automatización: ejecuta estas pruebas en cada ingesta y en cada cambio de participación. Registra los resultados en un registro de validación para la auditoría.