Большинство программ помнит, что изменилось. Куда меньше программ помнит, почему изменение было разрешено, кто или что приняло это решение и на каких доказательствах оно держалось. Именно в этом разрыве доверие тихо размывается. Команда эксплуатации обычно может ответить на вопрос «каково состояние сейчас»; зачастую она не может ответить на «покажи, как мы сюда пришли, и докажи, что нам это было разрешено».
Threada устроена так, чтобы на второй вопрос всегда можно было ответить. Каждое управляемое действие оставляет квитанцию.
Что на самом деле содержит квитанция
Квитанция — это не строка журнала. Строка журнала говорит: «что-то произошло». Квитанция говорит достаточно, чтобы позже воссоздать решение и отстоять его. В Threada управляемое действие фиксирует:
- Субъекта. Человека-оператора или ИИ-участника, записанных как отдельные события субъекта. Утверждение от агента никогда не выдаёт себя за человеческое.
- Входные данные. WorkItem, извлечённые из него сущности, личность запрашивающего и исходный канал, по которому пришёл запрос.
- Доказательства. Цитаты, трассу извлечения и — когда контекста было недостаточно — явную причину отката. Work нельзя создать без цитат или зафиксированной причины отката.
- Политику. Какой набор политик был активен, в какой версии, и применялся ли он ко всему тенанту или к суженному pack, рабочему процессу, каналу или группе запрашивающих.
- Итог. Было ли действие предложено, утверждено, отклонено, выполнено, успешно или провалено — со связью обратно к внешней записи, которую оно затронуло.
Прочтите эти поля вместе — и у вас есть защитимое описание одного шага. Прочтите их на протяжении жизненного цикла WorkItem — и у вас его полная история.
Аудируемость как настройка по умолчанию, а не функция, которую прикручивают потом
В большинстве систем возникает соблазн добавить аудит позже: выпустить функцию, а потом обернуть её журналированием, когда клиент попросит доказательства для SOC 2 или нагрянет регулятор. Этот порядок перевёрнут. Аудит, добавленный задним числом, всегда неполон, потому что систему никогда не просили нести контекст в тот момент, когда принималось решение.
Threada переворачивает порядок. Среда выполнения испускает структурированные события при каждом значимом переходе — work_item_created, approval_requested, approval_decided, action_proposed, action_executed, fallback_triggered — потому что акт выполнения работы есть тот же самый акт, что её записывает. Нет отдельного шага «включить аудит», потому что нет момента, когда работа происходит вне записи.
Именно это мы имеем в виду, когда говорим, что модель — это записи-и-квитанции. Запись — не отчёт, который вы порождаете; это остаток от того, что работа была сделана правильно.
Почему квитанции меняют то, как работают команды
Квитанция полезна аудитору в конце квартала. Но её более тихая ценность — для оператора посреди обычного вторника.
Когда каждое действие несёт свои доказательства и своё политическое основание, три вещи становятся проще:
- Проверка становится быстрой и честной. Утверждающему не нужно восстанавливать контекст по памяти или гоняться за запрашивающим, чтобы узнать исходную просьбу. Доказательства лежат рядом с действием. Уверенность, обратимость и ясность видны в точке принятия решения, так что проверяющие оптимизируют под проверяемость, а не только под скорость.
- Откат становится безопасным. Поскольку квитанция называет версию политики и входные данные, откат действия — это определённая операция, а не археологический проект. Вы знаете, что отменяете и почему это было сделано.
- Подотчётность перестаёт быть враждебной. Когда запись складывается сама, «кто это утвердил» — не обвинение, а просто поле. Разделение обязанностей между ролями строителя, утверждающего и управления обеспечено и видимо, так что вопрос подотчётности отвечен ещё до того, как кому-то приходится его задать.
Работа с высоким риском остаётся за человеком, под запись
Квитанции не означают, что всё автоматизировано. Они означают, что всё подотчётно. Автоматизации с высоким риском следуют явной последовательности с участием человека — предложено, затем утверждено, затем выполняется — и автоматически выполняются лишь там, где политика это явно разрешает. Квитанция фиксирует, какой из этих путей прошло данное действие. Автоматизация и утверждение не противоречат друг другу; и то и другое — просто шаги, оставляющие след.
В итоге получается система, которую можно с одинаковой уверенностью передать аудитору и новому оператору. Аудитор видит, что меры контроля выдержали. Оператор видит, как предыдущий человек справился со стоящим перед ним случаем. Оба читают одни и те же квитанции.
В этом и состоит ставка, лежащая в основе Threada: самое дешёвое время зафиксировать, почему решение было разрешено, — это тот миг, когда вы его принимаете; и команда, которая никогда не работает вне записи, — это команда, которая всегда может ответить на второй вопрос.