> Esta traducción se ofrece por comodidad. El texto normativo es el original en inglés. # Maestría de datos **Especificación del Meta-Universo** **ID del documento:** MU-V2-ARCH-018 **Título:** Estándar de arquitectura de meta-modelos - maestría de datos y sistemas de registro **Clase de documento:** normativo **Versión:** 2.0 (borrador) **Estado:** borrador de trabajo **Referencias normativas:** MMAS-Core, MMAS-Package, Model-Traversal-and-Layout, Traceability **Referencias informativas:** Synchronization, Extension-Model, Provenance-Graph, AI-Agent-Guide **Copyright:** © Orkestron.AI **Licencia:** Apache-2.0 --- # 1. Propósito Un Meta-Modelo rara vez vive solo. El mismo conocimiento suele existir además en un wiki (Confluence), un gestor de incidencias (Jira, ClickUp), un CRM, una base de datos o un repositorio documental, y esas copias las editan personas que nunca abren el modelo. Este documento responde a la única pregunta que decide si esa coexistencia es orden o caos: **para cada conjunto de datos, ¿quién es el maestro, el Meta-Modelo o el sistema externo?** Define: - el **sistema de registro (SoR)**: el único lugar donde se redacta la verdad de un conjunto de datos; - los tres **patrones de maestría** lícitos (dominado por el modelo, dominado externamente, particionado); - el **Registro de maestría** (`sources.yaml`): la declaración legible por máquina de todo lo anterior; - las reglas de flujo, frescura, conflicto y escritura que se derivan de cada patrón. Sin esa declaración, un lector no puede saber si un hecho hallado en el modelo es autoritativo o un espejo posiblemente obsoleto, y un agente no puede saber dónde debe escribirse una corrección. Con ella, ambas preguntas tienen respuesta mecánica. --- # 2. Alcance Esta especificación rige la relación entre un Meta-Modelo y los **sistemas operativos dentro del mismo dominio de gobernanza**: wikis, gestores de incidencias, bases de datos, almacenes de archivos, aplicaciones de negocio. No rige: - **la federación entre universos soberanos** - eso es [Synchronization](../03-federation/Synchronization.md) y MUFP (cada par tiene sus propios SoR; la federación nunca transfiere maestría); - **los estándares externos importados** (Schema.org, FHIR, vocabularios ISO) - esos siempre están dominados externamente por sus organismos de normalización y los trata [Extension-Model](Extension-Model.md). --- # 3. Principios de diseño - **Un maestro por conjunto de datos.** Cada conjunto de datos tiene exactamente un sistema de registro. «Los dos sitios son un poco autoritativos» no es conforme por definición. - **La maestría se declara, no se infiere.** Ningún lector debería deducir la autoridad de nombres de carpetas, costumbres o folclore de equipo. - **El flujo sigue a la maestría.** Los datos van *del* maestro *a* sus copias; una copia nunca se escribe salvo por ese flujo. - **Las copias son desechables.** Cualquier copia que no sea la maestra puede borrarse y reconstruirse desde el maestro sin pérdida. - **La procedencia es obligatoria.** Todo dato replicado sabe de dónde vino y cuándo. --- # 4. Definiciones - **Conjunto de datos** - un cuerpo coherente de datos gobernado como una unidad (un conjunto de Objetos, un árbol de páginas, una tabla, un registro). La granularidad la elige el propietario del modelo; la maestría se declara por conjunto de datos. - **Sistema de registro (SoR)** - el sistema en el que se *redacta* un conjunto de datos y cuyo estado prevalece en cualquier conflicto. - **Espejo** - una copia, mantenida dentro del modelo, de un conjunto de datos dominado externamente, producida por recolección. - **Recolección** - la tubería que captura un conjunto de datos externo dentro del modelo (captura en bruto más transformación semántica). - **Proyección de escritura de vuelta** - una copia de un conjunto de datos dominado por el modelo, publicada en un sistema externo por comodidad de lectura, almacenamiento o procesamiento. --- # 5. Los tres patrones de maestría ## 5.1 Patrón M: dominado por el modelo El conjunto de datos **nace en el Meta-Modelo**. Los hechos se redactan directamente en el modelo (se editan, se revisan, se versionan como código). Los sistemas externos reciben **proyecciones de escritura de vuelta**: páginas renderizadas, tablas exportadas, registros sincronizados, publicados para las personas y herramientas que prefieren leer allí. Reglas: - El flujo es **modelo → externo**, siempre. - Toda copia proyectada DEBERÁ marcarse como generada: declara su maestro, su hora de generación y un aviso de «no editar aquí» en la forma que admita el sistema destino (banner de página, campo de registro, cabecera de archivo). - Las ediciones hechas en la copia externa **carecen de autoridad**. Una implementación DEBERÍA bloquear la copia externa, sobrescribirla en la siguiente publicación, o capturar tales ediciones como *propuestas de cambio* encaminadas al proceso de cambios normal del modelo; NO DEBERÁ fusionarlas en silencio. - En cualquier conflicto, **gana el modelo**. *Ejemplo: un registro de decisiones de arquitectura redactado en el modelo; Confluence lleva una representación generada y de solo lectura porque el resto de la organización vive en Confluence.* ## 5.2 Patrón E: dominado externamente El conjunto de datos **vive y cambia en un sistema externo** (un espacio de Confluence que los equipos actualizan a diario, un gestor de incidencias, una base de datos de producción). El modelo mantiene un **espejo**: una copia recolectada y semánticamente estructurada que permite al modelo enlazar, clasificar y razonar sobre esos datos. Reglas: - El flujo es **externo → modelo**, siempre. - La recolección DEBERÁ depositar la captura sin modificar bajo `raw///` con su archivo lateral de procedencia, según [Model-Traversal-and-Layout](Model-Traversal-and-Layout.md) §6; la transformación semántica puebla después el espejo en las capas del modelo. - El contenido replicado es de **solo lectura dentro del modelo**. Una corrección se hace en el sistema externo y se vuelve a recolectar; el modelo puede además registrar una desviación anotada («la fuente dice X, nosotros valoramos Y») como afirmación propia, dominada por el modelo, claramente separada del hecho replicado. - Todo conjunto de datos replicado DEBERÁ llevar **metadatos de frescura**: hora de la última recolección correcta, cadencia declarada y un límite de obsolescencia a partir del cual DEBERÁ advertirse a los consumidores. - En cualquier conflicto, **gana el sistema externo**; el espejo se corrige volviendo a recolectar, nunca al revés. *Ejemplo: agentes de IA recolectan continuamente un espacio vivo de Confluence dentro del modelo; el modelo añade estructura, enlaces y clasificación, pero las páginas mismas se redactan en Confluence.* ## 5.3 Patrón H: particionado El área de conocimiento está dividida: algunos conjuntos de datos (o campos) los domina el modelo y otros el exterior. Es el caso habitual en el mundo real y es lícito **solo cuando la partición es explícita**: - Cada partición DEBERÁ declararse como su propio conjunto de datos con un único maestro (patrón M o E). - El mismo campo NO DEBERÁ ser escribible por ambos lados. La maestría bidireccional de un mismo dato no es conforme; si realmente hace falta, divida el dato (por ejemplo: el sistema externo domina `status`, el modelo domina `assessment`). - Las referencias entre particiones están permitidas y son deseables; son referencias, no copias. --- # 6. El Registro de maestría (`sources.yaml`) Todo repositorio conforme DEBERÁ contener un Registro de maestría en su raíz, que cubra **todos los conjuntos de datos que el modelo alberga o replica**. Un conjunto de datos ausente del registro se considera dominado por el modelo y redactado íntegramente in situ; cualquier participación de un sistema externo sin entrada en el registro no es conforme. Cada entrada DEBERÁ declarar: | Campo | Significado | |-------|---------| | `id` | Identificador estable del conjunto de datos | | `description` | Qué son estos datos, en una línea | | `master` | `model` o `external` | | `system` | Si participa un sistema externo: nombre del sistema, URL, alcance (espacio, proyecto, tabla) | | `model_location` | Dónde vive el conjunto de datos (o su espejo) en el repositorio | | `flow` | `model->external`, `external->model` o `none` | | `pipeline` | El recolector o publicador (herramienta, script, agente) que mueve los datos | | `cadence` | Con qué frecuencia se ejecuta el flujo; para espejos, también `staleness_limit` | | `conflict_rule` | Reiteración de quién gana, más el contacto de escalado (`steward`) | | `status` | Ciclo de vida del flujo: `active` (por defecto), `declared`, `suspended`, `retired` | **Entradas declaradas.** Los modelos reales atraviesan un estado transitorio sobre el que el registro debe poder decir la verdad: la maestría está decidida pero el flujo aún no está construido; existe una ubicación de espejo pero nunca se ha recolectado, o se ha acordado una escritura de vuelta pero ninguna tubería la publica. Tales entradas DEBERÁN llevar `status: declared`. Una entrada declarada es lícita, pero es **deuda abierta, no operación**: un espejo declarado NO DEBERÁ presentarse como fresco (no tiene hora de recolección alguna) y una escritura de vuelta declarada no ofrece protección frente a la deriva. Ocultar el estado transitorio omitiendo la entrada, o marcándola `active`, no es conforme; el registro existe precisamente para hacer visible ese estado. Registro ilustrativo con ambas direcciones de Confluence: ```yaml datasets: - id: adr-register description: Architecture decision records master: model system: { name: Confluence, url: https://wiki.example.com, scope: SPACE/Architecture } model_location: bundles/architecture/decisions/ flow: model->external pipeline: tools/publish-adr-to-confluence cadence: on-change conflict_rule: model wins; external edits become change proposals steward: architecture-owner - id: ops-runbooks description: Operational runbooks maintained by the ops team in Confluence master: external system: { name: Confluence, url: https://wiki.example.com, scope: SPACE/Ops } model_location: bundles/operations/runbooks-mirror/ flow: external->model pipeline: tools/harvest-ops-runbooks cadence: daily staleness_limit: 7d conflict_rule: Confluence wins; fix at source and re-harvest steward: ops-lead ``` Este es exactamente el artefacto que responde mecánicamente, para cada conjunto de datos, a «hay un Confluence: ¿qué contiene y quién es más autoritativo, el meta-modelo o Confluence?». --- # 7. Conflicto y deriva - **Detección.** Las implementaciones DEBERÍAN detectar la deriva entre maestro y copia (comparación de contenido, huellas, marcas de tiempo) al menos en cada ejecución del flujo. - **Resolución.** La deriva se resuelve **solo** en la dirección declarada por `conflict_rule`; resolver «según criterio» caso por caso no es conforme. - **Escalado.** La deriva que no puede resolverse mecánicamente (la propia partición está mal, el maestro está en disputa) va al custodio del conjunto de datos y, si la maestría cambia, produce una nueva versión de la entrada del registro: los cambios de maestría son eventos versionados, nunca ediciones silenciosas. --- # 8. Frescura y confianza El consumidor de un conjunto de datos replicado DEBERÁ poder ver, sin salir del modelo: el sistema maestro, la hora de la última recolección y si se ha superado el límite de obsolescencia. Los espejos obsoletos DEBERÁN señalarse, no ocultarse. Una afirmación procedente de un espejo obsoleto arrastra esa obsolescencia en su procedencia; las decisiones de confianza posteriores (véase Trust-Model) PUEDEN ponderarla en consecuencia. --- # 9. Reglas para agentes de IA Un agente que trabaje con un modelo conforme: - **Antes de fiarse de un conjunto de datos**: DEBERÁ consultar el registro; para los espejos, DEBERÁ comprobar la frescura y preferir volver a recolectar antes que suponer si están obsoletos. - **Antes de escribir**: DEBERÁ escribir únicamente en el maestro del conjunto de datos. Una corrección a un hecho dominado externamente va al sistema externo (o a una persona con acceso); una corrección a un hecho dominado por el modelo va al modelo. Escribir en una copia no es conforme por cómodo que resulte. - **Al citar**: DEBERÍA nombrar al maestro («según el espacio Ops de Confluence, recolectado el 2026-07-30») en lugar de presentar un espejo como origen. Estas reglas son lo que permite que equipos mixtos de personas y agentes trabajen sobre el mismo conocimiento sin corromperlo desde ninguno de los dos lados. --- # 10. Relación con otros estándares - **[Model-Traversal-and-Layout](Model-Traversal-and-Layout.md)** da a espejos y proyecciones sus lugares físicos (`raw/`, espejos en capas, `artifacts/`) y sus orígenes (recolectado / generado); este documento les da autoridad. - **[Synchronization](../03-federation/Synchronization.md)** rige a los pares *a través* de fronteras de soberanía; este documento rige a las herramientas *dentro* de una. La federación nunca mueve la maestría; un universo expone solo lo que domina o lo etiqueta claramente como replicado. - **[Extension-Model](Extension-Model.md)**: los estándares importados son un caso especial fijo del patrón E (maestro: el organismo de normalización; flujo: versiones publicadas hacia dentro). - **[Traceability](Traceability.md) / [Provenance-Graph](Provenance-Graph.md)**: las ejecuciones de recolección y publicación son eventos de procedencia; el registro dice la política, el grafo de procedencia dice lo que ocurrió de verdad. --- # 11. Validación La validación estructural (V1) DEBERÁ comprobar: que el registro existe, se analiza y que toda `model_location` declarada existe. La validación semántica (V2) DEBERÍA comprobar: que todo espejo tiene metadatos de procedencia y frescura; que ningún archivo es escribible bajo dos entradas; que los flujos concuerdan con los maestros (`master: external` nunca lleva `flow: model->external`); y que toda entrada con `status: declared` se informa como deuda abierta. La validación en ejecución (V5) PUEDE comprobar los límites de obsolescencia contra el historial real de recolección y DEBERÍA degradar a `declared` una entrada cuya cadencia declarada nunca se haya ejecutado. --- # 12. Invariantes arquitectónicos La maestría DEBERÁ preservar: - un único sistema de registro por conjunto de datos en todo momento; - transiciones de maestría declaradas y versionadas; - la procedencia y la frescura de todo espejo; - la desechabilidad de toda copia que no sea la maestra; - el cumplimiento constitucional. La maestría NUNCA DEBERÁ deducirse solo de la ubicación física: la ubicación da una lectura por defecto, el registro da la ley. --- # 13. Direcciones futuras Dos extensiones naturales: un formato de **perfil de conector** que describa las tuberías de recolección y publicación para sistemas habituales (Confluence, Jira, Notion, almacenes relacionales), de modo que los registros puedan referenciar conectores tipados en lugar de scripts improvisados; y exponer las entradas del registro en el **Paquete de distribución semántica**, para que quien consuma un modelo empaquetado vea de inmediato qué partes son conocimiento redactado y cuáles son espejos del wiki de otro. --- # Declaración final Todo conjunto de datos tiene exactamente un hogar para su verdad. El Registro de maestría hace explícito ese hogar, las reglas de flujo mantienen honestas a las copias y las reglas de frescura mantienen honestos a los lectores respecto de las copias. Un modelo que declara sus maestros puede convivir con seguridad con wikis, gestores de incidencias y bases de datos; uno que no lo hace está a una edición de tener dos verdades.