> Esta traducción se ofrece por comodidad. El texto normativo es el original en inglés. # Proceso de cambios **Especificación del Meta-Universo** **ID del documento:** MU-V2-CONST-003 **Título:** Proceso de cambios **Clase de documento:** normativo **Versión:** 2.0 (borrador) **Estado:** borrador de trabajo **Referencias normativas:** Constitución del Meta-Universo (MUC), MMAS, MUFP **Referencias informativas:** Governance.md, Conformance.md **Copyright:** © Orkestron.AI **Licencia:** Apache-2.0 --- # 1. Propósito Este documento define el proceso normativo para hacer evolucionar la familia de estándares del Meta-Universo. El objetivo es permitir la mejora continua preservando la estabilidad, la interoperabilidad y la trazabilidad a largo plazo. --- # 2. Alcance Este proceso se aplica a todas las especificaciones normativas de la familia de estándares del Meta-Universo, incluidas: - Constitución del Meta-Universo (MUC) - Estándar de arquitectura de meta-modelos (MMAS) - Protocolo de federación del Meta-Universo (MUFP) - Futuras extensiones normativas --- # 3. Principios rectores Todo cambio DEBERÁ seguir estos principios: - La Constitución antes que la implementación. - Explícito antes que implícito. - Trazabilidad por diseño. - Compatibilidad hacia atrás siempre que sea practicable. - Transparencia. - Revisión por la comunidad. - Evolución versionada. - Ningún cambio semántico silencioso. --- # 4. Ciclo de vida del cambio Todo cambio DEBERÁ pasar por el siguiente ciclo de vida: 1. Propuesta 2. Discusión 3. Análisis de impacto 4. Borrador de especificación 5. Revisión 6. Aprobación 7. Publicación 8. Adopción 9. Obsolescencia (opcional) 10. Retirada (opcional) Ninguna etapa DEBERÁ omitirse en los cambios normativos. --- # 5. Solicitud de cambio (CR) Toda modificación propuesta DEBERÁ representarse como una Solicitud de cambio (CR). Una CR DEBERÍA contener: - identificador único; - título; - motivación; - documentos afectados; - justificación; - beneficios esperados; - evaluación de compatibilidad; - consideraciones de migración; - impacto en la implementación; - autor; - fecha. --- # 6. Categorías de cambio Los cambios DEBERÍAN clasificarse en una de las siguientes categorías: ### Editorial Formato, redacción y aclaraciones sin cambiar la semántica. ### Correctivo Corrección de defectos o ambigüedades. ### Evolutivo Nuevas capacidades que preservan la compatibilidad. ### Rupturista Cambios semánticos que rompen la compatibilidad de forma intencionada. Los cambios rupturistas DEBERÁN exigir una justificación explícita. --- # 6a. Clasificación de cambios semánticos El eje Editorial / Correctivo / Evolutivo / Rupturista de la Sección 6 describe el **impacto** de un cambio. DEBERÍA complementarse con un segundo eje que describa el **sujeto semántico** del cambio, es decir, *qué tipo de significado se ve afectado*. Ese segundo eje es la **Clasificación de cambios semánticos**. Un cambio en la base normativa de reglas DEBERÁ superar además la [Comprobación de consistencia de políticas](../02-architecture/Policy-Consistency.md) previa a la fusión: un cambio que hiciera lógicamente insatisfacible el conjunto de reglas NO DEBERÁ fusionarse. Toda Solicitud de cambio DEBERÍA declarar uno o más tipos de cambio semántico: - **Cambio de estructura del modelo** - altera la estructura del meta-modelo (Objetos, Relaciones, Eventos, la forma de las definiciones). - **Cambio de significado/semántica** - altera el significado de un concepto existente sin cambiar necesariamente su estructura. - **Cambio de reglas de federación** - altera cómo se federan los Universos soberanos, las reglas de los perfiles de federación o las garantías del protocolo. - **Cambio de contrato** - altera los Contratos semánticos: propósito, permisos, responsabilidades o condiciones de divulgación. - **Cambio de comportamiento de proyección** - altera cómo se proyectan los Objetos en un contexto dado. - **Cambio de requisitos de conformidad** - altera lo que se exige para ajustarse a un estándar en cualquier nivel. Los dos ejes son ortogonales: un mismo cambio lleva a la vez una categoría de impacto y uno o más tipos de cambio semántico (por ejemplo, un cambio *Evolutivo* / *de estructura del modelo*, o un cambio *Rupturista* / *de significado/semántica*). Declarar el tipo semántico de forma explícita permite a los agentes de IA razonar sobre el cambio. Un agente DEBERÍA poder leer una Solicitud de cambio, determinar sus tipos de cambio semántico, evaluar el impacto de compatibilidad resultante sobre los documentos afectados y proponer pasos de migración allí donde la compatibilidad no pueda preservarse. Una clasificación legible por máquina convierte así la gestión de cambios en un proceso analizable y semiautomatizable en lugar de una revisión puramente manual. --- # 7. Evaluación de compatibilidad Toda Solicitud de cambio DEBERÁ incluir una evaluación de compatibilidad. Los resultados posibles incluyen: - Totalmente compatible - Compatible hacia atrás - Compatible hacia delante - Requiere migración - Rupturista --- # 8. Regla de congelación Los documentos aprobados entran en el estado Congelado. Los documentos congelados: - se convierten en referencias normativas; - NO DEBERÁN recibir modificaciones silenciosas; - solo PUEDEN cambiar mediante una Solicitud de cambio publicada; - DEBERÁN preservar el historial completo de revisiones. --- # 9. Versionado Toda especificación publicada DEBERÁ declarar su versión. Las nuevas versiones DEBERÁN publicarse en lugar de reemplazar a las versiones normativas anteriores. Las versiones históricas DEBERÍAN permanecer públicamente disponibles. --- # 10. Obsolescencia Las funcionalidades PUEDEN declararse obsoletas antes de su eliminación. Un aviso de obsolescencia DEBERÍA especificar: - funcionalidad afectada; - sustituto; - versión de declaración de obsolescencia; - versión prevista de eliminación. La obsolescencia DEBERÍA preceder a cualquier eliminación rupturista. --- # 11. Migración Siempre que la compatibilidad no pueda preservarse, la nueva especificación DEBERÁ ir acompañada de orientación de migración. La orientación de migración DEBERÍA incluir: - conceptos afectados; - transformaciones necesarias; - estrategia de compatibilidad; - ejemplos. --- # 12. Publicación Toda versión publicada DEBERÁ incluir: - número de versión; - fecha de publicación; - estado; - resumen de cambios; - declaración de compatibilidad; - referencias normativas. --- # 13. Auditabilidad La evolución de todo documento normativo DEBERÁ seguir siendo auditable. DEBERÁ ser posible determinar: - por qué se produjo un cambio; - quién lo propuso; - cuándo fue aceptado; - qué versión lo introdujo. --- # Direcciones futuras Este documento fija la forma *constitucional* de la Clasificación de cambios semánticos: los tipos de cambio y la exigencia de declararlos. El **modelo detallado** pertenece al Estándar de arquitectura de meta-modelos (MMAS): la taxonomía formal de los tipos de cambio semántico, sus reglas precisas de compatibilidad y el esquema legible por máquina que permite a los agentes de IA calcular el impacto de compatibilidad y generar migraciones. Un futuro Estándar de migración semántica (SMS) se apoyaría en esa taxonomía para normalizar cómo se expresan y aplican las migraciones. La Constitución establece el eje; MMAS lo hace operativo. --- # Principio final El Meta-Universo evoluciona mediante cambios transparentes, versionados y trazables. La estabilidad no se preserva impidiendo la evolución, sino haciendo que cada evolución sea explícita, revisable y reproducible.