# Владение данными

*Построение мета-модели · урок 4 из 6 · ~15 мин*

## Что вы узнаете

Вопрос, который решает, будут ли ваша модель и ваша вики сосуществовать в порядке или в хаосе: для каждого набора данных - кто мастер? (ARCH-018.)

## Болезнь двух истин

Ваша модель описывает продукт. Но ранбуки живут в Confluence, задачи жили в трекере, код живёт в GitLab, и люди правят всё это ежедневно. В момент, когда один и тот же факт существует в двух редактируемых местах, у вас две истины, и каждый читатель молча выбирает одну. Лекарство не в централизации (вы не переселите эксплуатацию с их вики), а в **объявленном владении**: у каждого набора данных ровно одна Система записи, машиночитаемо.

## Три законных паттерна

**Мастер - модель (обратная запись).** Набор данных рождается в модели; внешние системы получают порождённые, явно помеченные проекции только для чтения "для удобства чтения". Поток: модель → внешнее. Конфликт: побеждает модель; внешние правки недействительны либо становятся предложениями изменений. *Живой пример: модель Orkestron.AI мастерит факты о продукте; публичный сайт отдаёт порождённый `product-facts.json` с пометкой "здесь не править" и хешем содержимого для обнаружения расхождений.*

**Мастер - внешняя система (зеркало).** Набор данных живёт и меняется во внешней системе; модель держит собранное зеркало, чтобы связывать, классифицировать и рассуждать. Поток: внешнее → модель, через конвейер, который кладёт сырые выгрузки (с происхождением) и преобразует их. Зеркала в модели доступны только для чтения и несут **метаданные свежести**: последняя выгрузка, периодичность, предел устаревания. Конфликт: побеждает внешняя система; вы выгружаете заново, а не патчите зеркало. *Живой пример: постоянно обновляемые пространства вики, клоны исходного кода, мастер которых GitLab.*

**Разделённый.** Честный смешанный случай: часть наборов мастерит модель, часть - внешние системы, каждый объявлен отдельно. Одно железное правило: одно и то же поле никогда не доступно для записи с обеих сторон. Если вам действительно нужно и то и другое, разделите данное (внешняя система мастерит `status`, модель мастерит `assessment`).

## Реестр: sources.yaml

Один файл в корне репозитория объявляет каждый набор данных: мастер, внешнюю систему и охват, место в модели, направление потока, конвейер, периодичность, правило разрешения конфликта, распорядителя и **статус**: `active`, `declared` (владение решено, конвейер ещё не построен: законный, видимый долг), `suspended` или `retired`. Это и есть артефакт, который механически отвечает на вопрос "есть Confluence: что в нём и кто авторитетнее?" - для каждого набора данных, навсегда.

## Статусы, столкнувшиеся с реальностью

Словарь статусов пришёл из практики в считаные дни после того, как был написан:

- `declared`: модель Orkestron вышла с объявленным, но ещё не вендоренным зеркалом канона - видимый долг в реестре, закрытый сессию спустя. Реестры с нулём записей `declared` заслуживаются, а не предполагаются.
- `retired`: DevTeam.Games держит полный экспорт таск-трекера, аккаунт которого закрыт. Системы записи больше нет; зеркало - замороженный архив свидетельств, который невозможно выгрузить заново и который нельзя "исправлять". Реестр говорит ровно это.
- `suspended` плюс правило конфликта "никогда не публиковать": проприетарная эталонная кодовая база, однажды использованная для дизайнерского вдохновения: присутствует на диске, юридически неприкасаема, и этот факт живёт в реестре, а не в чьей-то памяти.

## Расхождение под присмотром машины

Объявленное владение делает возможной механическую честность: пример с обратной записью выше запускает ежедневную проверку, которая пересобирает проекцию из модели, сравнивает хеши содержимого с живой копией и зовёт владельца при расхождении, при отсутствии копии или если сломалась сама проверка. Расхождение замечает cron, а не неловкость на совещании.

## Главное

- Один мастер на набор данных; поток следует за владением; копии одноразовы и помечены.
- Три паттерна: обратная запись, зеркало, разделённый; одно и то же поле никогда не пишется дважды.
- `sources.yaml` плюс статусы (active/declared/suspended/retired) превращают племенное знание о том, кто главный, в версионируемые данные.

## Копнуть глубже

- [Владение данными и Системы записи (ARCH-018)](/spec/#02-architecture/Data-Mastership.md)
- [Синхронизация между вселенными](/spec/#03-federation/Synchronization.md) (родственник этого урока на уровне федерации)

Дальше: [Переиспользование мира](05-reuse.md)