> Esta traducción se ofrece por comodidad. El texto normativo es el original en inglés. # Matriz de compatibilidad **Especificación del Meta-Universo** **ID del documento:** MU-V2-ECO-002 **Título:** Matriz de compatibilidad multidimensional **Clase de documento:** informativo **Versión:** 2.0 (borrador) **Estado:** borrador de trabajo **Referencias normativas:** MUC, MMAS, MUFP **Referencias informativas:** Registered-Meta-Models, Certification, Known-Implementations **Copyright:** © Orkestron.AI **Licencia:** Apache-2.0 --- # 1. Propósito Este documento define la matriz de compatibilidad recomendada para los activos conformes con el Meta-Universo. La matriz de compatibilidad aporta un método estandarizado para declarar la interoperabilidad entre meta-modelos, estándares, perfiles de federación e implementaciones. Permite a personas y a agentes de IA determinar con rapidez si puede establecerse una federación semántica y en qué condiciones. --- # 2. Alcance La matriz de compatibilidad puede describir la compatibilidad entre: - meta-modelos; - versiones de MUC; - versiones de MMAS; - versiones de MUFP; - perfiles de federación; - estándares importados; - paquetes semánticos; - implementaciones. --- # 3. Principios de diseño Se espera que las declaraciones de compatibilidad sean: - explícitas; - conscientes de las versiones; - trazables; - legibles por máquina; - independientes de la tecnología; - reproducibles. La compatibilidad se declara, no se presupone. --- # 4. Dimensiones de la compatibilidad La compatibilidad no es un único sí o no. Es *multidimensional*: dos activos pueden encajar a la perfección en un eje y requerir trabajo en otro. Por eso la compatibilidad se evalúa de forma independiente en: - la compatibilidad constitucional (MUC); - la compatibilidad arquitectónica (MMAS); - la compatibilidad de federación (MUFP); - la compatibilidad semántica; - la compatibilidad de espacios de nombres; - la compatibilidad de identidades; - la disponibilidad de correspondencias; - la compatibilidad de proyecciones; - la compatibilidad de validación. Cada eje da su propio resultado. Un veredicto multidimensional típico se lee, por ejemplo, así: - **Compatible con MUC**: ambos activos obedecen los mismos principios constitucionales; - **Compatible con MMAS**: sus estructuras arquitectónicas encajan; - **MUFP requiere actualización**: la federación necesita una versión más reciente del protocolo en uno de los lados; - **Correspondencia semántica disponible**: las diferencias de concepto quedan salvadas por una correspondencia publicada; - **Se requiere perfil de federación**: la interacción depende de que se cargue un perfil concreto; - **Perfil de proyección admitido**: existe un perfil de proyección adecuado para el intercambio; - **Validación certificada**: la conformidad se ha verificado de forma independiente. Quien consume lee el vector entero, no una sola etiqueta, para entender exactamente qué encaja y qué hay que preparar. --- # 5. Niveles de compatibilidad Niveles recomendados: - Nativa - Compatible - Compatible con correspondencia - Compatible con transformación - Experimental - Incompatible Todo nivel declarado va acompañado de evidencia que lo respalda. --- # 6. Estructura de la matriz Una entrada de la matriz suele incluir: - el modelo de origen; - el modelo de destino; - la versión de origen; - la versión de destino; - el nivel de compatibilidad; - las correspondencias semánticas necesarias; - el perfil de federación necesario; - el estado de validación; - notas. --- # 7. Matriz de ejemplo | Origen | Destino | Resultado | |--------|--------|--------| | Meta-modelo de empleado | Meta-modelo de organización | Nativa | | Meta-modelo de empleado | O*NET | Compatible con correspondencia | | Meta-modelo de empleado | ESCO | Compatible con correspondencia | | Meta-modelo de empleado | Schema.org | Compatible con transformación | | Meta-modelo de empleado | HL7 FHIR | Experimental | Esta tabla es ilustrativa. --- # 8. Compatibilidad de versiones La compatibilidad es específica de versión. Ejemplo: - Employee MM 2.x ↔ Organization MM 2.x : compatible - Employee MM 2.x ↔ Organization MM 1.x : se requiere correspondencia Los cambios de versión mayor suelen disparar una revisión de compatibilidad. --- # 9. Compatibilidad de federación La compatibilidad declara: - la versión de MUFP admitida; - los perfiles de federación admitidos; - los perfiles de proyección admitidos; - el modelo de vínculo de identidad admitido; - las capacidades de sincronización. --- # 10. Estándares importados Puede publicarse compatibilidad para estándares importados, entre ellos: - Schema.org - OData CSDL - HL7 FHIR - O*NET - ESCO - BPMN - ArchiMate Las correspondencias se referencian en lugar de duplicarse. --- # 11. Validación La validación de compatibilidad verifica: - el alineamiento de versiones; - la coherencia de espacios de nombres; - la disponibilidad de correspondencias; - la compatibilidad de perfiles; - los requisitos contractuales; - la integridad semántica. La validación produce resultados reproducibles. --- # 12. Publicación La información de compatibilidad se publica junto con: - los metadatos del repositorio; - la entrada del meta-modelo registrado; - las notas de versión; - los informes de validación. Quien consume puede descubrir la compatibilidad antes de adoptar. --- # 13. Gobernanza Las declaraciones de compatibilidad identifican: - la autoridad que publica; - la fecha de publicación; - las versiones admitidas; - el estado de revisión. La compatibilidad se revalida periódicamente. --- # 14. Invariantes arquitectónicas La compatibilidad preserva: - la soberanía semántica; - las identidades canónicas; - la procedencia; - la trazabilidad; - el cumplimiento constitucional. Declarar compatibilidad no modifica ninguno de los modelos implicados. --- # 15. Resolución automática de la compatibilidad Como la matriz es multidimensional y legible por máquina, los agentes de IA pueden resolver la compatibilidad automáticamente antes de que empiece interacción alguna. Dados dos activos y sus versiones, un agente lee el vector de compatibilidad y determina: - **Si podemos interactuar siquiera**: si encajan los ejes constitucional y arquitectónico; - **Qué correspondencias semánticas cargar**: qué correspondencias publicadas salvan las diferencias de concepto; - **Si hace falta actualizar de versión**: si algún eje informa de *requiere actualización* en cualquiera de los lados; - **Qué perfil de federación usar**: de qué perfil depende la interacción; - **Qué restricciones aplican**: qué perfiles de proyección, reglas de divulgación y requisitos de validación rigen el intercambio. La analogía más cercana es la *resolución de dependencias en los gestores de paquetes*: igual que un gestor resuelve versiones, dependencias transitivas y características necesarias antes de instalar software, un agente del Meta-Universo resuelve versiones de estándares, correspondencias necesarias, perfiles y restricciones antes de federar. La matriz de compatibilidad es el grafo de dependencias de un ecosistema semántico, y la federación equivale a una instalación resuelta con éxito. --- # 16. Direcciones futuras Un futuro **marco de validación semántica (SVF)** podría estandarizar cómo se computa y se evidencia cada eje de compatibilidad, convirtiendo la matriz de tabla publicada en un servicio de resolución verificable y consultable. Un servicio así permitiría a los agentes pedir un plan de resolución ("¿qué necesito para federar A con B?") y recibir una lista ordenada de correspondencias, cargas de perfil y actualizaciones: el equivalente semántico de un fichero de bloqueo de dependencias resuelto, cruzado con los resultados de [Certification](Certification.md). --- # Declaración final La matriz de compatibilidad aporta un mecanismo transparente y reutilizable para evaluar la interoperabilidad en todo el ecosistema del Meta-Universo. Al publicar información de compatibilidad explícita, las organizaciones habilitan una federación predecible, una adopción informada y un razonamiento automatizado, preservando la autonomía semántica, la gobernanza y la evolución a largo plazo de meta-modelos gestionados de forma independiente.