Phase — архитектурный подход к построению цифрового предприятия

Архитектура кибер-предприятия эпохи ИИ

О чём этот документ

Это описание Phase — архитектурного подхода к построению информационных систем, предназначенных для автоматизации бизнеса. В основе Phase лежат две взаимосвязанные идеи: понятие цифрового предприятия и механизм управления жизненным циклом объектов через фазовые переходы.

Phase реализуется через Phase Engine — программный движок, который исполняет этот подход: отслеживает фазы объектов, обрабатывает фазовые переходы, управляет порождением дочерних объектов и подписками. В тексте: Phase — концепция и подход, Phase Engine — его программная реализация, фаза — один из трёх примитивов движка.

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

Часть I. Цифровое предприятие

Проблема

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

Для построения систем в новой парадигме нужна информационная модель, которая делает это удобным — не как надстройка над готовой архитектурой, а как её основа.

Идея

Рассматривать предприятие изначально как автоматическую кибернетическую систему — а не как набор людей с инструментами. Автоматизация в ней не исключение, а правило по умолчанию; участие человека — осознанное решение там, где оно действительно нужно.

Для описания и программирования работы такой системы использовать модель, привычную человеческому восприятию и давно используемую в программировании: объекты, которые могут изменять своё состояние и совершать действия. Договор, заказ, счёт, клиент — не строки в таблице, а объекты с поведением, жизненным циклом и связями. Эта модель одинаково понятна бизнес-аналитику, разработчику и ИИ-агенту.

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

Определение

Цифровое предприятие — кибернетическая информационная система, которая в процессе своей работы стремится достичь целей, поставленных перед ней владельцами.

Цифровое предприятие имеет собственный «двигатель», который действует двумя способами: реактивно — реагируя на входящие сигналы из реального мира и внутренние события, и активно — самостоятельно инициируя действия для достижения целей.

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

В рамках цифрового предприятия человек — это один из ресурсов, которые оно использует в своей работе, наравне с программными агентами, интеграциями и внешними сервисами.

Цифровые объектные модели

Цифровые объектные модели делятся на два вида.

Объекты-двойники имеют конкретный аналог в реальном мире. Между моделью и реальным объектом существует двусторонняя связь через адаптеры: входные принимают события из реального мира и обновляют модель, выходные инициируют действия в реальном мире при изменении модели. Примеры: Счёт — выставлен → оплачен; Договор — на подписании → подписан → исполняется → закрыт; Заказ — принят → в сборке → отгружен → доставлен.

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

Информационные объекты существуют только в цифровой среде — у них нет двойника в реальном мире. Их жизненный цикл полностью замкнут внутри системы: задача, карточка согласования, отчёт, конфигурация агента. Система управляет обоими видами одинаково; разница в одном — изменение объекта-двойника автоматически отражается в реальном мире через адаптер.

Часть II. Движок Phase

Проблема

Движок должен отвечать двум противоречивым требованиям. С одной стороны — быть простым и предсказуемым при программировании, понятным человеку и ИИ-агенту. С другой — быть достаточно мощным, чтобы покрывать все потребности предприятия: параллельные процессы, ветвление, таймеры, компенсации, взаимодействие с внешним миром.

Идея: три примитива

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

Фаза. Объект существует в одной из конечного множества фаз. Фаза — период жизненного цикла, в котором объект находится до выполнения критерия выхода: условия по полям, при котором движок инициирует переход. Фазовый переход мгновенен: условие по полям выполнено → объект скачком переходит в новую фазу.

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

Подписка. Объект может подписаться на фазу другого объекта: когда источник покидает указанную фазу, движок записывает сигнал в системное поле подписчика. Сигнал содержит контекст перехода — из какой фазы и в какую. Подписки бывают статические (все экземпляры типа реагируют на все экземпляры источника — связь архитектурная) и динамические (создаются движком при порождении между конкретными родителем и потомком).

Phase Engine гарантирует атомарность переходов и сериализацию всех изменений полей объекта — от какого бы источника они ни шли. Изменения применяются по одному и по порядку; каждое проверяется на актуальных значениях полей. Одновременная работа человека и агента над одним объектом не теряет обновлений и не порождает противоречивых переходов.

Ядро движка намеренно реактивно: оно отвечает только на изменения полей. Активное поведение — действия по расписанию, контроль сроков, периодический анализ — обеспечивается планировщиком и агентами через тот же механизм: планировщик записывает значение в системное поле, агент обновляет агентские поля — и движок реагирует как на любое другое изменение.

Подробнее о фазе

При нахождении в фазе возможны два варианта поведения. Ожидание с анализом — объект ждёт внешнего события, но параллельно человек или агент анализирует ситуацию и заполняет поля; переход происходит, когда совокупность условий выполнена. Активная работа — участники производят работу внутри фазы, чтобы добиться выполнения условия выхода.

Пример ожидания: Счёт — фаза «Ожидание платежа». Условие оплата_получена = истина выполнится само, когда банк пришлёт подтверждение. Параллельно агент анализирует платёжную историю и обновляет риск_неоплаты. Пример активной работы: Сделка — «Согласование условий поставки», условие условия_согласованы = истина; менеджер или агент ведёт переговоры и ставит значение по итогу.

В обоих случаях механика одна: движок не принимает решений на основе времени — он реагирует только на изменения полей. Момент входа в фазу фиксируется в аудите, но сам по себе не является условием перехода.

Поля и фазовый переход

Движок проверяет условия перехода при каждом изменении любого поля. Условия описываются как таблица: из какой фазы, при каком наборе условий — в какую фазу. Строки читаются сверху вниз, первое совпадение срабатывает.

Язык условий

Условие перехода — логическое выражение над полями: атомарные проверки, соединённые связками «и», «или», «не». Видов проверок три:

Словарь намеренно закрыт: условие — это проверка, а не вычисление. Движок не агрегирует и не вызывает функций. Всё, что требует вычисления, вычисляет участник — агент, адаптер, планировщик, дочерний объект — и фиксирует в поле. Поэтому условие всегда можно прочитать вслух, и это чтение в точности совпадает с тем, что проверит движок.

Поля в фазе

Тип поля определяет не только, кто пишет значение во время работы, но и кто заводит поле при проектировании. Агентские и пользовательские поля настраивает инженер в конфигураторе — это сборка поведения из готового словаря. Системные поля заводит только разработчик: за каждым стоит код — адаптер, обработчик планировщика, канал синхронизации. Разработчик строит словарь возможного, инженер собирает из него поведение.

Инструменты в фазе

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

Два слоя внутри фазы

Поток фактов — сырые сигналы в течение фазы: платёж получен, клиент ответил, истёк срок. Каждый факт фиксируется в журнале фазы — неизменяемой хронике. Дистиллят — поля объекта, наилучшее доступное знание о его свойствах. Движок проверяет условия перехода по дистилляту, а не по сырым фактам.

Отсюда темп системы: поле меняется в темпе бизнеса, а не в темпе сигналов. Высокочастотный поток — телеметрия, котировки — остаётся потоком фактов и дистиллируется адаптером или агентом до значимого значения. Phase — модель бизнес-темпа; скоростная обработка потоков — работа адаптеров, не движка.

Временной разрыв

Цифровая модель никогда не является мгновенной копией реального объекта. Между моментом события в реальном мире и моментом, когда система узнала, всегда есть разрыв. Phase работает с этим явно: каждое поле хранит не просто значение, а и его свежесть — когда знание было актуальным. Агент и человек знают, на чём стоят: на свежем сигнале или на оценке трёхдневной давности.

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

Цифровая модель — это наилучшее доступное знание о реальном объекте, а не абсолютная истина. Система не притворяется, что знает реальность — она знает, что именно ей известно и когда это знание обновилось.

Симметрия участников

Ключевое свойство Phase: ни одна из распространённых систем управления процессами не строит участие человека и ИИ-агента на одном и том же механизме.

Сотрудник и ИИ-агент изменяют фазу объекта через один механизм — запись в поле. Нет специального «шага человека» и «шага агента». Оба записывают значение → движок проверяет условия → переход происходит или нет. Тип поля управляет только правом записи; логика переходов к типам слепа — движок проверяет лишь значения полей.

Полная симметрия достигается, когда сотрудник формализует своё знание — вносит его в поля до принятия решения. Тогда агент и человек работают с одной информационной основой, и передача решения от человека к агенту становится возможной без потери качества. Следствие:

Степень участия человека в жизненном цикле объекта — это конфигурация, а не архитектура.

Адрес агента

тип объекта × фаза → конфигурация агента

Агент активируется при входе объекта в заданную фазу и повторно при каждом значимом событии или по расписанию. Он получает поля объекта, заполняет агентские поля, завершает работу. Решение о переходе принимает движок — не агент. Это даёт минимальный контекст, чистую ответственность, аудируемость (каждое действие привязано к объекту, фазе, версии конфигурации и снимку контекста) и версионируемость конфигураций.

Три примитива покрывают сложные паттерны

Параллельное согласование — порождение нескольких карточек согласования, каждая инкрементит счётчик родителя. Компенсация — порождение объекта с компенсационным жизненным циклом. Ветвление — порядок строк в таблице переходов. Таймеры — планировщик пишет в системное поле в заданное время. Глубокая иерархия — одноуровневая агрегация: каждый уровень агрегирует только своих детей. Вложенные этапы — либо обычные плоские фазы, либо дочерний объект, если у подпроцесса есть собственное знание. Вложенности состояний, от которой Phase отказался, не требуется.

Часть III. Что даёт Phase

Единый естественный взгляд на бизнес

Человек думает о бизнесе через фазы задолго до информационных систем. Когда каждый значимый объект имеет цифровую модель с фазами, возникает единая карта объектов в разных фазах — продажи, склад, финансы, производство описываются одним языком. «Сколько договоров в фазе согласования?», «Какие счета просрочены?» — прямые запросы к состоянию системы, понятные руководителю, разработчику и агенту. История каждого объекта — полная и неудаляемая.

Скорость реакции предприятия

Каскад фазовых переходов обеспечивает быструю реакцию всего предприятия на единичное событие — без центрального координатора, каждый объект реагирует локально. Время реакции определяется глубиной цепочки переходов, а не периодичностью опроса.

Автономия настраивается итеративно

Любой объект может начать с ручного управления и двигаться к автономии без переработки архитектуры. Это снимает главное возражение против ИИ-автоматизации: начните с «агент предлагает, человек подтверждает», а когда уверенность накоплена — уберите пользовательское поле из условия перехода.

Phase как источник обучающих данных

Для каждой активации агента есть контекст, решение, исход и коррекция человека — структура, нужная для улучшения агентов, появляется автоматически, без отдельной разметки. Данные используются для улучшения инструкций, дообучения модели и измеримого сравнения версий агента. Данные Phase размечены по умолчанию — большинство систем платят за такую разметку отдельно.

Код предсказуем для ИИ-агентов

Добавление типа объекта — заполнение конфигурационной схемы фиксированной структуры. Ограниченный словарь — три примитива, три типа полей, таблица переходов — позволяет агенту работать без риска изобрести неправильный паттерн. Каждая конфигурация имеет машинно-проверяемую схему; не прошедшая проверку не применяется. Для агента программирование становится замкнутым циклом: сгенерировал — проверил — исправил — применил.

Жизненный цикл проверяется до запуска

Таблица переходов — математический объект, доступный статическому анализу: можно проверить, что каждая фаза достижима, нет непреднамеренных фаз-ловушек, инварианты безопасности соблюдены («счёт не может оказаться в фазе „Оплачен", если оплата не получена»). Системам с жизненным циклом в коде такая проверка недоступна. Верифицируемость позволяет расширять автономию на доказательстве, а не на доверии.

Масштаб: количество вместо разнообразия

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

Часть IV. Управление адаптацией

Часть I описала, как предприятие действует. Но это лишь один контур управления. Полное управление — это два контура. Управление в системе — вести объекты к целям при заданной структуре. Управление адаптацией — менять саму структуру, когда её версия перестаёт достигать целей: ставить и пересматривать цели, перестраивать конфигурации, переводить живые объекты на новую структуру.

Кибернетика давно установила: жизнеспособная система обязана управлять и собой. Вопрос не в том, нужен ли этот контур, а в том, каким механизмом он построен. Обычный ответ — отдельный привилегированный слой вне модели (панель администратора, релиз кода). Phase даёт другой ответ: контур адаптации построен теми же тремя примитивами. Цель — объект Phase. Изменение конфигурации — объект Phase. Модель управления оказывается полной — она достаёт до самого верха, оставаясь одной моделью.

Целевой слой: цель как объект

Цель — информационный объект. Целевое значение ставит владелец (пользовательское поле), текущее обновляет аналитический контур (системное), оценку траектории даёт агент (агентское). Фазы цели: сформулирована → активна → достигнута, с путями пересмотра и отмены. При уходе оценки за порог цель переходит в «Пересмотр» и порождает корректирующие объекты — инициативы, задачи, эксперименты. Декомпозиция стратегии на подцели — это порождение дочерних целей.

Самоизменение: изменение конфигурации как объект

Акт изменения конфигурации не может быть привилегированной операцией вне модели — иначе движение счёта проходит фазы и аудит, а изменение таблицы переходов происходит бесследно. Решение: изменение конфигурации — обычный объект Phase с жизненным циклом «предложено → проверено → одобрено → применено» и компенсационным объектом отката. Проверки (статический анализ, тесты) заполняют поля автоматически; одобрение человека — пользовательское поле в условии перехода. Рекурсия конечна: тип «Изменение конфигурации» — системный, меняется только обновлением движка.

Кто адаптирует систему

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

Живые объекты при смене конфигурации

Каждый объект знает, по какой версии конфигурации живёт. По умолчанию объект дожинает жизненный цикл на своей версии — изменение затрагивает только новые. Если изменение должно затронуть живые объекты, политика перевода описывается в самом объекте изменения и проверяется статически: каждая фаза с живыми объектами должна быть покрыта сопоставлением. Смена версии аудируема пообъектно.

Рекурсивное масштабирование: предприятие как объект

Само предприятие может быть объектом внутри другого предприятия. Холдинг — это цифровое предприятие, чьи ресурсы — подчинённые предприятия. Связь между уровнями — знакомый механизм объекта-двойника: верхнее предприятие держит у себя цифрового двойника подчинённого и управляет им через адаптеры. Граница подчинённого не размывается, а становится границей двойника. Иерархия предприятий любой глубины описывается тем же словарём, что и жизненный цикл одной сделки.

Тёмное предприятие, которое перестраивает себя

Классический образ — тёмное предприятие: цех функционирует без людей, но люди снаружи контролируют и перестраивают его. Phase достраивает образ на уровень выше: контур, которым предприятие перестраивают, тоже получает инструмент — того же агента, ту же симметрию, ту же градуируемую автономию.

Граница автономии проходит по природе агента: он действует из накопленного знания, а новое привносит человек. Контур управления замкнут и работает сам, осознанно привлекая человека там, где упирается в границу известного. Не машина вместо людей — машина, которая точно использует человеческую мудрость, экономя её на повторяемом и обращаясь к ней за новым.

Чем Phase не является

Не BPMN-движок. BPMN строит граф процесса с токенами; Phase строит сеть объектов с фазами. Единица — объект, а не процесс.

Не Temporal / Cadence. Они оркеструют долгие процессы через код; Phase декларативен — жизненный цикл описывается конфигурацией.

Не событийный журнал. Event sourcing строит состояние из потока событий; Phase хранит фазу и поля напрямую, фиксирует снимки при переходах.

Не библиотека машин состояний. XState и аналоги дают инструмент в коде; Phase — концепция уровня архитектуры приложения.

Не статусная колонка с триггерами. Колонка status с обработчиками даёт переходы, но не модель: декларативность, свежесть знания, журнал фактов, адрес агента, порождение и синхронизацию как примитив.

Из чего Phase вырос

Phase собирает в одну дисциплину идеи с длинной историей: цифровое предприятие наследует кибернетике управления (Viable System Model); объекты-двойники — линии цифрового двойника; объект Phase близок к актору; поля, заполняемые разными участниками, — это «доска» (blackboard); условия переходов — правила «событие–условие–действие»; свежесть полей — битемпоральный учёт; цикл жизни фазы — контур автономных вычислений (MAPE-K).

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

Для кого

Phase адресован командам, которые строят бизнес-системы и хотят простой предсказуемый движок, удобный для ИИ-кодинга; интегрируют ИИ-агентов в операционные процессы и нуждаются в управляемой, аудируемой, постепенно расширяемой автономии; разрабатывают с активным использованием агентов и ценят явные паттерны без магии; создают платформы для бизнеса с понятной моделью фаз.

Связь с физикой

Название выбрано намеренно. В физике фазовый переход — мгновенный скачок системы в новое состояние при достижении параметром порога. Вода не «постепенно становится льдом» — она переходит скачком при 0 °C. В Phase: объект находится в фазе — это период накопления, в течение которого собираются факты и формируется дистиллят; фазовый переход — атомарное событие, когда дистиллят достиг порога. Сделка не переходит в «Квалифицирована» при первом ответе клиента — система накапливает факты, пока их совокупность не даёт основание.

Phase v1.0 · 2026 · Вадим Соглаев, Андрей Юмашев · CC BY-SA 4.0