Вопросы и ответы

ВЕРДИКТ — исполняемый регламент процесса: правила, сроки, шаги и действия при сбое записаны в одном месте, система работает строго по ним и по каждой операции показывает, почему решили так. Речь о процессах, которые идут по правилам и без человека на каждом шаге. Заявка, проверка, решение, платёж, возврат, отказ. ВЕРДИКТ решает, что делать дальше, держит сроки и обязательства и записывает основание каждого решения в тот момент, когда оно принимается.

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

ВЕРДИКТ сводит это в один регламент — условия, шаги, сроки, обратные действия — и исполняет его: исполняется ровно то, что вы читаете. Поэтому «как задумано» и «как работает» не расходятся — расходиться нечему.

Пока всё идёт как обычно, не видно, держится порядок на везении или на устройстве. Разница видна в шести местах:

Слева ничего не сломано. Там порядок держится на том, что кто-то в своё время предусмотрел этот случай и не ошибся, — и держится ровно до тех пор, пока случай не окажется тем, о котором не подумали. Справа он держится на описании, которое проверяется до выпуска и исполняется как записано.

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

В работе те же свойства видны, а не подразумеваются: в записи стоит, какой предел исчерпан и как он называется, какие цели остались незакрытыми и чем всё кончилось. «Завершена» и «достигла целей» — разные ответы. Оценку «правильно или неправильно» ВЕРДИКТ при этом не выносит и ваши системы не заменяет: предметную область знаете вы.

Ближайшие соседи и отличие от них:

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

CRM и учётные системы остаются у вас: решение принимает ВЕРДИКТ, действия выполняют они. ИИ не обязателен.

Из четырёх частей, и это один артефакт, а не четыре документа рядом.

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

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

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

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

В записи ВЕРДИКТА у каждого решения лежит: сработавшее правило; отклонённые правила с указанием невыполненного условия; версия описания, по которой шла операция; имя стратегии, выбиравшей шаг; исход операции отдельно от её статуса.

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

Восстановление опирается на пять источников, и каждый следующий выглядит надёжнее предыдущего. Ни один не даёт ответа.

• Отчёт. Операция, упавшая до первой записи, в нём отсутствует. «Не завершилось» и «не начиналось» выглядят одинаково: никак.
• Журналы. Отвечают, что произошло, а не на основании чего.
• Номер сработавшего правила. Через год он приведёт к сегодняшнему тексту правила, и подмену не заметить.
• Версии правил. Прогон возьмёт сегодняшние данные, и верные правила по неверным данным дадут результат, которого не было ни тогда, ни сейчас.
• Снимок данных. Справочники, ответы внешних систем и ваш собственный изменившийся код вам не принадлежат — «по состоянию на март» их не запросить.

Отсюда единственный работающий вывод: состав записи определяется до запуска процесса, а не в тот момент, когда о нём спросили.

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

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

Если каждый из трёх ответов находит система, а не человек, процесс уже управляем и пилот вам не нужен.

Нет. Учётные системы, CRM, процессинг, шина остаются на месте и продолжают выполнять действия — ВЕРДИКТ их не подменяет и не проксирует.

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

Каким должен быть процесс, решаете вы: ВЕРДИКТ исполняет его ровно так, как он описан, и не выносит оценку «правильно или неправильно».

Процессам, где сходятся четыре условия:

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

Отрасль значения не имеет. Например: скоринг и кредитный конвейер, тарификация, согласования с лимитами, обработка обращений со сроком ответа.

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

Процессам под присмотром человека на каждом шаге: основание там есть у кого спросить.

Процессам, где правила не менялись годами и объяснять решение некому. Механизм рассчитан на изменение и на внешний вопрос; без них он лишний.

Эти расходы у вас уже есть — они просто не оформлены счётом: очередь к разработчикам ради одного порога; споры о том, на что повлияет новая редакция правила, когда проверить это нечем; время сотрудников, которые восстанавливают основание давнего решения; ручной разбор сбоя, при котором часть действий выполнена, а часть нет. У этих расходов нет отдельной статьи в бюджете, поэтому они выглядят как загруженность сотрудников. С ВЕРДИКТОМ порог меняют без разработчика, до выпуска видно, какие случаи дадут другой результат, основание решения записывается в момент решения, а чем закончился откат, видно в записи.

Размер не определяет ничего. Определяет число шагов, систем и людей внутри процесса: от него зависит, во что обходится одно объяснение.

Цена объяснения растёт не от количества ошибок, а от количества участников: каждый новый шаг, каждое новое условие и каждый новый человек добавляют к ней понемногу.

Срок — поле процесса, а не строка в инструкции. Отсчитывает его ВЕРДИКТ: процесс возобновляется сам, без вашего планировщика и без запроса от ваших систем, и записывает исход. Молчание внешней системы становится результатом операции, а не аварией: ожидание заканчивается по сроку, и в записи видно, чем и почему.

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

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

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

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

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

Условия читаются словами предметной области, а не выражением: «Все условия выполнены: режим обслуживания — нет; остаток не больше порога». Это то же описание в деловом чтении.

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

Отдельный вопрос владельца — «а сейчас она ещё так делает». На него отвечает повторный запуск на тех же данных — из Конструкторской.

Отвечают две проверки, обе до выпуска.

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

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

Найти все ошибки проверка не обещает: она отвечает на объявленный набор вопросов, а догадка в отчёте помечена как догадка.

Отчёт первой строкой называет охват проверки.

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

Граница проходит между значением и предметом: значение живёт в таблице, новый предмет объявляется в контракте.

Операция привязана к своей версии, поэтому те, что шли в момент выпуска, доходят до конца по прежним правилам.

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

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

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

Любые две точки сравниваются деловым языком, а не построчной разницей кода: «порог суммы заказа был 10 000, стал 20 000», «появилось правило», «шаг теперь требует условие». Если правка контракта данных ломает совместимость, так и сказано.

Правку можно прочитать, не открывая код.

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

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

Неудачи отката не стираются из записи.

Повторная доставка поручения приходит с тем же ключом, по которому ваша система не повторяет уже выполненное действие.

Отменяются только шаги, у которых описано обратное действие.

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

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

В записи каждого решения стоит имя стратегии, которая выбирала. «Модель предложила» и «разрешили правила» — разные записи, а не одна.

Предсказуемой становится не модель, а граница её полномочий.

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

Ваш ИИ-агент подключается к ВЕРДИКТУ по открытому протоколу MCP, работает на вашей языковой модели и внутри вашей сети. Он предлагает и дорабатывает описание вместе с автором, а версию публикует только человек: составленное проходит ту же проверку до выпуска. Проверка до выпуска одинаково строга к любому описанию — кто бы его ни составил, и каждую находку, которую можно показать, показывает на конкретном входе.

Внутрь ваших систем ничего не устанавливается, их интерфейсы не переписываются.

На вашей стороне появляется одна новая часть — обработчик поручений: HTTP-адрес, который принимает поручение, вызывает нужные ваши сервисы и возвращает результат. Он один знает и адреса ваших систем, и доступы к ним.

Порядок обмена: ваша система запускает операцию; ВЕРДИКТ решает, что делать дальше, и отправляет поручение на адрес обработчика; обработчик выполняет его своими средствами и отвечает; ВЕРДИКТ считает следующий шаг.

Относительные сроки и состояние операции держит ВЕРДИКТ. Планировщик пробуждений и хранилище промежуточного состояния вам заводить не нужно: процесс возобновляется сам и переживает перезапуск узла.

Сроки только относительные — «через указанный интервал». Календарных моментов «в 9:00» или «первого числа» здесь нет как примитива.

Два направления, оба настраиваете вы.

Входящее: ваши системы обращаются к ВЕРДИКТУ — запустить операцию, прочитать состояние, ответить на поручение, сообщить событие, свернуть операцию.

Исходящее: ВЕРДИКТ отправляет поручение на адрес вашего обработчика — один на всё, по виду поручения или по пространству. Поручение повторяется по правилам, а ответ связывается с процессом.

Адресов ваших внутренних систем и доступов к ним у ВЕРДИКТА нет: к ним ходит ваш обработчик. Внешние сервисы о существовании ВЕРДИКТА не знают — их вызывают их собственным интерфейсом.

Поручение может прийти к вашей системе повторно — например, если действие выполнено, а ответ потерялся. Каждая доставка одного поручения приходит с одним и тем же ключом, и по нему ваша система не повторяет уже выполненное действие. Однократность действия во внешней системе обеспечивает сама эта система.

Подключение — через обычный HTTP-интерфейс; адреса и формат — на странице «Как устроено».

Начатая операция до конца идёт по той версии, на которой началась: выпуск и включение новой версии её не трогают. Обновление самого ВЕРДИКТА проходит без простоя: новая версия поднимается рядом, а старая доводит начатое.

На вашей стороне два предмета: обработчик поручений и вызов запуска операции из системы-инициатора. Оба — обычный HTTP с JSON.

Описание процесса — контракт, таблицы, шаги, сроки и обратные действия — ведётся в Конструкторской.

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

Часть уже написана — в каждом сервисе по-своему, разными людьми, в разные годы. Именно поэтому решение, прошедшее через четыре сервиса, сегодня не объяснить.

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

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

Люди входят через поставщика удостоверений по стандарту OpenID Connect — встроенного или вашего корпоративного; учётных записей людей ВЕРДИКТ не хранит. Доступ выдаётся по группе, по домену почты, конкретному человеку или по почте того, кто ещё ни разу не входил. Роли — четыре базовые, свои объявляются конфигурацией; менять доступ может только роль «владелец». Интеграция получает собственную личность, а не чужой пароль: сервисный аккаунт с меткой, сроком действия и доступом.

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

Решения принимаются по тем данным, которые вы передаёте, и ВЕРДИКТ работает только с ними. Поле, не участвующее ни в одном правиле, передавать не нужно: не решаете по почте клиента — не передавайте её, и в записи её не будет.

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

Кто может открывать разбор операций, решаете вы.

Описание живёт в Конструкторской вместе со всей историей правок. Его можно выгрузить в ваш git-репозиторий и загрузить оттуда — так же приходят готовые заготовки процессов.

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

К репозиторию ВЕРДИКТ обращается только по явному действию и только по адресу, который вы назвали. Ключ сервера проверяется: неизвестный сервер — это отказ с его отпечатком, а не молчаливое доверие. Выгрузка, загрузка и настройка адреса — отдельные права, которые не достаются по наследству ни одной роли.

Да. Загрузка версии и её включение — разные права. Версию процесса может подготовить и загрузить поставщик — мы или ваш подрядчик — под своим сервисным аккаунтом, а включает её ваш человек.

По записи видно, по какой версии шла каждая операция, — кто бы эту версию ни подготовил.

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

Не заменяет ваши прикладные системы и не выполняет действий во внешнем мире сам: их выполняют ваши системы по поручениям ВЕРДИКТА, своими доступами. Подключение обработчиков к вашим сервисам — работа на вашей стороне.

Не обещает, что проверка до выпуска найдёт все ошибки: она отвечает на объявленный набор вопросов и называет свой охват первой строкой отчёта.

Не толкует смысл ваших данных: запись восстанавливает ход дела, а не деловой смысл значений.

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

Проверка отвечает на объявленный набор вопросов и первой строкой называет свой охват.

Она не доказывает, что правила соответствуют вашему замыслу: замысел проверяется прогоном случаев на прежней и новой версии. И не обещает найти все ошибки — догадка в отчёте помечена как догадка.

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

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

Отмена может и не дойти до конца — тогда она заканчивается одним из четырёх объявленных исходов, например «исчерпаны попытки» или «требуется человек»; какой именно, видно в записи. Ручного перезапуска отката нет.

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

Повторный запуск спорного случая идёт на тех же данных — из Конструкторской.

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

Ваши системы остаются на месте: ВЕРДИКТ работал рядом с ними, а не вместо них. Решения, которые принимал ВЕРДИКТ, после отключения придётся принимать иначе.

Продукт готов к промышленной эксплуатации. Берём ваш процесс и доводим его до работы: разбор, описание, проверка до выпуска, установка в вашем контуре и передача управления вашим людям.

Начинаем с разбора: где решения становится трудно объяснить, что происходит, если сбой случился на полпути, и кто меняет пороги.

Напишите на hq@verdikt-app.ru, какой процесс взять в пилот.

Цена зависит от размера компании и числа процессов, которые вы ведёте. Цены и состав лицензий — на странице «Лицензирование».

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

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

Сегодня продукт работает на ваших серверах — в вашей сети и под вашим контролем. Облачная версия появится скоро; оплата в ней будет зависеть от объёма использования.

В лицензию для малого бизнеса — до трёх, в базовую — до десяти, в корпоративную — без ограничения. Черновики не считаются: платят только за процессы, выпущенные в работу.