protocol-9-runner

Protocol 9 Runner - Reality Audit Executable

When to invoke

Финансовые слова: «эффект на выручку», «потенциал», «плюс N млн», «рост на N%», «ICE», «ROMI», «Pareto», «окупаемость», «CAC», «LTV», «EBITDA», «доля рынка»

Планировочные: «положи в план», «добавь задачу», «новая инициатива», «стратегическая ставка», «приоритет 1», «к 31.X будет готово»

Розовые очки: «уникальный актив», «никто в РФ не делает», «монопольная позиция», «просто надо подключить», «база уже есть», «удвоит бизнес», «выстрелит», «взорвёт рынок»

Контекстные: работа с внешней презентацией; чужие кейсы (Shein/Cattelan/IKEA); диапазон шире 2x

Step 1 - Tag every figure

Для каждой цифры в тексте поставить тег:

• [ДАННЫЕ: <source-path>, snapshot YYYY-MM-DD, c=<confidence>] - есть верифицируемый источник
• [ГИПОТЕЗА: <author>, допущения: А=…, Б=…, В=…] - нет источника

Confidence scale:

• 1.0 - выгрузка из 1С с datestamp
• 0.9 - Bitrix24 выгрузка
• 0.7 - Marketplace API
• 0.5 - внешний рынок-репорт
• 0.3 - частная коммуникация

Если в тексте есть цифра без тега → процесс не завершён, вернуть на маркировку.

Cross-domain подтверждение. К той же дисциплине приходят growth-практики вне нашей системы: в промтах разметка {value, status: confirmed|estimated|missing, confidence: high|med|low} с запретом ИИ додумывать данные. Наши [ДАННЫЕ] / [ГИПОТЕЗА] - тот же принцип. Аргумент для защиты правила H1 перед скептиками. [источник: К. Жаворонков / big_bad_coach]

Step 2 - 5 Reality Audit Questions

Применяется к любой задаче с ICE ≥500 или эффектом ≥10M ₽ или любому тезису из внешней презентации.

Q1 - Кто ЦА и КАК ОНА РАБОТАЕТ

Не «сегмент дизайнеров», а конкретно:

• В каком отрезке дня/недели они принимают решение?
• Через какой канал узнают?
• Сколько касаний нужно до сделки?
• Кто ещё участвует в решении?

❌ Плохо: «дизайнеры покупают» ✅ Хорошо: «дизайнер-партнёр Tier 1, цикл 2–4 месяца ДО подписания клиентом, узнаёт через AD Russia → Pinterest, 4–6 касаний, ЛПР сам»

Q2 - На каких допущениях держится цифра

Каждый эффект разложить на цепочку:

• Допущение А: …
• Допущение Б: …
• Допущение В: …
• Эффект = функция(А, Б, В)

Если хотя бы одно не подтверждено:

• ICE снижается на 30–50%
• Pareto не ставится
• Бюджет ограничивается экспериментальным
• Метка «пилот»

Q3 - Какие данные есть и каких нет

Конкретно перечислить:

• «Есть данные:» - отчёты, выгрузки из 1С/Bitrix24
• «Нет данных - надо запросить у X:» - с указанием источника

Если «нет» > «есть» → это эксперимент, не план.

Q4 - Что произойдёт при downside

Худший сценарий:

• Какие ресурсы потеряем (деньги, время команды)?
• Какие репутационные риски?
• Какие альтернативы для этих ресурсов?

Правило: если downside > (оптимистичный эффект × 0.3) → не делаем.

Q5 - Кто и когда проверит первый сигнал

• Конкретная дата
• Ответственный
• Критерий «идём дальше или сворачиваем»

❌ Плохо: «увидим в Q4» ✅ Хорошо: «к 31.08 Денис делает выборку 100 контактов. Если <30% реальных - программа сворачивается»

Step 3 - Apply Hard Rules

Любое нарушение → блок задачи:

Step 4 - Trifecta Routing

После 5 вопросов передать через A2A:

1. DATA проверяет источники цифр
2. FENIX проверяет логику и нестыковки
3. MARCO проверяет реальное поведение ЦА

Каждый возвращает go|return|veto. Все три → go → задача проходит дальше.

Step 5 - Decision Matrix

Output template

# Reality Audit - <task name>

**Triggers fired:** <список>
**Owner:** <agent>
**Timestamp:** <ISO>

## Цифры

### [ДАННЫЕ]
- <цифра>: <source>, c=<conf>

### [ГИПОТЕЗА]
- <цифра>: <author>, допущения А/Б/В

### [РАСХОЖДЕНИЕ]
- <если есть>

## 5 вопросов

### Q1 - ЦА и механика
<ответ>

### Q2 - Допущения
<ответ>

### Q3 - Данные / отсутствующие
<ответ>

### Q4 - Downside
<ответ>

### Q5 - Первый сигнал
<дата, ответственный, критерий>

## Hard Rules - проверка
- H1: ✅/❌ - <обоснование>
- H2..H10: …

## Trifecta verdicts
- DATA: <go|return|veto>, причина
- FENIX: <go|return|veto>, причина
- MARCO: <go|return|veto>, причина

## Final verdict
**<GO | PILOT | BLOCK | KILL>**

Корректировка ICE: <до → после>
Корректировка budget: <до → после>
Чекпоинт: <дата>, ответственный <имя>

Anti-patterns

• ❌ Skip P9 «потому что срочно». Срочность - не повод обходить P9 (см. шаблон в Главе 7 Protocol 9)
• ❌ Округлять «для красоты» (28 500 ≠ 30 000)
• ❌ Принимать диапазон «72–144M» как точку (это [ШИРОКИЙ ДИАПАЗОН])
• ❌ Использовать модель из ниши с другой unit-экономикой (Shein vs нас)

Reference

См. полную доктрину: GENGROUP_Protocol_9_Reality_Audit.docx (в корне репозитория) или конспект в CLAUDE.md §5.