> Esta traducción se ofrece por comodidad. El texto normativo es el original en inglés. # Paquete MMAS **Especificación del Meta-Universo** **ID del documento:** MU-V2-ARCH-007 **Título:** Estándar de arquitectura de meta-modelos - estructura de repositorio y paquete **Clase de documento:** normativo **Versión:** 2.0 (borrador) **Estado:** borrador de trabajo **Referencias normativas:** Constitución del Meta-Universo (MUC), MMAS-Core, Versioning **Referencias informativas:** Extension-Model, MMAS-Conformance, Protocolo de federación del Meta-Universo (MUFP), Model-Traversal-and-Layout, Data-Mastership **Copyright:** © Orkestron.AI **Licencia:** Apache-2.0 --- # 1. Propósito Este documento define la estructura canónica de repositorio y paquete para los Meta-Modelos conformes con el Estándar de arquitectura de meta-modelos (MMAS). El objetivo es que todo Meta-Modelo tenga una organización predecible, comprensible tanto por personas como por agentes de IA. --- # 2. Alcance Esta especificación se aplica a: - repositorios de Meta-Modelos; - paquetes distribuibles de Meta-Modelos; - manifiestos de repositorio; - bundles; - capas; - recursos de apoyo; - ejemplos y documentación. Las implementaciones PUEDEN usar archivos adicionales siempre que no vulneren esta especificación. --- # 3. Principios de diseño Un paquete conforme DEBERÁ ser: - modular; - autodescriptivo; - versionado; - trazable; - legible por máquina; - legible por personas; - apto para la federación. La estructura del repositorio DEBERÁ reflejar la arquitectura semántica y no la tecnología de implementación. --- # 4. Estructura canónica del repositorio Todo Meta-Modelo DEBERÍA seguir la estructura canónica siguiente. ```text meta-model/ │ ├── README.md ├── BOOTSTRAP.md # operating instructions: how to read this model (read first) ├── LICENSE ├── CHANGELOG.md ├── manifest.yaml ├── sources.yaml # Data Mastership Register: System of Record per dataset │ ├── bundles/ │ ├── / │ │ ├── bundle.yaml │ │ ├── README.md │ │ ├── / │ │ │ ├── layer.yaml │ │ │ ├── objects/ │ │ │ ├── relationships/ │ │ │ ├── events/ │ │ │ ├── contracts/ │ │ │ └── projections/ │ │ └── ... │ └── ... │ ├── canon/ # canonical source texts the model treats as ground truth ├── raw/ # unprocessed harvested captures from external systems (never hand-edited) ├── artifacts/ # generated, regenerable outputs (never authored) ├── imports/ ├── mappings/ ├── schemas/ ├── examples/ ├── diagrams/ ├── docs/ └── tools/ ``` PUEDEN emplearse disposiciones equivalentes si se preserva la organización semántica. El contrato de recorrido sobre esta estructura (orden determinista del recorrido de bundles y capas, clasificación total de archivos, comprobación de completitud) y los significados reservados de `BOOTSTRAP.md`, `canon/`, `raw/` y `artifacts/` se definen normativamente en [Model-Traversal-and-Layout](Model-Traversal-and-Layout.md). El registro `sources.yaml` y las reglas para decidir si el maestro de un conjunto de datos es el modelo o un sistema externo (un wiki, un gestor de incidencias, una base de datos) se definen en [Data-Mastership](Data-Mastership.md). --- # 5. Manifiesto del repositorio Todo repositorio DEBERÁ contener un manifiesto. El manifiesto DEBERÍA declarar: - identificador; - nombre; - versión; - propietario; - espacio de nombres; - versión de MMAS admitida; - versión de MUC admitida; - versión de MUFP admitida; - estándares importados; - declaración de compatibilidad. El manifiesto es el punto de entrada principal para el descubrimiento automatizado. --- # 6. Estructura del bundle Todo Bundle DEBERÍA contener: - manifiesto del bundle; - documentación; - capas; - ejemplos opcionales. Los Bundles DEBERÁN tener una única responsabilidad semántica. --- # 7. Estructura de la capa Cada Capa DEBERÍA contener: - manifiesto de la capa; - definiciones de objetos; - relaciones; - eventos (si procede); - contratos (si procede); - perfiles de proyección (si procede). Las Capas DEBERÍAN seguir siendo comprensibles por separado. --- # 8. Documentación Todo repositorio público DEBERÍA incluir: - README; - visión general de la arquitectura; - historial de cambios; - información de licencia; - guía de contribución (opcional). La documentación DEBERÁ mantenerse sincronizada con la versión publicada. --- # 9. Ejemplos Los ejemplos de referencia DEBERÍAN almacenarse por separado de las especificaciones normativas. Los ejemplos NO DEBERÁN redefinir la semántica normativa. Los artefactos de ejemplo DEBERÍAN identificar la versión de la especificación a la que se dirigen. --- # 10. Estándares importados Los modelos semánticos importados DEBERÍAN aislarse bajo el directorio imports/. Las correspondencias entre conceptos importados y locales DEBERÍAN almacenarse bajo mappings/. Los artefactos importados DEBERÁN preservar las referencias a su fuente y versión originales. --- # 11. Metadatos del repositorio Un repositorio DEBERÍA exponer metadatos legibles por máquina suficientes para el descubrimiento. Metadatos recomendados: - huella semántica; - perfiles admitidos; - suma de verificación del paquete; - fecha de publicación; - URL del repositorio; - firma digital (opcional). --- # 12. Empaquetado Un paquete MMAS distribuible DEBERÁ preservar: - la estructura de directorios; - los manifiestos; - los identificadores; - las referencias semánticas; - los metadatos de versión. El formato de empaquetado depende de la implementación. Algunos ejemplos son repositorios Git, archivos comprimidos o registros. --- # 13. Paquete de distribución semántica (SDP) Mientras la Sección 4 define la disposición canónica del *repositorio*, la federación requiere una unidad de *distribución* portable y publicable. Un **Paquete de distribución semántica (SDP)** es esa unidad: un artefacto único, firmado y autocontenido que transporta un Meta-Modelo (o una parte acotada de él) junto con todo lo necesario para verificarlo, situarlo y usarlo en otro universo; el análogo de un artefacto Maven, npm u OCI, pero para modelos semánticos en lugar de código o imágenes. Un SDP conforme DEBERÁ contener: - un **manifiesto** (`manifest.yaml`) - identidad, versión, propietario, espacio de nombres y versiones de estándares admitidas, como en la Sección 5; - los **bundles y capas** que constituyen el Meta-Modelo empaquetado; - la **[huella semántica](Versioning.md)** del paquete, calculada sobre la estructura semántica normalizada; - una **firma digital** que vincula el contenido con un publicador; - una **declaración de conformidad** que indique la conformidad MUC, MMAS y MUFP (véase [MMAS-Conformance](MMAS-Conformance.md)); - la lista de **estándares importados** y los correspondientes [paquetes semánticos](Extension-Model.md); - las **correspondencias semánticas** entre conceptos importados y locales; - **proyecciones** y **ejemplos** opcionales que ayuden a la interpretación sin redefinir la semántica. Un SDP representativo, expandido, tiene esta forma: ```text employee-mm-2.3.1.sdp │ ├── manifest.yaml # identity, version, conformance declaration ├── bundles/ # bundles & layers (objects, relationships, events, contracts, projections) ├── mappings/ # semantic mappings to imported standards ├── imports/ # imported Semantic Packages (Schema.org, O*NET, FHIR, …) ├── examples/ # optional reference examples ├── fingerprint.sha256 # Semantic Fingerprint of the normalized structure └── signature.sig # digital signature of the package ``` Un SDP DEBERÁ ser autoverificable: el consumidor DEBERÁ poder recalcular la huella semántica a partir de la estructura contenida, contrastarla con `fingerprint.sha256` y validar la firma antes de confiar en el paquete. El SDP es la forma en tránsito y en estantería de la misma composición que alberga el repositorio; NO DEBERÁ redefinir la semántica, solo empaquetarla. --- # 14. Evolución del repositorio La estructura del repositorio DEBERÍA evolucionar de forma compatible. Los cambios estructurales que afecten al descubrimiento o a la interoperabilidad DEBERÁN versionarse y documentarse. Los cambios estructurales DEBERÍAN ir acompañados de orientación de migración. --- # 15. Requisitos nativos de IA Un repositorio conforme DEBERÍA permitir que los agentes de IA: - descubran el manifiesto; - enumeren bundles y capas; - resuelvan importaciones; - identifiquen dependencias; - localicen ejemplos; - determinen la conformidad; - naveguen el modelo sin conocimientos específicos de la implementación. La disposición del repositorio DEBERÍA minimizar la ambigüedad para el razonamiento automatizado. --- # 16. Invariantes arquitectónicos La organización del repositorio DEBERÁ preservar: - la identidad semántica; - la trazabilidad; - la propiedad; - la integridad de versiones; - el cumplimiento constitucional. La estructura del repositorio NUNCA DEBERÁ redefinir el significado semántico. --- # 17. Direcciones futuras El Paquete de distribución semántica hace portables a los Meta-Modelos; el paso natural siguiente es hacerlos **descubribles y resolubles a escala**. Una dirección futura es que la capa de ecosistema (`06-ecosystem`) opere como un **Registro de paquetes semánticos**: un servicio consciente de la federación que indexe los SDP y los [paquetes semánticos](Extension-Model.md) publicados por identidad, [huella semántica](Versioning.md), nivel de conformidad y rango de versiones compatibles, y que resuelva dependencias y migraciones bajo demanda; el equivalente para conocimiento semántico de Maven Central, npm o un registro OCI. Ese registro normalizaría la publicación, la confianza en la firma, la búsqueda y la recuperación, de modo que cualquier universo pueda localizar, verificar y adoptar un Meta-Modelo sin coordinación fuera de banda. --- # Declaración final La estructura de paquete MMAS es la organización física canónica de un Meta-Modelo. Su propósito es hacer que los modelos semánticos sean descubribles, reutilizables, extensibles e interoperables entre repositorios, organizaciones y agentes de IA, permaneciendo independientes de las tecnologías de implementación.