> Перевод даётся для удобства чтения. Нормативным является английский оригинал. # Валидация **Спецификация Мета-Вселенной** **Идентификатор документа:** MU-V2-ARCH-006 **Название:** Валидация - уровни смысловой проверки **Класс документа:** нормативный **Версия:** 2.0 (черновик) **Статус:** рабочий черновик **Нормативные ссылки:** MUC, [MMAS-Core](../02-architecture/MMAS-Core.md), [MMAS-Conformance](../02-architecture/MMAS-Conformance.md), [MMAS-Interchange](../02-architecture/MMAS-Interchange.md) **Информативные ссылки:** [Certification](../06-ecosystem/Certification.md), [Compatibility-Matrix](../06-ecosystem/Compatibility-Matrix.md), [Индекс требований](../REQUIREMENTS-INDEX.md) **Копирайт:** © Orkestron.AI **Лицензия:** Apache-2.0 --- # 1. Назначение Этот документ определяет **валидацию** в рамках Стандарта архитектуры мета-моделей (MMAS). Валидация - процесс проверки того, что мета-модель правильно построена, внутренне согласована, соблюдает Конституцию и готова участвовать в федерации. Это мост между архитектурной спецификацией и заслуживающей доверия смысловой моделью. --- # 2. Область действия Этот документ применяется к: - валидации отдельной мета-модели и её артефактов; - валидации импортированных внешних стандартов; - роли валидации на протяжении жизненного цикла мета-модели; - отношению валидации к [Соответствию](../02-architecture/MMAS-Conformance.md) и [Сертификации](../06-ecosystem/Certification.md). Он не предписывает конкретного инструмента или реализации валидации. --- # 3. Принципы - **Валидация слоиста.** Разные заботы проверяются на разных уровнях. - **Валидация непрерывна.** Модель проверяется на всём жизненном цикле, а не однократно. - **Валидация объяснима.** Каждый результат указывает, что проверялось и почему оно прошло или не прошло. - **Валидация независима от технологий.** Она проверяет семантику, а не хранение или транспорт. --- # 4. Измерения валидации Валидация отвечает на четыре всё более глубоких вопроса: 1. **Правильно ли построена** модель? (синтаксис и структура) 2. **Внутренне согласована** ли модель? (семантика) 3. **Соблюдает ли** модель **Конституцию**? (конституционное соблюдение) 4. **Может ли** модель **участвовать в федерации**? (совместимость) Эти вопросы отображаются на уровни валидации ниже. --- # 5. Уровни валидации Мета-Вселенная определяет слоистую модель валидации. Каждый уровень предполагает, что нижележащие уровни пройдены. | Уровень | Название | Что проверяет | |-------|------|----------| | **V0** | Синтаксис | Артефакты синтаксически корректны и разбираемы. | | **V1** | Структура | Модель соответствует иерархии композиции MMAS (Мета-Модель → Бандлы → Слои → Объекты → Свойства / Связи / События / Контракты / Проекции → Манифест). | | **V2** | Семантика | Модель внутренне согласована: идентичности уникальны, ссылки разрешаются, связи корректно типизированы, именование каноническое. | | **V3** | Конституция | Модель сохраняет каждую применимую статью [Конституции](../01-constitution/Meta-Universe-Constitution.md) (идентичность, происхождение, прослеживаемость, разделение проекций, контекст). | | **V4** | Федерация | Модель может участвовать в федерации: раскрывает публичные схемы, объявляет Смысловые контракты, поддерживает обмен Проекциями и согласование версий. | | **V5** | Время выполнения *(необязательно)* | Живые экземпляры модели остаются согласованными с моделью, а наблюдаемая реальность не противоречит заявленной семантике. | V0-V3 **обязательны** для любой соответствующей MMAS модели. V4 требуется для любой модели, участвующей в [федерации](../03-federation/MUFP.md). V5 НЕОБЯЗАТЕЛЕН и применяется к работающим реализациям. --- # 5a. Абстрактные процедуры тестирования Каждый уровень валидации задаётся набором **абстрактных процедур тестирования (ATP)** - проверок, которые соответствующий валидатор ОБЯЗАН выполнить. У каждой проверки есть устойчивый идентификатор (`V<уровень>-`), серьёзность при отказе и нормативные требования, которые она обеспечивает (по идентификатору из [Индекса требований](../REQUIREMENTS-INDEX.md)). ATP делают соответствие воспроизводимым: два валидатора, применившие эти проверки к одной модели, ОБЯЗАНЫ прийти к одинаковому вердикту. ## V0 - Синтаксис | Проверка | Что проверяет | При отказе | Что обеспечивает | |-------|----------|---------|----------| | `V0-01` | Документ разбирается как корректный JSON (или YAML, без потерь преобразуемый в него) в UTF-8. | Error | `MUIF-R02`, `MUIF-R03` | | `V0-02` | Поле `muif.version` присутствует и равно `"1.0"`. | Error | `MUIF-R01` | ## V1 - Структура | Проверка | Что проверяет | При отказе | Что обеспечивает | |-------|----------|---------|----------| | `V1-01` | Документ проходит проверку по `manifest.schema.json` и по схемам примитивов, на которые есть ссылки. | Error | `MUIF-R01` | | `V1-02` | Каждый примитив объявляет свой `muifType` и все обязательные поля. | Error | `MUIF-R01` | | `V1-03` | Иерархия композиции присутствует (`metaModel` плюс хотя бы один бандл или объект). | Warning | композиция `MMAS-CORE` | ## V2 - Семантика | Проверка | Что проверяет | При отказе | Что обеспечивает | |-------|----------|---------|----------| | `V2-01` | Все значения `id` уникальны внутри документа. | Error | `MUC-R03` | | `V2-02` | Каждая внутренняя ссылка (`relationship.source`/`target`, `event.subject`, `projection.subject`/`contract`) разрешается в объявленный `id` или в явно объявленную федеративную идентичность. | Error | `MUC-R15` | | `V2-03` | Каждое CSN соответствует каноническому шаблону, и каждое используемое пространство имён объявлено. | Error | `NAME` (CSN) | | `V2-04` | Каждое `relationship.kind` является объявленным или известным классом Профиля связи. | Warning | `REL` (профиль) | | `V2-05` | Самозаявленный `metaModel.fingerprint`, если он есть, совпадает с отпечатком, вычисленным по [MMAS-Interchange](../02-architecture/MMAS-Interchange.md). | Error | `MUIF-R12`, `MUIF-R18` | ## V3 - Конституция | Проверка | Что проверяет | При отказе | Что обеспечивает | |-------|----------|---------|----------| | `V3-01` | У каждого Объекта есть уникальная устойчивая идентичность. | Error | `MUC-R03`, `MUC-R04` | | `V3-02` | Каждый значимый факт объявляет владельца и происхождение. | Error | `MUC-R12`, `MUC-R13`, `MUC-R14` | | `V3-03` | Ни одна Проекция не переопределяет идентичность своего предмета. | Error | `MUC-R11` | | `V3-04` | Каждая раскрываемая вовне Проекция управляется Контрактом и объявляет цель. | Error | `MUC-R21`, `MUC-R22`, `MUC-R25` | | `V3-05` | Каждый смысловой факт существует внутри явного контекста. | Warning | `MUC-R08`, `MUC-R10` | | `V3-06` | Начало, владение, развитие и зависимости определимы. | Warning | `MUC-R15`, `MUC-R16` | ## V4 - Федерация | Проверка | Что проверяет | При отказе | Что обеспечивает | |-------|----------|---------|----------| | `V4-01` | Публичная схема обнаружима без раскрытия лежащих под ней данных. | Error | `MUC-R17`, `MUC-R18`, `MUC-R19`, `MUC-R20` | | `V4-02` | Для каждой Проекции, передаваемой вовне, объявлен Смысловой контракт. | Error | `MUC-R21` | | `V4-03` | Для согласования опубликованы версия и Смысловой отпечаток. | Error | `MUIF-R12` | | `V4-04` | Смысловые сопоставления присутствуют для каждого импортированного внешнего стандарта. | Warning | `EXT` (Смысловой пакет) | ## V5 - Время выполнения *(необязательно)* | Проверка | Что проверяет | При отказе | Что обеспечивает | |-------|----------|---------|----------| | `V5-01` | Живые экземпляры соответствуют заявленной модели. | Info | - | | `V5-02` | Нет смыслового дрейфа между заявленной моделью и наблюдаемой реальностью. | Info | - | Валидатор МОЖЕТ добавлять проверки, но ОБЯЗАН реализовать как минимум проверки серьёзности Error каждого уровня, который он заявляет. --- # 6. Классификация серьёзности Результат валидации ОБЯЗАН классифицировать каждую находку по серьёзности: - **Error** - нарушение, препятствующее соответствию на данном уровне. - **Warning** - замечание, не блокирующее соответствие, но которое СЛЕДУЕТ устранить. - **Info** - наблюдение или рекомендация. Модель проходит уровень только тогда, когда на этом уровне не осталось неустранённых **Error**. --- # 7. Отчёт валидации Прогон валидации ОБЯЗАН давать **отчёт валидации**, который включает: - идентичность и версию модели (с её [смысловым отпечатком](../02-architecture/Versioning.md)); - наивысший достигнутый уровень валидации; - каждую находку с серьёзностью, местом и объяснением; - идентичность валидатора и отметку времени валидации. Для каждого предпринятого уровня отчёт ОБЯЗАН фиксировать статус каждой проверки ATP (раздел 5a) по идентификатору проверки. Машиночитаемая структура задана в [`schemas/validation-report.schema.json`](../schemas/validation-report.schema.json); разобранный пример - [`examples/minimal-person/validation-report.json`](../examples/minimal-person/validation-report.json), где модель minimal-person проходит V0-V4 и фиксируется её проверенный Смысловой отпечаток. Отчёт сам по себе является прослеживаемым артефактом и МОЖЕТ упоминаться в [Заявлении о соответствии](../02-architecture/MMAS-Conformance.md) или в [Сертификате](../06-ecosystem/Certification.md). --- # 8. Валидация импортированных стандартов Когда мета-модель импортирует внешний стандарт как [Смысловой пакет](../02-architecture/Extension-Model.md), импортированный пакет ОБЯЗАН быть проверен: - его объявленные пространства имён и выбранные объекты разрешаются; - локальные расширения не изменяют импортированную модель запрещёнными способами; - смысловые сопоставления правильно построены; - импортированная версия попадает в объявленный диапазон совместимости. --- # 9. Непрерывная валидация Валидация ОБЯЗАНА применяться на всём жизненном цикле мета-модели: - при создании, до публикации; - при каждом изменении, в рамках [Процесса изменений](../01-constitution/Change-Process.md); - при импорте внешнего стандарта или другой модели; - перед установлением или изменением [федерации](../03-federation/Federation-Lifecycle.md). Изменение, понижающее достигнутый уровень валидации модели, ОБЯЗАНО считаться значимым изменением в рамках Процесса изменений. --- # 9a. Обнаружение дрейфа результата Уровни V0-V4 проверяют, что модель *корректна*. Они не проверяют, что она по-прежнему *достигает своей цели*. Модель может быть безупречно корректной, все проверки зелёные, и при этом описываемая ею реальность уходит в сторону от замысла, ради которого модель строилась. **Дрейф результата** - расхождение между заявленной целью или гипотезой (хранимой в модели, например заявленным намерением Объекта или бизнес-гипотезой) и наблюдаемым результатом ([горячим описательным фактом](../04-core-concepts/Virtual-Projection.md), прочитанным через Виртуальную проекцию). Он обнаруживается фоновым аудитом - «призрачным» аудитором, который непрерывно сравнивает одно с другим: > *Код корректен, тесты зелёные, но метрика, ради улучшения которой делалось изменение, падает.* → поднять сигнал дрейфа результата: технически соответствует, цель не достигнута; гипотезу модели СЛЕДУЕТ пересмотреть. Обнаружение дрейфа результата - часть необязательной валидации **V5 (время выполнения)**. Оно НЕ ДОЛЖНО блокировать структурное соответствие (дрейфующая модель всё ещё корректна), но обнаруженный дрейф СЛЕДУЕТ фиксировать как [Событие](../04-core-concepts/Event.md) и доводить до владельца. Оно соединяет [граф происхождения](../02-architecture/Provenance-Graph.md) (*какому замыслу это служит?*) с живыми результатами (*достигается ли этот замысел?*). --- # 10. Отношение к соответствию и сертификации Валидация, соответствие и сертификация различны: - **Валидация** проверяет модель по определённым здесь уровням. - **[Соответствие](../02-architecture/MMAS-Conformance.md)** объявляет, на какие стандарты и уровни зрелости претендует модель (в частности, уровень MMAS **A4 Проверенная** требует прохождения V0-V3, а также V4, где применима федерация). - **[Сертификация](../06-ecosystem/Certification.md)** - независимое подтверждение этих заявлений. --- # 11. Архитектурные инварианты - Валидация ОБЯЗАНА быть слоистой (от V0 до V5). - Более высокий уровень ОБЯЗАН предполагать, что нижние уровни пройдены. - Модель НЕ ДОЛЖНА заявлять уровень валидации, которого она не достигла. - Каждый результат валидации ОБЯЗАН быть объяснимым и прослеживаемым. --- # Дальнейшие направления Определённая здесь модель валидации проверяет одну мета-модель. Ожидается несколько более широких форм проверки, которые составили бы отдельную **рамку смысловой валидации (SVF)**: - **межмодельная валидация** - согласованность нескольких мета-моделей (например, мета-модель Сотрудника ↔ мета-модель Подразделения ↔ мета-модель Проекта); - **межвселенская валидация** - согласованность федерации между независимыми Вселенными; - **обнаружение дрейфа во время выполнения** - расхождение между заявленной моделью и реальным состоянием мира; - **валидация рассуждений ИИ** - проверка того, что выводы ИИ-агента не противоречат ограничениям и семантике модели. Всё это выходит за пределы базовой валидации MMAS и зафиксировано здесь как кандидаты в будущие стандарты (см. [Roadmap](../06-ecosystem/Roadmap.md)). --- # Заключение > Валидация - это то, как мета-модель зарабатывает доверие: не заявлением, а прохождением, уровень за уровнем, проверок, доказывающих, что она правильно построена, согласована, законна и готова к федерации.