Project-DR и Enterprise-DR часто называют в одной связке, хотя за этими именами стоят два разных объекта с разными владельцами и разными жизненными циклами. Project-DR (Project Digital Replica) - проектная цифровая реплика, внутренняя производственная технология и проектная среда, в которой строится и при необходимости структурно перестраивается профессиональная модель предприятия. Enterprise-DR (Enterprise Digital Replica) - эксплуатационная машиночитаемая модель конкретного предприятия, полученная из принятого состояния Project-DR. Заказчику передают вторую, первая остаётся у исполнителя: публичный разбор методологии описывает это разделение как базовое.
Физически заказчик получает Enterprise-DR Runtime Kit: комплект для развёртывания и эксплуатации, в который входят база на PostgreSQL (эталонный вариант для версии 2.5.1), программный интерфейс Enterprise-DR API и локальная LLM. Проектная среда исполнителя в комплект не входит.
Дальше начинается главное. Изменение самой профессиональной модели предприятия не выполняется в runtime: оно возвращается в Project-DR через structural handoff, после чего выходит новая версия Enterprise-DR со своим runtime. Ниже - как устроены все звенья этой цепочки.
Что такое Project-DR и Enterprise-DR: ключевое различие
Разделение ролей определяет всё остальное: кто владеет носителем модели, у кого остаётся проектная история и как быстро можно поменять структуру. Свести оба контура в таблицу проще всего.
| Признак | Project-DR | Enterprise-DR |
|---|---|---|
| Что это | проектная цифровая реплика, внутренняя производственная технология | эксплуатационная машиночитаемая модель конкретного предприятия |
| Назначение | построение и структурная перестройка профессиональной модели | повседневная эксплуатация модели |
| Кому передаётся | не передаётся, остаётся у исполнителя | передаётся заказчику |
| Ключевые части | Project Core, Unified Project Store | база Enterprise-DR, Enterprise-DR API, локальная LLM |
| Как меняется | проектная работа внутри среды исполнителя | новая версия после structural handoff |
Project-DR: внутренняя среда исполнителя
Аналогия, которая помогает не путать контуры: Project-DR - это сборочный цех вместе с чертежами и оснасткой, Enterprise-DR - изделие, которое уезжает к клиенту. Цех в поставку не входит. Внутри Project-DR модель предприятия перестраивают: меняют состав сущностей, связи и правила. Такая перестройка требует проектной работы и не сводится к правке одной записи в базе.
Enterprise-DR: что именно получает заказчик
Enterprise-DR - машиночитаемая модель конкретного предприятия, собранная из принятого состояния Project-DR. Это рабочий объект, а не комплект проектной документации. В версии 2.5.1 база Enterprise-DR построена на PostgreSQL, и СУБД выступает эталонным вариантом хранения для этой версии. Практический эффект: модель лежит в реляционной базе и доступна программно, а не вычитывается вручную из таблиц и PDF.
Где накапливается знание: Project Core и Unified Project Store
Знание о предприятии появляется не в одном месте. Пока идёт проектирование, оно распределено по специализированным ядрам, и только потом собирается в машиночитаемый слой.
Project Core: носитель специализированного знания
Project Core (проектное ядро) - проектный носитель специализированного ресурса. В нём хранится подробный результат работы по конкретному проекту. Каждое ядро отвечает за свою предметную область. Для логистической компании одно ядро может разбирать маршрутизацию, второе - складские операции, третье - работу с перевозчиками. Подробность здесь важна: ядро хранит результат целиком, включая детали, которые в клиентскую модель могут и не попасть.
Unified Project Store: сборка принятых проекций
Unified Project Store (единое проектное хранилище) - машиночитаемый слой Project-DR. В него попадают принятые проекции результатов специализированных Project Core: согласованные и утверждённые фрагменты, а не сырые черновики. Смысл слоя в том, что разрозненные ядра перестают быть набором отдельных артефактов и превращаются в связную структуру, из которой можно собирать клиентскую модель.
Дисциплина здесь сродни работе с архитектурной моделью системы, когда до генерации кода фиксируют уровни, связи и контракты: материал о проектировании вместо кода разбирает похожую логику для разработки. Разница в предмете: там речь о Change Set для агента, здесь - о baseline для компиляции в Enterprise-DR.
Компиляция baseline в очищенный клиентский release
Принятая baseline - это зафиксированное состояние Unified Project Store. Из неё собирают очищенный клиентский release: всё внутреннее, что относится к проектной кухне исполнителя, отсекается, а на выходе получается эксплуатационная модель Enterprise-DR.
Копированием проектных данных дело не ограничивается. Release собирается как отдельный артефакт: у него своя структура, пригодная для загрузки в клиентскую базу, и свой набор того, что вообще показывается наружу. Детальных шагов компиляции в открытых материалах нет, поэтому перечислять конкретные стадии (нормализацию, проверки, генерацию схем) не будем. Известно другое: результат отделён от проектного слоя и живёт самостоятельной жизнью.
Очистка работает в обе стороны. Заказчик получает модель без проектного шума, а исполнитель сохраняет рабочую среду, куда можно вернуться при следующем цикле изменений.
Что физически получает заказчик: Enterprise-DR Runtime Kit
Enterprise-DR Runtime Kit - комплект, который передают заказчику для развёртывания и эксплуатации Enterprise-DR. На его основе поднимается Enterprise-DR Runtime: физически работающая система, где клиентская модель загружена в базу данных и доступна через Enterprise-DR API. Технология Project-DR в комплект не входит, и это принципиальная часть сделки: описание поставки прямо разделяет эксплуатационную модель и проектную среду.
PostgreSQL как эталонная база Enterprise-DR
В версии 2.5.1 PostgreSQL используется как эталонная база Enterprise-DR. Практический эффект: модель хранится в реляционной СУБД, и доступ к ней идёт обычными средствами, а не через закрытый формат, который нельзя прочитать без вендора. Других свойств этому выбору приписывать не будем: в открытых материалах нет ни причин выбора, ни сравнения с альтернативами.
Enterprise-DR API: доступ к профессиональному контексту
Enterprise-DR API - программный интерфейс доступа к эксплуатационной модели. Через него получают профессиональный контекст, причины решений, зависимости, сигналы и операции изменения. Пример: интеграция запрашивает не только ответ по конкретной операции, но и обоснование, почему модель считает такой порядок действий корректным, и какие сущности от него зависят. Это отличает рабочий контур от чат-бота с базой знаний: у ответа есть прослеживаемая основа внутри модели.
Локальная LLM в составе runtime
В runtime-комплект входит локальная LLM. Работает она на стороне заказчика, что привычно для тех, кто разворачивает модели в своём контуре и не хочет отправлять рабочие данные наружу. Как именно LLM связана с API, где проходит граница между генерацией и выборкой из базы, в переданных материалах не раскрыто. Это первое, что стоит уточнять у исполнителя до старта.
Повседневная эксплуатация: ответы, сигналы, версионирование
Runtime - рабочая среда, и весь её смысл в трёх повторяющихся операциях: получить ответ, зафиксировать сигнал, сохранить новое состояние, не потеряв предыдущее.
Ответы на профессиональные вопросы
Ответ собирается из профессионального контекста, доступного через Enterprise-DR API, и формируется с участием локальной LLM. Качество ответа зависит от полноты модели, которую загрузили: если предметная область в baseline проработана слабо, интерфейс не спасёт. Гарантий безошибочности никто не даёт, и это нормально для систем, где ответ строится на модели, а не на жёстко прописанном сценарии.
Практика работы с таким контуром близка к context engineering: разбор context engineering показывает, как подготовка контекста влияет на качество ответов и где уместнее обычный запрос, а не генерация.
Регистрация сигналов и обратная связь
Сигнал - это событие или обратная связь, которую фиксируют в системе. Сигналы копятся и служат материалом для последующего анализа и решений об изменениях модели. Конкретный перечень типов сигналов в открытых материалах не приводится, поэтому описывать «сигнал о противоречии в регламенте» как готовую функцию не будем.
Версионирование без перезаписи предыдущих состояний
Новые состояния модели не затирают предыдущие. После регистрации сигнала и следующего изменения появляется новая версия, а старая остаётся доступной: её можно использовать для аудита и для сравнения, что именно поменялось и почему. Для предприятий, где решения приходится объяснять, это важнее красоты интерфейса: вопрос «на какой версии модели получен этот ответ» имеет конкретный ответ.
Граница runtime: structural handoff и выпуск новой версии
Почему изменения модели не делаются в runtime
Runtime рассчитан на эксплуатацию. Структурная перестройка профессиональной модели - смена сущностей, связей и правил - требует проектной работы, а её ведут в Project-DR. Если разрешить такие правки прямо в рабочем контуре, модель быстро разъедется по версиям, а происхождение решений станет непрослеживаемым. Разделение контуров сохраняет целостность и управляемость.
Похожая логика встречается в методологиях, где ИИ предлагает, человек утверждает, а применяет детерминированный исполнитель: Agent-Ops 0.4.0 описывает именно такой порядок для ИТ-операций.
Structural handoff: возврат изменений в Project-DR
Structural handoff - передача структурных изменений из runtime обратно в Project-DR. Механизм в переданных материалах не раскрыт: нет описания формата передачи, ролей и порядка согласования, поэтому детализировать нечего. Известен результат: после handoff выпускается новая версия Enterprise-DR, которая снова проходит путь до очищенного клиентского release и runtime-комплекта. Именно эта граница описана в разборе перехода как ключевая.
Практические выводы и ограничения подхода
Подход рассчитан на предприятия, которым нужна локальная эксплуатационная модель с прослеживаемыми решениями и возможностью менять структуру через проектный цикл. Связка из PostgreSQL, Enterprise-DR API и локальной LLM закрывает типовой набор требований: данные не покидают контур заказчика, доступ к модели программный, предыдущие версии сохраняются.
Ограничения стоит назвать прямо.
- Технология Project-DR остаётся у исполнителя. Заказчик не может сам перестроить модель: для структурных изменений нужен возврат в проектный контур, значит, зависимость от исполнителя сохраняется.
- Цикл обновления модели длиннее, чем правка записи в базе: изменение проходит через structural handoff и выпуск новой версии Enterprise-DR.
- В открытых материалах нет данных о производительности, стоимости, требованиях к железу под локальную LLM и о конкретных сценариях развёртывания. Оценивать эти параметры по одному описанию несерьёзно.
- Детали компиляции baseline и устройства structural handoff не раскрыты, так что часть архитектуры придётся уточнять на месте.
По версии 2.5.1 подтверждён только эталонный выбор базы: PostgreSQL. Всё остальное в этой версии закрыто от внешнего наблюдателя.
Если планируете такой контур, начните с двух вопросов исполнителю: что именно входит в Enterprise-DR Runtime Kit и как оформляется structural handoff. Ответы на них определяют, сколько вы сможете менять сами, а сколько придётся отдавать обратно в проект.