# Стандарт проверяемого решения

Источник: https://kurzemnek.ru/method/standard
Автор: Валерий Курземнек
Опубликовано: 2026-10-07
Обновлено: 2026-10-07

<h2 id="unit">Единица метода — проверяемая петля решения</h2>

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

<figure class="method-visual" aria-labelledby="loop-caption">
<figcaption id="loop-caption"><span class="method-figure-label">Петля решения</span>До действия — проверка. После действия — замер.</figcaption>
<ol class="decision-flow">
<li><strong>Данные</strong><span>Расход, события, люди, оплаты.</span></li>
<li><strong>Проверка данных</strong><span>Полнота, свежесть, определения и воспроизводимость расчёта.</span></li>
<li><strong>Решение и его проверка</strong><span>Агент предлагает действие. Критик сверяет основания и правила.</span></li>
<li><strong>Разрешённое действие</strong><span>В пределах бюджета и полномочий. Где требуется — после утверждения человеком.</span></li>
<li><strong>Замер результата</strong><span>Сравниваем прогноз и факт за оговорённый период.</span></li>
<li><strong>Проверенный урок</strong><span>Обновляем правило или инструмент и проверяем новое поведение.</span></li>
</ol>
<div class="decision-stop"><strong>Если проверка не пройдена</strong><span>Действие блокируется. Система сообщает причину и возвращает задачу на доработку.</span></div>
<p class="method-figure-note">После обновления правила цикл начинается заново. Каждый проход остаётся в журнале.</p>
</figure>

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

Для каждой петли нужно записать:

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

<h2 id="data">Как устроены машиночитаемые данные</h2>

Основа аналитического контура — **расход → визит → лид → квалификация → сделка → оплата**. Источники могут называть этапы по-разному. Эти названия сопоставляются с общей схемой, а определения лежат рядом с данными.

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

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

**Числа считают скрипты; модель интерпретирует результат и предлагает решение.** Каждый расчёт должен воспроизводиться по указанному источнику. Для значимых денежных решений нужна независимая сверка. Если данные устарели или поступили не полностью, система останавливает вывод и сообщает, чего ей не хватает.

У нас за эту работу отвечает [аналитическая система Соломон](/cases/solomon): данные, определения, расчётные инструменты, агент-аналитик и отдельный критик чисел Фома. В кейсе разобрано, как они работают вместе.

<h2 id="rules">Как выглядят правила решений</h2>

В Голиафе используются стоп-правила: семь дней без лидов; расход 3×ARPL без лида; стоимость ключевого этапа выше модельной в 1,7 раза. **Это правила конкретного контура, их нельзя переносить в другой бизнес без расчёта.** ARPL — выручка на одного лида в объявленной когорте и окне; задержка оплат меняет его смысл.

Перед остановкой нужно убедиться, что «нет лидов» означает отсутствие результата. Если кабинет, аналитика и CRM расходятся, сначала выясняем причину расхождения. Например, проверяем, не потерялись ли события. Бюджет увеличиваем ступенями: один большой чек ещё не показывает, что результат повторится при большем расходе.

Критик сверяет решение с источниками и правилами. Гейт — обязательная проверка перед действием — блокирует его при нарушении условия. Для арифметики и технических ограничений подходит программная проверка; для смысла текста и контекста — модель. Отказ критика должен действительно останавливать действие и возвращать задачу на доработку.