Наши публикации

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

2025-12-15 13:53 Knowledge Graphs Практика

Введение

В предыдущей статье я показал, как документ можно превратить в сеть смыслов и получить «живую» онтологию знаний. С помощью своего семантического ритуала я разбираю текст на термины и связи, и документ растворяется в графе, оставляя после себя осмысленную модель. Такой подход к знаниям убирает двусмысленность: ключевые понятия вынесены в онтологию, язык проекта становится частью архитектуры, и команда работает в едином контексте. В итоге сложные системы перестают зависеть от «шума» неверно понятых слов и начинают вести себя предсказуемо.
Теперь я иду дальше и развиваю концепцию живых онтологий – на этот раз применяя её к управлению процессами. Что, если моделировать процессы так же, как семантику текста? Могу ли я описать процесс как совокупность понятий, связей и состояний – и сделать так, чтобы эта модель не лежала мёртвым грузом в документации, а реально исполнялась? Обычно процессы умирают в момент, когда их нарисовали: диаграмма живёт отдельно, реальность — отдельно, а смысл расползается между людьми и системами. Мне стало интересно: а что если процесс тоже представить как живую модель — в виде объектов, связей и состояний — и дальше исполнять именно модель, а не “сценарий в коде”?
В этой статье я покажу, как я реализовал идею: описал процесс как онтологическую модель и подключил n8n как движок, который исполняет эту модель. Внутри: минимальная метамодель, разбор реального workflow и короткий эпизод “как выполнение одной задачи активирует следующий этап”

Проблема: «мёртвые» процессы без смысла

Почему вообще возникла потребность переосмыслить моделирование процессов? Дело в том, что типичное описание бизнес-процесса мертво – диаграммы BPMN и регламенты быстро устаревают и мало связаны с реальностью. Мы рисуем красивые схемы, но они существуют отдельно от данных и смыслов, которыми живёт система. Термины на таких схемах трактуются по-разному: один считает, что «Проект» – это разработка нового продукта, другой – что это просто бюджетная статья, третий – что так называется команда исполнителей[2]. В итоге каждый читает процессную диаграмму по-своему, и общего понимания нет.
Есть и вторая боль — процессы почти никогда не связаны с данными. Схема описывает шаги и переходы, но система не может ответить на вопросы уровня инженера:
🔹какой объект считается “готовым”?
🔹какое состояние считается “выполнено”?
🔹какие зависимости реально блокируют следующий этап?
🔹какие артефакты должны появиться в системах после шага?
Когда ответы живут “в головах” и в переписках, моделирование превращается в ритуал рисования. Процесс вроде есть, но система его “не чувствует”, а значит он бесполезен для автоматизации, наблюдаемости и — да — для AI-агентов (они наследуют всю неоднозначность).
Кроме того, классические модели процессов не несут формального знания о предметной области. Они описывают шаги и условные переходы, но не отвечают на вопросы: что значат эти шаги? почему именно такой порядок? какие понятия стоят за ролями и действиями? Поэтому моделирование процессов часто превращается в рутинное рисование графиков, не влияющее на ежедневные решения.
Процесс как бы есть на бумаге, но система его «не чувствует». Это и называется «мёртвым» процессом – он не встроен в живую модель знаний, а значит, бесполезен для AI-агентов и сложной аналитики.
Наконец, есть практическая боль разработки: при изменениях приходится переписывать сразу код, интеграции и документацию, причём несоответствия выявляются поздно. Диаграмма может обещать одно, а сервисы в реальности реализуют другое — потому что диаграмма не является источником истины и никак не участвует в исполнении.
Отсюда и требование, которое меня интересует: нужен процесс, который живёт в данных, а не “описан где-то”. Идеально — чтобы его можно было представить как модель, которая одновременно:
🔹однозначно задаёт смысл (термины и связи),
🔹отражает текущее состояние мира,
🔹может быть исполнена/проверена автоматически.
Дальше я покажу, как именно я попробовал это сделать через «живую онтологию процесса».

А что если процесс – это онтология?

Чтобы решить описанные проблемы, я попробовал сделать простой ход: вынести процесс из документов в модель, как я раньше выносил смысл из текста. То есть описывать процесс не как схему шагов, а как граф объектов и отношений, который живёт рядом с данными и обновляется вместе с ними.
На практике это значит следующее:
🔹Есть объект «Процесс» — как контейнер контекста.
🔹Есть объекты «Задачи» — как атомы работы внутри процесса.
🔹Есть связь включает (Процесс → Задача): какие задачи принадлежат процессу.
🔹Есть связь Ход (Задача — Задача): логическая зависимость “рядом в процессе”.
Самое важное (и это ключевой поворот): состояние задачи у меня — не поле status.
Состояние — это шаблон (тип объекта).
То есть “Не назначена”, “Назначена”, “Выполнена” — это разные шаблоны задач, и переход между состояниями — это буквально операция смены шаблона у объекта.
Почему это важно? Потому что тогда состояние становится частью онтологии:
его можно типизировать, наследовать, связывать с другими понятиями, и — главное — его можно интерпретировать машиной одинаково каждый раз, без “чтения между строк”.
Отдельная деталь: у связи Ход в Онто нет направления. “Направление” появляется из правила интерпретации: следующей считается та задача, которая становится доступной при выполнении соседей. В прототипе правило очень простое:
если у задачи B есть сосед по Ход, который находится в состоянии “Выполнена”, то B можно активировать (перевести в “Назначена”).
Это и делает модель “живой”: процесс перестаёт быть картинкой и превращается в структуру, по которой можно:
🔹проверять консистентность (есть ли тупики/висячие задачи),
🔹понимать текущее состояние,
🔹и самое интересное — исполнять: менять состояния задач не руками в таблице, а автоматически по правилам модели.
В следующих разделах я покажу минимальную метамодель (буквально 3 сущности и 2 связи) и то, как n8n выступает интерпретатором: читает граф задач и применяет переходы, меняя шаблон объектов.

Архитектура исполнения: где тут n8n

Идея идеей, но как сделать так, чтобы онтологический процесс действительно двигался, а не оставался “умной диаграммой”? В прототипе роль исполнителя модели у меня берёт на себя n8n — open-source платформа автоматизации. Но важная оговорка: n8n здесь не “хранит процесс” и не содержит его сценарий. Он работает как интерпретатор модели: читает текущий граф задач и применяет к нему переходы.
У меня есть Процесс, внутри которого есть набор Задач. Каждая задача в каждый момент времени находится в одном из состояний:
🔹Не назначена — задача существует в модели, но её ещё рано делать (она ждёт предусловий).
🔹Назначена — задачу уже можно выполнять: она “активирована” и видна исполнителю.
🔹Выполнена — исполнитель завершил задачу и зафиксировал это в системе.
🔹(опционально) Финализирована — задача обработана движком и больше не участвует в продвижении. Зачем я это делаю? Что бы задачи не попадали в выборку многократно.
Исполнитель в этой схеме не принципиален: это может быть человек, форма, внешний сервис — кто угодно. Важно другое: как только какая-то задача становится Выполнена, у процесса появляется шанс продвинуться дальше. Движок смотрит на связи “Ход” и переводит следующие задачи из “Не назначена” в “Назначена”. Так процесс продвигается “волной”: выполненная задача активирует следующий этап, следующий этап — следующий, и так далее.
Технически у меня это реализовано двумя workflow.
Workflow 1: ProcessExecutedTask — «собрать выполненные и обработать»
Этот workflow делает цикл по задачам, которые находятся в состоянии “Выполнена”.
  1. Он выполняет поиск задач через Onto API: POST /entity/find/v2 с фильтром metaEntityRequest.uuid по шаблону “Выполнена” и пагинацией.
  2. Затем проходит по найденным задачам батчами.
  3. Для каждой выполненной задачи делает смену шаблона: PATCH /entity/{id}/meta → metaEntityId = на шаблон “Финализирована”.
  4. Вызывает второй workflow, передавая id текущей задачи.

1) Сканируем «выполненные задачи» (ProcessExecutedTask)

{
  "method": "POST",
  "url": "https://app.ontonet.ru/api/v2/core/realm/<realmId>/entity/find/v2",
  "body": {
    "name": "",
    "comment": "",
    "metaEntityRequest": {
      "uuid": "45c30420-8b5b-4435-8bdc-930c72abc19f"
    },
    "metaFieldFilters": [],
    "pagination": {
      "first": 0,
      "offset": 100
    }
  }
}
Workflow 2: AssignTask — «активировать соседей по связи “Ход”»

Это тот кусок, где проявляется “движок процесса”.

  1. Workflow принимает id задачи (из первого workflow) и запрашивает её детали вместе со связанными сущностями: GET /entity/{id}?relatedEntities=true&relatedDiagrams=false.
  2. Он берёт related_entities и фильтрует соседей по двум условиям: связь должна иметь имя relationName == "Ход" + соседняя сущность должна быть в определённом шаблоне-состоянии: metaEntity.uuid по шаблону “Не назначена”.
  3. Для каждого подходящего соседа выполняется переход состояния как смена шаблона: PATCH /entity/{neighborId}/meta → metaEntityId = на шаблон “Назначена”.

2) Активируем соседей по связи «Ход» (AssignTask)

2.1 Получаем окружение задачи (связанные сущности):

{
  "method": "GET",
  "url": "https://app.ontonet.ru/api/v2/core/realm/<realmId>/entity/{{ $json.id }}?relatedEntities=true&relatedDiagrams=false"
}

2.2 Фильтруем соседей: берём только Ход и только задачи в “неактивном” состоянии (UUID 1bbe…):

// псевдокод фильтра в n8n (узел If)
relationName == "Ход" &&
entity.metaEntity.uuid == "1bbec7ad-6373-4bcb-b085-..."

2.3 Переводим выбранную соседнюю задачу в состояние “Назначена” через смену шаблона:

{
  "method": "PATCH",
  "url": "https://app.ontonet.ru/api/v2/core/realm/<realmId>/entity/{{ $json.entity.id }}/meta",
  "body": {
    "metaEntityId": "a885220e-f5bd-4cc3-8ff2-..."
  }
}
Если перевести это на язык модели, то получается простое правило:
🔹выполненная задача “подсвечивает” соседей по Ход,
🔹если сосед сейчас в “неактивном” состоянии, движок переводит его в “Назначена”.
Это и есть ключевой момент: состояние хранится не в поле, а в выбранном шаблоне, а n8n выполняет переходы, меняя шаблон объектов через API.

Мини-кейс из прототипа: как одна выполненная задача «зажигает» следующий этап

Чтобы не уходить в абстракции, покажу один реальный эпизод из прототипа (он же в видео).
У меня есть процесс, внутри которого задачи связаны отношением Ход — это “логика продвижения”. Связь не направленная, поэтому “что дальше” определяется правилом интерпретации: следующими считаются те задачи, которые можно активировать после выполнения соседей.

Сценарий

  1. Исполнитель (человек/форма/внешняя система — не важно) переводит одну задачу в состояние «Выполнена».
  2. Движок (n8n) периодически/по запуску смотрит список выполненных задач и берёт одну из них в обработку.
  3. Для этой выполненной задачи он загружает окружение: все связанные сущности (related_entities).
  4. Из окружения он выбирает только связи relationName == "Ход", и только тех соседей, кто находится в “неактивном” состоянии (например, “Не назначена”).
  5. Эти соседние задачи переводятся в состояние «Назначена» — то есть становятся доступными для исполнения.

Что видно в примере
В моём видео это выглядит так: после того как “Задача 3” становится выполненной, задачи 4.1–4.3 (связанные с ней по Ход) автоматически переходят в “Назначена”.

Никаких “если/то” в коде под конкретный процесс: правило одно и то же, оно просто применено к текущему графу.
Почему это важно
Это маленький эпизод, но он показывает главное отличие подхода:
🔹процесс задаётся моделью в графе (объекты + связи + состояния как шаблоны),
🔹а n8n выступает интерпретатором, который делает допустимые переходы (смена шаблона у объектов) на основании текущего состояния модели.
Именно этот разрыв — «модель первична, исполнение вторично» — и есть точка, в которой мой прототип начинает быть похожим на MBSE.

Почему это MBSE?

Небольшая вставка для тех, кто не сталкивался с термином. MBSE (Model-Based Systems Engineering) — это подход в инженерии сложных систем, где модель становится главным рабочим артефактом. Не “картинкой для отчёта”, а тем, вокруг чего реально строится работа: обсуждения, проверки, изменения, а иногда и генерация кода/тестов. В противоположность этому, в привычном мире у нас обычно есть разрозненные документы: требования в одном месте, схема процесса в другом, код — в третьем, и все они расходятся со временем.
Суть MBSE можно объяснить одной фразой: “сначала формальная модель, потом всё остальное”. В хорошей MBSE-системе модель не просто описывает, как “должно быть”, а помогает проверять консистентность, находить ошибки на ранней стадии и поддерживать трассируемость (что связано с чем и почему).
Теперь к моему кейсу. Я не использую SysML как стандарт, но принцип тот же: процесс описан как модель в графе (объекты + связи + состояния), и дальше машина работает по модели, а не по захардкоженному сценарию.
В моём прототипе:
🔹модель процесса — это граф “Процесс → задачи”, связь Ход между задачами и состояния, заданные шаблонами;
🔹исполнение — интерпретатор (n8n), который читает текущий граф и выполняет переходы, меняя состояние задач через смену шаблона объекта.
Отсюда следует важное: когда меняется модель (связи, типы, состояния), меняется и поведение — без переписывания сценариев. Это сокращает семантический разрыв между “как задумано” и “как работает”, и делает процесс проверяемым: можно анализировать граф, искать тупики и наблюдать реальное продвижение.
Оговорка честно: это прототип. До “взрослого” MBSE в методологическом смысле тут ещё много шагов (валидация модели, правила для нескольких предусловий, идемпотентность/гонки). Но идея исполняемой модели уже проявилась.

Заключение: исполняемый смысл как новая норма

Опыт с живыми онтологиями процессов показывает, что процессы не обязательно должны быть «немыми» схемами в документации. Их можно сделать полноценными носителями смысла, которые к тому же выполняются машиной. Это шаг к новой инженерной культуре, где смысл становится исполняемым. Знания больше не пылятся в wiki или в головах отдельных экспертов — они встроены в систему и непосредственно влияют на её работу.
Такой подход требует менять мышление. Архитектору мало нарисовать красивую диаграмму — нужно сформулировать онтологию: определить понятия, их отношения, ограничения. Зато наградой будет система, которая говорит с вами на одном языке. Когда знание превращается в активный элемент инфраструктуры (вспомним: в связке Онто + n8n я реально применяю правило модели и делаю переходы состояний задач, меняя их тип/шаблон), уходит привычный барьер между идеей и её реализацией. Решение, однажды зафиксированное в модели, сразу становится частью живого процесса.
Мне хочется верить, что за такими исполняемыми моделями будущее — по крайней мере в тех местах, где процессы постоянно меняются, а цена семантического разрыва высока. Представьте команды, где обсуждение требований напрямую формирует онтологию, и тут же автоматика берёт её в работу. Минимум ручной рутины, максимум отслеживаемости и единый язык для людей и AI. Живые онтологии процессов — это приглашение к новой культуре разработки, где мы проектируем не набор несвязанных артефактов, а цельную систему знаний и действий. Приглашаю инженеров и разработчиков поэкспериментировать с этим подходом: возможно, он подтолкнёт нас всех к более осмысленной и управляемой автоматизации.
P.S. Подробности реализации и наглядный эпизод “как выполнение одной задачи активирует следующий этап” — в видео в тексте статьи. Также рекомендую ознакомиться с предыдущим материалом «Семантический ритуал: как я извлекаю смысл из документов» для понимания концепции живых онтологий