# Зеркало и актуализация (MIR): обзор семьи

## Зеркальная позиция

Соответствующая Vercy Вселенная существует, чтобы быть первичным цифровым отражением реальности. Внутри её Измерения, когда цифровой мир хочет знать, что верно, он спрашивает модель первой. Всякое иное цифровое представление стоит ниже по течению: это либо проекция, порождённая из модели, либо внешний мастер, который модель честно зеркалит с объявленной его властью и его возрастом. «Первичность» поэтому есть не притязание на всеведение. Это притязание на честность. Модель не обещает знать всё; она обещает, что всё, что она держит, есть либо сочинённая истина, либо зеркало, называющее своего мастера и время своего сбора.

Реальность есть конечный референт. Для наборов данных, мастерящихся в модели, модель есть то место, где истина реальности сочиняется, и всякая цифровая копия течёт из неё наружу как проекция с обратной записью. Для наборов данных, мастерящихся снаружи, истина сочиняется в другом месте (в трекере, вики, промышленной базе данных, человеческом учреждении), а модель держит зеркало с метаданными происхождения и свежести. Реестр мастерства (sources.yaml) есть конституция этой семьи: один мастер на набор данных, объявленный поток, объявленный ритм, объявленное правило конфликтов. Ни один процесс MIR НЕ ДОЛЖЕН работать с необъявленным набором данных; сбор без объявленного мастерства и есть то, как рождаются две истины. MIR-1 есть единственный исполнитель изменений Реестра мастерства: всякое предложение, касающееся реестра, из любой семьи (массовый импорт CON-7, решения по спорам CON-9, сверка ACT-10, подъём MIR-7) исполняется через MIR-1 или не исполняется вовсе.

## Почему модель должна оставаться верной реальности

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

Из правдивости следует центральная асимметрия семьи: честно устаревшее лучше ложно свежего. Поэтому семья вкладывается в признание не меньше, чем в обновление: уровни обслуживания по свежести, раскрытие устарелости в момент чтения, карантинные пометы, путешествующие со всяким цитированием, и записи о дрейфе, которые никогда не разрешаются суждением, а только в объявленную сторону.

## Актуализационная половина петли реальности

Петля реальности идёт так: реальность меняется; изменение считывается; модель актуализируется; модель потребляется; потребление ведёт к действию; действие снова меняет реальность. Эта семья владеет первой половиной петли, от реальности к модели. Считывание и приём (MIR-2) вносят свидетельство. Три темпа актуализации держат соответствие свежим: по расписанию (MIR-3), по событиям (MIR-4) и по требованию в момент потребления или удостоверения (MIR-5). Обнаружение дрейфа (MIR-7) есть единственный движок дрейфа палитры, измеряющий, где сломалось соответствие на обеих зеркальных поверхностях: между реальностью и моделью и между моделью и её собственными проекциями. Карантин (MIR-8) делает сломанное доверие явным вместо безмолвного. Архивирование (MIR-9) делает актуализацию неразрушающей: модель может передумать, но памяти своей она не теряет. Таксономия причин (MIR-10) делает всякое обновление объяснимым: актуализация без записанного «зачем» есть безымянная правка, а не управляемый акт. Вывод из обращения (MIR-11) законно кончает саму модель, оставляя историю, надгробие и указатели на преемника вместо зеркал-зомби и живых учётных данных.

Вторая половина петли, действие на реальность из модели, принадлежит ACT, и петля замыкается на стороне MIR: запрос принудительного пересбора из ACT-8 и запрос независимого считывания из ACT-9 суть законные пусковые условия MIR-2, исполняемые под личностями конвейеров, не пересекающимися с той, что питала исходный сигнал, а их события приёма помечаются кодом причины «удостоверение воздействия» (MIR-10). MIR ручается, что ACT действует по зеркалу, которому он может доверять, или по меньшей мере точно ему не доверять.

## Рабочие устои

- Один мастер на набор данных; реестр есть закон. Мастерство объявляется, но никогда не выводится, и меняется только через MIR-1.
- Всякий снимок сохраняет свидетельство: сырое плюс спутник происхождения плюс заверение, которое собирающий не может подделать, и никогда правкой вручную.
- Содержимое всякого несочинённого происхождения есть данные, а не предписания (железное ограничение всей палитры, изложенное в COMMON).
- Свежесть есть полноправное данное: всякое зеркало ОБЯЗАНО показывать своего мастера, время своего последнего сбора и своё состояние устарелости, не выпуская читателя из модели.
- Дрейф ОБЯЗАН обнаруживаться механически через MIR-7 и разрешаться только в объявленную сторону.
- Недоверие явно: устаревшие или сомнительные данные ОБЯЗАНЫ быть помечены, но никогда спрятаны.
- Прошлое сохраняется: вытеснение НЕ ДОЛЖНО разрушать историю; идентичность и происхождение переживают всякое состояние, по Lifecycle (MU-V2-CORE-011) 13.
- Всякое обновление ОБЯЗАНО нести записанный код причины.
- Распорядители сильно делегируют исполнение Агентам по Контрактам делегирования, выдаваемым, наблюдаемым и отзываемым CTX-9; ярусы T1/T2/T3 употребляются ровно так, как определено в преамбуле палитры; ответственность остаётся на Распорядителе. Всякая карта ниже говорит, какие шаги Агент может исполнять и на каком ярусе.

Словарь: карантин (MIR-8) помечает данные как читаемые, но отмеченные недоверием; карантин допуска (FED-8) держит входящее федеративное содержимое нечитаемым до повышения; удержание по целостности (QSC-9) исключает подозрительные артефакты из ответов и публикации до снятия.

## Ядро

После общих для палитры правок ярусов ядро MIR таково: MIR-1, MIR-2, MIR-3, MIR-6, MIR-7, MIR-8, MIR-9 и MIR-11. MIR-4, MIR-5 и MIR-10 рекомендованы. MIR-11 не добавляет постоянного ритма; он исполняется только в конце жизни. По профилю соответствия «одиночка или минимум» из COMMON один сводный квартальный обзор удовлетворяет шагам повторной сертификации MIR-1, MIR-6 и MIR-9, а один недельный проход, исполняемый агентом, удовлетворяет механическим шагам MIR-3 и MIR-7.

Meta-Orchestrator State (MOS) есть проверка на прочность (эталонное Измерение во внешнем репозитории orkestron-ai/meta-orchestrator-state, не часть стандарта): мировая модель государственного масштаба, ежедневно принимающая сообщения граждан, телеметрию реестров и книг учёта и институциональные документы, потребляемая непрерывно тысячами Агентов. Если MOS может вести свой корпус мировых моделей на этих одиннадцати процессах, то сможет и всякая модель поменьше.

# Связи MIR с другими семьями

- К ACT: внутрь: запросы принудительного пересбора (ACT-8) и запросы независимого считывания (ACT-9) входят в список пусковых условий MIR-2 и исполняются под личностью конвейера, не пересекающейся с той, что питала исходный сигнал; наружу: итоги сбора со спутниками происхождения, метаданные свежести и события приёма, помеченные как удостоверение воздействия (MIR-10). Состояния свежести MIR-6 и карантинные пометы MIR-8 суть обязательные входы квалификации для ACT-2: набор данных в карантине блокирует испускание либо вынуждает понизить уверенность с подъёмом к Распорядителю по правилу класса. MIR-7 передаёт связанное с воздействием расхождение (привязанное по причине к открытой команде) в ACT-10; всякое иное расхождение остаётся на собственном пути разрешения MIR-7.
- К CON: прогон зарегистрированного конвейера MIR-2 по действующей записи sources.yaml ЕСТЬ приём и одобрение для собранного содержимого; исключительность CON-1 покрывает только сочинённые вклады, а CON-2 по CON-4 не обрабатывают партии сбора заново. MIR-2 есть единственный хозяин спутника происхождения сбора; CON-2 на него ссылается. Массовый импорт CON-7 вызывает MIR-1 (включая его шлюз Владельца для новых внешних систем) прежде, чем сдвинется хоть один байт; шаг 4 CON-9 поднимает предложения о смене мастерства в MIR-1; MIR-7 направляет намеренные внешние правки проекций с обратной записью в CON-11, единственный путь уловления и классификации, повышенный до ядра. События вытеснения из MIR-9 и события с кодом причины из MIR-10 питают историю версий CON-6; правило простановки MIR-10 покрывает события перехода CON-6, CON-7 и CON-8. Миграции CON-12 сохраняют сырое состояние до миграции по MIR-9 и проставляют «восполнение миграции» по MIR-10. CON-13 есть реестр потребителей и подписок, по которому разрешаются нацеливание панелей MIR-6 и уведомления MIR-8. Обходчик покрытия и манифесты, которые MIR-2 оставляет зелёными, суть механика CON (CON-3, CON-6).
- К CTX: Контракты делегирования, охватывающие исполнение шагов MIR Агентами, выдаются, изменяются, приостанавливаются и отзываются исключительно CTX-9; карты MIR называют ярусы по преамбуле палитры и никогда не толкуют их заново. CTX-1 проставляет состояние свежести MIR-6 и состояние карантина MIR-8 на всяком наборе данных, включённом в Пакет контекста, и исключает жёстко заблокированные; пакеты несут классы происхождения и заражения, так что зеркалированное внешнее содержимое никогда не считается предписаниями.
- К FED: входящие Проекции из Вселенных-партнёров ОБЯЗАНЫ пройти карантин допуска и повышение FED-8, прежде чем MIR-2 исполнит приземление после повышения; MIR-2 отказывает содержимому федеративного класса без записи о повышении. Состояния свежести, карантинные пометы и коды причин путешествуют наружу, прикреплённые к Проекциям и событиям синхронизации. Дрейф на границе оценивается движком MIR-7 по управляющему контракту, а разрешение направляется через FED-9. MIR-11 выстраивает FED-11 по партнёрам при выводе модели из обращения.
- К QSC: QSC-9 проверяет, что MIR-7 отработал в ритме, и выборочно проверяет его честность; при несовпадении он поднимает находку в MIR-7 и никогда сам не исполняет перегенерацию или маршрутизацию. Вход долга QSC-11 принимает долг объявленных записей MIR-1 и находки о нарушении уровня обслуживания MIR-6. QSC-13 копирует всё, что сохраняет MIR-9 (вынесенные неизменяемые копии, отдельное хранение), и объявляет правила ослабленного режима для MIR во время сбоев. QSC-14 принимает рабочие происшествия: умершие планировщики (MIR-3), умершие надзиратели свежести (MIR-6), несовпадения заверений (MIR-2). QSC-15 ведёт расписания MIR-3, подписки MIR-4 и надзирателей MIR-6 как зарегистрированные постоянные работы со сторожами пульса; кроны вне реестра QSC-15 не соответствуют. Закрытие MIR-11 опирается на последний прогон валидации QSC-4 и снимок соответствия QSC-10.
- К GOV: спорное мастерство, визы по уровням обслуживания для критичных наборов данных, оспариваемые снятия карантина и решение о выводе из обращения записываются как события решений GOV-1 с его лестницей апелляций. GOV-2 сочиняет и версионирует политики и настройки, которые исполняет MIR: политику хранения, применяемую MIR-9, настройку семантического порядка MIR-4, настройки порогов и шлюзов. Телеметрия мощностей и стоимости GOV-5 питает разбор реалистичности уровней обслуживания MIR-6. GOV-7 выдаёт и отзывает допуски к конвейерам и источникам, под которыми исполняются MIR-2 и MIR-5; всякое чтение источника называет живой допуск GOV-7 на шлюзе. GOV-8 выводит из обращения учётные данные и ключи при демонтаже MIR-11 и рутинно ротирует учётные данные конвейеров. Аудиторы, привлекаемые для проверки учений MIR-9 и заверения закрытия MIR-11, берутся через GOV-6.

# Карты процессов MIR

### MIR-1 Отображение источников истины и ведение реестра

- Назначение: Вести Реестр мастерства (sources.yaml) так, чтобы у всякого набора данных, который модель держит или зеркалит, была ровно одна объявленная Система записи, направление потока, конвейер, ритм и правило конфликтов. Реестр есть предусловие всякого другого процесса MIR. MIR-1 есть единственный исполнитель изменений Реестра мастерства: ни один иной процесс ни в одной семье в реестр не пишет; они поднимают сюда предложения.
- Пусковое условие: В модели появляется новый набор данных; вовлекается новая внешняя система; предложена смена мастерства; готовится массовый импорт (CON-7 вызывает MIR-1 прежде, чем сдвинется хоть один байт); предложение о смене мастерства поднимается с шага 4 CON-9 или шага 5 ACT-10; подъём по дрейфу приходит с шага 6 MIR-7; прогон покрытия или валидации сообщает об осиротевшем наборе данных; плановый обзор реестра.
- Действующие лица: Распорядитель (ответствен за истинность реестра); Владелец (одобряет передачи мастерства и выставление новых внешних систем); Вкладчик (предлагает записи); Агент; Аудитор (периодический обзор реестра). Агент МОЖЕТ исполнять шаги 1, 2, 6 и 7 на T2 и шаг 8 на T3. Шаги с 3 по 5 ОБЯЗАНЫ оставаться на T1 (Агент предлагает, человек одобряет каждое действие); согласие Владельца, выставляющее новую внешнюю систему, по существу не делегируется.
- Входы / Выходы: Входы: инвентарь наборов данных, каталог внешних систем, нынешний sources.yaml, отчёты валидации и покрытия, манифесты массового импорта из CON-7, поднятые предложения из CON-9, ACT-10 и MIR-7. Выходы: обновлённый версионированный sources.yaml, события смены мастерства со ссылками на их события решений GOV-1, список открытого долга по записям со status declared, заведение долга в QSC-11.
- Шаги:
  1. Обнаружить или получить набор данных, у которого нет годной записи в реестре (находка валидации, предложение Вкладчика, запрос нового конвейера, вызов массового импорта CON-7 либо поднятое предложение о смене мастерства).
  2. Составить запись реестра: id, описание, мастер, охват системы, model_location, поток, конвейер, ритм, conflict_rule, распорядитель, статус.
  3. Развилка: оспаривается ли мастерство, меняется ли оно, либо выставляет ли запись новую внешнюю систему? Если да, поднять к Распорядителю и Владельцу за явным одобрением, записанным как событие решения GOV-1 (T1; согласие Владельца не делегируется).
  4. Записать одобрение как версионированное событие; безмолвные правки мастерства НЕ ДОЛЖНЫ случаться.
  5. Внести обновление реестра тем же набором изменений, что и то изменение данных, которое оно описывает.
  6. Развилка: построен ли объявленный поток на деле и работает ли он? Если нет, поставить status declared и добавить запись в список открытого долга.
  7. Заново прогнать структурную и семантическую валидацию реестра (запись существует, model_location существует, поток сходится с мастером, ни одно поле не пишется под двумя записями).
  8. По расписанию разобрать все записи со status declared и их возраст; доложить о стареющем долге Распорядителю и завести состарившийся долг объявленных записей во вход долга QSC-11. Этот разбор МОЖЕТ быть удовлетворён сводным квартальным обзором профиля «одиночка или минимум» из COMMON, по общему образцу повторной сертификации реестров.
- Ограничения: Валидация «один мастер на набор данных»; смены мастерства только через записанные события одобрения GOV-1, исполняемые MIR-1 и никаким иным процессом; шлюз разрешения Владельца прежде, чем будет прочитана всякая новая внешняя система; валидация V1 и V2 как шлюз слияния; объявленные записи сообщаются как открытый долг в QSC-11, но никогда не прячутся. Поля мастерства и conflict_rule принадлежат классу наборов данных, критичных для безопасности, определённому в COMMON: изменения всегда T1 со вторым человеком-рецензентом, структурно неприменимы к полосам автоматического одобрения, а их хеши непрерывно якорит QSC-9.
- Ярус: ядро
- Разновидности: Одиночка: Владелец-Распорядитель ведёт короткий реестр руками; Агент лишь проверяет его. Команда: Распорядители по бандлам и один хозяин реестра, вливающий изменения. Федерация: записи дополнительно помечают, какие наборы данных выставлены партнёрам как Проекции. Вручную: YAML, правимый руками. Смешанно: составляет Агент, одобряет человек (обычный случай). Самостоятельно: Агент ведёт описательные метаданные на T3, но никогда поля мастерства.
- Метрики: Доля наборов данных с годной записью в реестре (цель 100); число и медианный возраст записей со status declared; среднее время от создания набора данных до записи в реестре; доля пройденных валидаций реестра.
- Способы отказать: Теневой набор данных работает без записи (защита: проверка покрытия относит его к осиротевшим и блокирует сборки). Одно поле пишется с обеих сторон разделения (защита: валидация V2 соблюдает правило разделённого данного). Мастерство изменено безмолвно в рутинном коммите (защита: различия реестра требуют ссылки на событие одобрения GOV-1). Изменение реестра исполняется через путь другой семьи и минует валидацию единственного мастера (защита: правило единственного исполнителя; CON-7, CON-9, ACT-10 и MIR-7 поднимают в MIR-1, но не пишут). Объявленные записи гниют в вечный долг (защита: тревога по возрасту, плановый разбор долга на шаге 8 и заведение в QSC-11).

### MIR-2 Считывание и приём из реальности

- Назначение: Улавливать изменения реальности в модель как свидетельство плюс зеркало: события источников, документы, потоки телеметрии и сообщения людей приземляются как неизменённые сырые снимки с происхождением и независимым заверением, а затем преобразуются в объявленное место зеркала. Прогон зарегистрированного конвейера MIR-2 по действующей записи sources.yaml ЕСТЬ приём и одобрение для собранного содержимого; запись реестра есть постоянное разрешение; CON-2 по CON-4 не обрабатывают партии сбора заново. MIR-2 есть единственный хозяин спутника происхождения сбора; CON-2 на него ссылается.
- Пусковое условие: Вызов конвейера из MIR-3 (настал ритм), MIR-4 (событие источника), MIR-5 (обновление по требованию); запрос принудительного внеочередного пересбора из ACT-8; запрос независимого считывания из ACT-9; Вкладчик, подающий сообщение человека; нацеленный сбор по распоряжению Распорядителя.
- Действующие лица: Распорядитель (ответствен по набору данных); Вкладчик (подаёт сообщения людей); Агент; служба заверения (инфраструктура конвейера, выпускающая заверения времени снятия, в которые собирающий Агент писать не может); Аудитор (выборочно проверяет полноту происхождения и различия пересбора). Агент МОЖЕТ исполнять все шаги на T3 для зарегистрированных, прежде доказанных конвейеров; первые прогоны нового или изменённого конвейера ОБЯЗАНЫ идти на T2 (Распорядитель разбирает вывод, прежде чем зеркалу начнут доверять); приём из источника, ещё не внесённого в реестр, НЕ ДОЛЖЕН идти ни на каком ярусе (сперва направить в MIR-1); помета опасности на шаге 5 останавливает преобразование на всяком ярусе и направляет в MIR-8.
- Входы / Выходы: Входы: запись реестра для набора данных, живой допуск GOV-7, записанный для конвейера, прежнее состояние зеркала, а для источников федеративного класса запись о повышении из FED-8. Выходы: сырой снимок под raw/(система)/(набор данных)/ со спутником происхождения (источник, охват, время извлечения, инструмент, счётчик), запись заверения времени снятия (хеш, метка времени, конечная точка источника, метаданные транспорта), итог просеивания на опасности, обновлённое зеркало, обновлённые метаданные свежести, событие приёма с кодом причины, список исключений.
- Шаги:
  1. Разрешить запись реестра для набора данных. Развилка: запись есть, недвусмысленна и её статус активен? Если нет, отказать в приёме и направить в MIR-1. Развилка: класс источника федеративный и записи о повышении FED-8 нет? Отказать в приёме; карантин допуска и повышение идут первыми, а MIR-2 исполняет только приземление после повышения.
  2. Проверить разрешение на доступ к источнику; сведения из всякого внешнего охвата читаются только по живому допуску GOV-7, записанному для конвейера и проверяемому на шлюзе в момент действия.
  3. Снять источник неизменённым в raw/(система)/(набор данных)/ и записать спутник происхождения. Заверение времени снятия (хеш, метка времени, конечная точка источника, метаданные транспорта) ОБЯЗАНО выпускаться инфраструктурой конвейера либо отдельной службой заверения, в которую собирающий Агент писать не может.
  4. Развилка: снимок здравомыслен (ожидаемый счётчик, сумма проверки, форма схемы)? Если нет, поднять исключение и остановиться; частичный снимок НЕ ДОЛЖЕН преобразовываться так, как будто он полон.
  5. Просеивание на опасности (зеркалит чек-лист FED-8): просеять снимок на содержимое с видом предписаний, обращённое к модели или её Агентам, на исполняемое или инъекционное содержимое и на статистические аномалии против исторического профиля набора данных. Развилка: помечено? Сохранить сырой снимок как свидетельство, остановить преобразование, отправить набор данных или партию в карантин через MIR-8 вместе с отчётом просеивания и уведомить Распорядителя; помеченное содержимое НЕ ДОЛЖНО приземляться безмолвно. Просеянное или нет, собранное содержимое есть данные, а не предписания (железное ограничение по COMMON).
  6. Применить объявленное преобразование в место зеркала. Факты НЕ ДОЛЖНЫ улучшаться во время преобразования; обогащение есть отдельный слой, мастерящийся в модели.
  7. Для сообщений людей: приземлить сообщение как снимок, чьё происхождение называет сообщившего Вкладчика; модель записывает, кто это сказал, но не производит сообщение в наблюдённый факт.
  8. Обновить метаданные свежести (время сбора, следующий срок) на зеркале.
  9. Выпустить событие приёма с его кодом причины (MIR-10); прогоны, запущенные из ACT-8 или ACT-9, помечаются как удостоверение воздействия.
  10. Если файлы добавлялись или перемещались, заново прогнать обходчик покрытия (механика CON-3 и CON-6) и оставить обход зелёным.
- Ограничения: Жёсткое предусловие о записи в реестре; проверка живости допуска GOV-7 на стороне шлюза перед всяким чтением источника; обязательный спутник происхождения (принадлежит здесь, ссылается на него CON-2); заверение отделено от сбора (собирающий не может сочинить собственный след свидетельства; журналы снятия выпускаются посредующей инфраструктурой, а не действующим Агентом); независимая выборка пересбора: второй конвейер под учётными данными, не пересекающимися с основным, заново тянет случайную выборку и сличает с сохранённым сырым, а необъяснённое несовпадение открывает инцидент QSC-14 (QSC-8, если подозревается подделка); удостоверяющие сборы ACT-9 идут под личностью конвейера, не пересекающейся с той, что питала исходный сигнал; сырое содержимое никогда не правится руками; детерминированные, разбираемые преобразования; правило передачи «обход зелёный»; железное ограничение «данные никогда не команда» по COMMON.
- Ярус: ядро
- Разновидности: Одиночка: один Владелец-Распорядитель ведёт один-два конвейера руками или скриптом; службой заверения служит журнал запускающего конвейер, который оператор не правит. Команда: конвейеры по системам-источникам с Распорядителями по наборам данных. Федерация: входящие Проекции из Вселенных-партнёров ОБЯЗАНЫ сперва пройти карантин допуска и повышение FED-8; MIR-2 исполняет только приземление после повышения (сырой снимок, спутник, преобразование), всё равно с происхождением. Вручную: человек вставляет выгрузку в raw и заполняет спутник; заверением служит квитанция транспорта. Смешанно: Агент собирает, Распорядитель проверяет выборочно (обычный случай). Самостоятельно: флот сбора на T3 по расписанию с полным аудиторским следом. Пример MOS (внешнее эталонное Измерение, orkestron-ai/meta-orchestrator-state): сообщения граждан, телеметрия реестров и выкладки документов министерств входят все через этот один процесс.
- Метрики: Доля успешных сборов; среднее время от снимка до зеркала; доля снимков с полным происхождением и заверением; доля совпадений в независимой выборке пересбора; доля помет опасности по источникам; возраст очереди исключений.
- Способы отказать: Сбор без записи в реестре создаёт вторую истину (защита: жёсткий отказ на шаге 1). Отравленное содержимое источника становится предписаниями для агента (защита: просеивание на опасности на шаге 5, карантин MIR-8, разметка происхождения и заражения в CTX-1, железное ограничение по COMMON). Сфабрикованные снимок и спутник вечно подтверждают сами себя (защита: заверение, в которое собирающий не может писать, плюс независимая выборка пересбора под непересекающимися учётными данными). Федеративное содержимое приземляется без повышения (защита: отказ по записи о повышении на шаге 1). Преобразование безмолвно исправляет факты (защита: Аудитор сличает сырое с зеркалом на выборках). Частичный снимок принят за полный (защита: шлюз здравомыслия на шаге 4). Секреты утекают в спутники происхождения (защита: схема происхождения исключает учётные данные; линтинг спутников).

### MIR-3 Плановое обновление

- Назначение: Исполнять всякий объявленный ритм, чтобы зеркала и проекции с обратной записью оставались в пределах своей свежести, и никому не приходилось помнить о том, чтобы попросить.
- Пусковое условие: Расписание, выведенное из поля ритма всякой записи реестра, зарегистрированное и исполняемое как постоянная работа QSC-15.
- Действующие лица: Агент (ведёт флот); Распорядитель (разбирает исключения и дневную сводку); Аудитор (проверяет, что покрытие расписания сходится с реестром). Агент МОЖЕТ исполнять шаги с 1 по 5 и 7 на T3; шаг 6 (понижение записи) на T2; подъёмы на шаге 4 всегда ложатся на Распорядителя.
- Входы / Выходы: Входы: ритмы sources.yaml, определения конвейеров, история прогонов, реестр работ QSC-15. Выходы: завершённые прогоны MIR-2 и переиздания проекций, обновлённые метаданные свежести, сводный отчёт об обновлении, уведомления о подъёме, предложения о понижении, открытия инцидентов QSC-14 при мёртвой механике.
- Шаги:
  1. Перечислить записи реестра, чей ритм настал (и зеркала, и проекции с обратной записью).
  2. Для всякой наступившей записи вызвать MIR-2 (зеркало, мастерящееся снаружи) либо зарегистрированного публикатора (обратная запись, мастерящаяся в модели).
  3. Развилка: прогон удался? Если нет, повторить по политике повторов этой записи, с разбросом.
  4. Развилка: повторы исчерпаны? Пометить набор данных как в опасности, уведомить Распорядителя и передать обратный отсчёт надзору MIR-6; умерший планировщик либо повторяющийся образец исчерпанных повторов открывает инцидент QSC-14.
  5. Обновить метаданные свежести и вычислить следующий срок.
  6. Сравнить фактическую историю прогонов с объявленным ритмом; запись, чей объявленный ритм на деле никогда не исполнялся, СЛЕДУЕТ понизить до status declared (с подтверждением Распорядителя).
  7. Опубликовать сводку об обновлении (что отработало, что упало, что подходит к своему пределу).
- Ограничения: Расписания ОБЯЗАНЫ порождаться только из реестра и регистрироваться как постоянные работы QSC-15; кроны вне реестра QSC-15 не соответствуют. Сторож пульса планировщика развёрнут и мета-наблюдается через QSC-15, независимо от самого планировщика. Тревога о пропущенном прогоне. Пределы темпа в сторону систем-источников.
- Ярус: ядро
- Разновидности: Одиночка: один недельный прогон всего; по профилю «одиночка или минимум» из COMMON один недельный проход, исполняемый агентом, с одним сводным событием законно удовлетворяет механическим шагам MIR-3 и MIR-7 вместе. Команда: расписания по источникам с общим каналом сводок. Федерация: обновление исходящих проекций чтит объявленную контрактом частоту синхронизации. Вручную: чек-лист, который Распорядитель проходит в назначенный день. Смешанно: Агент исполняет, Распорядитель читает сводку (обычный случай). Самостоятельно: полный T3 с месячным разбором аудиторского следа Распорядителем.
- Метрики: Доля соблюдения ритма; число пропущенных прогонов за период; средняя устарелость зеркала как доля его предела; время от подъёма до действия Распорядителя.
- Способы отказать: Планировщик безмолвно умирает, и ничто не обновляется (защита: сторож пульса QSC-15, независимый от планировщика, поднимающийся в QSC-14). Существует крон, о котором реестр не знает (защита: порождение расписаний из реестра, реестр QSC-15, сверка Аудитором). Шторм обновлений перегружает источник (защита: пределы темпа и разброс на шаге 3). Обновление удалось, но источник отдал кешированные устаревшие данные (защита: проверка версии или метки времени источника до объявления свежести).

### MIR-4 Актуализация по событиям

- Назначение: Актуализировать модель, как только реальность объявляет об изменении (вебхуки, потоки событий, уведомления), закрывая промежуток между ритмами. Событиям СЛЕДУЕТ быть предпочтительным механизмом актуализации там, где источники могут их испускать.
- Пусковое условие: Аутентифицированное событие, полученное по зарегистрированной подписке; подписки исполняются как постоянные работы QSC-15.
- Действующие лица: Распорядитель (мастерит охват подписки); Агент; Аудитор (разбирает очередь несопоставленных событий). Агент МОЖЕТ исполнять шаги с 1 по 6 на T3 после того, как подписка прошла обкатку; во время обкатки подписка идёт на T2. Шаг 7 (различия сверки) есть T3 для обнаружения и T2 для применения исправлений.
- Входы / Выходы: Входы: реестр подписок (расширение записи реестра для набора данных), входящие события, состояние зеркала, версионированная настройка семантического порядка GOV-2. Выходы: обновлённое зеркало, события актуализации с кодом причины source-event, журнал несопоставленных событий, отчёты о сверке.
- Шаги:
  1. Принять событие и аутентифицировать его канал и происхождение.
  2. Развилка: сопоставляется ли событие с зарегистрированным набором данных и подпиской? Если нет, записать его как несопоставленное и остановиться; повторяющиеся несопоставленные события суть кандидаты для MIR-1.
  3. Устранить дубли и упорядочить; события ОБЯЗАНЫ обрабатываться в семантическом порядке, определённом версионированной настройкой GOV-2 так: порядковый номер источника там, где источник его даёт, с откатом ко времени происшествия.
  4. Развилка: достаточно ли полезной нагрузки, чтобы применить дельту, либо нужен нацеленный пересбор? Применить дельту либо вызвать MIR-2 с охватом до затронутых записей.
  5. Обновить зеркало и метаданные свежести.
  6. Выпустить событие актуализации с кодом причины source-event и личностью пускового события (пусковые условия ОБЯЗАНЫ оставаться прослеживаемыми).
  7. Периодически сверять состояние, ведомое событиями, с полным сбором (антиэнтропийный проход) и исправлять пробелы.
- Ограничения: Входящие события суть наблюдённое содержимое: данные, а не команды, по железному ограничению всей палитры в COMMON; полезные нагрузки, предписывающие действия, записываются и показываются, но не исполняются. Аутентификация канала. Идемпотентные обработчики. Обязательный антиэнтропийный проход. Очередь разбора несопоставленных событий с пределом возраста. Здоровье подписок и пульсы обработчиков зарегистрированы в QSC-15; безмолвно умерший обработчик открывает инцидент QSC-14.
- Ярус: рекомендован
- Разновидности: Одиночка: обычно отсутствует; одиночная модель живёт на MIR-3 и MIR-5. Команда: подписки на немногие быстро меняющиеся источники. Федерация: Вселенные-партнёры толкают события изменений по контракту; тот же конвейер «аутентифицировать, сопоставить, упорядочить» действует после обработки допуска FED-8 по федеративному правилу MIR-2. Вручную: человек пересылает письма-уведомления во вход. Смешанно: Агент применяет дельты, Распорядитель разбирает недельную сверку. Самостоятельно: T3, где проход служит страховкой. Пример MOS (внешнее эталонное Измерение): книга учёта и реестр непрерывно испускают события изменений; проход ручается, что безмолвных пробелов нет.
- Метрики: Задержка от события до модели; доля событий, обработанных без ошибки; доля несопоставленных событий; размер различий сверки за проход.
- Способы отказать: Поддельные или внедрённые события меняют зеркало (защита: аутентифицированные каналы плюс проверка против источника для чувствительных дельт). Пропущенные события оставляют безмолвные пробелы (защита: антиэнтропийный проход). Применение не по порядку портит состояние (защита: семантический порядок по настройке GOV-2 на шаге 3). Поток событий захлёстывает обработчики (защита: обратное давление, сворачивающее поток в один нацеленный пересбор).

### MIR-5 Актуализация по требованию при потреблении или удостоверении

- Назначение: Проверять свежесть в момент потребления или удостоверения и заново актуализировать при устарелости, чтобы ни ответ, ни решение, ни миссия, ни удостоверение воздействия сознательно не опирались на истёкшее зеркало.
- Пусковое условие: Запрос на чтение, ответ или решение, зависящий от зеркалированного набора данных; явный запрос Потребителя обновить перед использованием; чтение, ведомое удостоверением (удостоверение ACT-9, потребляющее состояние зеркала, направляет свой пересбор через MIR-2 по пусковым условиям воздействия).
- Действующие лица: Потребитель (начинает, часто неявно); Агент; Распорядитель (задаёт политику того, когда обновление обязательно, а когда довольно раскрытия); Владелец (соглашается на всякое новое выставление источника; не делегируется). Агент МОЖЕТ исполнять шаги с 1 по 5 на T3 там, где конвейер обновления зарегистрирован и дозволен; шаг 6, требующий нового допуска, идёт через GOV-7 и ОБЯЗАН оставаться на T1 (Агент предлагает, человек одобряет каждое действие).
- Входы / Выходы: Входы: зависимости запроса от наборов данных, sources.yaml, метаданные свежести, живые допуски GOV-7. Выходы: свежий ответ либо ответ с раскрытой устарелостью и с цитированием, по желанию нацеленный прогон MIR-2, событие актуализации с кодом причины use-driven (или actuation-verification для прогонов, ведомых удостоверением).
- Шаги:
  1. Разрешить наборы данных, от которых зависит запрос, и найти всякий из них в реестре.
  2. Развилка: мастерится в модели? Запись и есть истина; отвечать прямо и цитировать запись.
  3. Для зеркал сравнить время последнего сбора с пределом устаревания и прочесть полное состояние свежести (состояние карантина раскрывается независимо от возраста сбора).
  4. Развилка: в пределах и не в карантине? Пользоваться зеркалом, называя мастера и время сбора (по системе-источнику, собрано в момент T).
  5. Развилка: устарело, но пересобрать можно прямо сейчас (конвейер зарегистрирован, допуск GOV-7 есть)? Прогнать нацеленный MIR-2 и отвечать из свежего состояния; записать код причины use-driven либо actuation-verification, когда прогон служит запросу ACT-8 или ACT-9.
  6. Развилка: устарело и пересобрать нельзя? Либо отвечать с явным раскрытием устарелости, либо отказать, по политике Распорядителя; недостающий допуск запрашивается через GOV-7; зеркало со status declared НЕ ДОЛЖНО подаваться как факт, а на зеркало со status retired ОБЯЗАНО отвечать только исторически.
- Ограничения: Проверка свежести обязательна в рецепте ответа; дисциплина цитирования (мастер назван, время сбора заявлено); ограничение минимального интервала на горячих наборах данных; обновление по требованию всегда идёт полным путём MIR-2 (сырой снимок, спутник, заверение включительно), но никогда сокращённым запросом; живость допуска проверяется на шлюзе в момент действия.
- Ярус: рекомендован
- Разновидности: Одиночка: собственная привычка Владельца-Распорядителя читать, поддержанная пометами свежести. Команда: соблюдается в общем инструментарии ответов. Федерация: партнёры получают пометы свежести со всякой Проекцией и применяют собственную политику перед использованием. Вручную: человек сперва смотрит на панель. Смешанно: Агент проверяет и раскрывает, человек решает, ждать ли обновления. Самостоятельно: проверка и обновление на T3 прямо внутри ответа агента. Воздействие: независимое удостоверение ACT-9 расширяет этот образец до момента удостоверения; удостоверяющее чтение идёт под личностью конвейера, не пересекающейся с той, что питала исходный сигнал (см. ограничения MIR-2).
- Метрики: Доля ответов, несущих цитаты о свежести; доля устаревших чтений (использование сверх предела без раскрытия, цель ноль); задержка обновления по требованию; выборочная верность отказов.
- Способы отказать: Агент отвечает из устаревшего зеркала без раскрытия (защита: проверка свежести, вшитая в путь ответа и аудируемая выборкой). Петля обновления долбит горячий набор данных (защита: ограничение интервала). Запрос по требованию минует сырой снимок и происхождение (защита: правило единственного пути приёма). Объявленное зеркало цитируется как нынешний факт (защита: шлюз статуса на шаге 6). Зеркало в карантине, но свежее по времени, подаётся без пометы (защита: чтение полного состояния свежести на шаге 3).

### MIR-6 Определение и надзор за уровнями обслуживания по свежести

- Назначение: Определить по всякому набору данных, насколько свежее есть достаточно свежее (ритм, предел устаревания, критичность), и непрерывно сравнивать фактическую свежесть с этим, чтобы устарелость была тревогой, а не сюрпризом.
- Пусковое условие: Новая запись реестра, которой нужен уровень обслуживания; плановый разбор уровней обслуживания; повторное нарушение существующего уровня; жалоба Потребителя на устаревшие данные.
- Действующие лица: Распорядитель (определяет уровни обслуживания); Владелец (визирует уровни для критичных наборов данных, записывается как решения GOV-1); Агент; Аудитор (разбирает реалистичность уровней против истории нарушений). Агент МОЖЕТ исполнять шаг 1 на T2 и шаги с 3 по 6 на T3 (непрерывный надзор и оповещение); шаг 2 (установка или смена уровня обслуживания) ОБЯЗАН оставаться на T1 (Агент предлагает, человек одобряет каждое действие).
- Входы / Выходы: Входы: критичность набора данных, скорость изменения источника, образцы потребления, история нарушений, телеметрия мощностей и стоимости GOV-5, реестр потребителей CON-13. Выходы: параметры уровня обслуживания, записанные в реестр (cadence, staleness_limit), состояние свежести по набору данных (свежо, стареет, устарело, в карантине), предупреждения и подъёмы, панель свежести, отчёт о разборе уровней, находки о нарушениях, заведённые в QSC-11. freshness_state есть определённое палитрой поле-расширение сверх схемы Реестра мастерства (Data-Mastership 6), отличное от канонического перечисления status; карантин никогда не трогает status; состояние доверия (в карантине) и состояние потока (приостановлено) суть независимые оси, которые могут сосуществовать.
- Шаги:
  1. Предложить параметры уровня обслуживания для набора данных исходя из его критичности, из того, как быстро на деле меняется его источник, и из того, как он потребляется.
  2. Распорядитель одобряет (Владелец подписывает вместе для критичных наборов данных, записывается как событие решения GOV-1); записать уровень обслуживания в реестр как версионированное изменение.
  3. Непрерывно вычислять состояние свежести всякого зеркалированного набора данных из времени его последнего сбора и его предела; надзиратель исполняется как постоянная работа QSC-15 с независимым пульсом.
  4. Развилка: предел приближается (настраиваемая доля упреждения)? Выпустить раннее предупреждение ответственному Агенту и Распорядителю, чтобы обновление успело случиться до нарушения.
  5. Развилка: предел превышен? Запустить карантин MIR-8 для набора данных, поднять и завести находку о нарушении в QSC-11.
  6. Опубликовать панель свежести, чтобы всякий Потребитель видел мастера, последний сбор и состояние, не выходя из модели; зависимые Потребители разрешаются по CON-13; состояния свежести и карантина питают квалификацию сигналов ACT-2 и простановку помет на пакетах CTX-1 как обязательные входы.
  7. По расписанию разобрать уровни обслуживания против истории нарушений, действительного потребления и телеметрии стоимости и мощностей GOV-5; поправить через шаг 2. Этот разбор вызывает общий образец повторной сертификации реестров из COMMON и МОЖЕТ быть удовлетворён сводным квартальным обзором профиля «одиночка или минимум».
- Ограничения: Изменения уровней обслуживания суть изменения реестра (версионированные события, никаких безмолвных правок); тревоги нельзя заглушить без записанного решения; консервативный предел по умолчанию действует для всякого зеркала без явного уровня обслуживания; видимость панели Потребителям обязательна; безмолвно умерший надзиратель открывает инцидент QSC-14 через мета-надзор QSC-15.
- Ярус: ядро
- Разновидности: Одиночка: три строки YAML и недельный взгляд на одну панель. Команда: уровни обслуживания по бандлам с общим каналом оповещений. Федерация: состояния уровней обслуживания уходят наружу как часть метаданных проекции; контракты МОГУТ объявлять окно согласованности, которое партнёры принимают. Вручную: разбор по календарю. Смешанно: Агент надзирает, Распорядитель настраивает (обычный случай). Самостоятельно: надзор на T3 при изменениях порогов на T1.
- Метрики: Доля зеркалированных наборов данных с явным уровнем обслуживания; доля нарушений уровня; среднее время в нарушении; упреждение предупреждения до нарушения.
- Способы отказать: Уровень обслуживания для красоты, который никогда не достигается (защита: автоматическая помета записей, нарушающих чаще N раз за период, для принудительного разбора со входом о стоимости из GOV-5). Уровня нет, и потому ничто никогда не тревожит (защита: консервативный предел по умолчанию). Сам надзиратель безмолвно умирает (защита: независимый пульс QSC-15, поднимающийся в QSC-14). Пределы скопированы между несхожими наборами данных (защита: разбор реалистичности Аудитором на шаге 7).

### MIR-7 Обнаружение дрейфа между реальностью и моделью и между моделью и проекциями

- Назначение: Обнаруживать расхождение на обеих зеркальных поверхностях: между внешними мастерами и их зеркалами внутри модели (реальность против модели) и между записями, мастерящимися в модели, и их проекциями с обратной записью (модель против её проекций). MIR-7 есть единственный движок обнаружения дрейфа палитры, по Data-Mastership (ARCH-018) 7, и единственный источник событий дрейфа; всякая иная семья эти события потребляет, но ни одна не обнаруживает заново. Записывать всякий дрейф и разрешать его только в объявленную сторону.
- Пусковое условие: Всякий прогон потока (как минимум, по Data-Mastership (ARCH-018) 7); плановый проход по дрейфу; подозрение, поднятое сверкой MIR-4; сообщение Потребителя или Аудитора.
- Действующие лица: Агент; Распорядитель (мастерит спорные разрешения); Аудитор (выборочно проверяет разрешения и качество сравнений). Агент МОЖЕТ исполнять шаги с 1 по 4 на T3 (обнаружение и запись), шаг 5 на T2 для зрелых конвейеров (механическое разрешение, Распорядитель разбирает выборки) и на T1 для новых (Агент предлагает, человек одобряет каждое действие); шаг 6 ОБЯЗАН оставаться на T1 (Агент предлагает, человек одобряет каждое действие).
- Входы / Выходы: Входы: состояние мастера, состояние копии, conflict_rule по набору данных, определения основы сравнения. Выходы: события дрейфа (что, где, насколько, в какую сторону), разрешения (пересбор или переиздание), направления в CON-11 (намеренные внешние правки) и ACT-10 (расхождение, связанное с воздействием), подъёмы в MIR-1, записи чистых проверок, разбор повторяющегося дрейфа.
- Шаги:
  1. Для всякого набора данных в охвате вычислить основу сравнения: как минимум хеш содержимого по сравнимой части, плюс счётчики записей и ключевые поля там, где они определены.
  2. Сравнить состояние мастера с состоянием копии (зеркала или проекции).
  3. Развилка: дрейф найден? Если нет, записать чистую проверку и остановиться.
  4. Записать событие дрейфа с тем, что разошлось, в какую сторону и насколько; записи дрейфа неизменны. Развилка: связано ли расхождение по причине с открытой командой воздействия? Передать его в ACT-10 вместе с событием дрейфа; ACT-10 потребляет только расхождение, связанное с воздействием и переданное отсюда либо из ACT-9.
  5. Развилка: даёт ли conflict_rule записи механическое разрешение? Для мастерящихся снаружи: пересобрать, побеждает внешняя система. Для мастерящихся в модели: переиздать, побеждает модель; правки, найденные во внешней копии, НЕ ДОЛЖНЫ вливаться безмолвно и ОБЯЗАНЫ направляться в CON-11, единственный путь уловления и классификации намеренных внешних правок, запускаемый этим событием.
  6. Развилка: механически неразрешимо (мастер оспорен, само разделение неверно)? Поднять к Распорядителю; если мастерство должно смениться, поднять как предложение о смене мастерства в MIR-1 (единственный исполнитель реестра).
  7. Заново прогнать сравнение, чтобы удостовериться в разрешении; закрыть запись дрейфа с кодом причины.
- Ограничения: Разрешение ОБЯЗАНО происходить только в ту сторону, какую объявляет conflict_rule; разрешение суждением по случаю не соответствует. Подкрученные руками проекции суть форки, а не проекции, и ОБЯЗАНЫ быть перегенерированы. Записи дрейфа неизменны и стареют (открытый дрейф сверх своего предела поднимается). Предпочтительны автоматические ежедневные проверки, чтобы расхождение замечала механика, а не неловкость. QSC-9 проверяет, что MIR-7 отработал в ритме, и выборочно проверяет честность его записей; при несовпадении он поднимает находку в MIR-7 и никогда сам не исполняет перегенерацию или маршрутизацию. FED-6 оценивает дрейф на границе этим движком по управляющему контракту.
- Ярус: ядро
- Разновидности: Одиночка: проверка хеша, вшитая во всякий скрипт публикации и сбора; по профилю «одиночка или минимум» из COMMON один недельный проход, исполняемый агентом, с одним сводным событием удовлетворяет механическим шагам MIR-3 и MIR-7 вместе. Команда: ночная работа-проход с оповещением Распорядителей. Федерация: поверхность «модель против проекции» простирается через границу; дрейф в федеративных Проекциях записывается этим движком и оценивается по управляющему контракту, где ищут семантическую связность, а не равенство байтов, а разрешение направляется через FED-9. Вручную: различие на глаз по чек-листу. Смешанно: Агент обнаруживает, человек разрешает спорные случаи (обычный случай). Самостоятельно: T3 обнаруживает и механически разрешает, при полном аудиторском следе.
- Метрики: Покрытие проверками дрейфа (доля потоков со сравнением); среднее время до обнаружения; среднее время до разрешения; доля повторяющегося дрейфа по наборам данных.
- Способы отказать: Дрейф разрешён перезаписью мастера (защита: инструментарий соблюдает объявленное направление; у разрешающего Агента доступ на запись есть только на стороне копии). Сравнение слишком грубо, чтобы заметить дрейф на уровне полей (защита: выборка Аудитора с полевыми различиями). Внешние правки проекции с обратной записью безмолвно влиты (защита: обязательное направление в CON-11, никакого слияния). Вторая петля обнаружения вырастает в другой семье и дважды обрабатывает ту же правку (защита: правило единственного движка; QSC-9 проверяет, CON-11 классифицирует, ACT-10 потребляет, но никто не обнаруживает). Тревоги о дрейфе копятся без внимания (защита: уровень обслуживания по возрасту открытых записей дрейфа с подъёмом).

### MIR-8 Карантин по устарелости

- Назначение: Помечать данные, которым больше не доверяют (истёкшие зеркала, упавшие конвейеры, неразрешённый дрейф, снимки с пометой опасности, сомнительные источники), чтобы всякий Потребитель и Агент видел недоверие явно. Карантин есть та самая помета доверия палитры, читаемая, но отмеченная (см. словарь семьи): он метит доверие, но никогда не удаляет данные, и он отличен от карантина допуска FED-8 и удержания по целостности QSC-9.
- Пусковое условие: Истечение уровня обслуживания из MIR-6; помета просеивания на опасности с шага 5 MIR-2; сбои сбора сверх политики повторов; дрейф, открытый сверх своего предела; вывод системы-источника из обращения; усмотрительное решение Распорядителя.
- Действующие лица: Агент; Распорядитель (усмотрительный карантин и всякое снятие); Потребители (видят пометы); Аудитор (проверяет, что пометы и вправду доходят до поверхностей чтения). Агент МОЖЕТ исполнять шаги с 1 по 3 и 5 на T3 для карантина по порогу, шаг 4 на T2; шаги 6 и 7 (виза по устранению и снятие) ОБЯЗАНЫ оставаться на T1 (Агент предлагает, человек одобряет каждое действие).
- Входы / Выходы: Входы: пусковое условие карантина с кодом причины, запись реестра, метаданные свежести, реестр потребителей CON-13. Выходы: состояние свежести «в карантине», пометы, распространённые на все поверхности потребления, уведомления, запись об устранении, событие снятия.
- Шаги:
  1. Принять пусковое условие карантина и его код причины.
  2. Установить состояние свежести набора данных в «в карантине» в реестре и метаданных свежести; данные остаются читаемыми, но помеченными; каноническое поле status не трогается никогда (состояние доверия и состояние потока суть независимые оси).
  3. Распространить помету на всякую поверхность потребления: рецепты ответов, панели, порождённые артефакты, исходящие Проекции и пакеты, квалификацию сигналов ACT-2 и пакеты контекста CTX-1 (где состояние карантина есть обязательный вход: оно блокирует испускание либо вынуждает понизить уверенность с подъёмом к Распорядителю по правилу класса, а жёстко заблокированные наборы данных исключаются из пакетов). Потребитель ОБЯЗАН видеть предупреждение всюду, где появляются эти данные.
  4. Развилка: требует ли политика жёсткой блокировки (безопасность, право, нарушение контракта)? Если да, приостановить затронутую Проекцию, а не только пометить: через GOV-7 для внутренних допусков и каналов, через FED-3 для допусков федерации; объект и его данные остаются целы (жизненный цикл проекции, а не объекта).
  5. Уведомить Распорядителя и зависимых Потребителей, разрешённых по CON-13.
  6. Устранить: починить конвейер, пересобрать, разрешить дрейф либо переопределить охват набора данных.
  7. Развилка: критерии выхода выполнены (есть удостоверенный свежий сбор и связанные записи дрейфа закрыты)? Распорядитель снимает карантин; снятие записывается как событие с обоснованием; спорные снятия поднимаются как решения GOV-1.
- Ограничения: Карантин НЕ ДОЛЖЕН сниматься без удостоверенного свежего состояния; пометы путешествуют с цитатами и происхождением; данные в карантине НЕ ДОЛЖНЫ нигде подаваться как нынешние; карантин есть обратимая пометка, но никогда не удаление; для содержимого с пометой опасности Распорядитель дополнительно ОБЯЗАН разобрать отчёт просеивания MIR-2 до снятия.
- Ярус: ядро
- Разновидности: Одиночка: один список карантина, который Владелец-Распорядитель держит честным. Команда: автоматический карантин по порогу с недельным разбором снятий. Федерация: состояние карантина сопровождает Проекции, так что партнёры наследуют сигнал недоверия; контракты МОГУТ требовать уведомления при карантине потребляемых наборов данных. Вручную: Распорядитель переключает помету руками. Смешанно: Агент помечает, Распорядитель снимает (обычный случай). Самостоятельно: пометка на T3, но снятие всегда остаётся на T1.
- Метрики: Время от пускового условия до карантина; средняя длительность карантина; доля выборочных чтений в карантине, где помета была показана (цель 100), причём выборка прямо включает квалификации сигналов ACT-2 и пакеты контекста CTX-1; доля повторного карантина по наборам данных.
- Способы отказать: Помета стоит в реестре, но невидима в момент чтения (защита: проверка пути чтения плюс выборка Аудитора по поверхностям потребления, включая оценки сигналов и пакеты). Набор данных в карантине, но свежий по времени, квалифицирует сигналы или входит в пакеты без пометы (защита: обязательная проводка входов на шаге 3 в ACT-2 и CTX-1). Карантин употреблён не по делу как удаление (защита: данные и история сохраняются по правилу; меняется только состояние доверия). Безмолвное снятие под давлением сроков (защита: снятие требует записанного события и удостоверенного сбора). Всё оказывается в карантине, и пометы теряют смысл (защита: разбор реалистичности уровней обслуживания на шаге 7 MIR-6).

### MIR-9 Архивирование вытесненных состояний

- Назначение: Сохранять вытесненные состояния модели, зеркала и снимки как воссоздаваемую историю, чтобы актуализация была неразрушающей: модель меняет свои утверждения, не теряя памяти, а исторические ссылки никогда не ломаются. MIR-9 есть процесс палитры для жизненного цикла и сохранения истории: другие семьи (исправление записей CON-8, миграция CON-12, конечные пакеты FED-11, конечное архивирование MIR-11) сохраняют историю через него.
- Пусковое условие: Всякая актуализация, заменяющая прежнее состояние; переход жизненного цикла в Архив или Выведено (канонический словарь состояний по Lifecycle, MU-V2-CORE-011, 4-5); вывод системы-источника из обращения; миграция CON-12, сохраняющая сырое состояние до миграции; конечное архивирование MIR-11; периодическое уплотнение по сроку хранения.
- Действующие лица: Агент; Распорядитель (применяет политику хранения и уплотнения); Владелец (одобряет всякое физическое удаление, дозволенное политикой; согласие не делегируется, записывается как решение GOV-1); Аудитор (проверяет воссоздаваемость). Агент МОЖЕТ исполнять шаги с 1 по 3 и 6 на T3 (механическое архивирование и заморозка) и шаг 4 на T2 (применение одобренной политики); сама политика хранения сочиняется и версионируется в GOV-2, а не здесь.
- Входы / Выходы: Входы: вытесняющие обновления, события жизненного цикла, политика хранения GOV-2. Выходы: сохранённые прежние состояния (история версий либо явный архив), события вытеснения, связывающие старое и новое состояние, замороженные выведенные зеркала, отчёты учений по реконструкции.
- Шаги:
  1. При всяком вытесняющем обновлении обеспечить, чтобы прежнее состояние было сохранено: по умолчанию история под контролем версий либо явное место архива для объёмных состояний.
  2. Записать событие вытеснения, связывающее старое и новое состояние, с его кодом причины (MIR-10).
  3. Развилка: выводится ли система-источник из обращения? Заморозить последнюю выгрузку как выведенное зеркало (статус в реестре retired); оно становится замороженным архивом только для чтения, по которому отвечают лишь исторически (по состоянию на последнюю выгрузку).
  4. Применить политику хранения, сочинённую и версионированную в GOV-2: что можно уплотнить, что хранится вечно. Идентичность, происхождение, история владения, связи, события и семантические ссылки ОБЯЗАНЫ пережить архивирование во всех случаях; историческая целостность имеет верх над физическим удалением, по Lifecycle (MU-V2-CORE-011) 13. Учение по реконструкции, уплотнение по сроку хранения и удаление с одобрения Владельца суть проработки палитры поверх этого называемого инварианта.
  5. Развилка: позволяет ли политика физическое удаление уплотнённого класса? Только с записанным одобрением Владельца (решение GOV-1; согласие не делегируется); иначе сохранять.
  6. Проводить периодическое учение по реконструкции: отстроить выбранное прошлое состояние из архива и проверить его; учение ОБЯЗАНО также подтвердить восстановимость из вынесенных копий QSC-13. Учение МОЖЕТ быть удовлетворено внутри сводного квартального обзора профиля «одиночка или минимум» из COMMON, по общему образцу повторной сертификации.
  7. Убедиться, что архивирование никогда не меняло каноническую Идентичность и что исторические ссылки по-прежнему разрешаются.
- Ограничения: Версионированное хранение обязательно для семантического содержимого; замороженные архивы только для чтения; учение по реконструкции как повторяющийся шлюз; консервативное хранение по умолчанию (хранить всё), пока нет политики GOV-2; удаление только по политике, одобренной Владельцем; архив лежит внутри охвата резервного копирования QSC-13 (вынесенные неизменяемые копии, отдельное хранение), а учение, которое не может восстановить из копий QSC-13, есть провалившееся учение.
- Ярус: ядро
- Разновидности: Одиночка: система контроля версий и есть архив; учение есть выгрузка старой ревизии. Команда: явные места архива для объёмных зеркал плюс система контроля версий для записей. Федерация: партнёры могут держать проекции состояний, которые источник позже заархивировал; архивирование у источника НЕ ДОЛЖНО обесценивать исторические ссылки партнёра. Вручную: заархивировать и подписать. Смешанно: Агент архивирует, Распорядитель уплотняет (обычный случай). Самостоятельно: архивирование на T3 с квартальным разбором учений.
- Метрики: Доля вытеснений с сохранённым прежним состоянием (цель 100); доля успешных учений по реконструкции (включая проверки восстановления из QSC-13); доля пройденных проверок целостности на выведенных зеркалах; расход хранилища против политики хранения GOV-2 (с проекциями GOV-5).
- Способы отказать: Перезапись на месте безмолвно уничтожает историю (защита: версионированное хранение как структурное требование, проверяемое валидацией). Гниение архива: нечитаемые форматы или сломанные ссылки годы спустя (защита: периодическое учение по реконструкции). Выведенное зеркало правят, чтобы починить прошлое (защита: соблюдение «только чтение»; исправления живут как аннотированные утверждения об архиве, мастерящиеся в модели). Уплотнение по сроку хранения удаляет свидетельство, нужное позже (защита: консервативные умолчания, одобрение Владельца через GOV-1 и множество «всегда переживает» на шаге 4). История внутри модели уцелела, но потерян весь репозиторий (защита: охват резервного копирования QSC-13 и проверка восстановления из вынесенных копий на учении).

### MIR-10 Таксономия причин обновления

- Назначение: Вести управляемую таксономию того, почему случаются обновления, и помечать всякое событие актуализации кодом причины, чтобы история изменений модели была объяснимой, аудируемой и разбираемой, а не потоком безымянных правок. Правило простановки простирается за пределы MIR: события перехода CON-6, CON-7 и CON-8 и события вытеснения ACT-10 и ACT-11 несут коды из этой же таксономии, сопоставленные с существующими базовыми кодами.
- Пусковое условие: Принятие модели (первая таксономия); обновление, чья причина не подходит ни под один существующий код; плановый разбор таксономии; запрос на разбор.
- Действующие лица: Распорядитель (мастерит таксономию); Агент; Аудитор (разбирает распределения причин). Агент МОЖЕТ исполнять шаг 2 на T3 (простановка на рутинных обновлениях) и шаги 3 и 4 на T2 (постановка неклассифицированных причин в очередь, составление разбора); изменения таксономии на шаге 5 ОБЯЗАНЫ оставаться на T1 (Агент предлагает, человек одобряет каждое действие).
- Входы / Выходы: Входы: базовая таксономия, события актуализации из MIR-2 по MIR-9, события перехода из CON-6, CON-7 и CON-8, события вытеснения из ACT-10 и ACT-11, пометы удостоверения воздействия с шага 6 ACT-8 и шага 5 ACT-9, события переоткрытия задачи из CTX-5. Выходы: события с кодом причины, очередь неклассифицированного, версии таксономии, периодический разбор распределения причин.
- Шаги:
  1. Принять базовую таксономию как набор данных, мастерящийся в модели. Базовые коды: scheduled-refresh; source-event; use-driven; actuation-verification (приём, служащий принудительному пересбору ACT-8 или независимому удостоверению ACT-9; проставляется шагом 6 ACT-8 и шагом 5 ACT-9); human-report; correction (в модели нашли и починили ошибку); drift-resolution; structural-change (сменились мастерство, уровень обслуживания или охват); quarantine или release; supersession-archival; migration-backfill (исполняется через CON-12); insufficient-context (проставляется на событиях переоткрытия задачи, вычислимый источник для метрики переделки CTX-5).
  2. Всякое событие актуализации, выпущенное из MIR-2 по MIR-9, всякое событие перехода CON-6, CON-7 и CON-8 и всякое событие вытеснения ACT-10 и ACT-11 ОБЯЗАНЫ нести ровно один основной код причины; второстепенные коды МОГУТ добавляться. Составное событие, выпущенное редакторской быстрой полосой (по COMMON), несёт свой код причины один раз и есть соответствующее свидетельство простановки.
  3. Развилка: ни один код не подходит? Проставить unclassified со свободным текстом и поставить случай в очередь на разбор таксономии; у очереди неклассифицированного есть предел возраста.
  4. По расписанию разбирать распределение причин по наборам данных: высокая доля correction сигналит о проблеме качества источника или преобразования; ноль обновлений use-driven сигналит о мёртвых данных; всплеск drift-resolution сигналит о протекающей проекции; всплеск actuation-verification сигналит о неустойчивой петле воздействия.
  5. Развивать таксономию как версионированное, одобренное Распорядителем изменение, следуя общему образцу повторной сертификации реестров из COMMON для планового разбора. Коды ОБЯЗАНЫ объявляться устаревшими, но никогда не удаляться и не переопределяться; исторические события сохраняют свой первоначальный смысл.
- Ограничения: Код причины обязателен на всяком покрытом событии (валидация отвергает непомеченные обновления); предел возраста очереди неклассифицированного; правило «объявлять устаревшим, а не переопределять»; находки разбора публикуются Распорядителю.
- Ярус: рекомендован
- Разновидности: Одиночка: базовые двенадцать кодов без изменений плюс ежегодный взгляд на распределение. Команда: отчёты о распределении по бандлам, питающие ретроспективы. Федерация: коды причин путешествуют с событиями синхронизации, чтобы партнёры могли отличить исправление от рутинного обновления, решая, как реагировать. Вручную: причина набирается в сообщении коммита по договорённости. Смешанно: Агент проставляет, Распорядитель разбирает очередь неклассифицированного (обычный случай). Самостоятельно: простановка на T3 с тревогами по аномалиям распределения.
- Метрики: Доля покрытых событий с кодом причины (цель 100); доля неклассифицированного; соблюдение ритма разбора таксономии; тренд доли correction по наборам данных.
- Способы отказать: Всё помечено одним кодом по умолчанию, и сигнал уничтожен (защита: проверка распределения Аудитором с нижней границей энтропии). Взрыв таксономии в десятки почти-дублей (защита: шлюз Распорядителя на T1 и устранение дублей при разборе). Коды со временем тихо переосмысливаются (защита: правило «объявлять устаревшим, а не переопределять»). Причины записаны, но никем не читаются (защита: плановый разбор на шаге 4 с публикуемыми находками). Исправления, сделанные через цепь CON, остаются невидимыми для разбора распределения (защита: расширенное правило простановки на шаге 2).

### MIR-11 Вывод модели из обращения и преемственность

- Назначение: Законно кончить модель или Измерение: слаженный вывод из эксплуатации, который не оставляет ни зеркал-зомби во Вселенных-партнёрах, ни живых учётных данных и допусков, ни постоянных работ, тревожащих по мёртвой модели, и сохраняет полную историю модели вместе с долговечным надгробием и указателями на преемника. Вывод из обращения есть акт жизненного цикла, но никогда не удаление.
- Пусковое условие: Решение Владельца вывести модель из обращения, записанное как событие решения GOV-1; преемственность или слияние в модель-преемника; устойчивая находка о нежизнеспособности из ресурсного планирования GOV-5, принятая Владельцем.
- Действующие лица: Владелец (приказывает вывод; согласие по существу не делегируется); Распорядитель (ведёт инструкцию вывода из эксплуатации); Агент; Аудитор (привлечён через GOV-6; заверяет закрытие); партнёры по федерации и Потребители (уведомляются). Агент МОЖЕТ исполнять механический демонтаж на шагах со 2 по 5 и механику архивирования на шаге 7 на T2; шаги 1, 6, 8 и 9 включают решение Владельца, закрывающее заявление о соответствии и заверение и ОБЯЗАНЫ оставаться на T1 (Агент предлагает, человек одобряет каждое действие), причём решение Владельца и заверение Аудитора не делегируются.
- Входы / Выходы: Входы: решение о выводе из GOV-1, реестр федераций (FED), реестры допусков (GOV-7, FED-3), список Контрактов делегирования (CTX-9), реестр постоянных работ QSC-15, реестр потребителей CON-13, политика хранения GOV-2, инвентарь учётных данных GOV-8. Выходы: последовательные события прекращения, последний отчёт валидации QSC-4 и снимок соответствия QSC-10, конечный архив MIR-9 с объявленным хранением, опубликованное надгробие с указателями на преемника, заверение закрытия Аудитором, конечное событие.
- Шаги:
  1. Записать решение Владельца о выводе как событие решения GOV-1 и заморозить новый приём: никаких новых записей реестра (MIR-1), никаких новых допусков (GOV-7, FED-3), никаких новых Контрактов делегирования (CTX-9), никаких новых федераций.
  2. Уведомить всех зарегистрированных Потребителей, разрешённых по CON-13, о графике вывода и указателях на преемника; отслеживать уведомление до полного завершения.
  3. Выстроить FED-11 по всякому партнёру по федерации: прекратить или передать всякую федерацию по её контракту, собирая подтверждения партнёров, чтобы ни один партнёр не сохранил непомеченного живого зеркала.
  4. Отозвать все Контракты делегирования через CTX-9 и вымести допуски GOV-7 и FED-3 до нуля живых в пределах объявленного TTL отзыва; прогнать зонд на стороне шлюза, проверяющий, что осиротевших прав не осталось.
  5. Демонтировать постоянные работы, планировщики и надзирателей через QSC-15, пока реестр работ этой модели не опустеет; вывести из обращения учётные данные и ключи через GOV-8.
  6. Прогнать последнюю валидацию QSC-4 и выпустить последний снимок соответствия QSC-10 как закрывающее заявление модели.
  7. Исполнить конечное архивирование через MIR-9: полная модель, история событий, реестры и свидетельство, по политике хранения GOV-2, с объявленным хранением и вынесенными копиями QSC-13.
  8. Опубликовать надгробие: минимальную долговечную запись, называющую модель, её срок жизни, её конечное событие, хранение её архива и указатели на преемника, с перенаправлениями входящих ссылок там, где это осуществимо.
  9. Аудитор заверяет закрытие: ноль живых учётных данных, ноль живых допусков, ноль работающих работ, полнота уведомления против CON-13, архив воссоздаваем; заверение записывается как конечное событие.
- Ограничения: Вывод из обращения НЕ ДОЛЖЕН идти без записанного решения Владельца (не делегируется). Последовательность обязательна: заморозка, затем уведомление, затем федерации, затем допуски и контракты, затем работы и учётные данные, затем снимок, затем архивирование, затем надгробие, затем заверение. Никакого физического удаления во время вывода сверх того, что политика хранения GOV-2 позволяет с одобрения Владельца. Заверяющий Аудитор НЕ ДОЛЖЕН быть тем, кто исполнял инструкцию. Надгробие и хранение архива переживают модель.
- Ярус: ядро
- Разновидности: Одиночка: инструкция сжимается до допусков, работ, архива и надгробия; закрытие заверяет внешний коллега-Аудитор (привлечён через GOV-6). Команда: инструкция под ведением Распорядителя с чек-листами демонтажа по семьям. Федерация: выстраивание FED-11 задаёт весь график; партнёры сохраняют исторические проекции по федеративному правилу MIR-9, помеченные как происходящие из выведенной модели. Вручную: печатный чек-лист, пройденный один раз, где всякая галочка есть событие. Смешанно: Агент исполняет демонтаж на T2, люди держат решение и заверение (обычный случай). Самостоятельно: неприменимо; решение и заверение никогда не бывают самостоятельными. Пример MOS (внешнее эталонное Измерение, orkestron-ai/meta-orchestrator-state): вывод Измерения из обращения без того, чтобы бросить его контракты с агентами-гражданами или исторические ссылки его партнёров.
- Метрики: Остаточные живые учётные данные, допуски и работы на момент заверения (цель ноль); полнота уведомления потребителей против CON-13 (цель 100); время от решения до заверения; доля разрешаемых указателей на преемника после вывода.
- Способы отказать: Зеркала-зомби остаются во Вселенных-партнёрах (защита: выстраивание FED-11 по партнёрам со сбором подтверждений). Живые учётные данные переживают демонтаж (защита: подметающий проход вывода GOV-8 плюс проверка нулевого остатка Аудитором). Постоянные работы вечно тревожат по мёртвой модели (защита: реестр QSC-15 опустошён и проверен на шаге 5). История утрачена в спешке закрытия (защита: конечное архивирование MIR-9 с копиями QSC-13, поставленное шлюзом перед конечным событием). Вывод застревает на полпути, оставляя модель ни живой, ни закрытой (защита: последовательная инструкция с событиями по шагам, где заверение Аудитора есть единственное законное конечное состояние).