> Перевод даётся для удобства чтения. Нормативным является английский оригинал. # Пакет MMAS **Спецификация Мета-Вселенной** **Идентификатор документа:** MU-V2-ARCH-007 **Название:** Стандарт архитектуры мета-моделей - структура репозитория и пакета **Класс документа:** нормативный **Версия:** 2.0 (черновик) **Статус:** рабочий черновик **Нормативные ссылки:** Конституция Мета-Вселенной (MUC), MMAS-Core, Versioning **Информативные ссылки:** Extension-Model, MMAS-Conformance, Протокол федерации Мета-Вселенной (MUFP), Model-Traversal-and-Layout, Data-Mastership **Копирайт:** © Orkestron.AI **Лицензия:** Apache-2.0 --- # 1. Назначение Этот документ определяет каноническую структуру репозитория и пакета для Мета-Моделей, соответствующих Стандарту архитектуры мета-моделей (MMAS). Цель в том, чтобы у каждой Мета-Модели была предсказуемая организация, понятная и людям, и ИИ-агентам. --- # 2. Область действия Эта спецификация применяется к: - репозиториям Мета-Моделей; - распространяемым пакетам Мета-Моделей; - манифестам репозиториев; - бандлам; - слоям; - вспомогательным материалам; - примерам и документации. Реализации МОГУТ использовать дополнительные файлы при условии, что они не нарушают эту спецификацию. --- # 3. Принципы проектирования Соответствующий пакет ОБЯЗАН быть: - модульным; - самоописывающим; - версионированным; - прослеживаемым; - машиночитаемым; - читаемым человеком; - пригодным для федерации. Структура репозитория ОБЯЗАНА отражать смысловую архитектуру, а не технологию реализации. --- # 4. Каноническая структура репозитория Каждой Мета-Модели СЛЕДУЕТ следовать канонической структуре ниже. ```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/ ``` Эквивалентные раскладки МОГУТ использоваться, если смысловая организация сохранена. Контракт обхода этой структуры (детерминированный порядок обхода бандлов и слоёв, полная классификация файлов, проверка полноты) и зарезервированные значения `BOOTSTRAP.md`, `canon/`, `raw/` и `artifacts/` нормативно определены в [Model-Traversal-and-Layout](Model-Traversal-and-Layout.md). Реестр `sources.yaml` и правила решения о том, кто является мастером набора данных - модель или внешняя система (вики, трекер, база данных), - определены в [Data-Mastership](Data-Mastership.md). --- # 5. Манифест репозитория Каждый репозиторий ОБЯЗАН содержать манифест. Манифесту СЛЕДУЕТ объявлять: - идентификатор; - имя; - версию; - владельца; - пространство имён; - поддерживаемую версию MMAS; - поддерживаемую версию MUC; - поддерживаемую версию MUFP; - импортированные стандарты; - заявление о совместимости. Манифест - основная точка входа для автоматического обнаружения. --- # 6. Структура бандла Каждому Бандлу СЛЕДУЕТ содержать: - манифест бандла; - документацию; - слои; - необязательные примеры. Бандлы ОБЯЗАНЫ иметь единственную смысловую зону ответственности. --- # 7. Структура слоя Каждому Слою СЛЕДУЕТ содержать: - манифест слоя; - определения объектов; - связи; - события (если применимо); - контракты (если применимо); - профили проекций (если применимо). Слоям СЛЕДУЕТ оставаться понятными по отдельности. --- # 8. Документация Каждому публичному репозиторию СЛЕДУЕТ включать: - README; - обзор архитектуры; - историю изменений; - сведения о лицензии; - руководство для участников (необязательно). Документация ОБЯЗАНА оставаться синхронной с опубликованной версией. --- # 9. Примеры Референсные примеры СЛЕДУЕТ хранить отдельно от нормативных спецификаций. Примеры НЕ ДОЛЖНЫ переопределять нормативную семантику. Артефактам-примерам СЛЕДУЕТ указывать версию спецификации, на которую они рассчитаны. --- # 10. Импортированные стандарты Импортированные смысловые модели СЛЕДУЕТ изолировать в каталоге imports/. Сопоставления между импортированными и локальными понятиями СЛЕДУЕТ хранить в mappings/. Импортированные артефакты ОБЯЗАНЫ сохранять ссылки на свой исходный источник и версию. --- # 11. Метаданные репозитория Репозиторию СЛЕДУЕТ раскрывать машиночитаемые метаданные, достаточные для обнаружения. Рекомендуемые метаданные: - смысловой отпечаток; - поддерживаемые профили; - контрольную сумму пакета; - дату публикации; - URL репозитория; - цифровую подпись (необязательно). --- # 12. Упаковка Распространяемый пакет MMAS ОБЯЗАН сохранять: - структуру каталогов; - манифесты; - идентификаторы; - смысловые ссылки; - метаданные версии. Формат упаковки зависит от реализации. Примеры: Git-репозитории, архивы или реестры. --- # 13. Смысловой пакет распространения (SDP) Раздел 4 задаёт каноническую раскладку *репозитория*, но для федерации нужна переносимая публикуемая единица *распространения*. **Смысловой пакет распространения (SDP)** и есть эта единица: единый подписанный самодостаточный артефакт, несущий Мета-Модель (или её ограниченную часть) вместе со всем, что нужно, чтобы проверить, разместить и использовать её в другой вселенной. Это аналог артефакта Maven, npm или OCI, но для смысловых моделей, а не для кода или образов. Соответствующий SDP ОБЯЗАН содержать: - **манифест** (`manifest.yaml`) - идентичность, версию, владельца, пространство имён и поддерживаемые версии стандартов, как в разделе 5; - **бандлы и слои**, составляющие упакованную Мета-Модель; - **[смысловой отпечаток](Versioning.md)** пакета, вычисленный по нормализованной смысловой структуре; - **цифровую подпись**, связывающую содержимое с публикатором; - **заявление о соответствии** с указанием соответствия MUC, MMAS и MUFP (см. [MMAS-Conformance](MMAS-Conformance.md)); - список **импортированных стандартов** и соответствующие [смысловые пакеты](Extension-Model.md); - **смысловые сопоставления** между импортированными и локальными понятиями; - необязательные **проекции** и **примеры**, помогающие толкованию и не переопределяющие семантику. Показательный SDP в развёрнутом виде выглядит так: ```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 ``` SDP ОБЯЗАН быть самопроверяемым: потребитель ОБЯЗАН иметь возможность заново вычислить смысловой отпечаток по содержащейся структуре, сверить его с `fingerprint.sha256` и проверить подпись, прежде чем доверять пакету. SDP - это форма той же композиции, что лежит в репозитории, но пригодная для передачи и хранения; он НЕ ДОЛЖЕН переопределять семантику, только упаковывать её. --- # 14. Развитие репозитория Структуре репозитория СЛЕДУЕТ развиваться совместимо. Структурные изменения, влияющие на обнаружение или совместимость, ОБЯЗАНЫ версионироваться и документироваться. Структурные изменения СЛЕДУЕТ сопровождать руководством по миграции. --- # 15. Требования ИИ-нативности Соответствующему репозиторию СЛЕДУЕТ позволять ИИ-агентам: - обнаружить манифест; - перечислить бандлы и слои; - разрешить импорты; - определить зависимости; - найти примеры; - определить соответствие; - перемещаться по модели без знаний, специфичных для реализации. Раскладке репозитория СЛЕДУЕТ минимизировать неоднозначность для автоматического рассуждения. --- # 16. Архитектурные инварианты Организация репозитория ОБЯЗАНА сохранять: - смысловую идентичность; - прослеживаемость; - владение; - целостность версий; - соблюдение Конституции. Структура репозитория НИКОГДА не должна переопределять смысловое значение. --- # 17. Дальнейшие направления Смысловой пакет распространения делает Мета-Модели переносимыми; естественный следующий шаг - сделать их **обнаружимыми и разрешимыми в масштабе**. Дальнейшее направление в том, чтобы слой экосистемы (`06-ecosystem`) работал как **реестр смысловых пакетов**: сервис с поддержкой федерации, индексирующий опубликованные SDP и [смысловые пакеты](Extension-Model.md) по идентичности, [смысловому отпечатку](Versioning.md), уровню соответствия и диапазону совместимых версий и разрешающий зависимости и миграции по запросу - аналог Maven Central, npm или реестра OCI для смыслового знания. Такой реестр стандартизировал бы публикацию, доверие к подписи, поиск и получение, чтобы любая вселенная могла найти, проверить и принять Мета-Модель без внепротокольных договорённостей. --- # Заключение Структура пакета MMAS - каноническая физическая организация Мета-Модели. Её назначение в том, чтобы делать смысловые модели обнаружимыми, переиспользуемыми, расширяемыми и совместимыми между репозиториями, организациями и ИИ-агентами, оставаясь независимой от технологий реализации.