Агент завершил задачу. Организация всё ещё может быть должна.

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

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

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

Задача — это попытка выполнить работу; обязательство — это работа, которую организация всё ещё должна

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

Элемент очереди может исчезнуть после сбоя исполнителя. Workflow может закончиться по тайм-ауту или в предусмотренном конечном состоянии. Аудиторский след может показать, что задача была выдана, но не установить, достигнут ли требуемый результат. Эти системы способны отслеживать обязательства, но не должны быть единственным каноническим источником, если срок обязательства пересекает границы исполнения.

AWS Step Functions делает эту границу наглядной: сервис поддерживает ожидания на относительный срок или до абсолютной отметки времени, но ожидания и исполнения Standard Workflow ограничены одним годом. Это не недостаток оркестрации. Это напоминание: экземпляр workflow — контейнер исполнения, но не обязательно долговечный контейнер организационной ответственности.

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

Сделайте реестр обязательств системой учёта

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

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

Как минимум запись должна содержать следующие поля:

• Стабильный идентификатор обязательства, организационного должника и бенефициара или затронутую сторону.
• Исходное действие, обязательство или запускающее событие со ссылками, достаточными для восстановления контекста.
• Версию применимого правила или соглашения, требуемый результат и требования к доказательствам исполнения.
• Условие наступления срока: фиксированную дату, если она применима, либо событие, запрос на исполнение, условие или повторяющийся график — в зависимости от фактического триггера.
• Подотчётную организационную роль и текущего исполнителя. Это намеренно разные поля.
• Зависимости: предварительные согласования, сведения или внешние события.
• Состояние жизненного цикла и применимый путь нарушения, устранения, средства защиты или иного последствия.

Такая модель делает переназначение безопасным. Замена исполнителя меняет того, от кого сейчас ожидают действие; она не стирает должника, не переписывает происхождение и не закрывает обязательство. Это принципиально, когда агенты недолговечны, полномочия ротируются или workflow нужно перезапустить в другой системе.

Стандарты дают полезные части, но не весь runtime

ODRL предлагает полезный понятийный аппарат. Его информационная модель представляет разрешения, запреты и обязанности. Обязанность может быть назначена стороне, относиться к действию и включать цель и ограничения. В ODRL исполнение требует и соблюдения ограничений, и совершения требуемого действия. Это более строгий тест, чем заявление агента: «готово».

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

XACML даёт более узкий, но столь же важный урок. Он отличает исполнимые обязательства от рекомендательной информации в решениях авторизации. При решении Permit точка принуждения политики может разрешить доступ, только если она понимает сопровождающие обязательства и может и будет их выполнять. Это обязательства, присоединённые к ответу авторизации, а не предписанный корпоративный реестр долговечных деловых, регуляторных или договорных обязанностей. Но они показывают, что авторизация и последующие обязанности должны оставаться связанными.

Policy Machine от NIST использует термин «обязательство» для правил шаблонов событий и ответных действий. Его точка обработки событий сопоставляет обязательства с событиями, а подходящие ответы могут содержать несколько административных действий, выполняемых атомарно с использованием авторизации создателя обязательства. Урок не в том, что любое организационное обязательство является атомарным ответом. Он в том, что исполнению, запускаемому политикой, нужны явная идентичность исполнителя и чёткие границы атомарности.

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

Дайте обязательствам жизненный цикл, включая неисполнение

Полезный реестр не сводит все конечные состояния к «исполнено» или «отменено». Он хранит управляемый автомат состояний. Типичные состояния: возникло, активно, ожидает зависимости, назначено, доказательства представлены, исполнено, просрочено, нарушено, устраняется, от него отказались, заменено и признано недействительным. Точная терминология будет различаться, но переходы должны быть явными и управляться политикой.

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

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

Доказательства — граница исполнения

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

Это не требует единого универсального механизма доказательств. Для разных обязательств нужны разные стандарты подтверждения. Требование уже: политика завершения и использованные для её выполнения доказательства должны быть связаны с записью обязательства. Без этой связи последующий проверяющий увидит активность, но не сможет надёжно определить, исполнила ли организация то, что была должна.

Операционное следствие: непрерывность принадлежит организации

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

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

Шлюз обязательств отвечает на предыдущий вопрос: когда организация становится связанной обязательством? Реестр обязательств отвечает на следующий: после правомерного возникновения обязанности как организация помнит, исполняет, доказывает и, если необходимо, устраняет последствия? Автономная организация надёжна не потому, что её агенты завершают задачи. Она надёжна, когда её обязательства остаются понятными до их действительного разрешения.