> Перевод даётся для удобства чтения. Нормативным является английский оригинал. # Мастерство данных **Спецификация Мета-Вселенной** **Идентификатор документа:** MU-V2-ARCH-018 **Название:** Стандарт архитектуры мета-моделей - мастерство данных и системы записи **Класс документа:** нормативный **Версия:** 2.0 (черновик) **Статус:** рабочий черновик **Нормативные ссылки:** MMAS-Core, MMAS-Package, Model-Traversal-and-Layout, Traceability **Информативные ссылки:** Synchronization, Extension-Model, Provenance-Graph, AI-Agent-Guide **Копирайт:** © Orkestron.AI **Лицензия:** Apache-2.0 --- # 1. Назначение Мета-Модель редко живёт одна. То же знание часто существует ещё и в вики (Confluence), в трекере (Jira, ClickUp), в CRM, в базе данных или в хранилище документов, и эти копии правят люди, которые модель никогда не открывают. Этот документ отвечает на единственный вопрос, решающий, будет такое сосуществование порядком или хаосом: **кто мастер для каждого набора данных - Мета-Модель или внешняя система?** Он определяет: - **систему записи (SoR)**: единственное место, где истина набора данных создаётся; - три законных **схемы мастерства** (мастерство модели, внешнее мастерство, разделённое); - **реестр мастерства** (`sources.yaml`): машиночитаемое объявление всего перечисленного; - правила потока, свежести, конфликтов и записи, вытекающие из каждой схемы. Без такого объявления читатель не может знать, авторитетен ли найденный в модели факт или это, возможно, протухшее зеркало, а агент не может знать, куда писать исправление. С ним оба вопроса получают механический ответ. --- # 2. Область действия Эта спецификация управляет отношением между Мета-Моделью и **операционными системами внутри того же домена управления**: вики, трекерами, базами данных, файловыми хранилищами, бизнес-приложениями. Она не управляет: - **федерацией между суверенными вселенными** - это [Synchronization](../03-federation/Synchronization.md) и MUFP (у каждого участника свои системы записи; федерация никогда не передаёт мастерство); - **импортированными внешними стандартами** (Schema.org, FHIR, словари ISO) - они всегда мастерятся снаружи своими органами по стандартизации и рассматриваются в [Extension-Model](Extension-Model.md). --- # 3. Принципы проектирования - **Один мастер на набор данных.** У каждого набора данных ровно одна система записи. «Оба места как бы авторитетны» несоответствующе по определению. - **Мастерство объявляется, а не выводится.** Никакому читателю не следует выводить полномочия из имён папок, привычек или командных преданий. - **Поток следует за мастерством.** Данные движутся *от* мастера *к* его копиям; копия никогда не записывается иначе как этим потоком. - **Копии одноразовы.** Любую немастерскую копию можно удалить и пересобрать из мастера без потерь. - **Происхождение обязательно.** Каждая зеркалируемая величина знает, откуда и когда она пришла. --- # 4. Определения - **Набор данных** - связное тело данных, управляемое как одна единица (набор Объектов, дерево страниц, таблица, реестр). Гранулярность выбирает владелец модели; мастерство объявляется на набор данных. - **Система записи (SoR)** - система, в которой набор данных *создаётся* и чьё состояние побеждает в любом конфликте. - **Зеркало** - копия набора данных с внешним мастерством, хранимая внутри модели и получаемая сбором. - **Сбор** - конвейер, захватывающий внешний набор данных в модель (сырой захват плюс смысловое преобразование). - **Обратная проекция записи** - копия набора данных с мастерством модели, опубликованная во внешнюю систему для удобства чтения, хранения или обработки. --- # 5. Три схемы мастерства ## 5.1 Схема M: мастерство модели Набор данных **рождается в Мета-Модели**. Факты создаются прямо в модели (правятся, рецензируются, версионируются как код). Внешние системы получают **обратные проекции записи**: отрисованные страницы, выгруженные таблицы, синхронизированные записи, опубликованные для людей и инструментов, которым удобнее читать там. Правила: - Поток всегда **модель → внешняя система**. - Каждая спроецированная копия ОБЯЗАНА быть помечена как сгенерированная: она объявляет своего мастера, время генерации и уведомление «здесь не править» в той форме, которую поддерживает целевая система (баннер страницы, поле записи, заголовок файла). - Правки, сделанные во внешней копии, **не имеют полномочий**. Реализации СЛЕДУЕТ либо заблокировать внешнюю копию, либо перезаписать её при следующей публикации, либо принимать такие правки как *предложения изменений*, направляемые в обычный процесс изменений модели; она НЕ ДОЛЖНА молча их сливать. - В любом конфликте **побеждает модель**. *Пример: реестр архитектурных решений, создаваемый в модели; Confluence несёт его сгенерированное представление только для чтения, потому что вся остальная организация живёт в Confluence.* ## 5.2 Схема E: внешнее мастерство Набор данных **живёт и меняется во внешней системе** (пространство Confluence, которое команды обновляют ежедневно, трекер, продакшен-база). Модель держит **зеркало**: собранную, смыслово структурированную копию, которая позволяет модели ссылаться на данные, классифицировать их и рассуждать о них. Правила: - Поток всегда **внешняя система → модель**. - Сбор ОБЯЗАН класть неизменённый захват в `raw/<система>/<набор-данных>/` вместе с сопроводительным файлом происхождения, согласно [Model-Traversal-and-Layout](Model-Traversal-and-Layout.md) §6; затем смысловое преобразование наполняет зеркало в слоях модели. - Зеркалируемое содержимое **доступно внутри модели только для чтения**. Исправление делается во внешней системе и собирается заново; дополнительно модель может зафиксировать размеченное отклонение («источник говорит X, мы оцениваем Y») как собственное утверждение с мастерством модели, чётко отделённое от зеркалируемого факта. - Каждый зеркалируемый набор данных ОБЯЗАН нести **метаданные свежести**: время последнего успешного сбора, объявленную периодичность и предел устаревания, после которого потребителей ОБЯЗАНО предупреждать. - В любом конфликте **побеждает внешняя система**; зеркало исправляется повторным сбором, и никогда наоборот. *Пример: ИИ-агенты непрерывно собирают живое пространство Confluence в модель; модель добавляет структуру, связи и классификацию, но сами страницы создаются в Confluence.* ## 5.3 Схема H: разделённая Область знания разделена: одни наборы данных (или поля) мастерятся моделью, другие - снаружи. Это распространённый случай в реальной жизни, и он законен **только тогда, когда разделение явно**: - Каждая часть ОБЯЗАНА объявляться как отдельный набор данных с единственным мастером (схема M или E). - Одно и то же поле НЕ ДОЛЖНО быть записываемым с обеих сторон. Двустороннее мастерство одной величины несоответствующе; если это действительно нужно, величину следует разделить (например: внешняя система мастерит `status`, модель мастерит `assessment`). - Ссылки между частями допустимы и поощряются; это ссылки, а не копии. --- # 6. Реестр мастерства (`sources.yaml`) Каждый соответствующий репозиторий ОБЯЗАН содержать в корне реестр мастерства, охватывающий **каждый набор данных, который модель держит или зеркалирует**. Набор данных, отсутствующий в реестре, считается мастерящимся моделью и полностью создаваемым на месте; любое участие внешней системы без записи в реестре несоответствующе. Каждая запись ОБЯЗАНА объявлять: | Поле | Значение | |-------|---------| | `id` | Устойчивый идентификатор набора данных | | `description` | Что это за данные, одной строкой | | `master` | `model` или `external` | | `system` | При участии внешней системы: имя системы, URL, объём (пространство, проект, таблица) | | `model_location` | Где набор данных (или его зеркало) лежит в репозитории | | `flow` | `model->external`, `external->model` или `none` | | `pipeline` | Сборщик или публикатор (инструмент, скрипт, агент), перемещающий данные | | `cadence` | Как часто выполняется поток; для зеркал также `staleness_limit` | | `conflict_rule` | Повторное указание того, кто побеждает, плюс контакт для эскалации (`steward`) | | `status` | Жизненный цикл потока: `active` (по умолчанию), `declared`, `suspended`, `retired` | **Объявленные записи.** Реальные модели проходят через переходное состояние, о котором реестр обязан говорить правду: мастерство решено, но поток ещё не построен - место зеркала существует, но сбор ни разу не выполнялся, или обратная запись согласована, но её никто не публикует. Такие записи ОБЯЗАНЫ нести `status: declared`. Объявленная запись законна, но это **открытый долг, а не работа**: объявленное зеркало НЕ ДОЛЖНО подаваться как свежее (у него вообще нет времени сбора), а объявленная обратная запись не даёт никакой защиты от расхождения. Скрывать переходное состояние, пропуская запись или помечая её `active`, несоответствующе; реестр существует именно для того, чтобы это состояние было видно. Иллюстративный реестр с обоими направлениями Confluence: ```yaml datasets: - id: adr-register description: Architecture decision records master: model system: { name: Confluence, url: https://wiki.example.com, scope: SPACE/Architecture } model_location: bundles/architecture/decisions/ flow: model->external pipeline: tools/publish-adr-to-confluence cadence: on-change conflict_rule: model wins; external edits become change proposals steward: architecture-owner - id: ops-runbooks description: Operational runbooks maintained by the ops team in Confluence master: external system: { name: Confluence, url: https://wiki.example.com, scope: SPACE/Ops } model_location: bundles/operations/runbooks-mirror/ flow: external->model pipeline: tools/harvest-ops-runbooks cadence: daily staleness_limit: 7d conflict_rule: Confluence wins; fix at source and re-harvest steward: ops-lead ``` Это ровно тот артефакт, который механически отвечает на вопрос «есть Confluence - что в нём, и кто авторитетнее, мета-модель или Confluence?» по каждому набору данных. --- # 7. Конфликты и расхождение - **Обнаружение.** Реализациям СЛЕДУЕТ обнаруживать расхождение между мастером и копией (сравнение содержимого, отпечатки, отметки времени) как минимум при каждом прогоне потока. - **Разрешение.** Расхождение разрешается **только** в направлении, объявленном в `conflict_rule`; разрешение «по усмотрению» в каждом случае несоответствующе. - **Эскалация.** Расхождение, которое нельзя разрешить механически (само разделение неверно, мастер оспаривается), уходит к попечителю набора данных и, если мастерство меняется, порождает новую версию записи реестра - смена мастерства является версионированным событием, а не молчаливой правкой. --- # 8. Свежесть и доверие Потребитель зеркалируемого набора данных ОБЯЗАН иметь возможность увидеть, не выходя из модели: систему-мастер, время последнего сбора и превышен ли предел устаревания. Протухшие зеркала ОБЯЗАНЫ помечаться, а не скрываться. Утверждение, взятое из протухшего зеркала, несёт эту протухлость в своём происхождении; последующие решения о доверии (см. Trust-Model) МОГУТ учитывать это при взвешивании. --- # 9. Правила для ИИ-агентов Агент, работающий с соответствующей моделью: - **Прежде чем полагаться на набор данных**: ОБЯЗАН свериться с реестром; для зеркал ОБЯЗАН проверить свежесть и предпочесть повторный сбор догадкам, если данные протухли. - **Прежде чем писать**: ОБЯЗАН писать только в мастера этого набора данных. Исправление внешне мастерящегося факта идёт во внешнюю систему (или к человеку с доступом); исправление факта с мастерством модели идёт в модель. Запись в копию несоответствующа, как бы удобна она ни была. - **При цитировании**: СЛЕДУЕТ называть мастера («по пространству Ops в Confluence, собрано 2026-07-30»), а не подавать зеркало как первоисточник. Именно эти правила позволяют смешанным командам людей и агентов работать над одним знанием, не портя его ни с одной стороны. --- # 10. Отношение к другим стандартам - **[Model-Traversal-and-Layout](Model-Traversal-and-Layout.md)** даёт зеркалам и проекциям их физические места (`raw/`, зеркала в слоях, `artifacts/`) и происхождения (собранное / сгенерированное); этот документ даёт им полномочия. - **[Synchronization](../03-federation/Synchronization.md)** управляет участниками *через* границы суверенитета; этот документ управляет инструментами *внутри* одной. Федерация никогда не переносит мастерство; вселенная раскрывает только то, что мастерит сама, либо явно помечает как зеркало. - **[Extension-Model](Extension-Model.md)**: импортированные стандарты - фиксированный частный случай схемы E (мастер: орган по стандартизации; поток: версионированные выпуски внутрь). - **[Traceability](Traceability.md) / [Provenance-Graph](Provenance-Graph.md)**: прогоны сбора и публикации являются событиями происхождения; реестр сообщает политику, граф происхождения сообщает, что произошло на самом деле. --- # 11. Валидация Структурная валидация (V1) ОБЯЗАНА проверять: реестр существует, разбирается, и каждое объявленное `model_location` существует. Смысловой валидации (V2) СЛЕДУЕТ проверять: у каждого зеркала есть метаданные происхождения и свежести; ни один файл не записываем по двум записям; потоки соответствуют мастерам (у `master: external` никогда не бывает `flow: model->external`); и каждая запись со `status: declared` сообщается как открытый долг. Валидация времени выполнения (V5) МОЖЕТ проверять пределы устаревания по фактической истории сбора и СЛЕДУЕТ понижать до `declared` запись, чья объявленная периодичность ни разу не отработала. --- # 12. Архитектурные инварианты Мастерство ОБЯЗАНО сохранять: - единственную систему записи на набор данных в любой момент; - объявленные версионированные переходы мастерства; - происхождение и свежесть каждого зеркала; - одноразовость каждой немастерской копии; - соблюдение Конституции. Мастерство НИКОГДА не должно подразумеваться одним лишь физическим расположением: расположение даёт чтение по умолчанию, реестр даёт закон. --- # 13. Дальнейшие направления Два естественных расширения: формат **профиля коннектора**, описывающий конвейеры сбора и публикации для распространённых систем (Confluence, Jira, Notion, реляционные хранилища), чтобы реестры ссылались на типизированные коннекторы, а не на разовые скрипты; и вывод записей реестра в **Смысловой пакет распространения**, чтобы потребитель упакованной модели сразу видел, какие части являются созданным знанием, а какие - зеркалом чьей-то вики. --- # Заключение У каждого набора данных ровно один дом для его истины. Реестр мастерства делает этот дом явным, правила потока держат копии честными, а правила свежести держат честными читателей относительно копий. Модель, объявляющая своих мастеров, может безопасно сосуществовать с вики, трекерами и базами данных; модель, которая этого не делает, находится в одной правке от двух истин.