# Titularidad de los datos

*Construir un meta-modelo · lección 4 de 6 · ~15 min*

## Qué aprenderá

La pregunta que decide si su modelo y su wiki conviven en orden o en caos: para cada conjunto de datos, ¿quién es el maestro? (ARCH-018.)

## La enfermedad de las dos verdades

Su modelo describe el producto. Pero los runbooks viven en Confluence, las tareas vivían en un gestor, el código vive en GitLab y hay gente editándolo todo a diario. En el momento en que el mismo hecho existe en dos lugares editables, usted tiene dos verdades, y cada lector elige una en silencio. La cura no es la centralización (no va a sacar a operaciones de su wiki); es la **titularidad declarada**: cada conjunto de datos tiene exactamente un Sistema de Registro, de forma legible por máquina.

## Los tres patrones lícitos

**Maestro en el modelo (escritura de vuelta).** El conjunto de datos nace en el modelo; los sistemas externos reciben proyecciones generadas, claramente marcadas y de solo lectura "para comodidad de lectura". Flujo: modelo → externo. Conflicto: gana el modelo; las ediciones externas son nulas o se convierten en propuestas de cambio. *Ejemplo vivo: el modelo de Orkestron.AI es maestro de los hechos de su producto; el sitio público sirve un `product-facts.json` generado y marcado con "no editar aquí", con un hash de contenido para detectar desviaciones.*

**Maestro externo (espejo).** El conjunto de datos vive y cambia en un sistema externo; el modelo guarda un espejo recolectado para poder enlazar, clasificar y razonar. Flujo: externo → modelo, mediante un pipeline que aterriza capturas crudas (con procedencia) y las transforma. Los espejos son de solo lectura dentro del modelo y llevan **metadatos de frescura**: última recolección, cadencia, límite de obsolescencia. Conflicto: gana el sistema externo; se vuelve a recolectar, nunca se parchea el espejo. *Ejemplo vivo: espacios de wiki en actualización constante, clones de código fuente cuyo maestro es GitLab.*

**Particionado.** El caso mixto honesto: algunos conjuntos con maestro en el modelo, otros externos, cada uno declarado por separado. Una regla de hierro: el mismo campo nunca es escribible en ambos lados. Si de verdad necesita ambos, divida el dato (el sistema externo es maestro de `status`, el modelo es maestro de `assessment`).

## El registro: sources.yaml

Un archivo en la raíz del repositorio declara cada conjunto de datos: maestro, sistema externo y alcance, ubicación en el modelo, dirección del flujo, pipeline, cadencia, regla de conflicto, responsable y un **estado**: `active`, `declared` (titularidad decidida, pipeline aún no construido: deuda lícita y visible), `suspended` o `retired`. Este es el artefacto que responde mecánicamente a "hay un Confluence: ¿qué contiene y quién manda más?", para cada conjunto de datos, para siempre.

## Estados que se encontraron con la realidad

El vocabulario de estados vino de la producción a los pocos días de escribirse:

- `declared`: el modelo de Orkestron salió con su espejo del canon declarado pero aún no vendorizado: deuda visible en el registro, cerrada una sesión después. Los registros con cero entradas `declared` se ganan, no se presuponen.
- `retired`: DevTeam.Games guarda una exportación completa de un gestor de tareas cuya cuenta se cerró. El Sistema de Registro ya no existe; el espejo es un archivo de evidencia congelado que jamás podrá volver a recolectarse y que nunca debe "corregirse". El registro dice exactamente eso.
- `suspended` más una regla de conflicto de no publicar nunca: una base de código propietaria de referencia usada una vez como inspiración de diseño: presente en disco, legalmente intocable, y el registro es donde vive ese hecho en lugar de en la memoria de alguien.

## La desviación, vigilada por maquinaria

La titularidad declarada habilita la honestidad mecánica: el ejemplo de escritura de vuelta de más arriba ejecuta una comprobación diaria que regenera la proyección desde el modelo, compara los hashes de contenido con la copia publicada y avisa al propietario si hay desviación, si falta la copia o si la propia comprobación se rompe. La divergencia la detecta un cron, no la vergüenza en una reunión.

## Ideas clave

- Un maestro por conjunto de datos; el flujo sigue a la titularidad; las copias son desechables y van marcadas.
- Tres patrones: escritura de vuelta, espejo, particionado; el mismo campo nunca es escribible dos veces.
- `sources.yaml` más los estados (active/declared/suspended/retired) convierten el conocimiento tribal sobre quién manda en datos versionados.

## Profundizar

- [Titularidad de datos y Sistemas de Registro (ARCH-018)](/spec/#02-architecture/Data-Mastership.md)
- [Sincronización entre universos](/spec/#03-federation/Synchronization.md) (el hermano de esta lección a nivel de federación)

Siguiente: [Reutilizar el mundo](05-reuse.md)