Approva начинается со знакомой проблемы.
Софт теперь умеет делать то, на что организация может быть не готова отпустить его действовать самостоятельно.
Как только система может запустить внешнее действие, дотронуться до чувствительных данных, изменить состояние продакшена или подвинуть деньги от чьего-то имени — разница между can execute и should execute перестаёт быть отвлечённой.
Approva сидит именно в этом промежутке.
Зачем нужен этот слой
Большинство команд не хотят вечно прогонять каждое значимое действие через ручные операции.
Но и оставлять последственные действия без понятной границы подтверждения они тоже не могут.
Approval становится инфраструктурой, когда у тебя появляется место для того, чтобы рассмотреть действие, подтвердить его в известном scope и сохранить запись о том, что именно было разрешено.
Что делает поток на практике
Если описать процесс по шагам, обычно выглядит примерно так:
- Система хочет выполнить чувствительное действие.
- Создаётся запрос на подтверждение с контекстом, данными актора и достаточной деталировкой для решения.
- Человек подтверждает или отклоняет.
- Если подтверждено, система получает ограниченную capability, а не бессрочное разрешение.
- Выполнение продолжается с трейсуемой записью того, что произошло.
В этом процессе нет ничего эффектного. Именно поэтому он важен.
Доверие чаще ломается не из-за того, что система была злонамеренной или некомпетентной, а из-за того, что этот средний слой никто толком не спроектировал.
Где это становится реальным
Потребность всплывает быстро в платежах, compliance-нагруженных процессах, внутренних операциях, инфраструктуре — везде, где у действий есть последствия для клиента.
В таких средах подтверждение человеком — не признак того, что система примитивная.
Часто это и есть то условие, при котором более широкая автоматизация становится приемлемой.
Текущий статус
Approva в активной разработке.
Сейчас работа идёт над тем, чтобы операционная модель была достаточно точной, чтобы выжить в реальном использовании — а не только в хорошем демо.