> Перевод даётся для удобства чтения. Нормативным является английский оригинал.

# Виртуальная проекция

**Спецификация Мета-Вселенной**

**Идентификатор документа:** MU-V2-CORE-012  
**Название:** Виртуальные проекции и горячие/холодные описательные факты  
**Класс документа:** нормативный  
**Версия:** 2.0 (черновик)  
**Статус:** рабочий черновик  
**Нормативные ссылки:** MUC, [Проекция](../04-core-concepts/Projection.md), [Событие](../04-core-concepts/Event.md), [Синхронизация](../03-federation/Synchronization.md), [Контракт](../04-core-concepts/Contract.md)  
**Информативные ссылки:** [Прослеживаемость](../02-architecture/Traceability.md), [Валидация](../02-architecture/Validation.md)  
**Копирайт:** © Orkestron.AI  
**Лицензия:** Apache-2.0

---

# 1. Назначение

Не все факты движутся с одинаковой скоростью. Структура API меняется редко; метрика задержки меняется каждую секунду. Обращаться с ними одинаково значит навязать себе плохой выбор: либо фиксировать изменчивые факты в модели и утопить её в шуме («усиление записи»), либо хранить их снаружи и тем самым лишить модель роли источника истины.

Этот документ решает задачу, классифицируя описательные факты как **холодные** или **горячие** и определяя **Виртуальную проекцию** - живое, управляемое контрактом представление, которое раскрывает горячие факты *без их материализации в модели*.

---

# 2. Холодные и горячие описательные факты

**Описательный факт** фиксирует нечто истинное о реальности (в отличие от нормативного правила, которое предписывает). Описательные факты классифицируются по изменчивости:

| Класс | Примеры | Обращение |
|-------|----------|-----------|
| **Холодные** | структура модели данных, схемы API, зависимости, владение | Материализуются как обычные [Объекты](../04-core-concepts/Object.md) и [Связи](../04-core-concepts/Relationship.md); версионируются; получают отпечаток |
| **Горячие** | метрики, логи, оповещения, живые сессии, текущее состояние инфраструктуры | **НЕ** материализуются; раскрываются как **Виртуальная проекция**, опирающаяся на живой источник |

Граница является модельным решением, записанным у самого факта; факт МОЖЕТ быть переведён из горячих в холодные (например, стабилизировавшаяся конфигурация) через явное изменение.

---

# 3. Определение

**Виртуальная проекция** - это [Проекция](../04-core-concepts/Projection.md), содержимое которой **вычисляется при чтении из живого источника**, а не хранится в модели.

Виртуальная проекция ОБЯЗАНА:

- ссылаться на Мета-Объект или систему, которую она проецирует (`subject`);
- объявлять свой **источник** (поток, запрос или конечную точку) и характеристику **свежести** (например, реальное время, выборка, окно);
- управляться [Смысловым контрактом](../04-core-concepts/Contract.md), как и любая другая Проекция;
- нести [происхождение](../02-architecture/Traceability.md), указывающее на живой источник, чтобы потребитель знал начало факта и его давность.

Виртуальная проекция НЕ ДОЛЖНА изменять каноническое состояние, а её чтение НЕ ДОЛЖНО порождать изменение модели. Модель остаётся стабильной, значение остаётся живым.

---

# 4. Почему это важно (без усиления записи)

Поскольку горячие факты читаются через Виртуальные проекции, а не записываются в модель:

- каноническая модель **не** переписывается на каждом тике метрики;
- нет постоянного шторма конфликтов слияния от высокочастотных обновлений;
- модель остаётся источником истины о *структуре и смысле*, а живые системы остаются источником истины о *текущих значениях*;
- ИИ-агент может на лету прочитать «какова частота ошибок прямо сейчас?», при этом модель никогда не утверждает, что *хранит* это число.

---

# 5. Горячие факты и События

Виртуальная проекция даёт *текущее значение*; когда горячий факт пересекает значимый порог, он МОЖЕТ дополнительно породить [Событие](../04-core-concepts/Event.md) (например, событие `Lifecycle` или `Conflict` при нарушении). События - долговечная неизменяемая запись; Виртуальная проекция - эфемерное живое представление. Одно дополняет другое: поток читается вживую, а значимые моменты запоминаются.

---

# 6. Федерация Виртуальных проекций

В [федерации](../03-federation/Synchronization.md) горячий факт разделяется как **поток**, а не как повторяющиеся фиксации: производитель доставляет потребителю обновления `SyncEvent` по контракту (путь [синхронизации MUFP](../03-federation/MUFP-Messages.md)), вместо того чтобы вынуждать потребителя материализовать и заново сохранять каждое изменение. Это федеративное выражение того же принципа: **синхронизируйте смысл и изменение, а не сырые строки.**

---

# 7. Валидация

Виртуальная проекция соответствует спецификации, когда она:

- управляется Контрактом и объявляет цель (как любая Проекция);
- объявляет свой источник и свежесть;
- не материализуется в каноническое состояние и не изменяет его;
- несёт происхождение до своего живого источника.

Модель НЕ ДОЛЖНА записывать горячий факт как холодный материализованный факт без явного перевода (раздел 2).

---

# 8. Архитектурные инварианты

- Чтение Виртуальной проекции НЕ ДОЛЖНО изменять модель.
- Горячие факты НЕ ДОЛЖНЫ фиксироваться в канонической модели так, будто они холодные.
- Виртуальная проекция ОБЯЗАНА управляться контрактом и нести происхождение.
- Модель остаётся авторитетной для структуры и смысла; живые системы остаются авторитетными для текущих значений.

---

# Дальнейшие направления

- Формат дескриптора **виртуального потокового представления** (привязка источника, окна, выборка) в MUIF, чтобы виртуальные проекции сами были обнаружимы.
- Стандартные сигналы **дрейфа результата**, выводимые из горячих фактов (см. [Валидацию](../02-architecture/Validation.md)).

---

# Заключение

> Модель должна помнить, что вещи *означают* и как они *устроены*, а не пытаться помнить каждое значение, которое было у них миллисекунду назад. Виртуальные проекции оставляют живые числа живыми, а смысл - неподвижным.