2.0 instruction — Nexus Consumer & Context Ripeness¶

Этап RB-STEP-2 — CUSTOMER VALIDATION (Stage 1) · Линза: Product (контекст: Business/Strategy) · Инструкция для Инженера Продукта нового поколения (PAF, [S1],[S2]). Преемственность метода: исходный раннбук RB-STEP-2-CUSTOMER-VALIDATION/index.md (классическая модель контекста потребителя — 8 сущностей).

🎯 Цель в PAF-оптике¶

Превратить разрозненные заметки из интервью в живой Нексус потребителя — цифровой двойник, чья метрика качества Context Ripeness (CR) = полнота × актуальность растёт по мере насыщения узлами. Стадия стартует не с «беготни по интервью», а с Understand (Und-Id-Ex): анализа текущего состояния Нексуса рынка/продукта из RB-STEP-1 [S1] VI.5. Цель — поднять CR Нексуса потребителя с 0% до порога, при котором Кортекс генерирует идеи с максимальным CP и формирует Банч [S1] Принцип 2.

👤 Роль и ответственность¶

Product Engineer — постановщик задач Кортексу, валидатор узлов, владелец фокуса; работает только через проводника-Кортекс, не вручную [S1] III.1.
Product Ops — настраивает структуру Нексуса потребителя (8 сущностей), метрику CR, флаги увядания; повышает ИИ-зрелость стадии [S1, S2].
Growth Engineer — задаёт слой mNSM-гипотез поверх узлов сегмента (валидация монетизируемой ценности) [S1] III.3.
Зона человека: стратегический выбор фокус-сегмента и синхронизация между подами — не передаётся ИИ [S2] III.4.

🤖 Что делает Кортекс-агент¶

Nexus-Builder Agent (Phase-0): - Вход: Big Idea Statement + Нексус рынка/продукта из RB-STEP-1 (узлы-кандидаты), внешние сигналы (отзывы, форумы, product analytics). - Действие: создаёт каркас графа Нексуса потребителя из 8 сущностей (Сегмент / Триггер / Начальное состояние / Целевое состояние / Альтернативный путь / Проблема+Причина / Мотивация / Value Stream); вешает на каждый узел метаданные (источник-интервью[], CP, timestamp, статус увядания); считает CR как вычисляемую метрику. - Выход: пустой/частично заполненный граф с начальным CR и списком узлов-кандидатов на насыщение.

Фазы Context Ripeness (по [S1] III.1)¶

Фаза	Что происходит	Действие инженера
Созревание	рост информации в узлах	насыщать через интервью/агентов (2.1–2.5)
Увядание	потеря актуальности (устаревание данных, смена поведения)	флаг `статус=увядает` → refresh через Кортекс

CR = полнота × актуальность. Полнота = доля заполненных сущностей из 8. Актуальность = 1 − доля увядших узлов. CR — не самооценка, а вычисляемая метрика, привязанная к gate [reformation Сквозная 1].

Пример метаданных узла (Node schema)¶

id: trigger-07
type: Триггер
text: "Ребёнок получил плохую оценку по математике"
source_interviews: []          # пусто на 2.0 → CP=0
cp: 0
timestamp: 2026-06-20
decay_status: нет данных       # созревание / увядает
linked_nodes: [segment-02, problem-03]

Входные узлы из RB-STEP-1 (преемственность)¶

Из Нексуса рынка/продукта берутся: сегменты-кандидаты, конкуренты 4 типов, тренды, opportunities/threats. Они становятся затравкой для узлов Сегмент и Альтернативный путь в Нексусе потребителя — но не копируются как факты, а переформулируются как гипотезы для проверки (см. 2.1).

🧠 Что делает человек (метапознание)¶

Чекпоинт метапознания: Product Engineer проверяет, что узлы не выдуманы Кортексом (трассировка до источника). Узел без источника → CP=0 [S2] III.4.
Veto-право: отклонить авто-сгенерированный узел, если он не подтверждён реальным интервью или верифицированным внешним сигналом.
Защита от AI-персон: на этом этапе персон нет — есть только каркас; узлы наполняются дальше (см. 2.5, 2.6).

Почему Stage 1 начинается с Understand, а не с интервью¶

По Und-Id-Ex [S1] VI.5: null-base продукт стартует с Understand (анализ Нексуса), а не с «беготни по интервью». Без спелого каркаса Кортекс «усиливает мусор» [S1] Часть IX. Поэтому 2.0 = сборка каркаса из имеющихся источников ДО интервью; интервью (2.3–2.4) насыщают уже структурированный граф, а не создают его с нуля. Это фундаментальное отличие от линейного конвейера исходного index.md (7 шагов подряд).

📦 Артефакт = узлы Нексуса потребителя¶

Типы узлов (по модели контекста из исходного 2.5): | Узел | Вопрос, на который отвечает | |---|---| | Сегмент | Кто этот человек (роль/контекст)? | | Триггер | Что запускает потребность? | | Начальное состояние | Откуда стартует? | | Целевое состояние | Куда хочет попасть? | | Альтернативный путь | Как решает сейчас? | | Проблема + Причина | Где спотыкается и почему? | | Мотивация | Почему цель важна? | | Value Stream | Какова дельта ценности текущих решений? |

Каждый узел несёт: источник[], CP, timestamp, статус увядания (созревание/увядание) [S1] III.1.

🚦 Confidence Point-гейт¶

Критерий входа в стадию: CR Нексуса рынка из RB-STEP-1 ≥ порога (проверяется Nexus-Builder).
Критерий выхода из 2.0: каркас Нексуса потребителя создан, CR baseline зафиксирован.
Стоимость риска: «Сколько ресурсов и негативного эффекта на клиентскую базу понесём, если начнём интервью без спелого каркаса Нексуса?» [S1] VI.7.

Цикл Product Sprint на Stage 1 (обёртка)¶

Этап 2.x — не линейный каскад, а цикл Product Sprint [S1] VI.4: 1. Progress Pulse — фиксация CR-состояния Нексуса потребителя (этот шаг, 2.0). 2. Bunch Saturation (Und-Id-Ex) — 2.1–2.5 насыщают узлы. 3. Pitching of Trust — 2.7: защита фокус-сегмента. 4. → переход в RB-STEP-3 / Value Validation (Harvesting-точка: fit-сегмент зафиксирован как инкремент контекста).

Эффект асинхронности [S1] VI.2: разные узлы Нексуса созревают с разной скоростью → обновление event-based, не по каденсу.

🔭 Связь с Тремя Линзами (3PL)¶

Product Lens — Нексус потребителя питает Product Sprint (Нексус продукта → Банч) [S1] VI.1. Business Lens — Growth Engineer навешивает mNSM-гипотезы на узлы сегментов. Стратегическая линза (RB-STEP-1) поставляет входные узлы.

🛡️ Анти-workslop чекпоинт¶

Узлы без источника — workslop (галлюцинация) → блокируются, CP=0 [S2] III.7.
Запрет на авто-генерацию «персоны» на этом шаге (нет интервью → нет персоны). Правило «персона ≥4 интервью» вступает в силу в 2.6.

🔄 Преемственность: классика → PAF¶

Было (исходный `index.md`)	Стало (PAF)
7-шаговый линейный конвейер	Цикл Product Sprint (Progress Pulse → … → Harvesting)
Контекст = статичный текст	Нексус потребителя — живой цифровой двойник
Context Ripeness — поле самооценки	CR = вычисляемая метрика (полнота × актуальность)
Старт с «беготни по интервью»	Старт с Understand (анализ Нексуса из RB-STEP-1)
Нет «увядания» контекста	Две фазы: созревание / увядание → авто-refresh
Артефакт = «профиль в Notion»	Артефакт = спелый подграф Нексуса

🧩 Маппинг к Skill Map / профстандарту 06.012¶

Skill Map сектор 1 (Discovery & Researches) [S3] IV.2 — управление контекстом потребителя.
Профстандарт B/01.5 «Продуктовые исследования» [S4] V — уровень Product Engineer.
Уровень: средний круг (анализ, агрегация, проектирование) [S3] IV.3.

📖 Пример сквозного кейса (AI-сервис подбора репетиторов)¶

Вход: из RB-STEP-1 — Big Idea «AI-подбор проверенного репетитора под ребёнка», Нексус рынка (сегменты: родители школьников, репетиторы; конкуренты: Profi.ru, Repetitor.ru, сарафанное радио). Действие Nexus-Builder: создаёт каркас из 8 сущностей; из узла «сегмент родители» генерирует кандидат-узлы Сегмент (родитель 7–11 класс), Триггер (плохая оценка / экзамен), Начальное состояние (нет репетитора), Целевое (занятия с проверенным специалистом), Альтернативный путь (чаты → Profi.ru → Авито), Проблема+Причина (не может сравнить — нет критериев), Мотивация (успешный экзамен), Value Stream (дельта: рекомендация vs перебор анкет). Результат 2.0: каркас с CR baseline ≈ 15% (только сущности, без подтверждений); список узлов-кандидатов на насыщение через интервью (2.3–2.4).

❓ Контрольные вопросы (метапознание)¶

Есть ли у каждого узла источник? Узел без источника → CP=0, не идёт в насыщение.
Все ли 8 сущностей представлены в каркасе? (полнота CR)
Описывают ли узлы поведение/ситуацию, а не демографию?
Не опередили ли мы себя — не начали ли генерировать «персоны» до интервью? (запрет на 2.0)
Какова стоимость риска, если начнём интервью на неспелом каркасе?

⚠️ Типичные ошибки 2.0¶

Сразу в интервью без каркаса → данные ложатся в хаос, CR не растёт. Контрмера: 2.0 обязателен до 2.3.
CR как самооценка → «поставили 70% потому что кажется». Контрмера: CR вычисляется из доли заполненных/увядших узлов.
Копирование узлов рынка как факты → конкурентная карта ≠ поведение потребителя. Контрмера: переформулировать в гипотезы (2.1).
Игнорирование увядания → контекст устарел, но CR не падает. Контрмера: Product Ops вешает флаги статус=увядает.
Иллюзия «Кортекс = один промпт» → Nexus-Builder — агент с RAG, не разовый запрос к LLM.

🔗 Связи¶

Назад: reformation (RB-STEP-1 → Stage 1) · Дальше: 2.1 instruction Связанные: reformation · index · naming_conventions · PAF-ANALYSIS