> Esta traducción se ofrece por comodidad. El texto normativo es el original en inglés. # Validación **Especificación del Meta-Universo** **ID del documento:** MU-V2-ARCH-006 **Título:** Validación - niveles de verificación semántica **Clase de documento:** normativo **Versión:** 2.0 (borrador) **Estado:** borrador de trabajo **Referencias normativas:** MUC, [MMAS-Core](../02-architecture/MMAS-Core.md), [MMAS-Conformance](../02-architecture/MMAS-Conformance.md), [MMAS-Interchange](../02-architecture/MMAS-Interchange.md) **Referencias informativas:** [Certification](../06-ecosystem/Certification.md), [Compatibility-Matrix](../06-ecosystem/Compatibility-Matrix.md), [Índice de requisitos](../REQUIREMENTS-INDEX.md) **Copyright:** © Orkestron.AI **Licencia:** Apache-2.0 --- # 1. Propósito Este documento define la **validación** dentro del Estándar de arquitectura de meta-modelos (MMAS). La validación es el proceso de verificar que un meta-modelo está bien formado, es internamente coherente, cumple la Constitución y está listo para participar en una federación. Es el puente entre una especificación arquitectónica y un modelo semántico digno de confianza. --- # 2. Alcance Este documento se aplica a: - la validación de un meta-modelo concreto y de sus artefactos; - la validación de los estándares externos importados; - el papel de la validación a lo largo del ciclo de vida del meta-modelo; - la relación entre validación y [Conformidad](../02-architecture/MMAS-Conformance.md) y [Certificación](../06-ecosystem/Certification.md). No impone una herramienta ni una implementación de validación concretas. --- # 3. Principios - **La validación es por capas.** Cada preocupación se verifica en un nivel distinto. - **La validación es continua.** Un modelo se valida a lo largo de su ciclo de vida, no una sola vez. - **La validación es explicable.** Todo resultado identifica qué se comprobó y por qué pasó o falló. - **La validación es independiente de la tecnología.** Verifica semántica, no almacenamiento ni transporte. --- # 4. Dimensiones de la validación La validación responde a cuatro preguntas progresivamente más profundas: 1. ¿Está el modelo **bien formado**? (sintaxis y estructura) 2. ¿Es el modelo **internamente coherente**? (semántica) 3. ¿**Obedece** el modelo **la Constitución**? (cumplimiento constitucional) 4. ¿Puede el modelo **participar en una federación**? (interoperabilidad) Estas preguntas se corresponden con los niveles de validación siguientes. --- # 5. Niveles de validación El Meta-Universo define un modelo de validación por capas. Cada nivel asume que los inferiores se han superado. | Nivel | Nombre | Verifica | |-------|------|----------| | **V0** | Sintaxis | Los artefactos son sintácticamente válidos y analizables. | | **V1** | Estructural | El modelo se ajusta a la jerarquía de composición MMAS (Meta-Modelo → Bundles → Capas → Objetos → Propiedades / Relaciones / Eventos / Contratos / Proyecciones → Manifiesto). | | **V2** | Semántica | El modelo es internamente coherente: las identidades son únicas, las referencias resuelven, las relaciones están bien tipadas, los nombres son canónicos. | | **V3** | Constitucional | El modelo preserva todos los artículos aplicables de la [Constitución](../01-constitution/Meta-Universe-Constitution.md) (identidad, procedencia, trazabilidad, separación de proyecciones, contexto). | | **V4** | Federación | El modelo puede participar en una federación: expone esquemas públicos, declara Contratos semánticos, admite intercambio de Proyecciones y negociación de versiones. | | **V5** | Ejecución *(opcional)* | Las instancias vivas del modelo siguen siendo coherentes con él y la realidad observada no contradice la semántica declarada. | V0-V3 son **obligatorios** para cualquier modelo conforme con MMAS. V4 se exige a todo modelo que participe en una [federación](../03-federation/MUFP.md). V5 es OPCIONAL y se aplica a implementaciones en ejecución. --- # 5a. Procedimientos de prueba abstractos Cada nivel de validación se define mediante un conjunto de **procedimientos de prueba abstractos (ATP)**: comprobaciones que un validador conforme DEBERÁ realizar. Cada comprobación tiene un identificador estable (`V-`), una severidad en caso de fallo y los requisitos normativos que impone (por ID, del [Índice de requisitos](../REQUIREMENTS-INDEX.md)). Los ATP hacen reproducible la conformidad: dos validadores que apliquen estas comprobaciones al mismo modelo DEBERÁN llegar al mismo veredicto. ## V0 - Sintaxis | Comprobación | Verifica | Si falla | Impone | |-------|----------|---------|----------| | `V0-01` | El documento se analiza como JSON bien formado (o YAML convertible a él sin pérdidas) en UTF-8. | Error | `MUIF-R02`, `MUIF-R03` | | `V0-02` | `muif.version` está presente y vale `"1.0"`. | Error | `MUIF-R01` | ## V1 - Estructural | Comprobación | Verifica | Si falla | Impone | |-------|----------|---------|----------| | `V1-01` | El documento valida contra `manifest.schema.json` y los esquemas de primitivos referenciados. | Error | `MUIF-R01` | | `V1-02` | Cada primitivo declara su `muifType` y todos los campos obligatorios. | Error | `MUIF-R01` | | `V1-03` | La Jerarquía de composición está presente (un `metaModel` más al menos un bundle u objeto). | Warning | composición `MMAS-CORE` | ## V2 - Semántica | Comprobación | Verifica | Si falla | Impone | |-------|----------|---------|----------| | `V2-01` | Todos los valores `id` son únicos dentro del documento. | Error | `MUC-R03` | | `V2-02` | Toda referencia interna (`relationship.source`/`target`, `event.subject`, `projection.subject`/`contract`) resuelve a un `id` declarado o a una identidad federada declarada explícitamente. | Error | `MUC-R15` | | `V2-03` | Todo CSN se ajusta al patrón canónico y cada espacio de nombres usado está declarado. | Error | `NAME` (CSN) | | `V2-04` | Todo `relationship.kind` es una clase de Perfil de Relación declarada o conocida. | Warning | `REL` (perfil) | | `V2-05` | Un `metaModel.fingerprint` autodeclarado, si existe, coincide con la huella calculada según [MMAS-Interchange](../02-architecture/MMAS-Interchange.md). | Error | `MUIF-R12`, `MUIF-R18` | ## V3 - Constitucional | Comprobación | Verifica | Si falla | Impone | |-------|----------|---------|----------| | `V3-01` | Todo Objeto tiene una identidad única y persistente. | Error | `MUC-R03`, `MUC-R04` | | `V3-02` | Todo hecho significativo declara propietario y procedencia. | Error | `MUC-R12`, `MUC-R13`, `MUC-R14` | | `V3-03` | Ninguna Proyección redefine la identidad de su sujeto. | Error | `MUC-R11` | | `V3-04` | Toda Proyección expuesta al exterior está gobernada por un Contrato y declara un propósito. | Error | `MUC-R21`, `MUC-R22`, `MUC-R25` | | `V3-05` | Todo hecho semántico existe dentro de un contexto explícito. | Warning | `MUC-R08`, `MUC-R10` | | `V3-06` | El origen, la propiedad, la evolución y las dependencias son determinables. | Warning | `MUC-R15`, `MUC-R16` | ## V4 - Federación | Comprobación | Verifica | Si falla | Impone | |-------|----------|---------|----------| | `V4-01` | El esquema público es descubrible sin exponer los datos subyacentes. | Error | `MUC-R17`, `MUC-R18`, `MUC-R19`, `MUC-R20` | | `V4-02` | Se declara un Contrato semántico para toda Proyección intercambiada al exterior. | Error | `MUC-R21` | | `V4-03` | Se publican una versión y una huella semántica para la negociación. | Error | `MUIF-R12` | | `V4-04` | Existen correspondencias semánticas para cada estándar externo importado. | Warning | `EXT` (paquete semántico) | ## V5 - Ejecución *(opcional)* | Comprobación | Verifica | Si falla | Impone | |-------|----------|---------|----------| | `V5-01` | Las instancias vivas se ajustan al modelo declarado. | Info | - | | `V5-02` | No hay deriva semántica entre el modelo declarado y la realidad observada. | Info | - | Un validador PUEDE añadir comprobaciones, pero DEBERÁ implementar al menos las de severidad Error de cada nivel que declare verificar. --- # 6. Clasificación de severidad Un resultado de validación DEBERÁ clasificar cada hallazgo por severidad: - **Error** - una infracción que impide la conformidad en el nivel correspondiente. - **Warning** - una preocupación que no bloquea la conformidad pero que DEBERÍA atenderse. - **Info** - una observación o recomendación. Un modelo supera un nivel solo cuando no queda ningún **Error** sin resolver en ese nivel. --- # 7. Informe de validación Una ejecución de validación DEBERÁ producir un **informe de validación** que incluya: - la identidad y versión del modelo (con su [huella semántica](../02-architecture/Versioning.md)); - el nivel de validación más alto alcanzado; - cada hallazgo, con severidad, ubicación y explicación; - la identidad del validador y la marca de tiempo de la validación. Para cada nivel intentado, el informe DEBERÁ registrar el estado de cada comprobación ATP (Sección 5a) por su ID. La estructura legible por máquina la define [`schemas/validation-report.schema.json`](../schemas/validation-report.schema.json); un ejemplo resuelto es [`examples/minimal-person/validation-report.json`](../examples/minimal-person/validation-report.json), que informa del modelo minimal-person superando V0-V4 y registra su huella semántica verificada. El informe es en sí mismo un artefacto trazable y PUEDE ser referenciado por una [Declaración de conformidad](../02-architecture/MMAS-Conformance.md) o un [Certificado](../06-ecosystem/Certification.md). --- # 8. Validación de estándares importados Cuando un meta-modelo importa un estándar externo como [paquete semántico](../02-architecture/Extension-Model.md), el paquete importado DEBERÁ validarse: - sus espacios de nombres declarados y los objetos seleccionados resuelven; - las extensiones locales no modifican el modelo importado de formas prohibidas; - las correspondencias semánticas están bien formadas; - la versión importada cae dentro del rango compatible declarado. --- # 9. Validación continua La validación DEBERÁ aplicarse a lo largo del ciclo de vida del meta-modelo: - al crearlo, antes de su publicación; - en cada cambio, como parte del [Proceso de cambios](../01-constitution/Change-Process.md); - al importar un estándar externo u otro modelo; - antes de establecer o modificar una [federación](../03-federation/Federation-Lifecycle.md). Un cambio que rebaje el nivel de validación alcanzado por un modelo DEBERÁ tratarse como un cambio significativo dentro del Proceso de cambios. --- # 9a. Detección de deriva de resultados Los niveles V0-V4 verifican que un modelo es *correcto*. No verifican que siga *cumpliendo su propósito*. Un modelo puede ser perfectamente válido, con todas las comprobaciones en verde, mientras la realidad que describe se aparta de la intención con la que se construyó. La **deriva de resultados** es la divergencia entre un propósito o hipótesis declarados (contenidos en el modelo, por ejemplo la intención declarada de un Objeto o una hipótesis de negocio) y el resultado observado (un [hecho descriptivo caliente](../04-core-concepts/Virtual-Projection.md) leído a través de una Proyección virtual). La detecta una auditoría de fondo, un auditor «fantasma», que compara continuamente ambos: > *El código es válido, las pruebas están en verde, pero la métrica que el cambio pretendía mejorar está cayendo.* → emitir una señal de deriva de resultados: técnicamente conforme, propósito incumplido; la hipótesis del modelo DEBERÍA revisarse. La detección de deriva de resultados forma parte de la validación **V5 (Ejecución)**, que es opcional. NO DEBERÁ bloquear la conformidad estructural (un modelo con deriva sigue siendo válido), pero una deriva detectada DEBERÍA registrarse como [Evento](../04-core-concepts/Event.md) y ponerse en conocimiento del propietario. Conecta el [Grafo de procedencia](../02-architecture/Provenance-Graph.md) (*¿a qué intención sirve esto?*) con los resultados vivos (*¿se está cumpliendo esa intención?*). --- # 10. Relación con la conformidad y la certificación Validación, conformidad y certificación son cosas distintas: - La **validación** verifica el modelo frente a los niveles aquí definidos. - La **[conformidad](../02-architecture/MMAS-Conformance.md)** declara a qué estándares y niveles de madurez aspira el modelo (en particular, el nivel MMAS **A4 Validado** exige superar V0-V3, y V4 cuando aplica la federación). - La **[certificación](../06-ecosystem/Certification.md)** es la confirmación independiente de esas declaraciones. --- # 11. Invariantes arquitectónicos - La validación DEBERÁ ser por capas (de V0 a V5). - Un nivel superior DEBERÁ asumir que los inferiores se han superado. - Un modelo NO DEBERÁ declarar un nivel de validación que no ha alcanzado. - Todo resultado de validación DEBERÁ ser explicable y trazable. --- # Direcciones futuras El modelo de validación aquí definido verifica un único meta-modelo. Se anticipan varias formas más amplias de verificación que conformarían un **Marco de validación semántica (SVF)** propio: - **validación entre modelos** - coherencia entre varios meta-modelos (p. ej. MM de Empleado ↔ MM de Departamento ↔ MM de Proyecto); - **validación entre universos** - coherencia de una federación entre Universos independientes; - **detección de deriva en ejecución** - divergencia entre un modelo declarado y el estado real del mundo; - **validación del razonamiento de IA** - verificación de que las conclusiones de un agente de IA no contradicen las restricciones y la semántica del modelo. Todo ello va más allá de la validación MMAS de base y queda recogido aquí como candidato a estándar futuro (véase [Roadmap](../06-ecosystem/Roadmap.md)). --- # Declaración final > La validación es la forma en que un meta-modelo se gana la confianza: no por afirmación, sino superando, nivel tras nivel, las comprobaciones que demuestran que está bien formado, es coherente, es conforme a la ley y está listo para federarse.