ВЕРДИКТ — от описания до объяснения
ИИВЕРДИКТ ведёт операции по вашим правилам до конца и объясняет каждое решение. Правила, сроки, шаги и действия при сбое записаны в одном регламенте, и система работает строго по нему. Ваши системы остаются на месте и работают рядом: процесс запускают они, задания тоже выполняют они.
Обычно это четыре разных инструмента, и на стыках между ними теряется смысл. В ВЕРДИКТЕ — один регламент.
Возьмём выплату на 300 000 ₽. Где сегодня лежат её правила:
Каждое место проверяют отдельно, а ломается на стыках: порог поправили в коде, а в схеме остался старый.
Ответ на вопрос «почему» собирают по частям.
Правила, сроки, шаги и действия при сбое записаны в одном месте. Система работает строго по ним и по каждой операции показывает, почему решили так.
Порог, шаги, срок и обратное действие проверяются вместе: проверка видит стыки, а причина решения — в записи операции.
На что похоже и чем отличается
Похоже на BPM, но схему не рисуют
Допустимые действия на каждом шаге определяют правила. Новое исключение — это просто строка в таблице.
Похоже на движок правил, но там не только правила
Сроки, шаги и обратные действия записаны рядом, в том же регламенте. Поэтому проверка находит ошибки на стыках между ними.
Похоже на журнал аудита, но запись ведётся сразу
Она появляется в момент исполнения. Её не нужно потом собирать из логов.
Поэтому ВЕРДИКТ — не BPM, не движок правил и не журнал аудита. Это исполняемый регламент процесса.
CRM и учётные системы остаются у вас: решение принимает ВЕРДИКТ, действия выполняют они. ИИ не обязателен.
Описать
Условие — строка таблицы: до 100 000 ₽ выплату одобряют сразу, выше — отправляют на проверку специалисту.
Порог поднимают до 150 000 ₽ прямо в Конструкторской, без разработчика, и вашу программу трогать не нужно. Новый шаг или новое поле по-прежнему добавляет программист.
Регламент записан понятным деловым языком, а инженерный вид того же регламента открывается одним переключателем.
В тексте — выплата, на экранах — учебный пример: кофейный автомат.
Правило в виде таблицы
Открыть кадр целикомПроверить
Порог решили поднять до 150 000 ₽. Перед публикацией правку прогоняют на проверочных случаях — сразу на старой и на новой версии.
Видно, на каких случаях новый порог даёт другой результат, в какой таблице и каким он стал.
Новая версия заработает, только когда её включат, а начатые операции закончатся на прежней.
Проверка перед публикацией
Открыть кадр целикомПроверить
Скидка работает. Акция работает. Вместе — нет.
Запустили новый тариф — а ни одно правило к нему не подходит
Клиент не заплатил в срок — а что делать дальше, не записано
Шаг «одобрить» есть — а отметку об одобрении он не ставит
Обратное действие записано — а деньги оно не возвращает
ВЕРДИКТ видит процесс целиком и проверяет стыки между правилами, шагами, сроками и обратными действиями ещё до запуска новой версии.
А в первой строке отчёта сказано, что именно проверено.
Исполнить
Заявку на 300 000 ₽ отправили на проверку. Видно, чего процесс ждёт и до какого срока: на проверку три дня, а если ответа нет, по регламенту заявка уходит руководителю. За сроком следит ВЕРДИКТ.
Платёж отправлен, но банк его не подтвердил. У такого шага есть своё обратное действие: ВЕРДИКТ даёт на него задание, и в записи видно, чем всё закончилось.
Каждая операция заканчивается названным итогом, а если откат не удался, это видно в записи.
Процесс в работе
Открыть кадр целикомСрок ответа по оплате ещё не истёк, возврат удержанных денег отправлен и ждёт подтверждения.
Объяснить
Это запись решения: какие шаги были допустимы, почему не подошли остальные, что выбрано, по какой версии правил и чем всё закончилось. Для выплаты на 300 000 ₽ видно, что допустимы были «одобрить» и «на проверку», а первый шаг не подошёл: сумма выше порога.
В ней же — каждое обращение к вашим системам, каждый срок и каждое изменение: что было и что стало.
Аудитор открывает запись выплаты сам и может спросить у правил, что бы они решили на тех же данных, — без разработчика.
Запись решения
Открыть кадр целикомСработало одно правило. Остальные зачёркнуты, и у каждого указано, какое условие не выполнилось.
Каждый пункт — свойство продукта, которое видно в работе.
Раньше: Заявка на выплату молча застряла на полпути
Теперь: Операция либо идёт дальше, либо заканчивается названным итогом
Раньше: Ответа специалиста ждали бесконечно
Теперь: У каждого ожидания обязательный срок — без него процесс не запустится
Раньше: Поменяли порог — и начатые выплаты пошли по новому
Теперь: Что начато по старым условиям — по ним и заканчивается
Раньше: После сбоя сервера выплаты разбирали вручную
Теперь: Достаточно подождать — процесс сам восстановится по записи
Раньше: Ошибку приняли за успешный результат
Теперь: Ошибка не маскируется под успех и прямо говорит, что не так
Раньше: Возврат приняли на веру, а он ничего не вернул
Теперь: Результат обратного действия проверяется по правилам
Раньше: Ход дела собирали по крупицам из логов
Теперь: Весь ход дела — в одной записи
Видно не только решение, но и отвергнутые варианты.
Для каждого отклонённого — какое условие не выполнилось.
Видно, по какой редакции правил принято решение.
Даже если порог с тех пор поменяли.
Начатое заканчивается по прежним правилам.
Выплата, начатая вчера, завершится по вчерашнему порогу в 100 000 ₽, даже если сегодня вы подняли его до 150 000 ₽.
Аудитор проверяет сам.
Открывает запись любой операции и может заново прогнать правила на тех же данных — без разработчика и без выгрузок.
Порог меняет сам владелец процесса.
Без очереди к разработчикам. Правку проверяют заранее, а не после первой жалобы.
Последнее слово — за правилами.
Что можно, а что нельзя, определяют правила — ещё до того, как к выбору подключится ИИ или человек.
Через месяц аудитор спрашивает, почему выплату на 300 000 ₽ не одобрили сразу. Ответ уже в записи: сумма выше порога, решение принято по такой-то версии правил.
Сроки и напоминания — часть процесса
ОбычноСроки держат в задачах и календарях, а о просрочке узнают, когда она уже случилась.
ЗдесьСрок — часть регламента, и следит за ним сам ВЕРДИКТ.
НапримерНа проверку заявки отведено три дня; если ответа нет, заявка уходит руководителю.
Цели, а не нарисованная схема
ОбычноМаршрут рисуют заранее, и каждое новое исключение — ещё одна стрелка на схеме.
ЗдесьПроцесс знает, чего добивается: на каждом шаге выбирает следующий из допустимых и отдельно показывает, достигнута ли цель.
НапримерПлатёж не подтвердился: отправить снова, вернуть деньги или позвать сотрудника — процесс выберет из того, что сейчас допустимо.
Пришёл документ — процесс учтёт сразу
ОбычноПока процесс ждёт, новые события копятся, и их разбирают потом — по расписанию или вручную.
ЗдесьДаже во время ожидания процесс принимает события от ваших систем и сразу их учитывает.
НапримерЗаявка ждёт проверки, а клиент присылает недостающий документ — ход заявки меняется сразу.
Предохранитель для любого шага
Обычно«Можно» и «сейчас» смешивают в одном правиле, и любое временное ограничение приходится вписывать в сами правила.
ЗдесьДаже разрешённое правилами действие можно остановить отдельным условием: «можно, но не сейчас».
НапримерВыплата разрешена, но ждёт окончания проверки документов.
Никаких неизвестных данных
ОбычноПропущенное значение молча заменяют нулём или чем-то «по умолчанию» — и решение принимается наугад.
ЗдесьВсё, с чем работает процесс, описано заранее. Если значение пропущено или испорчено, процесс прямо сообщит об ошибке.
НапримерВ заявке на выплату не пришла сумма — процесс не подставит ноль, а остановится и скажет, чего не хватает.
Процесс не ходит по кругу
ОбычноПовторы идут без счёта, а о «зависшем» процессе узнают из жалобы или из мониторинга.
ЗдесьСколько раз повторять шаг и сколько ждать, задано заранее. Лимит исчерпан — работа заканчивается, и причина записана.
НапримерБанк раз за разом отвечает ошибкой: после заданного числа попыток отправка прекращается.
Замечания проверки не проскочат мимо
ОбычноК предупреждениям проверки привыкают, а причину исключения помнит только его автор.
ЗдесьЕсли проверка нашла что-то новое, опубликовать новую версию из Конструкторской можно только осознанным решением. «Так задумано» — только с причиной, и такое исключение остаётся на виду.
НапримерНа время кампании для постоянных клиентов порог выплаты временно выше, и одно правило намеренно перекрывает другое — через месяц видно, почему так решили.
Повторный запрос легко узнать
ОбычноПовтор нечем отличить от нового запроса, и после сбоя связи действие может выполниться дважды.
ЗдесьЕсли ответ потерялся и запрос пришёл снова, у него тот же ключ — по нему ваша система не повторяет уже выполненное действие.
НапримерПлатёж прошёл, а ответ о нём потерялся: повторное задание придёт с тем же ключом, и ваша система поймёт, что деньги уже отправлены.
Что проверили, то и работает
ОбычноПроверяют на отдельном стенде или в упрощённом режиме, а в работе процесс ведёт себя иначе.
ЗдесьПри проверке и в работе процесс исполняется одним и тем же механизмом.
НапримерПорог 150 000 ₽ проверили в Конструкторской — после публикации выплаты исполняются тем же путём, без «на тесте работало».
Ни одна редакция не потеряется
ОбычноПравки перезаписывают друг друга, и через месяц уже не восстановить, кто и что менял.
ЗдесьКаждое сохранение регламента — точка в истории: что сделано, когда и кем. Вернуться можно к любой точке, и работа между ними не пропадёт.
НапримерПеред тем как поднять порог до 150 000 ₽, ставят точку «порог 100 000» — и в любой момент видно, с чего начинали.
Изменения читаются по-деловому
ОбычноРазница двух версий — сотни строк кода, и что изменилось по делу, понимает только автор правки.
ЗдесьЛюбые две редакции сравниваются словами бизнеса: «порог был 100 000, стал 150 000», «появилось правило», «шаг теперь требует условие».
НапримерПеред публикацией руководитель видит список изменений по существу и не открывает код.
Процессы — в вашем репозитории
ОбычноЛогика процесса живёт в чужой системе или у подрядчика, и забрать её целиком непросто.
ЗдесьПроцессы выгружаются в ваш git-репозиторий и загружаются оттуда. История только дописывается, а извне принимается лишь то, что прошло проверку.
НапримерГотовую заготовку берут из репозитория, а свою редакцию отправляют к себе — рядом с остальными исходниками компании.
Автор процесса и аудитор видят один и тот же регламент — разница только в том, кто может его менять. Служба безопасности и эксплуатация устанавливают ВЕРДИКТ у себя и управляют доступом.
Место ИИ
Подключайте ИИ там, где он полезен. Предложить он может что угодно — хоть удалить клиентскую базу, хоть выплатить деньги без проверки. Но процесс этого не сделает, если правила такого не разрешают.
Кто выбирает следующий шаг — решаете вы
Кто бы ни выбирал, дальше действуют одни и те же правила.
Прежде чем процесс обратится к ИИ, правила определяют, что сейчас допустимо, и передают это ему как исходные данные, а не как совет.
Процесс обращается к ИИ только так, как в нём заранее описано. В записи остаётся всё: что было допустимо, что выбрано и кем.
Описывать процессы можно и программно: весь путь от составления регламента до публикации новой версии доступен через один интерфейс, а проверка одинаково строга к любому регламенту — кто бы его ни составил.
Регламент можно составлять вместе с вашим ИИ-агентом: он предлагает, система проверяет, новую версию публикует человек. Агент подключается по открытому протоколу MCP, работает на вашей языковой модели и внутри вашей сети.
Банковская система или таблица с ботом — заменять её не нужно. ВЕРДИКТ обращается к вашим системам только по адресам, которые задали вы, а действия они выполняют сами, со своими правами доступа.
Ваши системы
наведите или нажмитеОстаются как есть
ВЕРДИКТ
АБС банка
Выдать кредит, отказать или отправить на ручную проверку — и как потом объяснить, почему именно так?
Логика процесса и запись решений
Дело не в размере и не в отрасли. Дело в том, как устроен ваш процесс.
За решение потом отвечают.
Отказ, выплата, лимит, скидка, условие возврата.
Между шагами приходится ждать.
Проверка занимает три дня, банк не подтвердил платёж, контрагент молчит.
Письмо, запрос или платёж должны дойти.
А если ответа нет, ожидание закончится по сроку, и в записи будет видно, чем.
Деньги уже в пути.
Платёж ушёл, а банк не подтвердил. Нужно точно знать, чем всё закончилось.
Правила меняются чаще, чем ваши системы.
Порог выплаты, срок проверки, лимит — каждый месяц.
Узнали у себя два-три пункта — ВЕРДИКТ вам подойдёт.
Продукт один и тот же. Разница — в масштабе и в цене ошибки.
Надёжность и безопасностьПродукт устанавливается на ваших серверах и работает в вашей сети. В этом случае вы платите за процессы, которые он ведёт, — а не за число запусков, пользователей или мощность серверов.
Счёт не зависит от нагрузки.
Сколько бы решений система ни приняла, сумма та же.
Мы не следим за вашей работой.
Раз в год вы сами присылаете лицензионный отчёт — внутрь никого пускать не нужно.
Работает без нас.
Даже когда лицензия закончится, выпущенные процессы продолжат работать.
Облачная версия
Сегодня продукт работает на ваших серверах — в вашей сети и под вашим контролем. В облаке оплата будет зависеть от объёма использования.
490 000 ₽ в год — малому бизнесу от 2 500 000 ₽ в год — базовая
Что входит в лицензиюПродукт готов к промышленной эксплуатации. Берём ваш процесс — тот, где ошибка стоит денег, — и доводим его от разбора до работы в вашем контуре.
Всё это — в вашем контуре и на ваших правилах.
Назовите процесс и контакт — ответим с разбором и планом пилота.
Переслать тем, с кем решаете

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