Evidence-before-write для AI-агентов: почему система должна требовать доказательства до записи

Evidence-before-write для AI-агентов — это рабочий контракт: агент не пишет в базу, не публикует страницу, не отправляет сообщение и не меняет production, пока не собрал доказательства права на действие. 25 июля 2026 в Solar OS этот принцип проверялся на публикациях, финансовых сверках, клиентском контуре и мониторинге входящих сигналов. Часть действий дошла до внешнего эффекта, часть осталась в blocked, и это нормальное поведение системы, а не авария.

Тема похожа на guardrails, fail-closed и идемпотентность, но угол другой. Guardrails задают границы поведения. Fail-closed запрещает движение при сомнении. Идемпотентность защищает от повторного внешнего эффекта. Evidence-before-write кладёт под каждое действие пакет доказательств: какой источник используется, что именно он подтверждает, что осталось неизвестным, кто дал право на запись и чем результат подтверждён после записи.

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

Практический смысл правила появляется на стыке 3 ролей: агент-исполнитель, независимый проверяющий и владелец решения. Исполнитель готовит artifact и доказательства. Проверяющий подтверждает, что artifact соответствует контракту. Владелец открывает gate там, где действие меняет сайт, деньги, клиентский контур или публичную коммуникацию. Если одну из ролей убрать, система снова скатывается в доверие к красивому отчёту.

Где ломается агент без доказательств

Самая опасная ошибка в автоматизации — принять отсутствие данных за нормальный результат. Пустая ячейка становится нулём. Черновик становится публикацией. Совпадение файла становится финансовой записью. Контакт из мониторинга становится outbound-сообщением. Система не выглядит сломанной; она выглядит уверенной. Это хуже, потому что человек видит аккуратный отчёт и поздно замечает, что отчёт построен на дыре.

В клиентском контуре это проявляется особенно быстро. Материал может пройти проверку текста и визуала, но это ещё не право менять сайт клиента. Отдельная проверка адаптива подтверждает только адаптив. Переписка подтверждает только согласование текста или следующего шага, если в ней это прямо написано. Финальный файл можно передать владельцу, но production publish остаётся отдельной операцией со своим gate.

Это пример evidence boundary. Проверка текста отвечает за текст. Проверка изображения отвечает за изображение. Проверка адаптива отвечает за верстку. Комментарий в задаче отвечает за статус задачи. Ни один из этих фактов сам по себе не равен разрешению менять production. Если агент смешивает эти статусы, он начинает делать лишнее именно в тот момент, когда владелец думает, что система аккуратна.

В блоге та же проблема выглядит мягче, но последствия остаются внешними. Публикационный контур может восстановиться, страницы могут открываться, sitemap может перечитаться, но короткий или повторный материал всё равно не становится качественной SEO-статьёй. Evidence-before-write заставляет проверять длину, структуру, hash, QA, canonical path и sitemap-readback до того, как страница попадает наружу.

В мониторинге сигналов ложная уверенность тоже стоит денег. Найденная публикация, профиль или контакт не являются лидом. Сначала нужно понять источник, причину включения, причину исключения, адрес назначения и запрет на холодную массовую отправку. Без этого агент превращает discovery в шумную активность. Бумажная корона на голове у шума всё ещё шум, просто с амбициями.

Source pack: что должно лежать перед решением

Source pack — это набор источников, без которого агент не имеет права менять внешний слой. Для статьи это исходный текст, slug, exact artifact, hash, anti-slop score, duplicate check, QA verdict и owner approval, если он нужен. Для финансов это первичный документ, период, валюта, объект, правило начисления, связанный контрагент и журнал исключений. Для мониторинга лидов это query, источник публикации, причина включения, причина исключения и адрес назначения.

У source pack есть 3 свойства. Первое — воспроизводимость. Другой агент должен открыть тот же файл, URL или запись и прийти к тому же выводу. Второе — область действия. Если источник подтверждает только мобильную верстку, он не подтверждает публикацию на сайте. Третье — readback. После действия нужно перечитать результат: страницу, ledger, таблицу, sitemap, message id или запись в реестре.

В Solar OS source pack обычно выглядит скучно: путь к artifact, SHA-256, issue UUID, run id, список пройденных проверок, список отсутствующих проверок и точный blocker. Эта скука спасает от театра автоматизации. Когда через сутки другой агент открывает задачу, он видит не героический рассказ, а проверяемую цепочку. Что было на входе. Что проверено. Что запрещено. Кто должен снять блок.

Хороший source pack не обязан быть большим. Он обязан быть точным. Для короткого внутреннего действия достаточно нескольких полей. Для внешней публикации нужно больше: exact payload, контроль дублей, QA PASS, canonical publisher, live URL, dedup ledger и marketing_publications. Для финансовой записи нужен документальный хвост, потому что ошибка меняет деньги и отчётность. Риск действия определяет размер пакета.

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

Для внедрения удобно начать с одной карточки source pack. В ней 10 полей: source_id, source_url_or_path, source_hash, period, scope, claim, required_checks, passed_checks, missing_evidence, next_owner. Такая карточка не заменяет базу и не делает процесс корпоративным. Она просто заставляет агента записать, на каком основании он собирается нажать кнопку. Если поле missing_evidence не пустое, write gate закрыт.

Вторая карточка нужна для claim. Один источник может поддерживать несколько утверждений, но не все сразу. Мобильный скрин подтверждает ширину страницы. Он не подтверждает согласие клиента на публикацию. Банковская строка подтверждает движение денег. Она не объясняет налоговый режим. Переписка подтверждает договорённость только в пределах написанного текста. Разделение source и claim убирает главный фокус-покус автоматизации: подмену узкого факта широким разрешением.

Write gate: где агент получает право менять мир

Write gate — это момент, где система переводит подготовленное действие во внешний эффект. До gate агент может читать, считать, нормализовать, создавать draft, собирать staging artifact и готовить комментарий. После gate появляются последствия: запись в базе, публичная страница, сообщение клиенту, отчёт инвестору, обновлённый каталог или отправленный лид. Поэтому gate должен быть отдельной технической сущностью, а не фразой в инструкции.

В простом варианте write gate — это функция или helper, который проверяет список обязательных полей. Есть artifact hash. Есть QA verdict. Нет второго поста за день. Нет дубля угла за 14 дней. Есть owner approval. Есть canonical publisher. Есть возможность readback. Если хотя бы один пункт отсутствует, helper возвращает отказ и пишет blocker. Агент не решает голосованием внутри себя, достаточно ли ему уверенности.

В более зрелом варианте gate разделяет права по уровню риска. Низкий риск: черновик или локальный отчёт. Средний риск: публикация в owned media после QA. Высокий риск: деньги, клиентский сайт, договор, доступы, массовая отправка. Для высокого риска default state должен быть closed. Открытие происходит только через конкретное разрешение и только для одной операции.

В кейсе 25 июля write gate остановил разные классы действий: материалы без достаточной глубины, финансовые записи без полного source pack, клиентские изменения без отдельного разрешения и напоминания без свежего справочника. Во всех случаях система могла сделать вид, что данных хватает. Нормальная система выбрала остановку.

Такой gate полезен ещё и психологически. Владелец перестаёт просить агента «будь аккуратнее» и начинает видеть конкретные причины отказа. Нет валюты. Нет списка объектов. Нет правила начисления. Нет адреса назначения. Нет QA PASS. Это уже не спор о стиле работы AI, а технический контракт, который можно чинить по одному полю.

В малой команде write gate можно описать таблицей на 4 уровня риска. Уровень 0 — локальная подготовка: читать, считать, писать draft. Уровень 1 — внутренняя запись: добавить staging artifact или комментарий в задачу. Уровень 2 — owned external: блог, канал, публичная страница после QA. Уровень 3 — irreversible или expensive: деньги, клиентский production, договоры, доступы, массовые сообщения. У каждого уровня свой gate, и это лучше, чем один общий запрет, который все начинают обходить.

Unknown state: почему пустота не равна нулю

Главное слово в evidence-before-write — unknown. У нормальной системы должно быть состояние, которое означает: источник не даёт достаточного знания для записи. Это состояние отличается от ошибки, нуля и отказа. Ошибка говорит, что процесс не смог выполниться. Ноль говорит, что проверенный результат равен нулю. Отказ говорит, что действие запрещено правилом. Unknown говорит: данных недостаточно, поэтому запись невозможна.

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

Эти детали нельзя заменять догадкой. Если связка источников полная, система может писать в реестр. Если связка неполная, она должна сохранить unknown и назвать недостающее доказательство. Для внешней статьи достаточно сказать «финансовая сверка остановлена без первичных данных». Публиковать суммы, балансы и имена контрагентов для объяснения принципа не нужно. Читателю нужен механизм, а не экскурсия по чужому карману.

Unknown особенно часто пропадает в AI-слоях, потому что модель обучена продолжать текст. Пользователь спрашивает, агент отвечает. Таблица просит число, агент ищет похожее. Сценарий ждёт next action, агент его формулирует. В production такой стиль токсичен. Если система не умеет сказать «я не знаю достаточно для записи», она будет заполнять пробелы правдоподобным мусором.

Технически unknown нужно делать отдельным типом статуса: unknown, needs_evidence, blocked_missing_currency, blocked_missing_owner_approval, а не хранить как пустую строку, 0 или false. Чем точнее статус, тем дешевле следующий шаг. Человек сразу видит, какой документ нужен, а агент не пытается лечить отсутствие валюты повторным пересказом исходного текста.

Есть ещё одно правило: unknown не должен стареть в тишине. У каждого блока нужен next evidence: какой файл нужен, кто его даёт, где он должен лежать, как проверить, что он новый. Если справочник не обновляется автоматически, задача не должна каждые сутки запускать напоминания с тем же старым справочником. Она должна ждать обновлённый источник или явное решение человека.

Proof readback после записи

Доказательства до записи закрывают только половину риска. Вторая половина появляется после действия. Publisher мог вернуть успех, но страница не открылась. Скрипт мог записать строку, но база приняла дубль. Sitemap мог обновиться, но URL не попал в список. Комментарий мог уйти не в тот issue. Поэтому после write gate нужен proof readback: независимое перечитывание внешнего результата.

Для сайта readback должен быть строгим. После публикации надо проверить live URL, canonical ledger, sitemap, structured data и запись в marketing_publications. Если raw events по CTA есть, но real clicks или organic qualified clicks отсутствуют, это диагностический шум, а не победа. Если страница открывается по HTTP 200, но exact artifact не совпадает с approved payload, публикацию нельзя закрывать как выполненную.

Proof readback нужен ещё до отчётности. Отчёт без readback часто звучит убедительно: «опубликовал», «обновил», «починил», «проверил». Нормальная формулировка длиннее, зато честнее: опубликованный URL открыт, hash совпадает, ledger содержит operation key, marketing_publications содержит canonical URL, QA run id указан в notes. Да, это менее романтично. Зато потом никто не ищет руками, что именно сделал агент.

У readback есть отдельный стоп: unknown external effect. Если система не может доказать, ушло ли сообщение или записалась ли строка, она не должна повторять действие вслепую. Правильный статус — blocked с named blocker. Повторный запуск без доказательства может создать второй пост, второй платёж, вторую заявку или вторую правку сайта. Внешний мир не обязан терпеть наши retry.

Readback стоит делать другим способом, чем запись. Если publisher написал файл, проверка должна открыть live URL. Если API вернул message id, проверка должна прочитать канал или ledger. Если база приняла запись, проверка должна посчитать уникальные строки и конфликтные ключи. Один и тот же слой не должен сам себе выдавать справку о честности. Это нормальная инженерная гигиена. Для публичного контура это ещё и защита от случайного раскрытия лишних деталей.

Как внедрить evidence-before-write в малом бизнесе

Начните с карты внешних действий. Запишите всё, что меняет мир: отправка сообщений, публикация страниц, изменение цен, запись расходов, обновление CRM, создание счёта, изменение прав доступа, запуск напоминаний, массовая обработка контактов. У каждого действия должен быть owner, риск, source pack, write gate и readback. Если действие нельзя откатить быстро, оно получает более жёсткий gate.

Второй шаг — отделить черновики от production. Агент может создавать exact artifact в отдельной папке, считать hash и просить QA. Он не должен писать live HTML, менять sitemap или запускать outbound, пока gate не открыт. Для сайта это означает staging payload вместо прямой правки шаблона. Для финансов — pending row вместо закрытого расхода. Для лидов — candidate list вместо сообщения человеку.

Третий шаг — завести журнал unknown. Каждый стоп должен оставлять не только текстовый комментарий, но и машинно читаемую причину. missing_currency, missing_object_list, missing_qa_pass, missing_destination, stale_reference, duplicate_angle, short_article. Через месяц такой журнал покажет, где система чаще всего упирается в отсутствие данных. Это уже очередь улучшений, а не устные претензии к агентам.

Четвёртый шаг — дать человеку узкое место для решения. Если отсутствует owner approval, человеку не нужно читать весь код. Ему нужно увидеть exact artifact, hash, краткий diff, список проверок и конкретный вопрос. Если неизвестны условия начисления, человеку не нужна лекция про финмодель. Ему нужно подтвердить валюту, объекты и правило. Чем уже запрос, тем быстрее снимается блок.

Пятый шаг — запретить победные отчёты без внешнего доказательства. Система может сказать: draft готов, QA запрошен, publish blocked. Это хороший результат. Плохой результат — «почти опубликовано» или «можно считать готовым». В production слово «почти» часто означает, что позже кто-то откроет реестр и обнаружит несколько версий одного результата.

Шестой шаг — проверять старые контуры на право молчать. Хорошая автоматизация не обязана каждый запуск что-то менять. Иногда лучший heartbeat заканчивается строкой selected=0, потому что нет новой задачи с доказанным интентом. Иногда лучший монитор не отправляет ни одного сообщения, потому что destination пустой. Иногда лучший финансовый импорт создаёт только список вопросов. Для AI-агента молчание после проверки — нормальный outcome, если оно подкреплено readback.

Седьмой шаг — разделить отчёты для людей и журналы для системы. Внутренний журнал может хранить точные суммы, адреса, имена файлов, конфликтные ключи и полный список исключений. Внешняя статья, письмо клиенту или пост в канал должны брать только тот уровень деталей, который разрешён для аудитории. Это часть evidence contract: один и тот же source pack может подтверждать действие, но не давать права раскрывать весь source pack наружу.

Что забрать в свою систему

Evidence-before-write сводится к 6 практическим вопросам. Какой источник подтверждает действие. Какой checksum или URL фиксирует artifact. Какой статус означает unknown. Где стоит write gate. Кто имеет право открыть gate. Как система перечитывает внешний результат после записи. Если на любой вопрос ответ размыт, агент пока не готов менять production. В спорной ситуации он готовит новый source pack, а не догадку.

25 июля 2026 в Solar OS нормальный день выглядел так: часть материалов прошла публикационный контур, часть была остановлена на QA, финансовые записи без полного source pack остались blocked, а мониторинг не отправил сообщений без адреса назначения. Верхний результат здесь не скорость, а разница между подтверждённым действием и красивым предположением.

Для AI-автоматизации малого бизнеса это базовый уровень зрелости. Черновик не становится публикацией. Пустота не становится нулём. Совпавший файл не становится расходом. Найденный контакт не становится outbound. PASS по технике не становится коммерческой победой. Каждое действие проходит через source pack, write gate и proof readback, иначе остаётся в blocked. Так система сохраняет деньги, репутацию и сон владельца без героизма на пустом месте.

Полный набор артефактов — AGENTS.md, write-gate чек-листы, QA-гейты, примеры source pack и рабочие разборы из моей системы — в клубе «Solar — внутрянка», от 2 500 ₽/мес. Бери и адаптируй: https://4bos.ru/inside/

Solar OS.