# AI-ориентированная организация — методология «AI-система управляемости» (System of Control)

Автор: Дмитрий Тетервак · https://tdlife.club
Версия 1.2 · обновлено 2026-09-17
Постоянный адрес этого файла (обновляется по этой же ссылке): https://tdlife.club/ai-org/methodology.txt
Читать глазами: https://tdlife.club/ai-org/ — короткая версия для собственника, 5 минут
Полная версия с картинками и схемами: https://tdlife.club/ai-org/ai-org-framework-system-of-control.html

Что это. Методология того, как выстроить внутри компании AI-контур: единую систему, в которой люди
и ИИ-агенты работают по общим правилам, ИИ помогает контролировать исполнение, а собственник видит
всё на одном экране. Порядок — system-first: сначала управляемость (карта бизнеса, процессы, роли,
регламенты, данные, контроль), и только поверх неё ИИ как усилитель.

Этот файл сделан для того, чтобы загрузить его в свой ИИ (Claude, ChatGPT, Gemini и другие)
и применить методологию к своей компании.

---

## Как пользоваться (для человека)

1. Загрузи этот файл в чат со своим ИИ. Надёжнее загрузить сам файл, чем дать ссылку:
   по ссылке некоторые ИИ читают только начало длинного документа. На этот случай всё нужное
   для разбора компании стоит в начале файла (Части 1 и 2).
2. Отправь вместе с файлом такой запрос:

   Вот методология «AI-система управляемости» Дмитрия Тетервака. Действуй по разделу «Инструкция для ИИ-ассистента» в начале файла: сначала задай мне вопросы о моей компании, потом определи стадию зрелости и собери план на 30 / 60 / 90 дней.

3. Отвечай на вопросы ИИ о своей компании. Чем конкретнее ответы, тем точнее план.
4. Возвращайся за обновлениями: файл лежит по постоянному адресу, список изменений — ниже.

---

## Инструкция для ИИ-ассистента

Ты получил методологию «AI-система управляемости» (автор — Дмитрий Тетервак). Владелец бизнеса
хочет применить её к своей компании. Работай так:

1. Не пересказывай методологию. Сначала расспроси владельца — блоками, не больше 5 вопросов
   в одном сообщении: чем занимается компания и сколько в ней людей; кто за что отвечает;
   какие процессы приносят деньги; какими программами и ИИ-инструментами уже пользуются и кто именно;
   где лежат данные (CRM, таблицы, мессенджеры, почта); что владелец делает сам каждый день
   и от чего хочет освободиться. Опирайся на Приложение H (опросник подготовки) — оно в Части 2.
2. Определи стадию зрелости по лестнице (стадии 1–5) и Приложению C (диагностика, Часть 2). Назови стадию
   и объясни, по каким признакам ты её определил.
3. Разложи компанию по контурам в каноническом порядке построения: C1 Карта бизнеса → C2 Процессы →
   C3 Люди → D Данные (минимум: журнал событий и состояние) → +A Агенты → C4 Регламенты →
   C5 Контроль и дашборд собственнику; сквозные правила (Governance) — через все шаги.
   По каждому контуру: что уже есть, чего нет, что сделать первым.
4. Выбери 1–3 первых шага по матрице приоритизации (Приложение D, Часть 2). Держи порядок system-first:
   не предлагай ставить ИИ-агента на процесс, у которого нет владельца и описания.
5. Там, где ИИ контролирует работу людей (звонки, переписка, документы), напомни владельцу:
   сотрудников нужно предупредить, а требования закона своей страны или штата о записи разговоров
   и о персональных данных — проверить до запуска.
6. Итог выдай планом на 30 / 60 / 90 дней: шаг, ответственный, результат, как проверить, что сделано.
   Пиши простым языком; термины методологии поясняй в скобках.
7. Если данных не хватает — спрашивай, а не додумывай. Цифры из методологии (проценты, сроки,
   экономика) — ориентиры для оценки, а не обещание результата. Если ты видишь не весь файл
   (текст обрывается до Части 3) — работай по Частям 1 и 2 и скажи владельцу, что для глубокого
   разбора отдельного контура файл нужно загрузить целиком.
8. Отвечай на том языке, на котором пишет владелец.

---

## Список изменений

- 2026-09-17 · версия 1.2 — сведены противоречия, найденные технической проверкой. Один канонический порядок построения
  контуров. Одна шкала самостоятельности агента L0–L3 (шаг регламента может быть строже общей
  ступени). Один список из 7 проверяемых законов конституции + блок принципов. Правило
  «1 мозг или 3» переписано в четыре вопроса да/нет; у нескольких узлов общие конституция,
  экран собственника и справочник клиентов. Новый раздел «Платежи на стадии 5 (жёсткий лимит)».
  Шаблон AOP получил процесс, владельца и цель; пример AOP в сквозном кейсе переписан по шаблону.
  Единые форматы: actor = human:/agent:, поля health, идентификаторы, режим роли и агента.
- 2026-09-17 · версия 1.1 — инструменты разбора (опросник H, диагностика C, матрица приоритизации D) перенесены
  в начало файла: теперь ИИ может работать по инструкции, даже если прочитал только начало
  (так бывает, когда файл дают ссылкой). Исправлено: «5 шагов на встрече» в диагностике,
  убрана ссылка на несуществующий контур C6, убраны две служебные заметки в приложениях H и J.
- 2026-09-17 · версия 1.0 — первая публикация текстовой версии: короткая версия для собственника
  + полная методика (контуры C1–C5, слой агентов, слой данных, Governance, приложения A–J).

---
---

# ЧАСТЬ 1 · Короткая версия для собственника (5 минут)

## За одну минуту (TL;DR)

У тебя зоопарк инструментов, ты тонешь в зумах, а данные в отчётах не сходятся между собой — и каждое решение упирается в «надо спросить у Х». Решение — не «внедрить AI», а собрать бизнес в систему из **7 контуров**: карта компании, процессы, люди, агенты, регламенты, данные и дашборд собственника. На выходе ты получаешь **управляемость** и **один экран**, где видно, что происходит сегодня и что делать. Первый шаг — нарисовать карту своего бизнеса на одной странице. 30 минут — и ты впервые увидишь его целиком.

## Что это и почему именно так

Это **system-first**, а не AI-first. Сначала наводим порядок в управляемости — кто за что отвечает, как идут процессы, где живут данные, — и только потом ставим AI поверх готовой системы. Так и должно быть: большинство AI-пилотов проваливаются не потому, что технология плохая, а потому, что её ставят на хаос — и она лишь ускоряет хаос. Сильный бизнес строится наоборот: сначала система, в которой видно и понятно, потом — умные помощники, которые в этой системе работают. AI не заменяет управление, он его усиливает — но только если есть что усиливать.

Схема фреймворка (картинка): https://tdlife.club/ai-org/ai-org-framework-diagram.html

## 7 контуров одним взглядом

| Контур | Что это простыми словами | Что ты как собственник получаешь |
|---|---|---|
| **C1. Карта** | Один лист: что продаём → какие процессы → кто люди → как управляем → чем пользуемся | Видишь весь бизнес целиком, без слепых зон |
| **C2. Процессы** | Каждое дело разложено: с чего начинается → шаги → результат, и где передаётся из рук в руки | Понятно, где затыки и кто роняет мяч на передаче |
| **C3. Люди** | Роль ≠ человек: что делает сам, что — с AI-помощником, что можно отдать «цифровому сотруднику» | Видно, кем закрыта каждая функция и где дыры |
| **+A. Агенты** | Умные помощники поверх людей: человек работает как привык — агент фоном собирает и готовит | Рутина уходит с людей, скорость растёт без раздувания штата |
| **C4. Регламенты** | Правила, которые реально исполняются и сами ловят отклонения, а не лежат мёртвым PDF | Стандарт соблюдается по факту, а не «на бумаге» |
| **D. Данные** | Единый источник правды: цифры считаются один раз и одинаково для всех | Данные перестают врать и спорить друг с другом |
| **C5. Дашборд + Governance** | Один экран: что делать сегодня (не отчёт за прошлый год) + правила игры для всей системы | Управляешь по факту, с одного места, держишь всё под контролем |

Строки таблицы идут по слоям схемы. Строят в другом порядке: карта → процессы → люди → минимум данных → первые агенты → регламенты → контроль; правила — с первого шага.

## Как это выглядит на примере

Возьмём живой пример — **«Светлый Дом», мебель на заказ, ~12 человек, без ERP**. Вот как каждый контур меняет работу — «было → стало»:

| Контур | Было (зоопарк) | Стало (система) |
|---|---|---|
| **C1. Карта** | Бизнес — в голове владельца; один клиент записан в 3 таблицах под 3 разными именами | Один лист: что продаём, кто за что, и «клиент» определён один раз для всех |
| **C2. Процессы** | Замер полежал в личном WhatsApp замерщика 2–3 дня — клиент остыл и ушёл | Процесс по шагам: видно, где зависло и кто принимает работу дальше |
| **C3. Люди** | Всё на дизайнере Лене: и смета, и КП, и клиент, и цех; ушла в отпуск — проекты встали | Рутина (смета, КП, напоминания) — на агенте; за Леной только решения |
| **+A. Агенты** | Ночные заявки из Instagram теряются до утра, КП клиент ждёт 2–3 дня | Агент ловит заявки 24/7 и готовит черновик КП к утру — человек проверяет и шлёт |
| **C4. Регламенты** | Предоплату берут «по договорённости» 0–50 %, PDF-стандарт никто не открывал | Правило «в цех только после 30 % предоплаты» соблюдается само; нарушение — сигнал владельцу |
| **D. Данные** | «Сколько заказов в работе?» — три человека дают три разные цифры | Одна цифра из одного источника — у всех одинаково |
| **C5. Дашборд** | О просрочке монтажа узнаёшь от злого клиента по телефону | Экран показывает: заказ завис 2 дня — почини сегодня |

> Это же по шагам, но на другой компании (автосервис) и с реальными артефактами — в глубокой версии для внедренца (Приложение B).

## Стадии зрелости и где ты сейчас

Ответь честно «да/нет» на 7 вопросов — по одному на контур:

1. **Карта.** Есть ли у тебя бизнес на одном листе, который ты можешь показать новому человеку за 5 минут?
2. **Процессы.** Ключевые процессы описаны (с началом, шагами и результатом), а не живут только в головах?
3. **Люди.** По каждой важной функции понятно, кто за неё отвечает, без «это вроде на Маше»?
4. **Агенты.** Хоть одну рутину у тебя уже делает AI-помощник, а не человек руками?
5. **Регламенты.** Твои правила и стандарты реально соблюдаются, и ты это видишь?
6. **Данные.** Ключевые цифры у всех совпадают, и ты им доверяешь?
7. **Дашборд.** Есть один экран, где видно состояние бизнеса прямо сейчас?

Посчитай «да»:

| «Да» | Стадия | Где ты |
|---|---|---|
| 0–1 | **1. Осознание** | Понимаешь, что пора, но системы нет |
| 2 | **2. Ad hoc** | Что-то делается, но от случая к случаю |
| 3 | **3. Зоопарк** | Инструментов много, цельной системы нет |
| 4–5 | **4. Контур** | Бизнес собран в управляемую систему |
| 6–7 | **5. AI-native** | Система работает, AI встроен в неё |

Главная цель — **скачок с 3 на 4**: выйти из «зоопарка» в управляемую систему. Это та точка, где собственник впервые перестаёт быть единственной несущей конструкцией.

## Что это даёт (деньги и время)

- **Меньше зумов и совещаний.** Статус виден на экране — не нужно собирать людей, чтобы узнать, что происходит.
- **Решения по факту, а не по памяти.** Цифры единые и достоверные — управляешь по данным, а не по ощущениям и пересказам.
- **Дёшево тестировать гипотезы.** Новую идею можно проверить силами агентов за дни, не нанимая людей и не перекраивая команду.
- **Меньше зависимости от ключевого человека.** Знания и процессы живут в системе, а не в одной голове, которая может уйти, заболеть или выгореть.
- **Рост без раздувания штата.** Рутину забирают агенты — люди занимаются тем, что требует человека, а объём работы растёт быстрее затрат.

## «1 мозг или 3» — простыми словами

Вопрос: вести один контур на весь бизнес или несколько?

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

Простое правило: **один бизнес — один мозг; разные бизнесы под одной крышей — разные мозги, но единый пульт у собственника.**

## Первый шаг — на этой неделе

1. **Нарисуй карту бизнеса на одном листе** (контур C1): что продаёшь → ключевые процессы → кто люди → как управляешь → какими инструментами. 30–60 минут. Уже на этом шаге проступят слепые зоны.
2. **Пройди само-проверку из 7 вопросов** выше и зафиксируй свою стадию. Это твоя точка отсчёта и понимание, какой контур подтягивать первым.

## Дальше

Инструменты разбора — в Части 2, полная методика — в Части 3 этого файла. С картинками и схемами: https://tdlife.club/ai-org/ai-org-framework-system-of-control.html

---
---

# ЧАСТЬ 2 · Инструменты разбора: опросник (H), диагностика зрелости (C), матрица приоритизации (D)

Эти три приложения стоят в начале, потому что по ним ИИ разбирает компанию. Термины, которые здесь
встречаются (контуры C1–C5, +A, D, Governance), коротко объяснены в Части 1 и подробно — в Части 3.

## Приложение H · Опросник подготовки

> **Кому.** Внедренцу. Заполняется ДО первой настройки — на интервью с собственником (1–2 часа на контур, лучше отдельными сессиями). Цель — вытащить из головы владельца сырьё для каждого контура C1→C5, чтобы не строить систему на догадках. **Правило интервью:** не объясняй теорию, спрашивай факты и примеры; на каждый ответ проси *конкретный кейс из прошлой недели*. Если собственник «не знает» — это находка, помечай как пробел и эскалируй.
>
> **Как читать таблицы.** `Вопрос` → что спросить дословно. `Наполняет` → артефакт контура, который ответ заполняет. `След. чек/шаг` → что внедренец делает/проверяет сразу после ответа. SMB-контекст: ERP нет, агенты порождают след с нуля — поэтому часть ответов фиксирует не «как есть в системе», а «как реально в головах и переписке».

---

### C1 · Карта бизнеса (онтология, идентичность, единый case_id)

| Вопрос (дословно) | Наполняет | След. чек/шаг |
|---|---|---|
| Что у вас считается **клиентом** и по какому ключу ловится дубль (телефон / email / ИНН / связка)? | Онтология сущности «клиент» | Зафиксировать `case_id`-ключ; проверить на 20 реальных записях, что дубли реально схлопываются |
| Перечислите **5–7 главных сущностей** бизнеса (клиент, сделка, заказ, объект, платёж…) и кто из них «корень», вокруг которого крутится всё. | Список сущностей + корневая | Выбрать носитель `case_id` (обычно сделка/заказ); остальное — связи к нему |
| Один и тот же объект где называется **разными словами** (лид/заявка/обращение — это одно или разное)? | Глоссарий, разрешение синонимов | Свести синонимы в один термин; занести в `04-glossary` |
| Что вы продаёте — назовите **продукты/услуги списком** и как они группируются в линейки. | Уровень «продукт» карты | Сверить с реальными позициями в счетах/прайсе за месяц |
| Где **физически живут** данные о клиенте и сделке сейчас (CRM / Excel / WhatsApp / голова менеджера)? | Инвентаризация инструментов (C1→ввод в D) | Список источников → кандидаты в Event Log; пометить «голова/мессенджер» как риск |
| По какому признаку вы поймёте, что **две записи — это один и тот же случай**, а не два? | Правило идентичности case_id | Записать правило мёрджа; проверить граничный кейс (повторный клиент / возврат) |

---

### C2 · Процессы (триггер→шаги→результат, handoffs, SIPOC)

| Вопрос (дословно) | Наполняет | След. чек/шаг |
|---|---|---|
| Возьмём **главный процесс** (как заявка превращается в деньги): что его **запускает** (триггер) и чем он **заканчивается** (результат)? | Границы процесса (вход/выход SIPOC) | Зафиксировать триггер-событие и определение «готово»; это первые и последние `activity` в Event Log |
| Назовите **шаги по порядку** — от триггера до результата, своими словами, без идеала. | Цепочка activity | Пронумеровать шаги; каждый шаг = одна `activity` с actor |
| В каких точках **дело переходит от одного человека к другому** (handoff) и где чаще всего **застревает**? | Карта handoffs, узкие места | Пометить handoff-точки как кандидаты на `qualifier/router`-агента и на drift-метрику |
| Что на входе каждого шага должно быть **готово**, иначе шаг буксует (поставщик→вход)? | SIPOC supplier/input | Сформулировать входной чек-лист; станет gate в AOP (C4) |
| Где у процесса есть **исключения и развилки** («а если клиент…», «а если оплата частями…»)? | Ветки процесса | Отделить happy path от исключений; исключения — отдельные ветки, не замазывать |
| Как сейчас понимаете, что **конкретная заявка зависла** — и через сколько дней это «зависла»? | План vs факт (вход в process mining C5) | Задать SLA/норматив на шаг → порог для drift-detector |

---

### C3 · Люди (роль≠исполнитель, RACI, каналы, value-stack)

| Вопрос (дословно) | Наполняет | След. чек/шаг |
|---|---|---|
| По каждому шагу процесса: **кто отвечает (R)**, кто **утверждает (A)**, кого **спрашивают/информируют**? | RACI-матрица | Заполнить RACI по шагам C2; найти шаги без A (никто не отвечает) — флаг |
| Где описана **роль**, а где — конкретный **человек**? Что сломается, если этот человек уйдёт завтра? | Разделение роль/исполнитель | Вынести роль в `role_slot`; пометить «bus factor = 1» как риск |
| Какие шаги человек делает **руками, но они тупые/повторяющиеся** (копипаст, разнести, напомнить, свести)? | Кандидаты на AI (collector/drafter/reconciler) | Список → вход в реестр агентов; выбрать 1 пилот «человек работает — агент собирает фоном» |
| По каким **каналам** реально идёт работа по каждой роли (телефон, WhatsApp, почта, CRM)? | Карта каналов | Сверить с источниками данных C1/D; канал без следа = слепая зона |
| Что в работе роли — **исполнение**, что — **надзор**, а что — **движение к целям** (value-stack)? | Value-stack по роли | Проверить, не съедает ли исполнение весь день руководителя; цель агентов — снять исполнение |
| Где роль = **человек**, где **человек+AI-помощник**, а где можно **цифрового сотрудника** (полностью на коннекторах)? | Режим исполнителя (assistant / digital-employee) | Проставить `mode` в карточке агента; цифровому — назначить коннекторы и autonomy-по-риску |

---

### +A · Агенты (поверх людей: реестр, карточки, guardrails, health)

| Вопрос (дословно) | Наполняет | След. чек/шаг |
|---|---|---|
| Для выбранного шага: что агент берёт **на входе**, что отдаёт **на выходе**, и кому отдаёт? | Карточка: `input` / `output` / `data_sink` | Заполнить карточку-стандарт; выход должен быть машиночитаем (не «в чате сказал») |
| **Откуда** агент читает данные и **куда** их пишет (read-only RAG или обновляет State Store)? | `data_source` / `data_sink`, режим записи | Подтвердить, что агент **обновляет** SSOT, а не только читает; иначе следа нет |
| Что агенту делать можно **самому**, а что — только **с подтверждением человека** (по риску ошибки)? | `autonomy` + `gate` (human-in-the-loop) | Привязать автономию к риску: дорого/необратимо → gate обязателен |
| Какие **красные линии** агент не пересекает никогда (не пишет клиенту сам, не двигает деньги, не удаляет)? | `guardrails` | Записать запреты явно; проверить, что технически невозможно их обойти |
| Как мы узнаем, что агент **молча сломался** (перестал собирать, выдал пусто) — и кто получит сигнал? | `health` / health-check против silent failure | Назначить health-метрику и владельца алерта; без неё агента не запускать |
| Кто **владелец** агента и в какой **роли-слоте** он стоит (кого дублирует/разгружает)? | `owner` / `role_slot` / реестр | Внести в реестр агентов; один агент = одна узкая задача (не «универсал») |

---

### C4 · Регламенты → AOP (исполнимый контракт + drift-detector)

| Вопрос (дословно) | Наполняет | След. чек/шаг |
|---|---|---|
| Покажите **действующий регламент** по этому процессу — он есть, его читают, по нему работают? | Базовый AOP-контент | Если PDF в шкафу — переписать в исполнимый AOP; «research writes, delivery reads» |
| Что в процессе считается **«сделано правильно»** — измеримый критерий, а не «качественно»? | Definition of Done / acceptance | Превратить в проверяемое условие → вход drift-detector |
| Что должно произойти, если **шаг пропущен или сделан не так** — эскалация к кому и когда? | Правила исключений / эскалация AOP | Прописать ветку эскалации; назначить адресата |
| Какие пункты регламента **по факту нарушаются** чаще всего — где жизнь расходится с бумагой? | Точки drift | Эти точки — приоритет для drift-метрик; не доверять «по бумаге всё ок» |
| Чек-лист полноты: для этого процесса заданы **триггер, шаги, роли, DoD, исключения, владелец**? Чего нет? | Полнота AOP | Закрыть пробелы до запуска; неполный AOP агенту не отдавать |
| Кто **владелец** этого AOP и как часто он его **пересматривает** (drift накапливается)? | Стюардство AOP | Назначить владельца + ритм ревизии; иначе контракт протухнет |

---

### D · Данные → SSOT (Event Log, State Store, контракты)

> Спрашивается сквозь все контуры, но фиксируется здесь. В SMB без ERP след порождается с нуля — задача интервью понять, **что станет источником событий**.

| Вопрос (дословно) | Наполняет | След. чек/шаг |
|---|---|---|
| По каждому шагу: остаётся ли **след «кто-что-когда»** (case_id + activity + timestamp + actor) — или только в голове? | Event Log | Где следа нет — назначить агента-collector, чтобы порождал событие |
| Где лежит **текущее состояние** дела (статус сделки) и кто его **меняет** — человек или система? | State Store | Завести State Store (SQL/таблица/граф), который агенты **обновляют**, не read-only |
| Когда вы говорите «**статус: в работе / оплачено / закрыто**» — где этот статус хранится и кто его источник истины? | Контекст-слой, источник истины статуса | Один источник на статус; запретить дубли статуса в разных местах |
| Какие данные приходят **извне** (банк, поставщик, площадка) и в каком формате? | Data contracts (вход) | Зафиксировать контракт на формат; кто нарушил формат — алерт |
| Что у вас **«данные»** (факты: суммы, даты), а что **«знания»** (как принимать решение)? Не путаются ли? | Разделение данные≠знания | Знания → в AOP/онтологию, данные → в SSOT; не складывать в одну кучу |
| Если завтра нужен отчёт «**сколько сделок зависло >7 дней**» — из чего его собрать прямо сейчас? | Готовность SSOT к метрикам | Если собрать неоткуда — это дыра в Event Log; закрыть до C5 |

---

### C5 · Контроль + Дашборд (actionable «что делать сегодня», process mining, metrics layer)

| Вопрос (дословно) | Наполняет | След. чек/шаг |
|---|---|---|
| Что вы открываете **утром первым**, чтобы понять «всё ли ок» — и чего там не хватает? | Прообраз дашборда | Отделить «что делать сегодня» (actionable) от отчётности «что было» |
| Назовите **3–5 чисел**, по которым реально управляете (а не «было бы интересно»). | Метрики дашборда | По каждой — один governed-расчёт (semantic layer), одна формула на всех |
| Для каждой метрики: какое значение — **«надо вмешаться сегодня»**? | Пороги / триггеры действий | Превратить порог в карточку действия «кому и что сделать» |
| Где сейчас **план расходится с фактом** в процессе — и видите ли вы это вовремя? | Process mining (план vs факт) | Сопоставить идеальную цепочку C2 с Event Log D; расхождение = алерт |
| Одно и то же число (выручка, конверсия) у разных людей **считается одинаково**? Бывают споры «у меня другая цифра»? | Semantic/metrics layer | Закрепить единый расчёт; убрать локальные версии формулы |
| Что из дашборда вы хотите **получать сам** (пуш в нужный момент), а не ходить смотреть? | Режим доставки + кандидаты-агенты | Назначить router/reconciler на пуш; дашборд приходит к собственнику, не наоборот |

---

### Governance · Сквозной чек (заполнить по итогам всех контуров)

| Вопрос (дословно) | Наполняет | След. чек/шаг |
|---|---|---|
| Кто **владелец каждого узла** (процесс / агент / AOP / метрика) — на каждый есть имя? | Stewardship 3→4 | Карта владельцев; узел без владельца не запускать |
| Где правила должны **исполняться в рантайме автоматически**, а не «договорились на словах»? | Runtime-enforcement | Перевести ключевые guardrails/gates в технический контроль, не в комитет |
| **Слепые зоны (Минцберг):** где в бизнесе вообще нет ни следа, ни владельца, ни регламента? | Чек-лист слепых зон | Список белых пятен → бэклог следующего этапа |
| Текущая **зрелость 1–5** по каждому контуру — где вы честно сейчас? | Оценка зрелости | Зафиксировать baseline; цель этапа — скачок 3→4, не сразу 5 |

---

**Итог интервью (внедренцу):** на выходе должно быть по каждому контуру — заполненный артефакт + список пробелов («не знает / нет следа / нет владельца»). Пробелы важнее ответов: именно они — карта работ на внедрение. Не запускай ни одного агента, пока для его шага нет `case_id` (C1), следа в Event Log (D) и владельца health-check (+A).

---

## Приложение C · Диагностика зрелости (само-оценка)

> **Зачем этот инструмент.** За одну встречу с собственником (60–90 мин) определить, **где организация находится по каждому контуру** системы управления, найти **узкое место** (самый слабый контур — он тормозит весь поток) и зафиксировать **разрыв до стадии 4** (Контур → AI-native), которая является целевой. Инструмент — не аудит ради оценки, а способ выбрать **первый контур для внедрения**: тянем не самый интересный, а самый слабый.
>
> **Как пользоваться (5 шагов на встрече):**
> 1. Объясняешь шкалу 1–5 (см. ниже) — 2 минуты.
> 2. По каждому из 7 контуров и по сквозному слою правил (Governance) — всего 8 строк — задаёшь 3–4 вопроса. Просишь собственника назвать уровень **по фактам, а не по намерениям** («как есть сегодня», не «как должно быть»).
> 3. Внедренец фиксирует уровень в таблицу + одну цитату-доказательство (иначе балл «нарисован»).
> 4. Считаешь профиль (медиана по контуру), строишь разрыв до 4.
> 5. Узкое место = контур с минимальным баллом → это кандидат №1 в дорожную карту.

---

### Шкала зрелости (общая, едина для всех контуров)

| Ур. | Имя | Суть одной фразой | Маркер «как узнать» |
|---|---|---|---|
| **1** | Осознание (Awareness) | «Знаем, что надо, но не делаем» | В голове у собственника, нигде не записано |
| **2** | Ad hoc (Active) | Делается, но каждый раз заново, руками, без стандарта | Один человек знает «как», уйдёт — встанет |
| **3** | Зоопарк (Operational) | Есть инструменты/документы, но разрозненные, не связаны, дублируют | Excel + чаты + CRM + голова, нет единой точки |
| **4** | Контур (Systemic) | Единый связанный процесс/данные, обновляется, есть владелец | Можно показать одну систему, где всё сходится |
| **5** | AI-native (Transformational) | Контур + агенты собирают/готовят фоном, человек надзирает | Агент работает, человек проверяет, не наоборот |

**Правило фактологии:** уровень засчитывается, только если собственник может **показать артефакт** (файл, экран, регламент) или назвать **конкретного человека/процесс**. «Планируем», «в целом есть», «у нас же все понимают» = уровень не выше 2.

---

### C1 · Карта бизнеса (онтология, идентичность, единый case_id)

| # | Вопрос | Ур.1 | Ур.2 | Ур.3 | Ур.4 | Ур.5 |
|---|---|---|---|---|---|---|
| C1.1 | Есть ли единая карта «продукт → процессы → люди → управление → инструменты»? | Только в голове собственника | Рисовали раз на салфетке | Куски в разных доках | Одна актуальная карта, поддерживается | Карта живая, агент сверяет с реальностью |
| C1.2 | Есть ли **единый идентификатор сделки/заказа** (case_id), сквозной от заявки до оплаты? | Нет, каждый отдел зовёт по-своему | Номер есть, но не везде | Номер в CRM, но в чатах/доках теряется | Сквозной id во всех системах | id ведёт агент, связывает события сам |
| C1.3 | Совпадает ли «как мы себя описываем» с тем, как реально работаем? | Не задумывались | Описание устарело | Частично, есть расхождения | Описание = реальность, ревизуется | Расхождения ловит дрифт-детектор |
| C1.4 | Знает ли новый сотрудник за день, «что у нас откуда берётся»? | Нет, учится месяцами | По устной передаче | Читает разрозненное | Есть карта-онбординг | Карта + агент-навигатор |

---

### C2 · Процессы (триггер → шаги → результат; handoffs; SIPOC)

| # | Вопрос | Ур.1 | Ур.2 | Ур.3 | Ур.4 | Ур.5 |
|---|---|---|---|---|---|---|
| C2.1 | Описаны ли ключевые процессы как «триггер → шаги → результат»? | Нет, «и так понятно» | 1–2 на бумаге | Есть схемы, но не у всех и устарели | Ключевые процессы описаны, актуальны | Процесс исполняется в системе, агент ведёт шаги |
| C2.2 | Видны ли **передачи (handoffs)** между людьми/отделами — кто кому что и когда? | Теряются, «у нас всё на согласовании» | Знают «по памяти» | Часть в чатах | Handoffs зафиксированы, видна точка передачи | Агент-router распределяет и логирует передачу |
| C2.3 | Знаете ли вы, **где процессы застревают** (узкие места, простои)? | Узнаём по жалобам клиента | По ощущениям собственника | Считаем вручную изредка | Есть метрика времени по этапам | Process mining: план vs факт автоматом |
| C2.4 | Для входа/выхода процесса определены поставщик и клиент (SIPOC)? | Нет | Для одного процесса | Частично | Да, для ключевых | Контракты входа/выхода проверяются автоматически |

---

### C3 · Люди (роль ≠ исполнитель; RACI; value-stack)

| # | Вопрос | Ур.1 | Ур.2 | Ур.3 | Ур.4 | Ур.5 |
|---|---|---|---|---|---|---|
| C3.1 | Разделены ли **роль и человек** (роль может выполнять человек / человек+AI / цифровой сотрудник)? | Роль = конкретный человек, иначе никак | Думали об этом | Кое-где замены прописаны | Роли описаны отдельно от людей | Часть ролей закрыта цифровым сотрудником |
| C3.2 | Есть ли **RACI** (кто делает / отвечает / согласует / информируется) по ключевым задачам? | Нет, «разберёмся» | В голове собственника | Частично, спорят о зонах | RACI зафиксирован | RACI исполняется системой, эскалации авто |
| C3.3 | Различаете ли вы **исполнение → надзор → цели** (value-stack) — кто что делает на каком уровне? | Собственник делает всё | Делегировано хаотично | Делегировано, но контроль ручной | Уровни разведены, надзор формализован | Исполнение у агентов, человек — надзор и цели |
| C3.4 | Знаете ли вы, **по каким каналам** идёт работа роли (где живут задачи и переписка)? | Везде и нигде | Личные чаты | Несколько каналов, дублируют | Каналы закреплены за ролями | Агент собирает из каналов в единый след |

---

### +A · Агенты (поверх людей; «человек работает — агент собирает фоном»)

| # | Вопрос | Ур.1 | Ур.2 | Ур.3 | Ур.4 | Ур.5 |
|---|---|---|---|---|---|---|
| A.1 | Используются ли AI-агенты в работе (не разовый ChatGPT, а в процессе)? | Нет / только пробовали | Сотрудники сами юзают ChatGPT кустарно | Несколько ботов, не связаны с процессом | Агенты встроены в процессы под задачу | Парк узких агентов под архетипы (collector/drafter/qualifier/router/reconciler) |
| A.2 | Есть ли на каждого агента **карточка-стандарт и реестр** (name, purpose, input/output, owner, guardrails, gate)? | Нет понятия | Знаем, что есть «какой-то бот» | Список в заметке | Карточка + реестр ведутся | Реестр живой, статус и health у каждого |
| A.3 | Заданы ли **guardrails, human-in-the-loop и автономия-по-риску** (где агент сам, где нужен человек)? | Нет, либо боимся, либо «пусть сам всё» | На усмотрение сотрудника | Где-то проверяем, где-то нет | Правила по риску прописаны, есть gate | Автономия дозирована по риску, эскалация авто |
| A.4 | Есть ли **health-checks против тихих сбоев** (агент молча перестал работать — узнаете)? | Узнаем, когда клиент пожаловался | Случайно замечаем | Проверяем вручную | Мониторинг статуса агентов | Авто health-check + алерт при silent failure |

---

### C4 · Регламенты → AOP (исполнимый контракт, не PDF)

| # | Вопрос | Ур.1 | Ур.2 | Ур.3 | Ур.4 | Ур.5 |
|---|---|---|---|---|---|---|
| C4.1 | В каком виде живут регламенты ключевых процессов? | В голове | Устные договорённости | PDF/док, который никто не открывает | Регламент-чек-лист, по нему реально работают | AOP = исполнимый контракт, система ведёт по шагам |
| C4.2 | Ловите ли вы **отклонение от регламента (drift)** — когда стали делать не по правилу? | Не ловим | Узнаём при разборе косяка | Замечаем выборочно при проверке | Сверяем периодически | Drift-detector ловит расхождение автоматом |
| C4.3 | Полны ли регламенты (вход, шаги, исключения, результат, ответственный)? | Нет | Только «нормальный сценарий» | Без исключений и владельца | По чек-листу полноты | Полнота проверяется при изменении |
| C4.4 | Разведены ли «**где пишут правила**» и «где их читают/исполняют» (research writes, delivery reads)? | Всё в одной куче | Правят все подряд | Путаница версий | Источник правил один, исполнение читает | Изменение правила авто-доезжает до исполнения |

---

### D · Данные → SSOT (Event Log, State Store, data contracts)

| # | Вопрос | Ур.1 | Ур.2 | Ур.3 | Ур.4 | Ур.5 |
|---|---|---|---|---|---|---|
| D.1 | Есть ли **единый журнал событий** (case_id + действие + время + кто), а не данные по чатам и головам? | Нет, «всё в переписке» | Частично в CRM | В нескольких системах, не сходится | Единый event log по ключевому потоку | Агенты сами пишут след в журнал |
| D.2 | Есть ли **актуальное состояние сделки/объекта** в одном месте (State Store), которое обновляется? | Спрашиваем у людей | В Excel, отстаёт | В CRM, но дублируется руками | Одно актуальное состояние, его **обновляют агенты** и люди (не read-only RAG) | Состояние обновляют агенты; расхождения с первичными системами ловятся и сверяются автоматически |
| D.3 | Различаете ли вы **данные и знания** (факты потока ≠ инструкции/контекст)? | Не различаем | Смешано в одном | Частично разделено | Данные и знания разведены, есть контекст-слой | Контекст-слой кормит агентов, данные отдельно |
| D.4 | Есть ли **контракты данных** (формат входа/выхода между системами/людьми фиксирован)? | Нет, кто как пришлёт | По устной норме | Часто ломается формат | Data contracts на ключевых стыках | Нарушение контракта ловится автоматом |

> **Поправка для SMB без ERP:** если систем-источников нет вовсе — это не «ниже 1», а нормальная стартовая позиция. Цель здесь: **агенты порождают след с нуля** (D.1–D.2 строятся самим внедрением агентов). Балл ставим по тому, **есть ли вообще единая точка правды**, а не по наличию ERP.

---

### C5 · Контроль + Дашборд (actionable «что делать сегодня», не отчётность)

| # | Вопрос | Ур.1 | Ур.2 | Ур.3 | Ур.4 | Ур.5 |
|---|---|---|---|---|---|---|
| C5.1 | Есть ли у собственника картина «**что делать сегодня / где горит**», а не отчёт за прошлый месяц? | Управляю по наитию | Отчёты постфактум, вручную | Несколько разных отчётов | Один actionable-дашборд: где затык сейчас | Дашборд + агент предлагает действие |
| C5.2 | Сверяете ли **план vs факт** по процессам (process mining)? | Нет | На глаз | Считаем руками изредка | Есть сравнение плана и факта по этапам | Process mining в реальном времени |
| C5.3 | Один ли у вас **governed-расчёт метрики** (все считают «выручку/конверсию» одинаково)? | У каждого своя цифра | Спорим о цифрах | Несколько версий метрик | Единый semantic/metrics layer | Метрики считаются детерминированно, вне LLM |
| C5.4 | Дашборд **ведёт к действию** (от цифры к «кому позвонить / что починить»)? | Нет дашборда | Цифры без действий | Смотрим, но не действуем | Цифра → задача → ответственный | Действие предлагается и эскалируется авто |

---

### Governance (конституция; runtime-enforcement; stewardship 3→4)

| # | Вопрос | Ур.1 | Ур.2 | Ур.3 | Ур.4 | Ур.5 |
|---|---|---|---|---|---|---|
| G.1 | Есть ли **«конституция»** — свод базовых правил, как тут всё устроено и решается? | Нет, «по ситуации» | В голове собственника | Разрозненные правила | Зафиксированный свод правил | Правила применяются в runtime, не на словах |
| G.2 | Правила соблюдаются **в моменте работы (runtime)** или «через комитеты и совещания»? | Никак | Ручной контроль собственником | Совещания, согласования | Часть правил вшита в процесс | Enforcement на уровне системы, не людей |
| G.3 | Есть ли **владелец-стюард** у каждого контура (кто отвечает за развитие 3→4)? | Всё на собственнике | Назначаем стихийно | Размытая ответственность | У контуров есть владельцы | Стюард + агенты ведут контур к 5 |
| G.4 | Проверяли ли вы **слепые зоны** (Минцберг: не управляем ли мы вслепую какой-то частью)? | Не задумывались | Узнаём по факту проблемы | Разовый аудит был | Регулярная сверка слепых зон | Слепые зоны подсвечиваются системой |

---

### Шаблон-таблица для заполнения (на встрече)

> Заполнять **по фактам**. В колонку «Доказательство» — конкретный артефакт/имя/экран. Без доказательства балл ≤ 2.

| Контур | Q.1 | Q.2 | Q.3 | Q.4 | **Балл (медиана)** | Доказательство / что показали | Разрыв до 4 |
|---|:--:|:--:|:--:|:--:|:--:|---|:--:|
| **C1** Карта бизнеса |   |   |   |   |   |   |   |
| **C2** Процессы |   |   |   |   |   |   |   |
| **C3** Люди |   |   |   |   |   |   |   |
| **+A** Агенты |   |   |   |   |   |   |   |
| **C4** Регламенты→AOP |   |   |   |   |   |   |   |
| **D** Данные→SSOT |   |   |   |   |   |   |   |
| **C5** Контроль+Дашборд |   |   |   |   |   |   |   |
| **G** Governance |   |   |   |   |   |   |   |

**Итог:** средний уровень зрелости = ___ · узкое место (минимум) = ___ · целевой контур №1 для внедрения = ___

---

### Правила скоринга

1. **Балл контура = медиана** его 3–4 вопросов (не среднее — медиана устойчивее к одному выпадающему ответу). При чётном числе ответов берём **меньшее из двух средних** (консервативно: зрелость не завышаем).
2. **Доказательство обязательно.** Нет артефакта/имени/экрана → балл по этому вопросу не выше **2**, что бы собственник ни говорил.
3. **«Планируем / собираемся» = текущий уровень, а не будущий.** Оцениваем «как есть сегодня».
4. **Разрыв до 4** по контуру = `max(0, 4 − балл)`. Это «сколько ступеней тянуть» до целевой стадии Контур.
5. **+A и D связаны с D как фундамент.** Если **D ≤ 2**, то баллы **+A** и **C5** ограничиваются сверху значением **D + 1** (агенты и дашборды не бывают зрелее данных, на которых стоят). Это не штраф, а защита от иллюзии: красивый бот на хаосе данных = уровень данных.
6. **Стадия организации = минимум по контурам**, не среднее. Система не сильнее слабого звена в потоке.

---

### Как интерпретировать профиль

**Узкое место = контур с самым низким баллом.** Это не «куда хочется», а **что тормозит весь поток** — начинаем внедрение отсюда. Если минимумов несколько с равным баллом — идём по каноническому порядку построения: **C1 → C2 → C3 → D → +A → C4 → C5**, правила Governance — сквозь все шаги (карта и процессы держат всё остальное; агенты и дашборд — надстройка). Это правило отвечает на вопрос «с какого контура начать»; сам порядок построения от него не меняется.

**Типовые профили и что делать:**

| Что видим в профиле | Диагноз | Первый ход |
|---|---|---|
| **+A высокий (3–4), D низкий (1–2)** | «Боты на болоте» — агенты есть, данных под ними нет. Самый частый провал (95% MIT / 80% RAND — пилоты не дают эффекта именно отсюда). | Заморозить наращивание агентов. Строить D: event log + state store по одному потоку. |
| **Всё 2, ровно** | Зоопарк по всем фронтам. Не размазывать. | Выбрать **один поток** (где больше денег/боли) и поднять его C1→C2→D до 4, остальное не трогать. |
| **C3/Governance низкие, процессы выше** | Процессы есть, но всё держится на собственнике (роль=человек, нет RACI/стюардов). | Развести роль и человека, назначить стюардов контуров — иначе масштаб упрётся в собственника. |
| **C5 высокий, C2/D низкие** | Красивый дашборд на негодных данных — «приборка не подключена к двигателю». | Не верить цифрам. Сначала event log (D) и метрику плана/факта (C2), потом дашборд. |
| **Всё ≥ 4, кроме одного контура** | Почти готовая система с одной дырой. | Точечно закрыть дыру до 4 — и только потом думать про скачок к 5 (AI-native). |

**Главный вывод для собственника (формулировка на встрече):**
> «Ваша система работает на уровне **самого слабого контура — это [X], балл [N]**. Разрыв до рабочего состояния (стадии 4) — **[4−N] ступени**. Любые инвестиции в [сильный контур] не дадут отдачи, пока [X] на [N]. Первый шаг — поднять [X], не трогая остальное. Целевой скачок 3→4 (единый связанный контур), потом — 4→5 (агенты собирают фоном, вы надзираете).»

**Что не делать (типовые ошибки внедренца на этой встрече):**

- Не оценивать «по намерениям» — только по тому, что **показали**.
- Не тянуть самый интересный/модный контур (обычно +A) — тянуть **самый слабый**.
- Не гнаться за 5 там, где нет 4: **AI-native без Контура = зоопарк с ботами**.
- Не размазывать ресурс по всем контурам сразу — **один поток до 4**, затем следующий.

---

## Приложение D · Матрица приоритизации

> **Зачем это приложение.** У внедренца на старте — список из 20–40 процессов и соблазн начать с того, что «болит у собственника прямо сейчас» или «технически красиво». Оба критерия ведут в 95% провалов пилотов (MIT) — потому что игнорируют риск необратимости и реальный объём. Это приложение даёт **детерминированный decision-tool**: посчитал три числа — получил порядок очереди. Расчёт вне LLM (принцип «детерминизм»), скоринг повторяемый, спор с собственником закрывается цифрой, а не вкусом.

---

### D.1 · Правило в одной строке

**Первым агентизируй то, что делается ЧАСТО, ошибку легко ОТКАТИТЬ, и оно реально БОЛИТ. Необратимое и денежное — в конец очереди и только под human-in-the-loop.**

Формально: ранжируем процессы по `PRIORITY`, где высокая частота и высокая боль тянут вверх, а низкая обратимость (высокий риск) тянет вниз.

---

### D.2 · Три оси скоринга

Каждый процесс оценивается по трём осям, шкала **1–5** (целые числа, никаких «3,5» — это убивает повторяемость).

#### Ось 1 — ОБЪЁМ / ЧАСТОТА (`V`) — «сколько раз в неделю это происходит»
Сколько повторяющейся ручной работы агент снимет. Чем чаще — тем выше отдача от автоматизации.

| Балл | Частота |
|---|---|
| 1 | реже раза в месяц |
| 2 | пару раз в месяц |
| 3 | несколько раз в неделю |
| 4 | ежедневно, единицы раз |
| 5 | ежедневно, десятки+ раз / непрерывный поток |

#### Ось 2 — ОБРАТИМОСТЬ (`R`) — «легко ли откатить ошибку агента»
**Это инверсия риска.** Высокий балл = ошибку видно и откатить дёшево (черновик, внутренняя заметка). Низкий балл = ошибка уходит наружу/в деньги/в юридику и стоит дорого.

| Балл | Обратимость / цена ошибки |
|---|---|
| 5 | полностью обратимо: артефакт внутренний, до отправки человеку (черновик, тег, саммари) |
| 4 | обратимо с лёгкой правкой; наружу не уходит без гейта |
| 3 | частично: затронут внешний контакт, но без денег и обязательств |
| 2 | трудно откатить: уходит клиенту/в публичный канал, репутационный след |
| 1 | необратимо: платёж, договор, юр-обязательство, удаление данных, отгрузка |

#### Ось 3 — БОЛЬ (`P`) — «как сильно это жрёт людей и тормозит бизнес сейчас»
Узкое место, ручная рутина, источник просрочек/ошибок, то, что собственник называет первым.

| Балл | Боль |
|---|---|
| 1 | мелкое неудобство, никто не жалуется |
| 2 | раздражает, но терпимо |
| 3 | регулярно отъедает время, заметно |
| 4 | узкое место: тормозит другие процессы, ошибки, просрочки |
| 5 | острая боль: теряем деньги/клиентов, собственник называет это первым |

---

### D.3 · Формула

```
PRIORITY = (V × wᵥ) + (P × wₚ) + (R × wᵣ)
```

**Веса по умолчанию (SMB без ERP, цель — быстрая победа с низким риском):**

| Ось | Вес | Почему такой |
|---|---|---|
| ОБЪЁМ `V` | **wᵥ = 3** | объём = главный множитель отдачи; «дробление=качество AI» работает на потоке |
| БОЛЬ `P` | **wₚ = 2** | боль обеспечивает адопшн и спонсора, но без объёма даёт разовый эффект |
| ОБРАТИМОСТЬ `R` | **wᵣ = 2** | риск — фильтр-предохранитель: тянет необратимое вниз, не глуша всё подряд |

Диапазон: **min 7 — max 35**. Чем выше — тем раньше в очереди.

> **Подстройка весов под аппетит к риску.** Консервативный собственник / зарегулированная ниша → `wᵣ = 3` (риск важнее боли, необратимое падает ещё ниже). Агрессивный, «нужен эффект вчера» → `wₚ = 3`. **Веса фиксируются ОДИН раз на весь портфель** до начала скоринга — иначе теряется сопоставимость и появляется соблазн «подкрутить под любимый процесс».

---

### D.4 · Жёсткие правила-предохранители (поверх балла)

Считаются ДО рейтинга и переопределяют его:

1. **`R = 1` → НИКОГДА не первый кандидат, какой бы ни был `PRIORITY`.** Платёж, отгрузка, подпись договора, удаление — только режим **цифрового сотрудника под human-in-the-loop с гейтом** (агент готовит → человек подтверждает). Сначала агентизируется *подготовка* (reversible-часть: собрать, проверить, заполнить черновик платёжки), а сам необратимый акт остаётся за гейтом.
2. **Деньги наружу = гейт по умолчанию.** Любой автономный перевод средств запрещён на стадиях зрелости 1–4. На стадии 5 он возможен только в жёстком лимите — см. «Платежи на стадии 5» в контуре +A.
3. **`V ≤ 2` при любом `P` → не цифровой сотрудник, а максимум AI-помощник.** Строить коннекторы и расписание под процесс, который случается дважды в месяц, — перерасход; человек дёргает помощника руками.
4. **Узкий агент.** Если процесс набрал высокий балл за счёт того, что «большой и делает 5 вещей» — сначала режем его на под-процессы (по handoffs из C2) и скорим каждый отдельно. Скорим атомарные шаги, не «отделы».
5. **Старт = пилот.** Первый кандидат сначала идёт **в режиме collector/drafter** (фоновый сбор / черновик, `R=5`), даже если по карте он мог бы быть router. Автономия повышается health-check'ами, а не сразу.

---

### D.5 · Пример: скоринг портфеля (6 процессов SMB)

Веса: `V×3 + P×2 + R×2`.

| # | Процесс | Архетип | V | P | R | PRIORITY | Очередь | Стартовый режим |
|---|---|---|:--:|:--:|:--:|:--:|:--:|---|
| 1 | Квалификация входящих лидов (тег, скоринг, маршрут) | qualifier/router | 5 | 5 | 5 | **35** | **1** | digital-employee, фон |
| 2 | Сбор статусов заказов из почты/чатов в Event Log | collector | 5 | 4 | 5 | **33** | **2** | digital-employee, фон |
| 3 | Черновики ответов клиентам по типовым вопросам | drafter | 4 | 4 | 4 | **28** | **3** | assistant + гейт |
| 4 | Сверка «оплачено vs отгружено» (reconciler) | reconciler | 3 | 5 | 3 | **25** | **4** | assistant, human reviews |
| 5 | Еженедельный дайджест по проектам собственнику | collector/drafter | 2 | 4 | 5 | **24** | **5** | assistant, фон |
| 6 | Проведение платежей поставщикам | — | 4 | 3 | **1** | 20 | **последний** | HITL-гейт: агент готовит платёжку, человек жмёт «оплатить» |

**Как читать таблицу:**

- **№1 — образцовый первый кандидат:** high-volume (5) + reversible (5) + high-pain (5) = 35. Снимает рутину каждый день, ошибка = неверный тег (откатывается мгновенно), и это первое, что назвал собственник.
- **№6 имеет неплохой `PRIORITY=20`, но `R=1` сработал предохранителем** (правило D.4.1) → выброшен в конец и переведён в HITL, несмотря на то что по голому баллу обгоняет №5. Агентизируем не «платёж», а *подготовку платежа*; кнопку жмёт человек.
- **№4 и №5 близки по баллу** (25 vs 24), но решает разное: №4 берём раньше из-за боли (P=5, узкое место денежного контура), хотя у него средняя обратимость; №5 — приятный, безопасный, но редкий (V=2), поэтому ниже.

**Порядок внедрения:** строго сверху вниз по «Очереди», по одному. Следующий процесс берём только когда предыдущий прошёл health-check и не даёт silent failures.

---

### D.6 · Критерий «1 мозг или 3» — сколько систем разворачивать

Параллельно с очередью внедренец решает **архитектурный вопрос: один общий контур на всё или несколько суверенных узлов.** Режем **по реальным швам бизнеса из карты C1**, не по оргструктуре и не по вкусу.

**Шов есть (→ отдельный узел), если между двумя зонами ответ «нет» хотя бы на ДВА вопроса из четырёх:**

- **единица работы (онтология / `case_id`)** — можно ли вести работу обеих зон как один вид дела с одним набором статусов? Заявка и заказ — да: это стадии одного дела. Заказ товара и производственная партия — нет: разные статусы, сроки и результат. Разный вид дела = разный State Store = разный мозг.
- **данные и SSOT** — можно ли писать события обеих зон в один Event Log без перевода полей и без потери смысла?
- **клиент и P&L** — один ли это рынок и один ли учёт результата (общая прибыль, один ответственный за неё)? Частично общие клиенты сами по себе шва не создают.
- **регламенты / AOP** — проходит ли дело через обе зоны одной цепочкой шагов (handoff внутри процесса)? Если у каждой зоны своя цепочка со своим входом и своим результатом для клиента — ответ «нет».

| Ситуация | Швов между зонами | Решение | Почему |
|---|---|---|---|
| Общий бэк-офис (один поток заявок, одна касса, одни клиенты, один case_id) | нет / 0–1 | **1 мозг** | один Event Log + один State Store; агенты переиспользуются; дробить = плодить интеграции на пустом месте |
| Разные бизнесы / юрлица / рынки под одним собственником (напр. 3 направления со своими клиентами и P&L) | 2+ по каждой паре | **3 мозга** (по узлу на бизнес) | разные онтологии и SSOT нельзя слить честно; **федерация суверенных узлов** под общей конституцией |
| Один бизнес, но автономные функции (продажи / производство / финансы) с общим клиентом и case_id | 0–1 | **1 мозг, несколько агентов-узкоспецов** | шва нет — это handoffs внутри одного контура (C2), а не граница систем |
| Два направления с частично общими клиентами, но разной единицей работы и своими цепочками шагов (напр. оптовая торговля и производство под заказ) | 2+ | **по мозгу на направление + общий справочник клиентов** | у каждого свой Event Log и State Store; клиент — одна запись на оба узла |

**Decision-rule (применять к каждой ПАРЕ зон):**

```
По каждой ПАРЕ зон отвечаем на 4 вопроса (единица работы, данные, клиент+P&L, регламенты).
  0–1 ответ «нет»  → ОДИН мозг (общий контур, агенты переиспользуются, шов = handoff внутри C2)
  2+ ответа «нет»  → РАЗНЫЕ мозги (суверенные узлы, федерация под одной конституцией)
```

**Что остаётся общим у нескольких мозгов.** У каждого узла свой источник правды — свой Event Log и свой State Store; сливать их нельзя. Общими остаются три вещи: **конституция**, **экран собственника** (собирается из метрик узлов) и **справочник клиентов** — один `client_id` на клиента во всех узлах, чтобы клиент, который покупает в одном направлении и заказывает в другом, был одной записью. У справочника свой владелец (data-steward) и свой Data Contract.

> **Антипаттерн А — переслияние:** один гигантский «корпоративный мозг» поверх трёх разных бизнесов. Получаешь конфликт онтологий, грязный Event Log, агента, который не знает, что такое `case_id`, — и тихие сбои.
> **Антипаттерн Б — передробление:** отдельный узел на каждый отдел внутри одного бизнеса. Получаешь интеграционный ад и дубли там, где хватило бы handoff. **При сомнении — начинай с 1 мозга, дроби по факту боли** (снизу-вверх), а не авансом.

---

### D.7 · Чек-лист внедренца (пройти за один присест)

```
[ ] Зафиксировал веса (V/P/R) ОДИН раз на весь портфель — под аппетит к риску собственника
[ ] Разрезал «отделы» на атомарные процессы по handoffs из C2 (узкие агенты)
[ ] Проставил V, P, R (1–5) каждому процессу — цифрами, не на глаз
[ ] Посчитал PRIORITY = V×3 + P×2 + R×2
[ ] Применил предохранители D.4: R=1 → конец очереди + HITL; деньги → гейт; V≤2 → только помощник
[ ] Отсортировал по очереди; первый кандидат стартует как collector/drafter (R=5), не сразу router
[ ] По карте C1 применил «1 мозг или 3»: посчитал швы по 4 критериям на каждую пару зон
[ ] Внедряю строго по одному; следующий — только после health-check предыдущего
```

**Итог:** три числа на процесс + правило швов на портфель = повторяемый, защищаемый перед собственником порядок очереди. Объём даёт отдачу, боль даёт спонсора и адопшн, обратимость держит риск — а необратимое и денежное никогда не оказывается первым.

---
---

> Отметка для ИИ: если ты получил файл по ссылке и текст ниже оборвётся — для задачи из «Инструкции
> для ИИ-ассистента» прочитанного уже достаточно (Части 1 и 2). Дальше идёт глубокий материал
> для внедренца; он нужен, когда владелец просит подробно разобрать отдельный контур.

# ЧАСТЬ 3 · Полная методика (для внедренца): контуры, Governance, приложения A, B, E, F, G, I, J

Приложения H, C и D стоят выше, в Части 2.

# AI-ориентированная организация

### Люди + агенты как единая управляемая структура · глубокий разбор

## 📖 Как читать этот документ

Это **источник-правды** для систематизации компании под AI: не верхушка, а уровень внедрения. Документ устроен как набор **контуров C1–C5 + надстройки A (Агенты), слоя D (Данные) и сквозных правил и контроля (Governance)** — каждый раскрывает один слой управляемости от карты бизнеса до дашборда собственника. Разделы идут по слоям архитектуры, а не в порядке работ: порядок построения один и задан в «Генераторе внедрения». Каждый раздел написан по **единому шаблону**: Что это · Сущности (именованные объекты) · Механика · Кто делает · Зачем/что ломается без · По этапам зрелости · Как внедряется (SMB без ERP) · Антипаттерны · Связи. Читать сверху вниз (хребет строится снизу) либо точечно — по нужному контуру через Связи.

## 🏷️ Название и позиция

- **Ядро (что это технически):** «AI-система управляемости» / **System of Control** — слой, который делает компанию управляемой через единый цифровой след людей и агентов.
- **Витрина (как звучит собственнику):** **«Командный центр собственника»** (Owner Cockpit) — поверхность, на которой собственник *приоритизирует, мониторит, симулирует*.
- **Позиция в одном предложении:** это **system-first, а не AI-first** — сначала выстраивается управляемость (процессы, роли, регламенты, данные, контроль), и только поверх неё садится AI как усилитель; именно этот порядок — антидот к 95% (MIT) / 80% (RAND) провалов пилотов.

## 🧭 Схема контуров

*Кликни по картинке — откроется интерактивная схема. Горизонтальный вариант для слайда/печати: landscape.*

Хребет читается **снизу вверх**: C1 Карта → C2 Процессы → C3 Люди → C4 Регламенты → C5 Контроль → **Управляемость** (это слои схемы, а не очередь работ: порядок построения один и задан в «Генераторе внедрения»). **+A Агенты** — надстройка над слоем людей (помощник), а на верхних стадиях — и узел-сотрудник рядом с ними (цифровой сотрудник). Слева направо разнесены **слой действий** (люди работают как привыкли) и **слой данных** (агенты собирают след фоном) — они сходятся в **D · SSOT**. **Обратная петля контроля**: «горит» в C5 возвращается правкой в C2/C4. **Governance** прошивает все контуры. **Ось зрелости** — сбоку, целевой скачок **3→4**.

## 🪜 Лестница зрелости

| Стадия | Что характеризует | Где AI | Целевой скачок |
|---|---|---|---|
| **1 · Awareness (Осознание)** | Всё руками; структура и правила в головах; AI отрицают/осознают. Карты, ролей, следа нет. | Нет / точечное любопытство | |
| **2 · Active (Ad hoc)** | ChatGPT точечно, ad hoc; нет своих систем, реестров, владельцев; результат не оседает. | Внешний чат, ручной копипаст | |
| **3 · Operational «зоопарк»** | Свои боты есть, но вразнобой: дубли, рассинхрон, у каждого свой «клиент» и своё хранилище; риск ключевого лица (bus-factor); silent failures незаметны. | Разрозненные узкие боты без реестра | ━━ старт скачка ━━ |
| **4 · Systemic «контур»** | Единая карта+онтология, реестры ролей/процессов/агентов, **единый SSOT (в пределах узла)**, governed-KPI, **дашборд**, федеративная конституция, drift-детекция. | Стандартизованные агенты в едином контуре | **◀▶ ЦЕЛЕВОЙ СКАЧОК 3→4** (макс. ценность по MIT) |
| **5 · Transformational (AI-native)** | Управляемость как система; AI-native операционка; контуры самоподдерживаются, роли двигаются вверх по value stack; симуляция «что-если». | AI штатная прослойка действие↔данные | |

## 🗺️ C1 · Карта бизнеса (фундамент)

#### Что это

C1 — это контур, который отвечает на единственный вопрос, без ответа на который любой AI-слой галлюцинирует: «что вообще представляет собой этот бизнес как объект, который мы собираемся оцифровывать?». Это L0 zoo-фреймворка (слои zoo-фреймворка L0–L5 — не путать со ступенями самостоятельности агента L0–L3) — карта, которую все вышестоящие контуры (процессы, люди, агенты, данные, контроль) обязаны буквально повторить своей структурой. C1 фиксирует продукт, ценностные потоки, узлы (отделы/функции) и их владельцев, границы бизнеса и — главное — единую **онтологию/идентичность** (что в этой компании считается «клиентом», «сделкой», «объектом»). Без согласованной онтологии два бота, два сотрудника и три таблицы под словом «клиент» понимают три разные вещи, и SSOT (контур D) собирается из взаимно несводимых фактов.

Роль C1 — быть «РАГ для сознания» собственника и для всех агентов: статической, человекосозданной точкой опоры, относительно которой считываются все остальные слои. Это не «стратегия» и не «миссия» — это инженерный скелет-модель бизнеса на одну страницу, по которому видно, из каких частей он состоит, кто за каждую отвечает и где проходит его контур. По грунту Дмитрия это business map по Рыбакову (Продукт → проекты/процессы → люди → управление → инструменты) и «база знаний клиента как фундамент». По индустрии это пересечение Ontology/Identity-компонента Context Layer (Atlan) и языка Digital Twin of Organization (Gartner) — карты, на которой собственник «приоритизирует, мониторит, симулирует».

#### Сущности

Конкретные артефакты, которые создаются и существуют в C1:

1. **Business Map (одностраничная карта)** — единственный обязательный артефакт контура. Формат: один файл `00-MAP.md` (или одна страница Notion/один лист Miro). Структура жёстко по слоям Рыбакова: `Продукт → Проекты/Процессы → Люди → Управление → Инструменты`. Это скелет-модель бизнеса: схема, которую остальные контуры наполняют. Пример строки слоя «Люди»: `Узел: Продажи · Владелец: Ирина (РОП) · Вход: лид · Выход: оплаченная сделка`.

2. **Карточка продукта (Product Definition)** — что компания продаёт и за какой результат клиент платит. Поля: `название · обещанный результат (jobs-to-be-done) · единица продажи · за что именно идёт оплата · что НЕ входит`. Это якорь: ценностные потоки и определение «сделки» выводятся отсюда, а не наоборот.

3. **Реестр ценностных потоков (Value Streams)** — список сквозных потоков «от триггера до ценности у клиента». Формат строки: `Поток · стартовый триггер · конечная ценность · какие узлы пересекает`. Пример: `Поток «Производство тиража» · триггер: подтверждённый макет · ценность: отгруженный тираж · узлы: продажи→препресс→печать→логистика`. Это мост к C2 (процессы) — поток разворачивается в процессы.

4. **Реестр узлов и владельцев (Nodes & Owners)** — отделы/функции как «узлы федерации». Поля: `узел · функция (зачем существует) · владелец (1 имя) · вход · выход · граничит с (узлы)`. Принцип федеративной конституции: каждый узел суверенен (свой `00-CONTEXT` как локальная база), но подчинён общим стандартам карты. Один владелец на узел — обязателен (антидот риску ключевого лица).

5. **Онтология / Глоссарий идентичности (Ontology · `04-glossary.md`)** — ядро контура и его самая недооценённая сущность. Это таблица единых определений ключевых сущностей бизнеса. Поля: `Термин · Определение (что СЧИТАЕТСЯ этим) · Когда возникает · Когда закрывается/исчезает · Уникальный ключ (как опознаём дубль) · Чем НЕ является`. Пример: `Клиент = юрлицо, по которому есть ≥1 оплаченная сделка; ключ — ЕДРПОУ/ИНН; НЕ клиент — лид без оплаты`. Без этого `case_id` в будущем event-логе (контур D) собирать не из чего.

6. **Границы бизнеса (Boundaries)** — явный список того, что внутри контура и что снаружи: `что делаем сами · что отдано подрядчику · где кончается наша ответственность · смежные юрлица/каналы`. Закрывает зону, где обычно течёт «теневая работа» вне всякого учёта.

7. **Карта инструментов (Tooling Inventory)** — где сейчас физически живут данные каждого узла: `узел · инструмент (Excel/CRM/чат/голова) · кто ведёт · формат`. Это вход для контура D: показывает, из каких источников агентам предстоит порождать след с нуля (для SMB без ERP — критично).

#### Механика (что происходит)

Поток работы через контур, по шагам:

1. **Сбор сырья.** Собственник + аналитик проходят бизнес сверху вниз по слоям Рыбакова: что продаём → какими потоками это создаётся → какие узлы участвуют → кто владелец каждого → чем меряют → где данные. Источник — интервью, не догадки.
2. **Определение продукта.** Заполняется карточка продукта. От «за что платит клиент» отстраивается всё остальное (иначе ценностные потоки описывают активность, а не ценность).
3. **Прорисовка ценностных потоков.** Каждый поток фиксируется как линия «триггер → ценность» с перечнем узлов. Потоки — горизонтальны, узлы — вертикальны; их пересечение даёт матрицу ответственности.
4. **Кристаллизация онтологии.** Самый дорогой шаг: команда договаривается, что считается клиентом/сделкой/объектом, и фиксирует ключи идентичности. Здесь вылавливаются конфликты («у продаж клиент = контакт, у бухгалтерии = юрлицо»). Расхождение не замазывается — выносится в обсуждение и разрешается одним определением.
5. **Назначение владельцев и границ.** Каждому узлу — один владелец; явно отрезается внешнее (подрядчики, смежные юрлица).
6. **Сборка карты.** Всё сводится в один артефакт `00-MAP.md`. Критерий готовности: новый человек (или новый агент) по карте за 15 минут понимает, из чего состоит бизнес и кто за что отвечает.
7. **Замок на верхние контуры.** Карта становится обязательным шаблоном: C2 повторяет потоки→процессы, C3 повторяет узлы→роли, D строит SSOT по онтологии C1. Любой вышестоящий контур, не сводимый к карте, — сигнал, что карта неполна, и его правят, обновляя C1.

Что во что превращается: интервью → карточка продукта → потоки → узлы+владельцы → **онтология (ядро)** → одностраничная карта → шаблон-инвариант для всех контуров.

#### Кто делает

- **Определение продукта и границ бизнеса** — **СОБСТВЕННИК** (это его картина мира; делегировать нельзя, можно только записать с его слов).
- **Кристаллизация онтологии/идентичности** — **СОБСТВЕННИК утверждает**, **ЧЕЛОВЕК-аналитик** фасилитирует и сводит конфликты определений. Это решение уровня владельца, потому что от него зависит, как считается весь бизнес.
- **Прорисовка ценностных потоков и реестра узлов** — **ЧЕЛОВЕК-аналитик** (внешний консультант или внутренний COO) на интервью с владельцами узлов.
- **Назначение владельца узла** — **СОБСТВЕННИК** (только он может закрепить ответственность).
- **Сборка и оформление карты в `00-MAP.md`, ведение глоссария, проверка консистентности терминов** — **AI-АГЕНТ** (структурирует сырьё интервью в шаблон, ловит синонимы и дубли определений, предлагает уникальные ключи; человек создаёт истину, агент усиливает).
- **Поддержание карты в актуальном состоянии** (диффы при изменении структуры) — **AI-АГЕНТ** предлагает, **ЧЕЛОВЕК-владелец карты** утверждает.

Принцип сквозной: истину создаёт человек (особенно собственник для онтологии), AI — усилитель и оформитель, расчёт и определения не выдумывает.

#### Зачем / что ломается без него

C1 — фундамент, потому что это единственный контур, задающий *систему координат*. Без него:

- **Онтологический хаос.** Под «клиентом» каждый узел понимает своё → SSOT (D) собирается из несводимых фактов → дашборд собственнику (C5) показывает суммы, которые ничего не значат («у нас 200 клиентов» — это контакты, оплаты или юрлица?).
- **Агенты галлюцинируют структуру.** Бот без карты не знает, к какому узлу относится задача и что считать сделкой — порождает мусорный след, который потом нельзя свести.
- **Риск ключевого лица.** Нет реестра узлов и владельцев → знание «как тут всё устроено» живёт в голове одного человека; уходит он — карта теряется.
- **Scope creep сверху.** Без границ агенты и процессы расползаются на смежные юрлица и теневую работу, и никто не знает, где кончается бизнес.
- **AI-first вместо system-first.** Без карты компания строит ботов на несуществующем фундаменте — отсюда 95% (MIT) / 80% (RAND) провалов пилотов. C1 — это и есть «сначала система, AI поверх».

#### По этапам зрелости

- **1 Awareness.** Карты нет вообще. Структура бизнеса — в голове собственника; «клиент» и «сделка» каждый понимает по-своему. На вопрос «из чего состоит бизнес» собственник отвечает разными словами в разные дни.
- **2 Active.** Карты как артефакта нет, но собственник от руки/в ChatGPT набрасывает структуру ad hoc под конкретную задачу. Определения возникают разово и не сохраняются; узлы и владельцы нигде не закреплены.
- **3 Operational («зоопарк»).** Появились куски карты, но разрозненно: оргсхема в одном файле, прайс — в другом, у каждого бота своё представление о «клиенте». Дубли определений, противоречия между источниками. Нет одного `00-MAP.md` и единой онтологии — самый дорогой провал, потому что данные уже копятся, но несводимы.
- **4 Systemic («контур»).** Есть единая одностраничная карта `00-MAP.md`, единая онтология с ключами идентичности, реестр узлов с одним владельцем на каждый. Карта — обязательный инвариант: процессы, люди, SSOT и дашборд повторяют её. Узлы суверенны, но подчинены общим определениям (федеративная конституция).
- **5 Transformational.** Карта живёт как живая модель бизнеса: агенты читают её как контекст в runtime, изменение структуры бизнеса автоматически отражается в карте (агент предлагает дифф), собственник по ней «приоритизирует, мониторит, симулирует». Онтология — исполняемый контракт для всех агентов, а не документ.

#### Как внедряется (для SMB без ERP)

1. **Интервью с собственником (60–90 мин).** Пройти 5 слоёв Рыбакова вслух. Записать дословно — это сырьё.
2. **Карточка продукта.** Один экран: результат, единица продажи, за что платят, что не входит. Согласовать с собственником.
3. **Реестр узлов.** Выписать все отделы/функции, на каждый — один владелец, вход, выход, соседи. Незакрытые («владельца нет») пометить красным — это будущие проблемы C3.
4. **Реестр ценностных потоков.** 3–7 главных потоков «триггер → ценность → узлы». Больше 7 для SMB — признак переусложнения.
5. **Сессия онтологии (отдельная, самая важная).** Собрать владельцев узлов, на каждый ключевой термин (клиент, сделка, объект, лид) выработать ОДНО определение + уникальный ключ + «чем не является». Зафиксировать в `04-glossary.md`. Конфликты разрешает собственник.
6. **Границы.** Один список: своё / подрядчик / смежные юрлица / где кончается ответственность.
7. **Карта инструментов.** На каждый узел — где сейчас данные (Excel/чат/голова). Это вход для контура D.
8. **Сборка `00-MAP.md`.** Агент сводит всё в одну страницу по шаблону карты. Тест готовности: новичок за 15 мин понимает бизнес.
9. **Замок-инвариант.** Объявить карту обязательным шаблоном: ни один процесс/бот/таблица не заводится, если не привязан к узлу и не использует онтологию C1.

Артефакты на выходе: `00-MAP.md`, карточка продукта, `04-glossary.md` (онтология), реестры узлов/потоков/инструментов, список границ. Всё — текстовые файлы/одна страница, без ERP.

#### Антипаттерны / грабли

1. **«Нарисовали оргсхему — считаем, что есть карта».** Оргсхема — это иерархия людей, а не карта потоков, узлов и онтологии. По Минцбергу: организация — сообщество, а не оргсхема; карта без ценностных потоков и определений мертва.
2. **Пропустить онтологию («и так все знают, кто такой клиент»).** Самая дорогая ошибка: расхождение всплывёт на контуре D, когда несводимый след уже накопится. Онтология — не бюрократия, это `case_id` будущего event-лога.
3. **Несколько владельцев (или ноль) на узел.** «Отвечают все» = не отвечает никто; риск ключевого лица и пинг-понг. Ровно один владелец, всегда.
4. **Карта-простыня вместо одной страницы.** Если карта не помещается на экран и её не читают за 15 минут — это не L0, это документация. Длинно = мёртво.
5. **Описывать «как хотим», а не «как есть».** Карта — слепок реальности (грунт для process mining: «регламент vs факт»). Идеализированная карта расходится с тем, что породят агенты, и обесценивает SSOT. Сначала «как есть», улучшение — позже.

#### 🔍 Было → стало (на примере)

> _«Светлый Дом» — мебель на заказ (кухни, шкафы), ~12 человек, без ERP._

**Было (3 · «зоопарк»).** Структура — в голове владельца. «Клиент» у продаж = оставивший заявку, у цеха = тот, чью кухню пилят, у бухгалтерии = внёсший предоплату. Один человек — три записи в трёх таблицах, отчёты не сходятся.

**Стало (4 · «контур»).** Одна страница `00-MAP.md` + единая онтология: узел = строка с одним владельцем, «клиент» определён один раз.

**Пример записи (строка карты + строка онтологии):**

```
КАРТА → Узел: Продажи · Владелец: Ирина (РОП) · Вход: лид · Выход: договор+предоплата
ОНТОЛОГИЯ → Клиент = физлицо с подписанным договором и предоплатой ≥30%;
            ключ = телефон+e-mail; «замер без договора» = ЛИД, не клиент;
            возникает при подписании, закрывается при подписании акта монтажа
```

_Полный сквозной разбор перехода 3→4 на другой компании (автосервис) — Приложение B._

#### Связи

- **→ C2 Процессы (выход).** Ценностные потоки C1 разворачиваются в процессы; C2 обязан повторить потоки карты. Вход для C2 — реестр Value Streams.
- **→ C3 Люди (выход).** Реестр узлов и владельцев C1 — это скелет ролей и ответственности C3. Узел = будущая роль/`00-CONTEXT` суверенного узла.
- **→ +A Агенты (выход).** Карта — контекст («РАГ для сознания») для каждого агента: к какому узлу он привязан, что считать сделкой. Без C1 у агента нет границ scope (отсюда scope creep).
- **→ D Данные/SSOT (выход, критичный).** Онтология C1 задаёт схему SSOT и ключи идентичности (`case_id`, уникальные ключи дублей). Карта инструментов C1 — список источников, из которых агенты порождают след. SSOT собирается строго по определениям C1.
- **→ C5 Контроль/Дашборд (выход).** Узлы карты — это разрезы дашборда; продукт и потоки задают, какие метрики вообще имеют смысл. KPI считаются на сущностях, определённых в онтологии C1.
- **← Governance (вход/сквозное).** Федеративная конституция опирается на C1: узлы суверенны (своя локальная база), но обязаны общим определениям и шаблону карты. Governance = runtime-enforcement инварианта «всё привязано к карте».
- **← Обратная связь от всех контуров.** Если любой контур не сводится к карте — это сигнал неполноты C1; карта правится. C1 — единственный контур, который остальные обязаны буквально повторить.

---

## ⚙️ C2 · Процессы

#### Что это

Контур C2 — это слой ДЕЙСТВИЙ организации, разложенный на повторяемые единицы работы: процессы. Если C1 (Карта бизнеса) отвечает на вопрос «из чего состоит компания и как создаётся ценность» статически, то C2 описывает динамику — как ценность реально течёт от триггера к результату руками людей и агентов. В хребте Дмитрия это первый слой («ПРОЦЕССЫ → дела»): пока он не разложен, всё, что выше (люди, регламенты, контроль, агенты, данные), повисает в воздухе — нельзя назначить роль на несуществующий шаг, нельзя написать регламент к неописанной работе, нельзя посадить агента собирать след там, где не определено, какое действие он сопровождает.

Роль контура двойная. Во-первых, это **операционная карта**: инвентаризация того, как работа происходит «как есть» (as-is) ДО любой автоматизации — без неё AI-first превращается в автоматизацию хаоса. Во-вторых, это **скелет цифрового следа**: каждый шаг процесса — это место, где агент потом фоном соберёт данные (см. слой D), а собственник на дашборде (C5) увидит, где работа стоит. В SMB без ERP это особенно важно: процессов формально нет нигде, кроме голов людей, и контур C2 — первое, что превращает «ремесло» в «систему» (Craft2Scale).

#### Сущности

Конкретные объекты, которые создаются и живут в этом контуре:

1. **Карточка процесса (Process Card)** — атомарная единица контура. Формат — markdown-файл или строка в реестре с полями: `id` (формат P-NN: P-01), `название` (глагол + объект: «Обработать входящую заявку»), `триггер` (что запускает: «лид написал в Instagram Direct»), `шаги` (нумерованный список 5–15 действий), `результат/выход` (что на выходе: «заявка квалифицирована, в CRM, назначен менеджер»), `владелец процесса`, `участники-роли`, `частота` (N раз/день), `точки handoff`, `статус` (as-is / to-be / автоматизирован). Пример: P-003 «Выставить счёт» — триггер «менеджер закрыл сделку» → 6 шагов → выход «счёт отправлен клиенту, занесён в учёт».

2. **SIPOC-таблица** — паспорт процесса на одной странице: `Supplier` (кто даёт вход) | `Input` (что на входе) | `Process` (5–7 макрошагов) | `Output` (что на выходе) | `Customer` (кто получает результат). Заполняется ПЕРЕД детализацией шагов — это рамка, не дающая процессу «расползтись». Пример для найма: Supplier=рекрутер → Input=отклик кандидата → Process=скрининг→интервью→оффер → Output=вышедший сотрудник → Customer=руководитель отдела.

3. **Карта потока ценности (Value Stream)** — последовательность процессов, через которые проходит ОДИН тип ценности от запроса клиента до денег/результата. Не отдельный процесс, а цепочка карточек: «Лид → Квалификация → КП → Договор → Производство → Отгрузка → Оплата». Формат — горизонтальная диаграмма со временем на каждом шаге и временем ожидания МЕЖДУ шагами (где копится потеря).

4. **Реестр процессов (Process Registry)** — единая таблица всех карточек: `id`, `название`, `владелец`, `value stream`, `зрелость`, `автоматизация`, `критичность для выручки`. Это оглавление контура; первый артефакт, который видит собственник.

5. **Карта handoffs (точки передачи ответственности)** — отдельный список мест, где работа переходит от одного исполнителя/роли/системы к другому. Каждый handoff — поле: `от_кого → кому`, `что передаётся`, `канал`, `риск разрыва`. Это самые хрупкие точки (классика: «кандидат приехал на смену — а работы для него нет»: handoff между рекрутингом и планированием не сработал). Именно здесь процессы ломаются чаще всего, не внутри шагов.

6. **Различение процесс vs проект** — рабочая классификация (не один файл, а правило сортировки реестра): процесс = повторяемый, один и тот же триггер→результат много раз (его автоматизируют, регламентируют, сажают агента); проект = уникальный, разовый, с началом и концом (его не регламентируют, им управляют как набором задач). Путаница ломает весь контур: попытка «зарегламентировать» проект даёт мёртвый PDF, попытка «вести проектом» процесс даёт ручное переизобретение каждый раз.

7. **Event Log (журнал событий)** — таблица фактического исполнения, минимум 4 поля: `case_id` (id конкретного прохода — заявка №451), `activity` (выполненный шаг), `timestamp`, `actor` (кто). В SMB без ERP его не существует — и ключевая идея контура: агенты ПОРОЖДАЮТ его с нуля, фоново фиксируя каждый шаг по мере работы людей. Именно Event Log позволяет потом сравнить «регламент vs факт» (process mining).

#### Механика (что происходит)

Работа течёт через контур так:

1. **Инвентаризация as-is.** Берётся value stream (например, «от лида до оплаты»), и для каждого звена заводится карточка процесса в формате «как есть на самом деле» — со слов того, кто реально делает работу, а не как «должно быть». Сначала SIPOC (рамка), потом детализация шагов.
2. **Выявление handoffs.** По каждой карточке отмечаются точки передачи — где работа уходит из рук в руки. Они выписываются в отдельную карту: это будущие точки отказа и места, где данные теряются.
3. **Разметка процесс/проект.** Реестр сортируется: повторяемое идёт в кандидаты на регламент+агента (C4/+A), уникальное выводится в проектное управление.
4. **Наложение слоя данных.** Для каждого шага определяется, какой цифровой след он оставляет (или должен оставлять) → это спецификация для агента: «когда менеджер отвечает лиду — агент фиксирует событие в Event Log». Так СЛОЙ ДЕЙСТВИЙ (человек работает как привык) разносится со СЛОЕМ ДАННЫХ (агент собирает фоном).
5. **Сравнение факт vs регламент.** Когда Event Log накопился — фактический путь процесса (как реально идут case_id) сопоставляется с задуманным. Расхождение («регламент говорит 5 шагов, факт — 8, и два — петли переделок») — это вход для оптимизации.
6. **Итерация.** Узкое место/разорванный handoff/лишний цикл переделки → переписывается карточка (as-is → to-be) → меняется регламент (C4) → перенастраивается агент (+A). Контур живой, не одноразовый.

Превращения: разговор с сотрудником → карточка процесса; набор карточек → value stream; шаги карточки → спецификация следа → Event Log; Event Log + карточка → диагноз расхождения → новая версия процесса.

#### Кто делает

- **Инвентаризация процессов «как есть» (интервью исполнителей, черновик карточек)** — AI-АГЕНТ (process-interviewer) формулирует и структурирует, ЧЕЛОВЕК-исполнитель даёт фактуру («истину создаёт человек, AI — усилитель»).
- **Утверждение, что процесс описан верно** — ЧЕЛОВЕК-исполнитель/владелец процесса (только он знает реальность).
- **Назначение владельца процесса** — СОБСТВЕННИК (это управленческое решение, не делегируется агенту).
- **Разметка процесс vs проект, приоритизация по критичности для выручки** — СОБСТВЕННИК при поддержке агента-аналитика.
- **Ведение реестра процессов, поддержание актуальности карточек** — AI-АГЕНТ (фоново), ревизия — ЧЕЛОВЕК (владелец).
- **Порождение Event Log, фиксация шагов** — AI-АГЕНТ (полностью фоново, человек работает как привык).
- **Диагноз «факт ≠ регламент», предложение to-be** — AI-АГЕНТ готовит, ЧЕЛОВЕК/СОБСТВЕННИК решает (изменение процесса необратимо для людей → human-in-the-loop).

#### Зачем / что ломается без него

Без C2 организация не имеет языка, чтобы вообще говорить о работе системно. Конкретные провалы при отсутствии контура:

- **Автоматизация хаоса.** Сажают агента на процесс, которого никто не описал → агент «галлюцинирует к шагу 3», потому что шаги нигде не зафиксированы, и каждый исполнитель делает по-своему.
- **Риск ключевого лица.** Процесс живёт только в голове одного человека; он уходит в отпуск/увольняется — работа встаёт (типичная боль стадии «зоопарк»).
- **Разрыв на handoff.** Самый дорогой класс провалов: «кандидат приехал — работы нет», «сделка закрыта — счёт не выставлен», «заявка пришла — никто не взял». Внутри каждого участка всё работает, но на стыках теряется, и никто не владеет стыком.
- **Нет базы для остального хребта.** Нельзя написать регламент (C4) к неописанному процессу, нельзя посчитать KPI (C5) для несуществующих шагов, нельзя собрать данные (D) там, где не определено действие. C2 — фундамент, на котором стоят C4/C5/D.
- **Невозможность отличить «надо чинить процесс» от «надо лучше делать проект»** → регламентируют разовое, теряют время на переописание уникального.

#### По этапам зрелости

- **1 Awareness.** Процессов как сущности нет вообще. Работа = «как привыкли», передаётся изустно, существует только в головах. Никто не отличает процесс от проекта. Handoffs невидимы, разрывы списывают на «человеческий фактор».
- **2 Active.** Появляются разрозненные описания (кто-то набросал инструкцию в заметках, спросил ChatGPT «опиши процесс продаж»). Ad hoc, несвязно, без реестра и владельцев. Карточек нет — есть случайные тексты.
- **3 Operational («зоопарк»).** Некоторые процессы описаны и даже частично автоматизированы своими ботами, но разрозненно: дубли описаний, у одного процесса две версии, нет единого реестра, владельцы не назначены, Event Log если и есть — у каждого бота свой. Handoffs между «островами автоматизации» рвутся. Риск ключевого лица сохраняется на уровне «кто настроил бота».
- **4 Systemic («контур»).** Единый реестр процессов, у каждого — карточка по стандарту, назначен владелец, размечены value streams и handoffs. Агенты фоново порождают общий Event Log → можно сравнивать факт vs регламент. Процесс vs проект разведены. Это целевое состояние перехода 3→4.
- **5 Transformational.** Контур самоподдерживающийся: процессы непрерывно сверяются с фактом, агенты предлагают оптимизацию, новые процессы заводятся по шаблону с первого дня с уже встроенным следом. Управляемость процессов = система, а не разовая инвентаризация; AI-native операционка.

#### Как внедряется (для SMB без ERP)

1. **Выбрать ОДИН денежный value stream** — обычно «от лида до оплаты». Не описывать всю компанию сразу (узкий scope выживает, scope creep убивает).
2. **Разложить его на 5–9 макропроцессов** и завести реестр (одна таблица: id, название, владелец-кандидат, критичность).
3. **На каждый процесс — SIPOC на одну страницу**, затем карточку as-is со слов исполнителя (агент-интервьюер структурирует, человек подтверждает).
4. **Выписать handoffs** в отдельную карту — сразу видны самые хрупкие стыки, их чинить первыми.
5. **Назначить владельца каждого процесса** (решение собственника) — без владельца стык ничей.
6. **Развести процесс/проект** в реестре.
7. **Определить цифровой след каждого шага** → спецификация для агента, который начнёт порождать Event Log с нуля (в SMB без ERP это единственный способ получить факты). Встраивать сбор в канал, где люди УЖЕ работают (Instagram Direct, Telegram, таблица), а не плодить новый интерфейс (friction audit, integration > innovation).
8. Через 2–4 недели накопленного лога — **первая сверка факт vs регламент**, найти петли переделок и мёртвые шаги, переписать в to-be.

Минимальные артефакты на старт: реестр процессов (1 таблица), 5–9 карточек, карта handoffs, спецификация следа. ERP не нужен — карточки и реестр живут в markdown/таблице, Event Log порождают агенты.

#### Антипаттерны / грабли

1. **Описывать «как должно быть» вместо «как есть».** Карточка to-be до карточки as-is = красивая фантазия, которую невозможно автоматизировать, потому что реальная работа идёт иначе. Сначала фотографируем реальность.
2. **Boil the ocean — описать ВСЕ процессы сразу.** Команда тонет, ничего не доходит до автоматизации. Один value stream → довести до конца → следующий.
3. **Путать процесс и проект.** Регламентируют разовое (мёртвый PDF), «ведут проектом» повторяемое (ручное переизобретение). Разметка обязательна.
4. **Игнорировать handoffs, описывать только «тело» процессов.** Внутри участков всё чисто, а ломается на стыках («кандидат приехал — работы нет»). Стыки без владельца = гарантированный разрыв.
5. **Процесс без владельца.** «Все отвечают» = никто не отвечает; карточка устаревает, расхождение факт/регламент копится молча. Каждый процесс — ровно один владелец.
6. **Silent failures в порождении следа.** Агент тихо перестал писать Event Log на шаге 4 — и диагностика идёт по дырявым данным. Нужны health-checks: процесс без событий за N дней подсвечивается на дашборде.

#### 🔍 Было → стало (на примере)

> _«Светлый Дом» — мебель на заказ (кухни, шкафы), ~12 человек, без ERP._

**Было (3).** «Замерщик съездил — дальше как-нибудь передаст дизайнеру.» ТЗ лежит в личном WhatsApp замерщика по 2–3 дня; пока он в разъездах — клиент остывает. Шаги у каждого свои.

**Стало (4).** Карточка процесса с явным handoff и SLA; передача — через карточку проекта, а не личный мессенджер.

**Пример записи (карточка процесса):**

```
P-02 «Выезд на замер»
триггер: согласован слот замера
шаги: 1 подтвердить слот → 2 замер на объекте → 3 фото+эскиз
      → 4 ТЗ в State Store → 5 handoff дизайнеру
результат (DoD): ТЗ готово, дизайнер уведомлён ≤24 ч · владелец: Игорь
handoff: Замерщик → Дизайнер (что: ТЗ+фото; канал: карточка проекта;
         риск: «терялось в личном WhatsApp»)
```

#### Связи

- **← C1 (Карта бизнеса).** Вход: C1 даёт перечень функций/направлений и то, как создаётся ценность; C2 раскладывает это на конкретные value streams и процессы. Без C1 непонятно, какие процессы вообще должны быть; без C2 карта C1 остаётся статичной схемой.
- **→ C3 (Люди).** Выход: роли-участники и владельцы из карточек процессов — это «места», на которые C3 назначает конкретных людей и компетенции. Процесс определяет роль, человек заполняет роль.
- **→ +A (Агенты).** Выход: каждый повторяемый процесс с описанными шагами и спецификацией следа — это ТЗ для узкого агента (вход/выход берутся прямо из карточки). C2 определяет, ГДЕ агент работает и какой след собирает.
- **→ C4 (Регламенты → AOP).** Выход: карточка процесса (триггер→шаги→результат) — это исходник для AOP: регламент на естественном языке, превращаемый в исполняемый workflow. Регламент пишется НА процесс; нет процесса — нет регламента.
- **→ D (Данные → SSOT).** Выход: спецификация цифрового следа каждого шага → агенты порождают Event Log → факты текут в SSOT. C2 говорит, какие события вообще существуют и что считать состоянием.
- **→ C5 (Контроль + Дашборд).** Выход: Event Log + карточки дают сравнение «регламент vs факт» (process mining) и метрики по value stream (время цикла, потери на ожидании, разрывы handoff) — это сырьё для actionable-дашборда собственнику.
- **↔ Governance (сквозное).** Изменение процесса (as-is → to-be) затрагивает людей и необратимо → проходит через human-in-the-loop; разметка владельцев и критичности — это runtime-правила, а не разовый комитет.

---

## 👥 C3 · Люди

#### Что это

C3 — слой «КТО» в хребте Дмитрия (ПРОЦЕССЫ → **ЛЮДИ** → РЕГЛАМЕНТЫ → КОНТРОЛЬ → УПРАВЛЯЕМОСТЬ). Если C2 отвечает на вопрос «какие дела делаются», то C3 отвечает «кто их делает, кто за них отвечает и через какой интерфейс работает». Это привязка процессов и шагов к конкретным носителям ответственности — ролям и их исполнителям. Исполнителем роли может быть **человек**, **человек + AI-помощник** (агент поверх), а на верхних стадиях — **цифровой сотрудник** (агент занимает роль-слот сам, под человеком-руководителем). Роль и её исполнитель — разные сущности: роль может «держать» и человек, и агент.

Ключевая роль контура двойная. Первое — навести классическую управляемость в людях (роли, зоны ответственности, кто кому подчинён, нет дыр и нахлёстов). Второе и более важное для AI-ориентированной организации — это **точка входа адопшна**: именно здесь реализуется принцип «человек делает работу как привык, агент собирает цифровой след фоном» (System of Engagement по триаде Moore/Greylock — действие людей = Engagement, след = digital exhaust). C3 — это разъём между живыми людьми в их привычных каналах (WhatsApp/Telegram, голос, чек-листы) и машинным контуром (+A Агенты, D Данные). По BCG 10-20-70 это тот самый «70% людей и процессов», который решает успех, а не алгоритмы. Без проработанного C3 любая агентская надстройка повисает в воздухе: некому работать через интерфейс, некому доверять, некому собирать след.

#### Сущности

Конкретные объекты, которые создаются и живут в этом контуре:

1. **Реестр ролей (Role Registry).** Таблица/база, строка = роль (не человек). Поля: `role_id` (стабильный код: `R-NN` или `R-<слово>`, один формат на компанию; он же стоит в Role Card рядом со `slot`), название роли, миссия роли в одну фразу, основные процессы из C2 (ссылки на `process_id`), ключевые результаты (что роль обязана выдавать на выход), требуемые навыки, канал работы (где роль реально живёт — Telegram/телефон/1С/полевой обход), статус (есть человек / вакантна / совмещена). Пример строки: `R-07 · Приёмщик · "Превратить входящий звонок клиента в заведённый заказ" · процессы P-02 (приём), P-03 (диагностика) · выход: карточка заказа · канал: телефон + Telegram`.

2. **Карта «роль → человек» (Role-Person Map).** Отдельная сущность, потому что один человек носит несколько ролей, а одну роль могут делить двое. Поля: `person_id`, ФИО, какие `role_id` несёт, % загрузки по каждой, признак «риск ключевого лица» (роль держится на одном человеке без дублёра). Пример: «Марина несёт R-03 (опер-менеджер) на 70% и R-09 (адм) на 30%; R-03 — риск ключевого лица, дублёра нет».

3. **RACI-матрица на процессы C2.** Строки = шаги процессов из C2, столбцы = роли. В ячейках буквы R (исполняет), A (отвечает/owner, ровно один на шаг), C (консультируют), I (информируют). Это сущность-стык C2↔C3: процесс получает ответственных, роль получает свои шаги. Инвариант: на каждый значимый шаг ровно один **A**; шагов без A быть не должно (дыра), двух A — тоже (конфликт).

4. **Карточка роли (Role Card).** Развёрнутый «паспорт» одной роли в формате документа (можно держать в `00-CONTEXT`-логике локального узла). Содержит: миссию, границы (что НЕ входит), span of control (сколько людей/единиц под ролью), вход (что получает и от кого), выход (что отдаёт и кому), KPI роли (стык с C5), список AI-агентов-помощников этой роли (стык с +A), red flag-зоны под её KPI (минцберговский чек-лист слепых зон — что метрика роли НЕ видит).

5. **Friction Audit (карта трения каналов).** Артефакт-инвентаризация: по каждой роли — в каких каналах человек реально работает сегодня, сколько интерфейсов ему уже навязали, где «двойной ввод» (написал в WhatsApp + продублировал в систему). Поля: роль, канал, частота, «боль/трение», вердикт (встроить агента сюда / не плодить новый интерфейс). Принцип integration > innovation: агента ставим в канал, где человек уже живёт.

6. **Реестр span of control / оргсвязей.** Кто кому подчинён, у кого сколько прямых подчинённых, где перегруз (один руководитель тащит 12 человек) или вырожденные звенья. Может быть простой иерархической таблицей `role_id → manager_role_id` + счётчик подчинённых.

7. **Карта движения роли по value stack.** Для каждой роли — текущая высота на стеке McKinsey (исполнение → надзор → постановка целей) и целевая после внедрения агентов. Пример: «R-07 Приёмщик: сейчас 90% исполнение (руками заводит заказы); цель — агент заводит черновик заказа, человек переходит в надзор (проверяет/правит) → высвобожденное время на работу с клиентом».

#### Механика (что происходит)

Как работа и данные текут через контур:

1. **Из C2 приходят процессы и их шаги.** Берём карту процессов и для каждого значимого шага задаём вопрос «кто?». Так наполняется RACI и Реестр ролей: процесс порождает роли, роль притягивает к себе шаги.
2. **Роли привязываются к людям** через Role-Person Map. Здесь же всплывают патологии: дыры (шаг без A), нахлёсты (двое думают, что отвечают), риски ключевого лица (всё на одном человеке), перегруз span of control.
3. **Проводится Friction Audit:** для каждой роли фиксируем, в каком канале человек уже работает. Это вход для +A — где встроить агента.
4. **Над ролью встаёт агент-помощник (стык с +A), но НЕ меняет способ работы человека.** Человек продолжает: звонит, пишет в Telegram, ходит в цех, диктует голос. Это **слой действий**. Параллельно агент фоном превращает эти действия в структурированный **слой данных** — цифровой след (написал в чат «принял мотор Иванова на диагностику» → агент создаёт/обновляет запись о заказе в D/SSOT). Так разносятся слой действий ↔ слой данных, и закрывается MIT learning-gap: организация учится без того, чтобы человек менял привычки.
5. **Роль начинает двигаться вверх по value stack.** То, что было исполнением (руками вбить, посчитать, скопировать), забирает агент; человек переходит в надзор (проверить черновик агента) и дальше — в постановку целей. Карта движения роли фиксирует это «до/после».
6. **След от ролей сходится в D/SSOT, метрики ролей — в C5/дашборд.** KPI из Карточки роли становятся строками в дашборде собственника; видно, кто что выдал на выход, не дёргая людей отчётами.

#### Кто делает

- **Реестр ролей и RACI (первичное заполнение):** СОБСТВЕННИК + человек-аналитик/консультант. Это управленческое решение «кто за что отвечает» — его нельзя делегировать агенту, истину о структуре создаёт человек.
- **Поддержание Role-Person Map в актуальности:** ЧЕЛОВЕК (HR/операционный менеджер); AI-агент подсвечивает рассинхрон (роль в реестре есть — человека нет).
- **Friction Audit:** ЧЕЛОВЕК (аналитик) проводит интервью/наблюдение; собственник валидирует приоритеты.
- **Сбор цифрового следа за работой роли:** AI-АГЕНТ (фоновый, в канале роли). Человек просто работает.
- **Решение «двигать роль вверх по value stack» / какие шаги отдать агенту:** СОБСТВЕННИК (это про деньги и риск). Автономия агента по риску: необратимое / траты > $0 — human-in-the-loop, решает человек роли.
- **Проверка черновиков агента (надзорный слой):** ЧЕЛОВЕК-носитель роли.
- **Исполнять роль как цифровой сотрудник** (где роль отдана агенту целиком): AI-АГЕНТ-исполнитель, но с **ЧЕЛОВЕКОМ-руководителем** (owner роли-слота), который принимает работу и отвечает за результат.
- **Назначение KPI роли:** СОБСТВЕННИК совместно с носителем роли (стык с C5).

#### Зачем / что ломается без него

C3 нужен, потому что процессы (C2) без привязки к ответственным — это инструкция без исполнителей, а агенты (+A) без ролей — это автоматизация в вакууме, которой некому пользоваться и нечей след собирать.

Что конкретно ломается без C3:

- **Дыры и нахлёсты ответственности.** Шаг процесса есть, A нет — «я думал, это делает Петя». Или два A — конфликт и перекладывание. Заказы/задачи проваливаются в щели между людьми.
- **Риск ключевого лица.** Критичная роль на одном человеке без дублёра и без описания — ушёл в отпуск/уволился, и процесс встал. Знание ушло с ним (память гниёт без обслуживания).
- **Агенты не приживаются.** Без Friction Audit агента ставят как ещё один интерфейс «вот вам новая система, вносите сюда» — человек саботирует двойной ввод, след не собирается, пилот умирает (часть тех самых 95% провалов MIT / 80% RAND — провал не модели, а адопшна).
- **Люди застревают в исполнении.** Без карты value stack агентов вешают «сбоку», люди продолжают руками делать то, что мог бы агент; высвобождения и роста ценности нет.
- **Собственник управляет людьми вручную, дёргая отчётами.** Нет привязки «роль → выход → KPI» — приходится спрашивать каждого «ну что там», вместо того чтобы смотреть в дашборд.

#### По этапам зрелости

- **1 Awareness.** Ролей как сущности нет; в голове собственника «кто чем занимается». Всё держится на памяти и устных договорённостях. Дыры/нахлёсты не видны, риски ключевого лица не отслеживаются. Цифрового следа за людьми ноль.
- **2 Active.** Появляются обрывочные описания должностей (где-то в чате/Word), кто-то из сотрудников точечно гоняет ChatGPT под себя. Единого реестра ролей нет, RACI нет, привязки к процессам нет. Знание о том «кто за что», по-прежнему в головах.
- **3 Operational («зоопарк»).** У отдельных людей появились свои боты/помощники, но разрозненно: у каждого свой, дубли, никто не знает, кто чьим пользуется. Роли частично описаны, но бессистемно. Острый риск ключевого лица: и роли, и боты держатся на конкретных людях. Цифровой след собирается кусками и не сходится.
- **4 Systemic («контур»).** Есть единый Реестр ролей + RACI на процессы C2, Role-Person Map с пометкой рисков ключевого лица, Friction Audit проведён. Над ролями стоят стандартизованные агенты-помощники в каналах, где люди уже работают; след фоном сходится в SSOT; KPI ролей — на дашборде. Узлы суверенны, но подчинены общим стандартам (федеративная конституция). Это целевое состояние перехода 3→4.
- **5 Transformational.** Роли непрерывно двигаются вверх по value stack, люди работают преимущественно в надзоре и постановке целей, агенты несут исполнение (~2.5 человека на 50–100 агентов как ориентир сетевой agentic-структуры). Организация управляется как система; силосы заменены сетями людей+агентов; адопшн — норма, а не проект.

#### Как внедряется (SMB без ERP, с нуля)

1. **Выгрузить процессы из C2** и для каждого значимого шага задать «кто это делает / кто отвечает». Если C2 ещё нет — сначала он (system-first, не AI-first).
2. **Собрать Реестр ролей** (роль ≠ человек). Самый простой носитель — таблица (Google Sheets / Notion-база), без ERP. Заполнить поля из сущности №1.
3. **Построить RACI** на шаги процессов. Прогнать инвариант: на каждый шаг ровно один A; устранить дыры и двойные A. Это даёт мгновенную управленческую картину «где провалы».
4. **Наложить людей (Role-Person Map),** пометить риски ключевого лица и перегруз span of control. По каждому риску ключевого лица — решение: дублёр, описание роли, или агент-страховка.
5. **Провести Friction Audit:** по каждой роли выписать реальные каналы работы. Выбрать 1–2 роли с самым болезненным «двойным вводом» как пилот для агента.
6. **На пилотной роли поставить агента ПОВЕРХ канала** (человек пишет в Telegram как привык → агент фоном пишет в SSOT). Никакого нового интерфейса для человека. Это стык с +A и D.
7. **Завести Карточку роли** для пилотной роли: вход/выход, KPI, агенты-помощники, чек-лист слепых зон под KPI.
8. **Вывести KPI роли на дашборд** (стык с C5) — собственник видит выход роли без ручных отчётов.
9. **Зафиксировать карту value stack** «до/после» и расширять на следующие роли по тому же циклу.

**Антипаттлерны / грабли.**

1. **«Новая система — вносите сюда».** Заставить людей бросить WhatsApp/Telegram и работать в новом интерфейсе. Нарушает integration > innovation; люди саботируют, двойной ввод, след не собирается. Правильно: агент поверх существующего канала.
2. **Роль = человек.** Описывать не роли, а конкретных Петь и Маш. Уволился человек — рухнула «роль». Роль должна быть отделена от носителя (поэтому Реестр ролей и Role-Person Map — разные сущности).
3. **Размытое или двойное A.** «Отвечают все» = не отвечает никто; два A = конфликт. RACI без жёсткого инварианта «один A на шаг» бесполезен.
4. **Игнор риска ключевого лица.** Описали роли красиво, но не пометили, что три критичных держатся на одном человеке без дублёра и без выгруженного знания. Память узла гниёт без обслуживания.
5. **Приказ сверху вместо движения снизу.** Спустить роли/агентов директивой, не вовлекая носителей. По Минцбергу перемены устойчивее снизу; организация — сообщество, не оргсхема. Слепое доверие метрике роли вытесняет неизмеримую ценность (дивизионализация ≠ децентрализация) — поэтому в Карточке роли обязателен чек-лист слепых зон под KPI.

#### 🔍 Было → стало (на примере)

> _«Светлый Дом» — мебель на заказ (кухни, шкафы), ~12 человек, без ERP._

**Было (3).** Дизайнер Лена и считает смету, и рисует, и пишет клиенту, и торопит цех. Уходит в отпуск — проекты встают (риск ключевого лица). Сколько КП зависло без ответа — никто не видит.

**Стало (4).** Роль ≠ исполнитель: роль R-дизайнер расщеплена по value-stack — рутина уходит агенту, за человеком остаётся решение.

**Пример записи (Role Card, фрагмент):**

```
Роль: R-дизайнер-конструктор · исполнитель: Лена
  Исполнение (рутина) → агент proposal-drafter: пересчёт сметы по прайсу,
                        сборка черновика КП, напоминания клиенту
  Надзор → Лена (человек): дизайн-решение, утверждение цены и изменений
  Цели → Владелец: маржа проекта, загрузка цеха
Риск ключевого лица: было «весь проект в голове Лены» →
                     стало «знание в шаблонах + State Store»
```

#### Связи

- **← C2 Процессы (вход).** C3 берёт шаги процессов и навешивает на них ответственных через RACI. Процессы C2 — это «что», роли C3 — «кто это что делает». Без C2 ролям не к чему крепиться.
- **→ +A Агенты (выход/вход).** C3 говорит агентам, какую роль каждый из них усиливает и в каком канале живёт человек (из Friction Audit). Агент = помощник конкретной роли, карточка роли ссылается на своих агентов. Обратно +A двигает роль вверх по value stack.
- **→ C4 Регламенты→AOP.** Роли C3 — субъекты регламентов: AOP описывает, КАК роль выполняет шаг. «Кто» (C3) + «как одинаково» (C4) = воспроизводимость.
- **→ D Данные→SSOT (выход).** Действия людей в их каналах (слой действий) агенты превращают в цифровой след (слой данных), который сходится в SSOT. C3 — источник этого следа: нет ролей и людей, работающих через каналы — нет и следа.
- **→ C5 Контроль+Дашборд (выход).** KPI из Карточек ролей становятся метриками на дашборде собственника; выход каждой роли виден без ручных отчётов.
- **↕ Governance (сквозное).** Автономия агента над ролью ограничивается по риску (human-in-the-loop на необратимом/тратах), RACI определяет, кто принимает решения. Носитель роли — точка runtime-контроля, а не комитет.

---

## 🤖 +A · Агенты (поверх людей)

#### Что это

«+A» — это контур, который вставляется **поверх контура C3 «Люди»**, не заменяя его. Люди продолжают делать работу так, как привыкли (звонят, пишут в мессенджер, заполняют накладную, проводят встречу), но между слоем их **действий** и слоем **данных** появляется прослойка узких AI-агентов, которые собирают цифровой след фоном. Это операционализация хребта Дмитрия в точке стыка ЛЮДИ→КОНТРОЛЬ: вместо того чтобы заставлять человека вести вторую, «отчётную» жизнь в системе, агент превращает его естественные действия (System of Engagement) в структурированный факт (digital exhaust → System of Record/Intelligence). Это и есть закрытие MIT learning-gap и механика операционализации «70% — люди и процессы» из BCG 10-20-70: ценность создаёт не модель, а то, что человек ничего не меняет в своей работе, а след всё равно появляется.

Ключевой принцип контура: **«человек работает — агент собирает»**. В **базовом режиме** агент — не автономный сотрудник, а **усилитель и сборщик следа** (копайлот над человеком). Истину создаёт человек, AI её фиксирует, нормализует и сверяет. На необратимых действиях и тратах автономии у агента — ноль (human-in-the-loop gate). Контур умышленно строится **снизу-вверх и узким**: набор маленьких специализированных агентов с явными границами, а не один «универсальный ассистент» — потому что на практике узкие агенты выживают, а scope creep убивает («галлюцинирует к шагу 3»).

**Два режима агента — спектр исполнителя роли.** Агент в этом контуре работает в одном из двух режимов, и роль может двигаться по спектру **человек → человек + AI-помощник → цифровой сотрудник**:

- **AI-помощник (копайлот)** — садится *поверх* человека: человек держит роль и делает работу, агент помогает, корректирует, готовит черновики и собирает след. Исполнитель роли — человек.
- **Цифровой сотрудник** — *занимает роль* и выполняет работу сам, заменяя часть (или всю) функцию сотрудника. Это уже не инструмент при человеке, а **узел оргструктуры наравне с людьми**: у него есть роль-слот в C3 «Люди», человек-руководитель (owner) и — главное — **коннекторы** (кому подчиняется, с кем стыкуется — люди и другие агенты, в каком канале живёт, как эскалирует). По сути цифрового сотрудника **онбордят как человека**: даёшь ему регламент (AOP) = должностную инструкцию, вход/выход, точки передачи и уровень автономии.

Чем выше автономия и необратимость действий цифрового сотрудника — тем жёстче коннекторы, gates и owner-надзор (автономия-по-риску). Принцип «истину создаёт человек» сохраняется: цифровой сотрудник действует в границах регламента и guardrails, а на необратимом и тратах всё равно есть человек на gate.

#### Сущности

Контур состоит из конкретных, создаваемых и «трогаемых» объектов:

1. **Типы агентов (5 архетипов-ролей).** Каждый агент в реестре обязан принадлежать одному типу — это его «класс», задающий guardrails и уровень автономии:
   - **Collector (собиратель следа)** — слушает канал, где человек уже работает (Telegram-чат, почта, расшифровка звонка), и порождает структурированный факт. Для SMB без ERP это базовый агент — он создаёт event log с нуля. Автономия: пишет в данные, но не в боевые системы.
   - **Drafter** — готовит черновик (ответ клиенту, протокол встречи, описание задачи). Никогда не отправляет сам — отдаёт человеку на gate.
   - **Qualifier** — классифицирует/скорит (лид горячий/холодный, обращение — жалоба/заказ, риск сделки). Выдаёт метку + причину, не принимает решение.
   - **Router** — маршрутизирует: кому назначить, в какую папку/проект положить, какой следующий шаг. (Прямой аналог логики операционного кодекса Дмитрия: «определи проект, не угадывай».)
   - **Reconciler / сверщик** — сравнивает **регламент vs факт**: что было обещано (commitment) vs что сделано; что говорит AOP vs что реально произошло в event log. Поставляет drift-сигналы наверх.

2. **Карточка-стандарт агента (Agent Card).** Единый паспорт на каждого агента, в формате одного файла (YAML/MD), с обязательными полями:
   ```
   id:              стабильный идентификатор, не меняется; им агент подписывает события (actor = agent:<id>)
   name:            collector-telegram-remservice
   type:            collector
   mode:            assistant | digital-employee   # помощник над человеком | цифровой сотрудник в роли
   purpose:         "собрать факты обращений из клиентского чата в SSOT"
   input:           источник + триггер (канал X, новое сообщение)
   output:          схема факта (case_id, activity, timestamp, actor, payload)
   data_source:     откуда читает (Telegram API / расшифровка)
   data_sink:       куда пишет (таблица events в SSOT)
   schedule:        событийно / cron 'каждые 15 мин' / по запросу
   runbook:         что делать при сбое (ссылка на raw, ретрай, эскалация)
   autonomy:        L0 | L1 | L2 | L3   # L0 предлагает · L1 действует+уведомляет · L2 авто в зелёной зоне · L3 полностью авто
   guardrails:      запреты (не пишет в боевую систему, не тратит, не отправляет наружу)
   gate:            none | human-in-the-loop | dual-control   # кто именно подтверждает — в шаге AOP
   owner:           ФИО человека-владельца/руководителя
   role_slot:       роль/позиция в оргструктуре (C3), если это цифровой сотрудник; иначе —
   connectors:      кому подчиняется · с кем стыкуется (люди/агенты) · канал · эскалация
   status:          draft | active | paused | retired
   health:          heartbeat (как часто подаёт признак жизни) · alert_if (когда бить тревогу) · last_ok (последний успешный прогон)
   ```
   Это L2-сущность из zoo-фреймворка (реестр+карточка с вход/выход), доведённая до исполняемой полноты.

3. **Реестр агентов (Agent Registry).** Один список/таблица всех карточек — единственное место, где видно, **кто из агентов существует, что делает, чем владеет человек и жив ли он**. Поля-проекция карточек: name · type · owner · status · health · последний прогон. Без реестра неизбежен «зоопарк» (стадия 3): дубли, риск ключевого лица, никто не знает, что крутится.

4. **Инструменты (tools / MCP).** То, чем агент дотягивается до мира: коннекторы к каналам и хранилищам (почта, мессенджер, календарь, диск, SSOT-store). Каждый tool привязан к карточке и ограничен guardrails (read-only там, где нельзя писать).

5. **Guardrails.** Жёсткие, машинно-проверяемые ограничения на агента: что нельзя трогать, куда нельзя писать, что нельзя отправлять наружу, потолок трат = $0 без подтверждения. Это **runtime-enforcement, а не комитет** — правило живёт в конфиге агента и срабатывает в момент действия (governance как runtime, не как регламент-PDF).

6. **Human-in-the-loop gates.** Точки обязательной остановки, где человек подтверждает действие, прежде чем оно станет необратимым. Сущность gate = {какое действие, кто подтверждает, что показывается на подтверждение, fallback при таймауте}.

7. **Матрица «Автономия-по-риску».** Таблица, привязывающая уровень автономии к обратимости и деньгам действия:

   | Действие | Обратимо? | Траты? | Автономия агента |
   |---|---|---|---|
   | Собрать факт в SSOT | да | нет | полная (collector сам) |
   | Подготовить черновик | да | нет | полная до отправки, отправка — gate |
   | Назначить задачу внутри | да | нет | авто + лог, откат возможен |
   | Отправить наружу клиенту | нет | нет | **gate (человек жмёт «ок»)** |
   | Любая трата / платёж / договор | нет | да>$0 | **ноль автономии, всегда человек** (стадии 1–4; на стадии 5 — только платежи в жёстком лимите, см. ниже) |

   В ступенях шкалы `autonomy`: «полная» = L3 · «авто + лог» = L2 · «полная до отправки, отправка — gate» = L1 с gate на отправке · «gate» = L0: агент готовит, человек подтверждает · «ноль автономии» = действие закрыто для агента на любой ступени.

   **Платежи на стадии 5 (жёсткий лимит).** На стадиях 1–4 деньги наружу — всегда человек. На стадии 5 агент может провести платёж сам, только если выполнены ВСЕ условия:

   - **белый список получателей** — платёж только контрагенту из утверждённого списка с проверенными реквизитами; новый получатель или смена реквизитов = человек, без исключений;
   - **потолок суммы** на один платёж и **дневной потолок** на агента — утверждает собственник; хранятся в `guardrails` карточки агента, а не в промпте;
   - **основание в данных** — платёж ссылается на `case_id` и на документ-основание в State Store (счёт, сверенный с заказом); нет основания = нет платежа;
   - **текст не основание** — просьба «оплати», пришедшая в письме или сообщении, платёж не запускает (защита от подмены);
   - **сверка после** — агент-сверщик в тот же день сверяет проведённые платежи с выпиской; расхождение = автоматическая пауза агента и инцидент P1;
   - **отчёт собственнику** — все автоплатежи за день одной плиткой на дашборде; попытка платежа сверх лимита или вне списка — отдельным сигналом.

   Договоры, возвраты клиентам и любые платежи вне списка остаются за человеком на любой стадии.

8. **Health-check / журнал прогонов.** Поле health в карточке (heartbeat, alert_if, last_ok) + журнал прогонов: время, успех/сбой, текст ошибки. Существует, чтобы ловить **silent failures** — агент, тихо переставший собирать след, хуже ручного процесса, потому что в данные приходит молчаливая дыра.

9. **Цифровой сотрудник и его коннекторы.** Когда агент не помогает человеку, а **занимает роль**, он становится узлом оргструктуры и получает «обвязку», как при найме человека:
   - **role_slot** — позиция в C3: какой участок держит, его вход/выход в сквозном процессе;
   - **руководитель / owner** — кому подчиняется, кто принимает его работу и отвечает за него;
   - **коннекторы** — точки стыковки: от кого получает (люди/агенты), кому передаёт (handoffs), в каком канале «живёт» (Telegram/CRM/почта), как и кому эскалирует;
   - **регламент (AOP)** — его исполнимая «должностная инструкция», сверяемая на drift;
   - **уровень автономии** — по матрице риска; на необратимом и тратах всё равно человек на gate.

   Цифровой сотрудник = композиция архетипов (collector + qualifier + drafter + router…), которой выдан слот, регламент и коннекторы — он держит участок работы целиком, а не помогает по кусочку. Без коннекторов цифровой сотрудник повисает так же, как несонбордженный человек.

#### Механика (что происходит)

Поток работы и данных через контур:

1. **Действие.** Человек делает работу в своём канале — пишет клиенту в Telegram, проводит звонок, ставит задачу. Слой действий не меняется.
2. **Захват.** Collector-агент через свой tool/MCP видит событие (новое сообщение, законченная встреча, расшифровка) — триггер из карточки.
3. **Нормализация.** Агент превращает сырое событие в структурированный факт по схеме output: минимум `case_id + activity + timestamp + actor`, плюс payload. Сырьё параллельно кладётся в `raw/` (чтобы можно было пересобрать). Цифры/расчёты — **вне LLM** (детерминизм): агент извлекает и раскладывает, но не выдумывает суммы и даты.
4. **Запись в данные.** Факт пишется в SSOT — **структурированный store состояния** (SQL/граф), который агенты обновляют, а не только read-only RAG. RAG-извлечение — поверх, для поиска, не как источник истины о состоянии и времени.
5. **Квалификация / маршрутизация.** Qualifier ставит метку (+причину), Router определяет адресата/следующий шаг. Drafter, если нужно, готовит черновик ответа/протокола.
6. **Gate.** Если следующее действие необратимо или тратит деньги — агент останавливается на human-in-the-loop gate: показывает человеку черновик/предложение, человек подтверждает. Только после «ок» действие исполняется.
7. **Сверка.** Reconciler периодически сравнивает event log (факт) с AOP/обязательствами (регламент) и поднимает drift-сигнал, если «обещали ≠ сделали».
8. **Наверх.** Структурированные факты и drift-сигналы текут в контур D (SSOT) → C5 (Контроль/Дашборд собственнику).

Итог превращения: **сырое человеческое действие → структурированный факт → сверенный сигнал → строка дашборда**, без того чтобы человек вёл вторую отчётную жизнь.

#### Кто делает

- **Определить, какой след нужен** (какие факты ловим) — **Собственник** (это его язык управляемости, его KPI; Минцберг-оговорка: рядом держим чек-лист слепых зон, чтобы метрика не срезала неизмеримую ценность).
- **Спроектировать узкого агента и схему факта** — **Человек-архитектор контура** (внедренец), не агент.
- **Захват, нормализация, запись следа** — **AI-агент** (collector).
- **Классификация / скоринг / маршрутизация** — **AI-агент** (qualifier/router), но решение по спорному кейсу — **человек на gate**.
- **Черновики наружу** — **AI-агент** готовит, **человек-владелец** отправляет.
- **Любая трата / необратимое / отправка клиенту** — **только человек** (gate). Единственное исключение для денег — платежи в жёстком лимите на стадии 5 (см. «Платежи на стадии 5» в контуре +A).
- **Держать роль целиком как цифровой сотрудник** (выполнять участок вместо сотрудника) — **AI-агент в режиме цифрового сотрудника**, но всегда с **человеком-руководителем** (owner), который принимает его работу; найм/онбординг (slot, коннекторы, AOP, автономия) делают **человек-архитектор + собственник**.
- **Владение каждым агентом** (его здоровье, runbook, остановка) — **конкретный человек-owner** в карточке (по McKinsey ~2.5 человека на 50–100 агентов — но владелец у каждого агента всегда один и поимённый).
- **Утвердить уровни автономии и guardrails** — **Собственник + архитектор** (governance-runtime).
- **Реагировать на drift-сигнал сверщика** — **Человек** (агент только сигналит).

#### Зачем / что ломается без него

Без этого контура остаётся неустранимый разрыв между тем, что люди **делают**, и тем, что попадает в **данные**. В SMB без ERP этот разрыв = пропасть: event-логов нет, поэтому либо людей заставляют вручную дублировать работу в CRM/таблицы (саботаж, неполные данные, «отчётная жизнь»), либо данных просто нет и собственник управляет вслепую. Конкретные провалы при отсутствии «+A»:

- **Дашборд врёт или пуст** — нечем его наполнять: люди работают, след не собирается, KPI считаются по памяти и интуиции (то, против чего и нужна AI-система управляемости).
- **Регламент нечем сверить с фактом** — AOP остаётся декларацией, drift не виден, «делаем как договорились» проверить невозможно.
- **Адопшн проваливается** — без механики «человек работает, агент собирает» внедрение AI = ещё одна система, которую люди обходят (это и есть 95% MIT / 80% RAND провалов пилотов: AI-first без выстроенной управляемости).
- **Знание о том, кто что делает, живёт в головах** — риск ключевого лица, тот самый «зоопарк».

#### По этапам зрелости

- **1 Awareness.** Контура нет. След не собирается вообще; вся работа и все данные — в головах и переписках. Агентов нет, есть отрицание/осознание. Слой действий = слой данных = ничего структурированного.
- **2 Active.** Точечный ChatGPT ad hoc: человек руками просит модель «сделай черновик/суммируй звонок» и копипастит результат. Это **drafter без карточки и без записи в данные** — след не оседает, нет реестра, нет owner, нет gate как стандарта. Одноразовая польза, нулевая накопляемость.
- **3 Operational / «зоопарк».** Уже есть свои боты-агенты, но разрозненно: несколько collector'ов/drafter'ов у разных людей, дубли, разные форматы выхода, нет единого реестра, риск ключевого лица. Silent failures незаметны. Автономия не отрегулирована по риску — где-то агент уже что-то отправляет сам. Цель — вытащить контур отсюда в стадию 4.
- **4 Systemic / «контур».** Есть **реестр агентов**, у каждого — карточка-стандарт с owner, schedule, runbook, guardrails и health. Все collector'ы пишут в **единый SSOT** по общим схемам. Автономия-по-риску формализована (ноль на тратах/необратимом), gates стандартны, reconciler сверяет регламент vs факт. Federated-конституция: узлы (проекты/отделы) суверенны, но соблюдают общие стандарты карточки и схемы факта. Появляются первые **цифровые сотрудники** на простых, обратимых участках (агент держит роль целиком под owner'ом, вписан в оргструктуру с коннекторами). Это целевое состояние «+A».
- **5 Transformational.** Контур «+A» становится частью AI-native операционки: новый процесс рождается сразу с агентом-сборщиком следа и AOP; управляемость работает как система, агенты — штатная прослойка между действием и данными, роли людей сдвинуты вверх по value stack (исполнение → надзор → цели), как в Agentic Organization. Часть ролей штатно держат **цифровые сотрудники**: оргструктура = люди + агенты-узлы, а человек — руководитель и точка эскалации.

#### Как внедряется (SMB без ERP, с нуля)

1. **Выбрать ОДИН канал, где люди уже живут** (friction audit: не плодить новые интерфейсы — встраиваться в существующий, напр. клиентский Telegram-чат или почта). Integration > innovation.
2. **Определить 3–5 фактов, которые нужны собственнику** для одного KPI (что считаем «обращением», «обязательством», «сделкой»). Методология до инструмента.
3. **Завести первого узкого collector'а** под этот канал: создать его **карточку-стандарт** (все обязательные поля), задать схему факта `case_id+activity+timestamp+actor+payload`, настроить tool/MCP к каналу.
4. **Поднять минимальный SSOT-store** состояния — простая SQL-таблица/таблица событий (не вектор-RAG как источник истины), куда collector пишет. RAG — позже и поверх.
5. **Создать реестр агентов** (одна таблица) и завести в него карточку; назначить **owner** и **runbook**.
6. **Прописать автономию-по-риску и guardrails**: collector — только запись следа (ступень по шкале L0–L3 — от риска канала), ноль трат, ничего наружу без gate. Поставить human-in-the-loop gate на первое же действие наружу.
7. **Включить health-check**: фиксировать `last_ok` и ошибки прогонов в журнале; завести правило «нет прогона N часов → сигнал owner'у» (анти-silent-failure).
8. **Добавить второго узкого агента** (drafter или qualifier) только когда первый стабилен — расширяться количеством узких агентов, а не раздуванием одного.
9. **Подключить reconciler** последним, когда уже есть и факт (event log), и регламент (AOP из контура C4), чтобы сверять «обещали vs сделали».
10. Всё снизу-вверх: сперва один работающий контур на одном канале, потом тиражирование по federated-стандарту.

#### Антипаттерны / грабли

1. **Scope creep — один «универсальный агент».** Пытаются сделать одного агента, который и собирает, и пишет, и отправляет, и решает. К шагу 3 он галлюцинирует. Лечится дроблением на узкие агенты по 5 типам.
2. **Silent failures без health-check.** Агент тихо перестал собирать след — данные молча гниют, дашборд врёт, и это **хуже ручного процесса**, потому что иллюзия покрытия. Лечится health-полем + правилом эскалации owner'у.
3. **Автономия на необратимом/тратах.** Дали агенту отправлять клиенту/тратить/подписывать без gate — первый же дорогой инцидент. Правило железное: ноль автономии на необратимом и любых тратах >$0.
4. **Агент без owner'а и runbook'а («зоопарк»).** Бот крутится, никто не отвечает за него, при сбое некому чинить, при увольнении сотрудника знание теряется — риск ключевого лица. Лечится обязательным поименным owner в карточке и реестром.
5. **SSOT как чистый read-only RAG.** Векторный store «не знает истины и времени», агенты не могут обновлять состояние. Нужен структурированный store состояния (SQL/граф), который агенты **пишут**, а RAG — извлечением поверх. Плюс: ~60% работы — это data plumbing, недооценка приводит к срыву сроков.
6. **(грабли адопшна)** Заставить людей менять способ работы ради агента — вместо «человек работает как привык, агент собирает фоном». Любое требование вести «вторую отчётную жизнь» убивает контур.

#### 🔍 Было → стало (на примере)

> _«Светлый Дом» — мебель на заказ (кухни, шкафы), ~12 человек, без ERP._

**Было (3).** На входящие в Instagram — автоответ «Спасибо, скоро ответим» и тишина. Ночные и выходные заявки теряются до утра; КП клиент ждёт 2–3 дня.

**Стало (4).** Два узких агента поверх людей: `intake-collector` сводит заявки из всех каналов в один реестр; `proposal-drafter` — цифровой сотрудник, по ТЗ собирает черновик КП к утру, человек проверяет и отправляет.

**Пример записи (Agent Card):**

```
id: proposal-drafter
тип: цифровой сотрудник (занимает рутинную часть роли R-дизайнер)
вход: ТЗ из P-02 · выход: черновик КП+смета на проверку Лене
коннекторы: прайс-лист (read) · State Store (read/write) · почта (draft-only)
автономия: L0 (готовит черновик, сам не отправляет) — отправка клиенту через gate человека
владелец: Лена · health-check: нет черновика >4 ч после ТЗ → алерт
```

#### Связи (вход/выход)

- **↔ C3 «Люди».** Двойная связь: в режиме **помощника** «+A» садится *поверх* C3 (агент усиливает человека, owner берётся из «Люди»); в режиме **цифрового сотрудника** агент сам становится *узлом внутри* C3 — занимает роль-слот рядом с людьми, с человеком-руководителем и коннекторами к коллегам. Вход: действия людей (System of Engagement) + назначенные роли-слоты.
- **← C2 «Процессы».** Вход: какой шаг процесса порождает какой факт — определяет, что должен ловить collector и где ставить gate.
- **← C4 «Регламенты → AOP».** Вход для **reconciler**: живой AOP (SOP на естественном языке → исполняемый workflow + drift-detection) — эталон, с которым сверяется факт. Выход обратно: drift-сигналы уточняют AOP.
- **→ D «Данные → SSOT».** Главный выход: collector'ы — это L4-«клей» zoo-фреймворка (агент читает описание/контекст из L1 → пишет факты в L3-хаб данных). Контур «+A» — основной **поставщик следа** в SSOT.
- **→ C5 «Контроль + Дашборд».** Выход: структурированные факты и drift-сигналы → governed-расчёт KPI (semantic/metrics layer, dbt — один governed-расчёт, цифры вне LLM) → actionable-дашборд собственнику (L5 / Digital Twin of Organization: приоритизировать, мониторить, симулировать).
- **↕ Governance (сквозное).** guardrails + автономия-по-риску + gates — это runtime-enforcement governance внутри каждого агента, а не отдельный комитет; реестр агентов — объект governance-надзора.

---

## 📋 C4 · Регламенты → AOP (исполнимый контракт)

#### Что это

Слой РЕГЛАМЕНТЫ из хребта Дмитрия (ПРОЦЕССЫ → ЛЮДИ → **РЕГЛАМЕНТЫ** → КОНТРОЛЬ → УПРАВЛЯЕМОСТЬ) — это «чтобы все делали одинаково». В классике он умирает как мёртвый PDF: документ написан, лежит в папке, его никто не открывает, факт расходится с бумагой. Контур C4 переводит регламент из мёртвого документа в **живой исполнимый контракт двойного назначения**: одна и та же сущность читается человеком как SOP (инструкция «как делать») и исполняется агентом как AOP — Agent Operating Procedure (регламент на естественном языке → исполняемый workflow агента, по линии AWS Strands / Decagon). Регламент перестаёт быть описанием намерения и становится исполняемым артефактом, против которого можно проверять реальность.

Роль контура — быть **прослойкой стандарта** между тем, как люди и агенты *должны* работать (C2 Процессы, C3 Люди, +A Агенты), и тем, как они *фактически* работают (D Данные/SSOT). C4 не хранит факты (это слой D) и не хранит описание устройства бизнеса (это L1 база знаний zoo / C1 карта). C4 хранит **норму** и держит её сверку с фактом. В терминах System of Intelligence: C4 — это операционные плейбуки контекст-слоя (Atlan: Operational Playbooks), исполняемые поверх System of Record. Это контур, который превращает «у нас есть процессы» в «процессы соблюдаются и это видно».

#### Сущности

Конкретные объекты, которые в этом контуре создаются и трогаются:

1. **SOP (Standard Operating Procedure) — человекочитаемый слой контракта.** Markdown-файл с фронтматтером. Поля: `id`, `version`, `owner`, `trigger` (когда запускается), `steps[]` (нумерованный список действий человеческим языком), `definition_of_done`, `inputs`, `outputs`, `escalation` (когда эскалировать человеку). Это то, что читает сотрудник. Пример шага: «3. Проверить, что у лида заполнен телефон в формате +XX; если нет — запросить у источника, не двигать дальше».

2. **AOP (Agent Operating Procedure) — исполнимый слой того же контракта.** Тот же SOP, размеченный для агента: к каждому шагу привязан `tool` (какой инструмент/действие), `precondition`, `postcondition`, `autonomy` (ступень L0–L3 для этого шага: не выше ступени агента-исполнителя из его карточки; строже — можно), `risk_class`. AOP — это не отдельный документ, а **исполнимая проекция SOP**: один источник, два потребителя. Шаг 3 выше в AOP превращается в: `precondition: lead.phone matches /^\+\d+/`, `on_fail: action=request_from_source, autonomy=L2`, `block_advance: true`.

3. **Чек-лист обязательных пунктов (mandatory checklist) — контроль ПОЛНОТЫ, не детерминизма.** Отдельный список пунктов, которые агент ОБЯЗАН затронуть при исполнении регламента. Это лечит конкретную болезнь LLM — «пропустил пункт на шаге 3» — но **не делает разбор детерминированным**: агент по-прежнему рассуждает свободно, чек-лист лишь верифицирует, что ни один обязательный пункт не выпал. Формат: `checklist[]` с полями `item`, `required: true/false`, `covered: bool` (заполняется после прогона). Это разные вещи: детерминизм цифр живёт в слое D (расчёт ВНЕ LLM); полнота пунктов живёт здесь.

4. **Drift-detector (детектор отклонения факт ↔ регламент).** Сущность-правило, сверяющая событийный след из слоя D (event log: минимум `case_id + activity + timestamp + actor`, по van der Aalst / Celonis Process Mining) с предписанной в AOP последовательностью. Выдаёт `drift_events[]`: пропущенный обязательный шаг, нарушенный порядок, превышенный SLA, действие без предписания. Это операционализация «регламент vs факт» process mining для SMB, где event log агенты порождают сами (зазор: нет ERP — след генерируется с нуля).

5. **Версия регламента (versioned contract).** Каждый SOP/AOP — под версионированием (semver: `MAJOR.MINOR.PATCH`), с `changelog`, `effective_from`, `supersedes`. Старая версия не стирается — архивируется. Это обязательное условие «живого контракта»: когда процесс меняется, меняется версия, а drift меряется против *действующей* версии, не против легенды.

6. **Decision Memory (память решений по регламенту).** Лог прецедентов: «в кейсе X отступили от шага 5, потому что Y, решение принял Z». Поля: `case_id`, `deviation`, `rationale`, `approved_by`, `date`. По Atlan Decision Memory — чтобы исключения не превращались в тихий размыв стандарта, а накапливались как явные прецеденты (и питали следующую версию).

7. **Карточка владельца регламента (steward card).** Привязка каждого SOP/AOP к человеку-владельцу (MIT CISR stewardship-фактор). Поля: `owner`, `review_cadence` (как часто пересматривать), `last_reviewed`. Без явного владельца регламент гниёт (память гниёт без обслуживания — Reddit-практика).

#### Механика (что происходит)

Как работа и данные текут через контур:

1. **Извлечение нормы.** Берётся реальный процесс из C2 и роль из C3. Человеческое «как мы это делаем» записывается в SOP (steps + definition_of_done). На этом этапе ещё нет агента — есть человекочитаемый стандарт.
2. **Разметка в AOP.** К каждому шагу SOP добавляются исполнимые атрибуты (tool, pre/postcondition, autonomy, risk_class) и собирается mandatory checklist. SOP → AOP — это не переписывание, а **обогащение того же файла** под второго потребителя (агента).
3. **Исполнение через интерфейс.** Человек делает работу как привык (механика адопшна: «человек работает — агент собирает фоном»). Агент либо ведёт его по AOP (подсказывает шаг, проверяет precondition), либо исполняет шаги со ступенью `autonomy` L2–L3 сам. Каждое касание оставляет событие в event log слоя D.
4. **Проверка полноты.** После прогона чек-лист обязательных пунктов сверяется: все `required: true` пункты `covered`? Непокрытые — флаг. Это ловит «LLM дошёл до шага 3 и поплыл» до того, как результат уйдёт дальше.
5. **Детекция дрейфа.** Drift-detector сверяет фактический след (D) с предписанной в действующей версии AOP последовательностью. Расхождения → `drift_events[]`.
6. **Разрешение дрейфа.** Дрейф — это сигнал, и у него две причины: либо **реальность нарушает норму** (чинить исполнение, эскалация по C5), либо **норма устарела** (чинить регламент → новая версия). Решение фиксируется в Decision Memory; если систематическое — поднимается версия AOP. Контракт остаётся живым.
7. **research writes / delivery reads.** Регламенты, которые *вырабатываются/исследуются* (новые SOP, апдейты версий), пишутся отдельным «research»-контуром; контур *исполнения/доставки* (delivery) их только читает. Это предотвращает гниение памяти: тот, кто исполняет в бою, не правит норму на лету — иначе стандарт размывается без следа.

#### Кто делает

- **Извлечение реального процесса в SOP** — ЧЕЛОВЕК (носитель процесса / РОП / операционный менеджер) при ассисте AI-АГЕНТА (агент интервьюирует, структурирует черновик; «истину создаёт человек, AI — усилитель»).
- **Разметка SOP → AOP (tool/pre/postcondition/autonomy)** — AI-АГЕНТ генерирует разметку, ЧЕЛОВЕК-владелец валидирует (особенно autonomy и risk_class).
- **Назначение autonomy и risk_class** — СОБСТВЕННИК / владелец регламента. Это решение про риск (human-in-the-loop на необратимом и на тратах > $0), его нельзя делегировать агенту. Единственное исключение для денег — платежи в жёстком лимите на стадии 5 (см. «Платежи на стадии 5» в контуре +A).
- **Исполнение по AOP** — AI-АГЕНТ (для auto-шагов) + ЧЕЛОВЕК (для шагов своей зоны; агент собирает след фоном).
- **Проверка чек-листа полноты** — AI-АГЕНТ (механически сверяет covered), эскалация непокрытого — ЧЕЛОВЕКУ.
- **Детекция дрейфа** — AI-АГЕНТ (drift-detector работает на event log автоматически).
- **Решение «чинить факт или чинить норму»** — ЧЕЛОВЕК-владелец регламента; систематический/дорогой дрейф эскалируется СОБСТВЕННИКУ.
- **Подъём версии регламента** — ЧЕЛОВЕК-владелец (research-контур пишет), фиксация — обязательна.
- **Утверждение нового/изменённого регламента как нормы** — СОБСТВЕННИК (федеративная конституция: общий стандарт утверждается на уровне, который его держит).

#### Зачем / что ломается без него

Без C4 регламент остаётся PDF: написан один раз, расходится с реальностью, никто не знает, соблюдается ли он. Конкретные провалы при отсутствии контура:

- **Нет единого «одинаково».** Каждый сотрудник и каждый агент делают по-своему — слой РЕГЛАМЕНТЫ хребта проваливается, дальше рушится КОНТРОЛЬ (нечего проверять) и УПРАВЛЯЕМОСТЬ (нечем управлять).
- **Агент галлюцинирует к шагу 3.** Узкий агент без явного AOP и чек-листа полноты ползёт за пределы scope, выдумывает шаги, тихо пропускает обязательные пункты. Scope creep убивает агента (Reddit-практика) — AOP жёстко очерчивает границу и список обязательного.
- **Silent failures.** Без drift-detector отклонение факта от нормы невидимо — а тихий сбой хуже ручной работы: его не замечают, пока не прорвёт. Drift-detector + health-checks делают сбой видимым.
- **Норма устаревает молча.** Без версионирования и Decision Memory регламент либо костенеет (его обходят, но он формально «есть»), либо тихо размывается исключениями. Дрейф некуда деть — он либо игнорируется, либо ломает стандарт без следа.
- **Риск ключевого лица и зоопарк.** Без owner-карточек и единого формата регламенты живут в головах и в разрозненных ботах; уход человека уносит норму.

#### По этапам зрелости

- **1 Awareness.** Регламентов как артефактов нет или они в головах/случайных файлах; «как делать» передаётся устно. AI не участвует. SOP не написаны, AOP/drift/версий нет — норма неуправляема и невидима.
- **2 Active.** Кто-то ad hoc просит ChatGPT «напиши регламент» — получается одноразовый текст в чате/Google Docs. Нет единого формата, нет связи с исполнением, нет версий. Регламент = мёртвый PDF, рождённый из LLM.
- **3 Operational (зоопарк).** Появились боты, у некоторых зашита логика «как делать», но регламенты разрознены, дублируются между ботами, расходятся между собой; нет единого SOP↔AOP, нет drift-детекции, версии — в лучшем случае в чьей-то голове. Риск ключевого лица: норма живёт в конкретном боте/человеке. **Это точка, из которой тянем вверх (3→4 — макс. скачок ценности).**
- **4 Systemic (контур).** Единый формат SOP/AOP, каждый регламент версионируется и имеет owner-карточку; чек-листы полноты встроены; drift-detector работает на едином event log слоя D; дрейф разрешается явно (Decision Memory) и питает версии; research writes / delivery reads разведены. Регламент — живой контракт. Федеративно: узлы держат свои SOP суверенно, общие стандарты — на уровне конституции.
- **5 Transformational.** Регламенты самообновляются по сигналам дрейфа (норма подстраивается под доказанно лучший факт через research-контур с человеческой санкцией), AOP — основа AI-native операционки; управляемость как система: новый процесс рождается сразу как версионируемый исполнимый контракт, а не как документ-вдогонку.

#### Как внедряется (SMB без ERP)

1. **Выбрать 1–2 болевых процесса из C2** (узкое место, где «делают по-разному» дороже всего). Не весь бизнес сразу — узкий scope выживает.
2. **Завести формат файла.** Один шаблон `SOP-AOP.md` с фронтматтером (поля из «Сущностей»: id, version, owner, trigger, steps, definition_of_done, autonomy, risk_class, checklist). Положить в репозиторий стандартов (для фермы Дмитрия — естественно лёг бы рядом с `00-CONTEXT` узла: регламент = локальный контракт узла, формат — общий по конституции).
3. **Записать SOP с носителем процесса** (человек диктует, агент структурирует). Зафиксировать definition_of_done и mandatory checklist — что НЕЛЬЗЯ пропустить.
4. **Разметить в AOP**: к каждому шагу — tool, pre/postcondition; владелец проставляет autonomy (по умолчанию L0 и gate human-in-the-loop на всём необратимом и тратах > $0) и risk_class.
5. **Встроить в канал, где люди уже живут** (integration > innovation, friction audit: не плодить новый интерфейс). Агент ведёт/исполняет по AOP, собирает event log фоном — так с нуля порождается след (зазор SMB без event-логов).
6. **Включить чек-лист полноты** на выходе каждого прогона: блокировать передачу дальше, если непокрыт обязательный пункт.
7. **Запустить drift-detector** против event log: сверка факт ↔ действующая версия. Начать с простейшего — «обязательный шаг пропущен / порядок нарушен / SLA превышен».
8. **Поставить версионирование и owner-карточку** на каждый регламент; назначить review_cadence. Развести research (пишет норму) и delivery (читает).
9. **Вывести drift-метрику в дашборд C5** — % соблюдения регламента как actionable-сигнал собственнику.

#### Антипаттерны / грабли

- **Мёртвый PDF.** Написали красивый регламент, положили в папку — он не привязан к исполнению, не версионируется, не сверяется с фактом. Регламент без AOP и drift-детекции мёртв по определению.
- **Чек-лист путают с детерминизмом.** Думают, что mandatory checklist делает разбор детерминированным. Нет: он лечит ТОЛЬКО полноту («LLM пропустил пункт»), но агент всё ещё рассуждает. Детерминизм цифр — это слой D (расчёт ВНЕ LLM), не C4. Смешение оставляет дыру: цифры в регламенте по-прежнему могут выдумываться, если их не вынесли в D.
- **Scope creep в AOP.** Один AOP пытаются сделать «на весь отдел» — агент галлюцинирует к шагу 3. Узкие AOP выживают; широкие убивают агента.
- **Тихий дрейф без разрешения.** Drift-detector есть, но дрейф никто не разбирает — события копятся, их перестают читать (silent failure второго порядка). Каждый дрейф обязан получить решение: чинить факт или чинить норму, с записью в Decision Memory.
- **Delivery правит норму на лету.** Исполнитель в бою меняет регламент под себя без версии и санкции — стандарт размывается без следа, память гниёт. Правило research writes / delivery reads нарушать нельзя.
- **Регламент без владельца.** Нет steward-карточки и review_cadence — регламент устаревает молча, риск ключевого лица возвращается.

#### 🔍 Было → стало (на примере)

> _«Светлый Дом» — мебель на заказ (кухни, шкафы), ~12 человек, без ERP._

**Было (3).** PDF «Стандарт работы с клиентом» висит в общем чате — открыли один раз. По факту предоплату берут «по договорённости»: 0 / 20 / 50 % — кто как договорился. Проекты уходят в цех без денег.

**Стало (4).** Регламент — исполнимый контракт (AOP), проверяемый в runtime, а не PDF. Нарушение ловит drift-детектор.

**Пример записи (правило AOP):**

```
RULE pre-payment:
  статус проекта = «в производство» РАЗРЕШЁН ТОЛЬКО ЕСЛИ
  предоплата.процент ≥ 30
  иначе → блок перехода + уведомить владельца (drift-алерт)
  проверка: при каждой смене статуса проекта
```

#### Связи

- **← C2 Процессы** (вход): C4 берёт реальные процессы и роли как сырьё для SOP. Процесс без регламента — это «делаем», но не «делаем одинаково».
- **← C3 Люди / +A Агенты** (вход): из C3 берётся «кто исполняет» (owner, исполнитель-человек), из +A — карточка-стандарт агента (вход/выход), к которой AOP привязывает tool/autonomy. AOP — это «клей» (zoo L4) в части предписания: что агент обязан сделать.
- **→ D Данные/SSOT** (выход и вход одновременно): C4 *предписывает* действия, исполнение которых порождает event log в D (выход — норма задаёт, какие события должны быть); drift-detector *читает* факт из D (вход — сверка против структурированного store состояния, не против read-only RAG). Граница строгая: C4 хранит норму, D хранит факт; детерминизм расчётов живёт в D, не в C4.
- **→ C5 Контроль + Дашборд** (выход): drift-метрика (% соблюдения, число дрейф-событий, непокрытые обязательные пункты) уходит в дашборд собственнику как actionable-сигнал. C4 даёт C5 предмет контроля — без нормы KPI «соблюдаемости» не существует.
- **↕ Governance (сквозное):** autonomy и risk_class в AOP — это runtime-enforcement governance (не комитеты, а правило, исполняемое в момент действия: human-in-the-loop срабатывает на необратимом). Версионирование + Decision Memory + федеративное утверждение нормы (узел суверенен, общий стандарт — на уровне конституции) — это governance, встроенный прямо в контракт.
- **↔ C1 Карта / L1 База знаний (разграничение):** C4 НЕ описывает, как устроен бизнес (это C1/L1 — описание ≠ норма ≠ данные). C4 хранит предписание «как должно делаться», L1 — «как оно вообще работает», D — «как сделалось фактически». Три разных слоя, которые нельзя сливать.

---

## 🗄️ D · Данные → единый источник правды (SSOT, слой данных)

#### Что это

Контур D — это слой данных организации: единое, машиночитаемое место, где живут *факты* о состоянии бизнеса (а не описание того, как бизнес устроен — описание лежит в L1 базе знаний контура C4/Регламентов, и это принципиально другой слой). Если хребет Дмитрия идёт ПРОЦЕССЫ → ЛЮДИ → РЕГЛАМЕНТЫ → КОНТРОЛЬ → УПРАВЛЯЕМОСТЬ, то контур D — это разнесение СЛОЯ ДЕЙСТВИЙ (что люди делают, живёт в их привычных каналах) и СЛОЯ ДАННЫХ (цифровой след этих действий, который агенты собирают фоном), и сборка этого следа в один источник правды, питающий дашборд собственника (C5). В терминах разведки мира это System of Intelligence (Moore/Greylock) — слой, который надстраивается над System of Record и превращает «digital exhaust» от работы людей в управляемый актив.

Ключевая инженерная установка контура: **SSOT — это НЕ чистый векторный RAG**. RAG read-only, «не знает истины и времени», он годен для *извлечения* из неизменных документов, но не для хранения *состояния*. Истина о том, на какой стадии сделка №412 сегодня и кто за неё отвечает, должна жить в структурированном store состояния (SQL или граф), который агенты **обновляют** транзакционно, а RAG ставится *поверх* для семантического поиска. Перепутать эти две вещи — корневой архитектурный провал контура (см. антипаттерны).

#### Сущности

Конкретные артефакты, которые в этом контуре можно создать и потрогать:

1. **EVENT LOG (журнал событий)** — append-only лента фактов «что произошло». Минимальная схема ван дер Аалста / Celonis: `case_id | activity | timestamp | actor` (+ опц. `payload`, `channel`, `source_agent`). Пример строки: `deal-412 | "выставлен инвойс" | 2026-06-15T14:03Z | agent.invoicer | {amount: 4200, currency: EUR}`. Это основа process mining «регламент vs факт»: по логу видно, как процесс течёт НА САМОМ ДЕЛЕ, а не как написано в AOP. Append-only — события не редактируются, только дописываются.
2. **STATE STORE (хранилище состояния)** — структурированный store ТЕКУЩЕГО состояния предметных сущностей (SQL-таблицы или граф). Не лента, а снимок «как есть сейчас»: `deal-412: stage=invoiced, owner=Артём, amount=4200, updated_at=...`. Агенты его **обновляют** (read-modify-write), это и есть System of Record для SMB, который раньше держал ERP. Каждое обновление параллельно роняет строку в EVENT LOG.
3. **CONTEXT LAYER (контекстный/семантический слой)** — 5 компонентов Atlan: **Semantic/Metrics Layer** (один governed-расчёт каждого KPI, как dbt: «выручка» определена ОДИН раз и считается ВНЕ LLM); **Ontology/Identity** (что такое «клиент», «сделка», единый ID — что Артём и А. Иванов это один actor); **Operational Playbooks** (ссылка на AOP, как трактовать данные); **Lineage** (откуда взялась цифра — от какого события/агента); **Decision Memory** (журнал принятых решений и их обоснований, чтобы агенты и люди не переоткрывали закрытые вопросы).
4. **Предметные сущности (domain entities)** — типизированные карточки объектов бизнеса со стабильными полями: `Сделка` (id, стадия, сумма, владелец, клиент_id), `Клиент` (id, контакты, сегмент, LTV), `Объект`, `Задача` (id, исполнитель, дедлайн, статус), `Инвойс` (id, сделка_id, сумма, оплачен), `Кандидат`. Именно они наполняют STATE STORE; их набор = карта C1, переведённая в данные.
5. **DATA CONTRACTS (контракты данных)** — формальная схема-договор на каждый поток: какие поля обязательны, типы, допустимые значения, владелец потока, что считать «свежим». Пример: контракт на `Инвойс` требует `amount > 0`, `currency ∈ {EUR, UAH}`, `сделка_id` существует в STATE STORE. Агент, пишущий невалидную запись, отбивается контрактом — это runtime-governance, а не комитет.
6. **AI-Ready Data (профиль готовности)** — не отдельный файл, а 4 проверяемых свойства всего слоя: **unified** (один источник, без дублей), **governed** (контракты + lineage), **contextually meaningful** (через CONTEXT LAYER), **continuously refreshed** (свежесть по SLA). Чек-лист, по которому слой признаётся «AI-ready».
7. **RAG-индекс (поверх)** — векторный/гибридный индекс над неизменными документами (договоры, регламенты, переписка) для *извлечения*. Стоит поверх STATE STORE, не вместо него.

#### Механика (что происходит)

1. Человек делает работу как привык — в своём канале (мессенджер, почта, звонок, таблица). Это СЛОЙ ДЕЙСТВИЙ. Он ничего не «вносит в систему» специально.
2. Агент-наблюдатель (из контура A), встроенный в этот канал, **собирает след фоном**: распознаёт, что произошло событие → формирует запись по схеме EVENT LOG и валидирует её против DATA CONTRACT.
3. Валидная запись **дописывается в EVENT LOG** (append-only) и одновременно **обновляет STATE STORE** (агент делает read-modify-write предметной сущности: сделка-412 переходит invoiced). Lineage фиксирует, какое событие/агент породили изменение.
4. CONTEXT LAYER связывает запись с онтологией (резолвит, что «Артём» = actor `human:artem.ivanov`) и с метриками (это событие влияет на KPI «выручка месяца», расчёт которого определён один раз).
5. KPI считаются **детерминированно ВНЕ LLM** по Semantic Layer поверх STATE STORE; LLM цифры не выдумывает, а только их *достаёт и формулирует*.
6. Готовые, governed-данные текут в C5 (дашборд собственника) и обратно в агентов (как контекст для следующих решений). RAG-индекс параллельно даёт семантический доступ к сырым документам.

Итог превращения: разрозненные человеческие действия → валидированные события → актуальное состояние → governed-метрики → управляемость.

#### Кто делает

- **Проектирование схем** (EVENT LOG, предметные сущности, DATA CONTRACTS, онтология) — **ЧЕЛОВЕК** (архитектор данных / интегратор; «методология до инструмента»). Это акт создания истины — его делает человек.
- **Сбор следа из каналов, формирование событий, валидация по контракту, write в EVENT LOG/STATE STORE** — **AI-АГЕНТ** (узкий, по одному каналу/сущности; scope creep его убивает).
- **Резолв идентичности, поддержка lineage, расчёт метрик** — **AI-АГЕНТ** детерминированными правилами + Semantic Layer; LLM не считает.
- **Разрешение противоречий и пробелов данных** (два агента записали разное про сделку-412) — **ЧЕЛОВЕК** (human-in-the-loop); расхождение фиксируется, не перезаписывается тихо.
- **Утверждение определения KPI и онтологии, владение SSOT, доступ к дашборду** — **СОБСТВЕННИК** (или назначенный data-steward; фактор stewardship по MIT CISR). Истину утверждает человек — «AI лишь усилитель».
- **Необратимые операции / траты >$0, инициированные данными** — **ЧЕЛОВЕК** в петле (автономия по риску). Единственное исключение для денег — платежи в жёстком лимите на стадии 5 (см. «Платежи на стадии 5» в контуре +A).

#### Зачем / что ломается без него

Без слоя данных AI-организация невозможна: агенты действуют, но след их и людей работы исчезает (digital exhaust улетает в трубу), и собственник управляет вслепую. Конкретные провалы при отсутствии контура: **(1)** KPI считаются по-разному в разных чатах и таблицах — «выручка» у РОПа одна, у бухгалтера другая, спор о цифрах вместо управления; **(2)** silent failures — агент тихо сломался на шаге 3, никто не заметил, потому что нет состояния и health-check поверх него (а тихий сбой хуже ручной работы); **(3)** риск ключевого лица — данные живут в голове и личных таблицах сотрудника, ушёл человек — ушла история; **(4)** LLM-галлюцинации цифр, когда нет детерминированного расчёта вне модели; **(5)** невозможен process mining «регламент vs факт» — не видно, что AOP нарушается, потому что нет EVENT LOG. По BCG данные — это 20% (тех-слой), но без них не работают и 70% людей-и-процессов, и 10% алгоритмов.

#### По этапам зрелости

- **1 Awareness.** Данных-как-слоя нет. Факты живут в головах, бумажных журналах, разрозненных Excel. «Источник правды» = память владельца. EVENT LOG отсутствует как понятие.
- **2 Active.** Точечный ChatGPT помогает считать/форматировать ad hoc, но результат никуда не пишется системно. По-прежнему нет STATE STORE, нет схем; данные одноразовые, после сессии теряются.
- **3 Operational («зоопарк»).** Появились свои боты, КАЖДЫЙ со своим хранилищем: у бота продаж своя табличка, у бота поддержки своя. Дубли, рассинхрон, у каждого «свой» клиент-412. EVENT LOG если и есть, то у каждого бота свой формат. Это и есть боль, ради которой строят контур: данные есть, но не единые.
- **4 Systemic («контур»).** Единый STATE STORE + общий EVENT LOG с одной схемой; DATA CONTRACTS на потоках; CONTEXT LAYER с governed-метриками (один расчёт KPI); lineage; дашборд собственника питается отсюда. Федеративная конституция: узлы (под-проекты/отделы) суверенны в своих данных, но общие стандарты схем и контрактов обязательны. **Целевое состояние перехода 3→4.**
- **5 Transformational.** SSOT = живой Digital Twin of Organization: на нём можно не только мониторить, но и **симулировать** («что будет с выручкой, если…»), приоритизировать на языке совета директоров. Data-слой самообслуживается, decision memory полная, AI-native операционка.

#### Как внедряется (SMB без ERP)

Ключевая особенность SMB: готового event-лога и ERP нет — **агенты порождают след с нуля**. Шаги:

1. **Карта сущностей из C1.** Выписать 5–8 предметных сущностей, реально живущих в бизнесе (Сделка, Клиент, Задача, Инвойс…) и их ключевые поля. Артефакт: таблица сущностей.
2. **Спроектировать EVENT LOG-схему.** Зафиксировать минимум `case_id + activity + timestamp + actor`. Артефакт: список допустимых `activity` по каждому процессу из C2.
3. **Поднять STATE STORE.** Для SMB — обычная SQL-БД (Postgres/SQLite) или Airtable/Notion-база как старт; таблицы = предметные сущности. Артефакт: схема БД.
4. **Написать DATA CONTRACTS** на каждый поток (обязательные поля, типы, владелец, свежесть). Артефакт: YAML/markdown-контракты.
5. **Встроить агентов-сборщиков в существующие каналы** (friction audit: НЕ плодить новый интерфейс — встроиться туда, где люди уже живут). Каждый агент узкий: один канал → одна сущность. Он порождает событие и обновляет state.
6. **Поднять Semantic Layer** — определить каждый KPI ОДИН раз, расчёт вне LLM. Артефакт: словарь метрик.
7. **Поставить RAG поверх** для документов и **health-checks + дашборд** поверх STATE STORE (silent failures недопустимы).
8. **Назначить data-steward и владельца SSOT** (stewardship). Включить human-in-the-loop на противоречиях и необратимом.

Принцип сборки — снизу вверх, методология до инструмента, «истину создаёт человек».

#### Антипаттерны / грабли

1. **SSOT = чистый векторный RAG.** Состояние засунули в read-only векторную базу — система «не знает истины и времени», агенты не могут обновлять, всё рассыпается. Нужен структурированный store состояния + RAG только поверх.
2. **LLM считает KPI.** Цифры генерит модель, а не детерминированный Semantic Layer → галлюцинации в отчётах собственнику. Расчёт всегда ВНЕ LLM.
3. **Scope creep агента-сборщика.** Один агент пытается собирать след из всех каналов и про все сущности — «галлюцинирует к шагу 3». Узкие агенты выживают, широкие умирают.
4. **Зоопарк хранилищ (застрять на стадии 3).** У каждого бота своя база, нет общих схем/контрактов — дубли и рассинхрон. Лечится DATA CONTRACTS + единым STATE STORE, а не ещё одним ботом.
5. **Память гниёт без обслуживания / тихая перезапись противоречий.** EVENT LOG и decision memory никто не чистит и не разруливает; агент молча затирает чужую запись. Принцип «research writes, delivery reads», расхождения — в явный contradictions-журнал, не тихо.
6. **Новый интерфейс вместо встраивания.** Заставили людей вносить данные в отдельную систему → люди не вносят → след пустой. Integration > innovation: собирать там, где работа уже идёт.

#### 🔍 Было → стало (на примере)

> _«Светлый Дом» — мебель на заказ (кухни, шкафы), ~12 человек, без ERP._

**Было (3).** «Сколько заказов в работе?» — владелец звонит троим: менеджер считает по заявкам, цех по распилам, бухгалтер по оплатам. Три цифры, ни одна не сходится.

**Стало (4).** Единый Event Log (`case_id+activity+timestamp+actor`) + State Store; «заказов в работе» = один governed-запрос к одному источнику.

**Пример записи (строки Event Log → State Store):**

```
SD-2026-0617-007 | замер_проведён       | 2026-06-17T11:40+03:00 | human:Игорь
SD-2026-0617-007 | КП_отправлено        | 2026-06-18T09:12+03:00 | agent:proposal-drafter
SD-2026-0617-007 | предоплата_получена  | 2026-06-19T14:03+03:00 | human:Ольга
→ State Store: проект SD-2026-0617-007 · статус «в производство» · предоплата 40 %
```

#### Связи

- **← C1 (Карта бизнеса):** карта даёт перечень предметных сущностей и процессов — вход для схем STATE STORE и `activity` EVENT LOG.
- **← C2 (Процессы):** определяет допустимые активности и переходы состояний (что считать событием).
- **↔ C4 (Регламенты → AOP):** РАЗВЕДЕНЫ намеренно — C4/L1 хранит *описание* «как должно быть» (знания), D хранит *факты* «как есть» (данные). Стык — process mining: сравнение EVENT LOG (D) с AOP (C4) даёт drift-detection «регламент vs факт».
- **↔ +A (Агенты):** агенты — *писатели* в слой данных (порождают след, обновляют state) и *читатели* (берут state как контекст). D — их общая память и рабочее поле.
- **→ C5 (Контроль + Дашборд):** governed-метрики Semantic Layer и состояние STATE STORE — прямой вход дашборда собственника; health-checks поверх состояния ловят silent failures.
- **↔ Governance (сквозное):** DATA CONTRACTS + lineage + ownership SSOT — это runtime-enforcement governance (не комитеты), реализованный именно в слое данных.
- **Оговорка Минцберга:** STATE STORE/KPI режут невидимую ценность — рядом с метриками держать чек-лист слепых зон, помнить, что организация ещё и сообщество, а не только то, что попало в EVENT LOG.

---

## 📊 C5 · Контроль + Дашборд собственнику

#### Что это

C5 — это контур, который превращает цифровой след всех нижних контуров (процессы C2, регламенты-AOP C4, SSOT-данные D) в одну управленческую поверхность собственника: набор **governed-определений** «что считать правдой» + **actionable-вид** «что делать сегодня». В хребте Дмитрия это слой КОНТРОЛЬ (KPI / проверка / отчётность), но в AI-версии он не отчётный, а исполнительный: не «вот цифры за месяц», а «вот три вещи, которые горят, и решение по ним за тобой». На витрину это выходит как «Командный центр собственника» (Owner Cockpit — язык собственника/совета: приоритизировать, мониторить, симулировать), технически — как System of Intelligence (Moore/Greylock) поверх System of Record: слой, который читает digital exhaust людей и агентов и сводит его в состояние, по которому принимают решения.

Ключевое отличие от классической BI-отчётности: C5 живёт на детерминизме (расчёт KPI ВНЕ LLM — LLM не выдумывает цифры, только формулирует, что они значат) и на обратной петле — каждое «горит» в дашборде должно иметь адрес возврата в C2 (сломанный процесс) или C4 (нарушенный регламент-AOP), иначе это просто красивый светофор, на который никто не жмёт.

#### Сущности

Конкретные объекты, которые создаются и существуют в этом контуре:

1. **`metrics.yml` (Semantic / Metrics layer, governed).** Один файл-источник определений KPI — паттерн dbt-метрик. Поля на метрику: `name`, `description`, `formula` (SQL-выражение над SSOT), `grain` (по дню/неделе/клиенту), `filters`, `owner` (человек), `source_tables`, `refresh`. Пример: `revenue = SUM(orders.amount) WHERE orders.status='paid' AND orders.is_test=false`. Смысл: ОДИН governed-расчёт revenue/orders, а не 5 версий в пяти отчётах. «Сколько у нас заказов» имеет ровно один ответ.
2. **Карточка KPI (KPI card / definition).** Документ на каждую метрику: что меряем, формула простым языком, целевое значение (target/threshold), кто owner, **чек-лист слепых зон** (Минцберг — см. ниже), частота обновления, источник данных. Существует как `.md` в реестре метрик рядом с `metrics.yml`.
3. **Плитки дашборда (tiles).** Визуальные единицы поверхности. Каждая плитка = одна метрика из `metrics.yml` + состояние (норма / внимание / тревога), дельта к периоду, спарклайн, ссылка-drill в SSOT. Плитка НИКОГДА не считает сама — только рендерит governed-число.
4. **Вид «ЧТО ДЕЛАТЬ СЕГОДНЯ» (action queue).** Главный экран. Не графики, а очередь записей четырёх типов: 🔥 **горит** (порог пробит), ⏳ **решение не принято** (висит человек-in-the-loop по необратимому/тратам), 💰 **должны деньги** (просрочка дебиторки/незакрытый счёт), 🔧 **сломанный процесс** (variance из process mining). Запись = `{тип, объект, с какого момента, к кому привязано, кнопка-действие}`.
5. **Health-checks (контракты живости).** Набор проверок против silent failures — не «упал ли агент», а «течёт ли след». Каждый check = `{что проверяем, ожидание, период, severity}`. Примеры: «event log пополнялся за последние 24ч», «у >95% заказов проставлен статус», «агент-сборщик C4 писал в SSOT сегодня», «нет дубль-определения revenue». Health-check ловит немой отказ — когда система «работает», но данные молча перестали приходить.
6. **Alerts (правила тревог).** `{metric/health-check, условие, канал, адресат, severity, что делать}`. Срабатывают на пробой порога ИЛИ провал health-check. Падают в канал, где человек уже живёт (Telegram/почта), а не в отдельную панель, куда надо заходить.
7. **Event Log (журнал событий) + variance-отчёт (Process Mining).** Минимальная схема лога: `case_id · activity · timestamp · actor` (van der Aalst/Celonis). Variance-отчёт = сравнение «регламент/AOP (C4) vs факт (лог)»: где реальный путь кейса отклонился от заданного, как часто, сколько это стоит. Существует как таблица отклонений с привязкой к конкретному AOP.
8. **Decision Memory (журнал решений собственника).** Лог `{дата, что горело, какое решение принял собственник, почему, исход}`. Накапливает контекст: почему в марте отключили этот процесс. Это компонент Context Layer (Atlan) и страховка от повтора ошибок.

#### Механика (что происходит)

Поток данных и работы через контур, по шагам:

1. **Сбор следа (фон).** Люди делают работу как привыкли (слой действий, C2/C3); агенты C4 фоном пишут цифровой след в Event Log и обновляют состояние в SSOT (слой данных, D). C5 ничего не собирает руками — он подписан на SSOT.
2. **Детерминированный расчёт.** Движок метрик берёт `metrics.yml` и считает KPI прямо над SSOT (SQL/граф), ВНЕ LLM. Результат — числа с одним governed-определением. LLM сюда не пускают считать — только объяснять.
3. **Оценка состояния.** Каждое число сверяется с target/threshold карточки KPI → плитка получает цвет. Параллельно прогоняются health-checks: течёт ли след вообще.
4. **Process mining.** По Event Log строится фактический граф процесса и сравнивается с AOP из C4 → variance. Большой variance = «сломанный процесс».
5. **Сборка очереди действий.** Из пробитых порогов, проваленных health-checks, висящих human-in-the-loop решений, просрочек по деньгам и variance собирается вид «ЧТО ДЕЛАТЬ СЕГОДНЯ». LLM здесь работает усилителем: формулирует каждую запись человеческим языком («дебиторка по клиенту X висит 14 дней, обычный цикл — 5») — но цифры берёт готовые, не выдумывает.
6. **Доставка и решение.** Срочное уходит alert'ом в живой канал. Собственник открывает очередь, по необратимым/денежным пунктам принимает решение → запись в Decision Memory.
7. **Обратная петля.** Решение/диагноз возвращается вниз: «сломанный процесс» → тикет на правку C2 или AOP C4; «немой отказ агента» → правка карточки агента C4; новое «что меряем» → новая запись в `metrics.yml`. Контур замыкается.

#### Кто делает

- **Определить, что вообще считать управляемостью (какие KPI, что значит «горит»):** СОБСТВЕННИК (его язык целей) + ЧЕЛОВЕК-архитектор формализует. Истину создаёт человек.
- **Написать и держать `metrics.yml` / карточки KPI / чек-листы слепых зон:** ЧЕЛОВЕК (data/ops-инженер, owner метрики). Governed-слой нельзя отдавать LLM на самосочинение.
- **Считать числа (детерминированный движок):** КОД (SQL/движок метрик), не AI-агент и не человек руками.
- **Собирать след в Event Log / обновлять состояние SSOT:** AI-АГЕНТЫ C4 (фоном, пока люди работают).
- **Прогонять health-checks и process-mining, формировать черновик очереди «что делать сегодня», писать человекочитаемые формулировки:** AI-АГЕНТ (детерминированный расчёт + LLM-объяснение поверх).
- **Принимать решения по 🔥/💰/необратимому (human-in-the-loop):** СОБСТВЕННИК. Автономия по риску — необратимое и траты > $0 не отдаются агенту. Единственное исключение для денег — платежи в жёстком лимите на стадии 5 (см. «Платежи на стадии 5» в контуре +A).
- **Замыкать петлю (превратить диагноз в правку C2/C4):** ЧЕЛОВЕК-владелец процесса; агент может предложить, но правку регламента подтверждает человек.

#### Зачем / что ломается без него

Без C5 нижние контуры работают «вслепую»: агенты собирают след, SSOT наполняется — но собственник этого не видит и продолжает управлять по ощущениям и устным докладам. Конкретные провалы при отсутствии:

- **Silent failures дороже ручного труда.** Агент молча перестал писать в SSOT, статусы не проставляются — а дашборда нет, значит никто не замечает неделями. По практике (Reddit) немой отказ хуже честного ручного процесса: ты думаешь, что система работает, а она врёт. Health-checks — единственный механизм, который это ловит.
- **Пять версий правды.** Без `metrics.yml` каждый отчёт считает revenue по-своему; на совещании три цифры выручки, спор о цифрах вместо решений. Governed metrics layer убирает спор.
- **Отчётность вместо управления.** Без вида «что делать сегодня» дашборд превращается в красивые графики, на которые смотрят раз в месяц. Боль: данные есть, действий нет — провал ценности, тот самый разрыв «зоопарк → контур».
- **Невидимая дебиторка и зависшие решения.** «Должны деньги» и «решение не принято» без очереди просто теряются — деньги висят, необратимые шаги делаются агентом без санкции.
- **Регламент мёртв.** Без process mining AOP из C4 остаётся декларацией: написано одно, делается другое, и никто не меряет зазор.

#### По этапам зрелости

- **1 Awareness:** контроля как контура нет. KPI — в голове собственника, «отчётность» = устные доклады и таблица в Excel, которую кто-то ведёт руками. Цифры расходятся, проверка реактивная (узнали, когда уже сломалось).
- **2 Active:** точечный ChatGPT помогает свести отчёт ad hoc («сделай мне сводку из этой выгрузки»), но определения KPI не зафиксированы, дашборда нет, всё пересобирается заново каждый раз. След не собирается системно.
- **3 Operational («зоопарк»):** появились свои боты и дашборды, но их несколько и они считают по-разному — у отдела продаж своя выручка, у финансов своя. Дубли определений, риск ключевого лица (метрику знает один человек), нет health-checks → silent failures проходят незамеченными. Это «отчётность есть, управляемости нет».
- **4 Systemic («контур»):** один `metrics.yml` (governed), единый actionable-дашборд поверх SSOT, вид «что делать сегодня», работающие health-checks и alerts, process mining против AOP, обратная петля на C2/C4. KPI имеют owner'ов и чек-листы слепых зон. Это целевая стадия (скачок 3→4 — максимум ценности по MIT).
- **5 Transformational:** контроль становится системой — симуляция («что будет, если отключить процесс X»), Decision Memory как актив, метрики самообслуживаются и пересобираются под новые вопросы; собственник управляет состоянием, а не собирает его. AI-native операционка.

#### Как внедряется (SMB без ERP)

Порядок шагов и артефакты с нуля:

1. **Спроси собственника 5–7 вопросов «по чему ты реально управляешь».** Зафиксируй язык целей (язык командного центра). Выход: черновой список из 5–8 KPI — не больше. System-first: меряем то, чем управляем, не всё подряд.
2. **Заведи реестр метрик: `metrics.yml` + карточка на каждый KPI.** Один governed-расчёт на метрику. Это самый дорогой и самый важный артефакт — делается руками человека.
3. **Реши, откуда брётся след.** В SMB без ERP лога нет — агенты C4 ПОРОЖДАЮТ его с нуля: задай минимальную схему Event Log `case_id · activity · timestamp · actor` и навесь на агентов запись событий фоном, пока люди работают как привыкли.
4. **Поставь детерминированный расчёт над SSOT** (даже если SSOT — это SQLite/Google Sheets + структурированный store состояния; RAG только поверх для извлечения, НЕ как источник цифр).
5. **Собери минимальный дашборд: сначала вид «ЧТО ДЕЛАТЬ СЕГОДНЯ», потом плитки.** Начни с очереди действий, графики — потом. Actionable раньше красивого.
6. **Включи health-checks с первого дня** — хотя бы три: «след пополнялся», «статусы проставлены», «нет дубль-определения». Silent failure ловится только так.
7. **Настрой alerts в канал, где люди уже живут** (Telegram/почта). Friction audit: не плодить новую панель, встроить в существующий канал.
8. **Добавь process mining, когда есть хотя бы один AOP в C4** — variance-отчёт «план vs факт».
9. **Заведи Decision Memory** — простой лог решений собственника. Дёшево, окупается контекстом.
10. **Под каждый KPI — чек-лист слепых зон** (Минцберг). Например, к «среднему чеку» — приписка: «не отражает лояльность и сарафан; рост чека за счёт ухода мелких клиентов — красный флаг, не победа».

**Антипаттерны / грабли.**

- **Дашборд как отчётность, а не как действие.** Делают красивые графики, открывают раз в месяц — управляемости ноль. Лечится приоритетом вида «что делать сегодня».
- **KPI считаются внутри LLM.** Просят агента «посчитай выручку» — он галлюцинирует к третьему шагу. Цифры — детерминированно, вне LLM; LLM только объясняет.
- **Нет health-checks → silent failures.** Самая дорогая грабля: система «работает», но след молча иссяк, и решения принимаются по протухшим данным. Хуже честного ручного процесса.
- **Пять версий KPI без semantic layer.** Каждый отчёт со своей формулой revenue → споры о цифрах вместо решений.
- **Метрики вытесняют невидимую ценность (Минцберг).** Метрический контроль начинает душить неизмеримое — отношения, доверие, качество. «Твёрдые данные режут невидимую ценность»: без чек-листа слепых зон под каждым KPI дашборд оптимизирует то, что меряется, и убивает то, что нет. Дивизионализация по метрике ≠ управляемость.
- **Дашборд без обратной петли.** «Горит» загорается, но нет адреса возврата в C2/C4 — диагноз есть, правки нет, лампочка горит вечно.

#### 🔍 Было → стало (на примере)

> _«Светлый Дом» — мебель на заказ (кухни, шкафы), ~12 человек, без ERP._

**Было (3).** Владелец заходит в цех, спрашивает «что по заказам?» — слышит «вроде нормально». О просрочке монтажа узнаёт от злого клиента по телефону.

**Стало (4).** Один экран с плитками-действиями («что делать сегодня») и план vs факт по сроку цикла.

**Пример записи (плитки дашборда):**

```
🔴 SD-...-007: предоплата 19.06, в цех не передан 2 дня — handoff завис → [открыть]
🟡 3 КП отправлены >5 дней назад без ответа — нужен follow-up
🟢 Монтаж SD-...-003 завтра 10:00 — бригада подтверждена
Метрика: срок цикла замер→монтаж — план 21 дн / факт 27 дн
         (где теряем: согласование дизайна +6 дн)
```

#### Связи

- **← D (Данные → SSOT):** вход. C5 не хранит данные, он читает governed-состояние из SSOT и Event Log. SSOT — структурированный store, который агенты обновляют (не read-only RAG).
- **← C4 (Регламенты → AOP):** вход двойной. Агенты C4 поставляют цифровой след; AOP'ы C4 — это «план», с которым process mining сравнивает «факт». **→ C4 обратная петля:** немой отказ агента или drift → правка карточки агента / AOP.
- **← C2 (Процессы):** вход — фактический ход кейсов в логе. **→ C2 обратная петля:** «сломанный процесс» (variance) → тикет на правку процесса.
- **↔ C3 (Люди):** owner'ы метрик — из C3; человек-in-the-loop по решениям — оттуда же.
- **↔ Governance (сквозное):** C5 — место runtime-enforcement, а не комитетов: governed `metrics.yml`, health-checks и автономия-по-риску (human-in-the-loop на необратимом/тратах) — это и есть governance в действии.
- **→ СОБСТВЕННИК:** выход контура и всей модели — командный центр собственника «приоритизировать / мониторить / симулировать». C5 — последний контур, ради которого собирались все нижние.


---

## 🏛️ Сквозное · Правила и контроль (Governance) / Зрелость / Конституция

#### Что это

Это не отдельный контур рядом с остальными, а сквозной слой, который держит все контуры (C1 Карта → C2 Процессы → C3 Люди → D Данные/SSOT → +A Агенты → C4 Регламенты/AOP → C5 Контроль/Дашборд) под единым набором правил. Правила и контроль (governance) отвечают на вопрос «по каким законам живут все узлы фермы», и закрывает он его не комитетами и не PDF-политиками, а через runtime-enforcement — правила вшиты в слой данных и дашборда, нарушение либо физически невозможно, либо мгновенно подсвечено. В хребте Дмитрия это слой УПРАВЛЯЕМОСТИ: то, что превращает набор работающих процессов, людей и агентов в управляемую систему, а не в «зоопарк», где каждый узел живёт по своим правилам.

Роль контура — федеративная конституция: узлы (отделы, процессы, локальные базы знаний 00-CONTEXT, агенты) суверенны в своей внутренней механике, но обязаны соблюдать общий минимум стандартов входа/выхода, чтобы данные каждого узла сшивались в его единый SSOT, а метрики узлов — в общий дашборд собственника (один узел — один SSOT; что остаётся общим у нескольких узлов — Приложение D.6). Это прямой перенос операционного кодекса Дмитрия (проекты суверенны + кодекс = конституция, 00-CONTEXT = локальная база узла) на уровень всей компании. Governance — это то, что делает скачок 3→4 (зоопарк → контур) необратимым: без него стандарты декларируются, но не держатся, и система сползает обратно в зоопарк.

#### Сущности

Конкретные артефакты, которые создаются и живут в этом контуре:

1. **КОНСТИТУЦИЯ (`governance/CONSTITUTION.md`)** — корневой документ Governance: 7 законов, обязательных для всех узлов, и короткий блок принципов. Поля каждого закона: `id`, `правило`, `обоснование`, `как проверяется (runtime)`, `владелец`. Закон — только то, что проверяется исполнением; что исполнением проверить нельзя — принцип. Семь законов (полный шаблон с проверками — Приложение A.4):
   - *1 · Единый case_id* — любое событие и запись несут номер дела из реестра своего узла; клиент — из общего справочника клиентов.
   - *2 · История только дописывается* — Event Log не правят и не удаляют; исправление = новое событие.
   - *3 · Автономия по риску* — необратимое и деньги идут через человека; единственное исключение для денег — стадия 5 и только в жёстком лимите (см. «Платежи на стадии 5» в контуре +A).
   - *4 · Детерминизм* — расчёт KPI/денег ВНЕ LLM (SQL/metrics layer), LLM не выдумывает цифры и не «знает истину и время».
   - *5 · Данные ≠ знания* — знания (описание, как работает) живут отдельно от данных (фактов); агент читает знания → пишет факты, не смешивает.
   - *6 · Data contract* — у каждого потока данных есть контракт (см. ниже).
   - *7 · У каждого агента владелец и health-check* — нет владельца или проверки «жив» → агент не активируется.
   - *Принципы (для людей; исполнением не проверяются, в законы не входят):* **стандарт входа и выхода** — у каждого агента и процесса формализованы вход и выход (карточка-стандарт); **инструкция на сбой (runbook)** — у каждого критического процесса есть исполняемая инструкция «что делать при сбое»; **истину создаёт человек, AI — усилитель** — приоритет вовлечения снизу над приказом сверху.

2. **DATA CONTRACT (`contracts/<поток>.yaml`)** — машиночитаемый контракт на каждый поток в SSOT. Поля: `источник` (какой агент/узел пишет), `схема` (имена и типы полей, обязателен минимум `case_id` + `activity` + `timestamp` + `actor` — формат event log для process mining), `частота обновления`, `владелец-steward`, `правила валидации` (что отвергается на входе), `потребители` (кто читает: дашборд, другой агент). Пример строки схемы: `lead_id:uuid · stage:enum(new|qualified|won|lost) · ts:datetime · actor:human|agent_id`.

3. **РЕЕСТР УЗЛОВ И АГЕНТОВ (`governance/registry.csv`)** — сводная таблица суверенных узлов и агентов. Источник правды по агентам и регламентам — файлы-карточки `registry/agents/<id>.yaml` и `registry/aops/<aop_id>.yaml`; таблица — сводка по ним плюс узлы-отделы и процессы. Колонки: `узел`, `тип (отдел|процесс|агент)`, `владелец`, `вход`, `выход`, `статус (active|deprecated)`, `соответствие конституции (✓/✗ по каждому закону)`, `bus-factor`. Это карта федерации: кто чему подчиняется, кто что нарушает.

4. **ПОЛИТИКА АВТОНОМИИ-ПО-РИСКУ (`autonomy-policy.md` + таблица матрицы)** — матрица «действие × уровень автономии». Строки — классы действий (читает данные / черновик / отправка наружу / трата денег / необратимое), столбцы — `авто` (ступени L2–L3), `подтверждение человеком` (L0–L1 с gate), `запрещено агенту` (действие закрыто для агента на любой ступени). Правило-якорь: всё необратимое и любые траты > $0 → human-in-the-loop; обратимое и внутреннее → авто.

5. **HEALTH-CHECK / DRIFT-ПАНЕЛЬ** — набор автоматических проверок поверх SSOT, ловящих silent failures (молчаливые сбои хуже ручной работы): «агент X не писал в SSOT N часов», «дрейф AOP: факт разошёлся с регламентом» (process mining: регламент vs Event Log), «контракт нарушен: поле приходит пустым», «память узла гниёт: последняя запись 30 дней назад». Это runtime-enforcement в чистом виде — контроль живёт в дашборде, а не в совещании.

6. **STEWARDSHIP-ПЛАН ПЕРЕХОДА 3→4 (`migration-3to4.md`)** — именованный документ владения миграцией из зоопарка в контур. Поля: `steward` (конкретный человек, владелец перехода), `инвентарь зоопарка` (список разрозненных ботов и дублей), `карта схлопывания` (что во что сводится), `этапы`, `критерий готовности узла к SSOT`, `% бюджета на change-management (≥20)`. Фактор stewardship — по MIT CISR именно он отличает зрелость, доказанную деньгами, от пилота-витрины.

7. **РЕЕСТР ПРОТИВОРЕЧИЙ (`contradictions/`)** — место, куда явно пишутся расхождения между узлами (один отдел считает KPI так, другой иначе; регламент говорит одно, факт показывает другое), вместо тихой перезаписи. Каждое противоречие — отдельный файл с двумя позициями и статусом разрешения.

8. **ЧЕК-ЛИСТ СЛЕПЫХ ЗОН ПОД KPI (Минцберг-оговорка)** — список того, что метрики не видят («твёрдые данные режут невидимую ценность»): лояльность, репутация, неформальные связи, обучение. Висит рядом с дашбордом как противовес.

#### Механика (что происходит)

Поток работы и данных через контур:

1. *Принятие закона.* Собственник + steward формулируют закон конституции → каждый закон получает поле «как проверяется (runtime)». Закон без runtime-проверки не считается принятым (иначе он PDF, а не конституция).
2. *Регистрация узла.* Новый узел/агент попадает в `registry` только с заполненными вход/выход и привязанным data contract. Нет контракта → нет права писать в SSOT.
3. *Валидация на входе.* Когда агент пишет в SSOT, контракт валидирует данные (схема, типы, обязательные поля event log). Нарушение → запись отвергается и подсвечивается в health-панели, а не молча портит SSOT.
4. *Enforcement в рантайме.* Перед необратимым действием или тратой агент сверяется с autonomy-policy → если класс действия требует человека, ставит на паузу и эскалирует (human-in-the-loop). Контроль происходит в момент действия, не на ретро-комитете.
5. *Детекция дрейфа.* Process mining непрерывно сравнивает Event Log (факт) с AOP (регламент). Расхождение → drift-алерт: либо чинят процесс, либо обновляют живой AOP (регламент = живой AOP, не застывший PDF).
6. *Разрешение противоречий.* Конфликт расчёта/трактовки → запись в `contradictions/`, не тихая перезапись → steward разводит позиции → решение возвращается в конституцию или metrics layer как governed-определение.
7. *Миграция 3→4.* Steward по `migration-3to4.md` инвентаризирует зоопарк, схлопывает дубли, подводит каждый узел под контракт и SSOT; ≥20% усилий идёт в change-management (Deloitte), потому что 70% успеха — люди и процессы (BCG 10-20-70), а не алгоритмы.

#### Кто делает

| Задача контура | Человек | AI-агент | Собственник |
|---|---|---|---|
| Формулировка законов конституции | steward готовит проект | — | утверждает, владеет смыслом |
| Заведение data contract на поток | data-steward узла пишет | агент-валидатор проверяет на лету | — |
| Регистрация узла/агента в реестре | владелец узла заполняет вход/выход | — | визирует соответствие |
| Runtime-валидация записей в SSOT | — | агент-валидатор (детерминированно) | — |
| Health-check / drift-детекция | реагирует на алерт | агент мониторит фоном | смотрит сводку на дашборде |
| Решение по эскалации (автономия-по-риску) | оператор подтверждает/отклоняет | агент ставит на паузу, эскалирует | задаёт пороги политики |
| Разрешение противоречий | steward разводит позиции | агент фиксирует расхождение | арбитр при тупике |
| Stewardship миграции 3→4 | steward — единый владелец перехода | агенты переносят/нормализуют данные | финансирует, защищает приоритет |
| Чек-лист слепых зон | руководители заполняют | — | держит как баланс KPI |

Принцип распределения: детерминированную проверку и сбор следа делает агент (фоном); смысловые решения, арбитраж и владение — человек/steward; пороги, законы и приоритеты — собственник. Это операционализирует «70% людей»: человек работает как привык, агент собирает след и сторожит правила в фоне.

#### Зачем / что ломается без него

Governance — это то, что превращает «много работающих ботов» в управляемую систему. Без него:

- *Зоопарк не схлопывается.* Стандарты декларируют, но не держат → дубли ботов, у каждого свой формат, данные не сшиваются в SSOT, дашборд собирать не из чего. Система застревает на стадии 3 навсегда.
- *Silent failures.* Агент тихо перестал писать или пишет мусор — никто не замечает, решения принимаются по гнилым данным. Молчаливый сбой хуже ручной работы, потому что ему доверяют.
- *Scope creep и галлюцинации цифр.* Без закона детерминизма LLM начинает «считать» KPI и выдумывать числа («галлюцинирует к шагу 3»); собственник принимает решения по вымышленным метрикам.
- *Риск ключевого лица и гниль памяти.* Без реестра и stewardship знание о том, как работает узел, держится в голове одного человека; память узлов гниёт без обслуживания.
- *Приказ сверху отторгается.* Без вовлечения снизу (Минцберг) конституция воспринимается как навязанная бюрократия, узлы саботируют → формальное соответствие, фактический зоопарк.
- *Необратимый ущерб.* Без автономии-по-риску агент однажды потратит деньги или отправит наружу то, что нельзя отозвать.

Это и есть антидот к статистике провалов: 95% пилотов (MIT) / 80% (RAND) горят потому, что AI лепят AI-first поверх неуправляемого хаоса. System-first governance — выстроить управляемость, и только потом надстроить AI — снимает этот провал.

#### По этапам зрелости

- **1 Awareness.** Конституции нет. Правила — устные и противоречивые. «Governance» = собственник в голове держит, как «должно быть». Стандартов входа/выхода нет, данных нет. Контроль = ручная проверка по факту скандала.
- **2 Active.** ChatGPT применяют точечно и ad hoc; правил для его использования нет (кто что куда копирует — никто не знает). Появляется смутное ощущение «надо договориться о стандартах», но артефакта нет. Enforcement отсутствует.
- **3 Operational (зоопарк).** Есть свои боты, но каждый по своим правилам: дубли, расходящиеся форматы, риск ключевого лица. Может существовать пара локальных регламентов (PDF), но они мертвы и расходятся с фактом. Нет конституции, нет контрактов, нет реестра. Боль максимальна — отсюда максимальный скачок ценности при переходе 3→4 (MIT).
- **4 Systemic (контур).** Есть `CONSTITUTION.md` с runtime-проверками, data contracts на потоки, единый реестр узлов/агентов, health/drift-панель, политика автономии-по-риску, единый SSOT в каждом узле и общий дашборд. Узлы суверенны, но соблюдают общий минимум — федеративная конституция работает. Steward провёл миграцию. Governance = runtime-enforcement, не комитеты.
- **5 Transformational.** Управляемость существует как система: конституция самоподдерживается (новые узлы заводятся уже compliant by design), drift чинится автоматически, AOP живые, автономия откалибрована по риску динамически. Это AI-native операционка — компания управляется из командного центра собственника, где можно «приоритизировать, мониторить, симулировать».

#### Как внедряется (SMB без ERP, с нуля)

1. **Написать конституцию на 1 страницу.** 5–7 законов из брифа (данные≠знания, детерминизм, стандарт вход/выход, data contract, runbook, автономия-по-риску, истину создаёт человек). У каждого закона — поле «как проверяется». Без ERP это просто `CONSTITUTION.md` в репозитории/Notion. Артефакт: `CONSTITUTION.md`.
2. **Завести реестр узлов в одной таблице.** Перечислить отделы/процессы/ботов, у каждого — владелец, вход, выход, bus-factor. Это карта федерации. Артефакт: `registry.csv`.
3. **Определить SSOT как структурированный store состояния, не RAG.** RED FLAG: не строить SSOT чистым векторным RAG (read-only, «не знает истины и времени»). Нужен структурированный store (SQL/Airtable/Google Sheets для SMB), который агенты ОБНОВЛЯЮТ, + RAG поверх для извлечения знаний (L1). Артефакт: SSOT-таблица с минимальной схемой event log (`case_id+activity+timestamp+actor`).
4. **Написать по одному data contract на 2–3 ключевых потока.** Начать с того, что уже считают руками (лиды, заявки, отгрузки). Артефакт: `contracts/*.yml`.
5. **Поскольку event-логов нет — агенты порождают след с нуля.** Уникальность SMB: человек работает как привык (в своём канале), агент встроен в этот канал (integration > innovation, friction audit — не плодить интерфейсы) и фоном пишет цифровой след в SSOT. Артефакт: «клей»-агент L4 (читает L1 → пишет L3).
6. **Поставить health-checks и автономию-по-риску.** Простейшие проверки «давно не писал / пусто / трата>$0 = стоп и спроси». Артефакт: health-панель + `autonomy-policy.md`.
7. **Назначить steward перехода 3→4 и заложить ≥20% усилий в change-management.** Один человек владеет миграцией; вовлечение снизу, не приказ сверху (Минцберг). Артефакт: `migration-3to4.md`.
8. **Свести один дашборд собственнику** поверх SSOT с governed-расчётом KPI (один metrics layer, один способ считать каждую метрику). Артефакт: дашборд C5.

#### Антипаттерны / грабли

1. **Governance как комитет, а не рантайм.** Создают «комитет по AI» и политики-PDF → правила не исполняются, зоопарк продолжается. Лекарство: enforcement в слое данных/дашборда (валидация на входе, drift-алерты), а не на совещаниях.
2. **Унитарное принуждение вместо федерации.** Центр диктует узлам всё до мелочей → отторжение, саботаж, формальное соответствие. Дивизионализация ≠ децентрализация: метрический контроль вытесняет неизмеримые цели (Минцберг). Лекарство: суверенитет узлов + только общий минимум стандартов, вовлечение снизу.
3. **SSOT как векторный RAG.** Складывают состояние бизнеса в read-only векторную базу → она «не знает истины и времени», агенты не могут обновлять факты. Лекарство: структурированный store состояния (SQL/граф/таблица), RAG только поверх для знаний.
4. **LLM считает деньги.** Доверяют расчёт KPI/финансов языковой модели → галлюцинации цифр, решения по вымышленным числам. Лекарство: закон детерминизма — расчёт в metrics layer вне LLM.
5. **Конституция спущена приказом сверху без stewardship.** Собственник издаёт «указ», никто не владеет миграцией, change-management не финансируется → буксует, скатывается обратно в зоопарк. Лекарство: именованный steward, ≥20% бюджета на change-management, вовлечение снизу.
6. **Стандарты есть, health-checks нет.** Контракты написаны, но никто не следит за их соблюдением в рантайме → silent failures накапливаются. Лекарство: drift/health-панель с первого дня.

#### 🔍 Было → стало (на примере)

> _«Светлый Дом» — мебель на заказ (кухни, шкафы), ~12 человек, без ERP._

**Было (3).** Две крайности: либо «агентам ничего не доверяем, всё руками» (тогда зачем агенты), либо «бот сам пишет и обещает клиентам» без рамок (репутационный риск). Кто что может делать необратимого — нигде не зафиксировано.

**Стало (4).** Конституция инвариантов + автономия-по-риску: обратимое агент делает сам, необратимое — через gate человека; все действия агентов в append-only логе.

**Пример записи (строка CONSTITUTION):**

```
L3 · Автономия по риску:
  action = «собрать заявку в реестр»   → risk: низкий  → агент автономно
  action = «отправить договор клиенту»  → risk: высокий → подтверждает человек
  action = «вернуть предоплату»         → risk: высокий → подтверждает владелец
  инвариант: каждое действие агента пишется в Event Log (append-only)
```

#### Связи

- **← C1 Карта бизнеса (фундамент).** Карта даёт список узлов и границ → конституция и реестр строятся поверх неё. Вход: карта узлов. Выход: правила, которым эти узлы подчиняются.
- **↔ C4 Регламенты → AOP.** Закон конституции «регламент = живой AOP» делает регламенты исполняемыми; process mining питает drift-детекцию (регламент vs факт по Event Log). Вход: AOP. Выход: drift-алерты, обновлённые AOP.
- **↔ D Данные → SSOT.** Главная стыковка: data contracts и закон «данные≠знания/детерминизм» определяют, что и как попадает в SSOT; SSOT — это место, где governance физически исполняется. Вход: схема и состояние SSOT. Выход: валидация на входе, отвергнутые/принятые записи.
- **↔ +A Агенты.** Карточка-стандарт агента (L2, вход/выход), политика автономии-по-риску и реестр — это governance над агентами. Вход: регистрация агента. Выход: разрешённый класс действий, эскалации.
- **→ C5 Контроль + Дашборд.** Health/drift-панель и чек-лист слепых зон выводятся на дашборд собственнику; metrics layer обеспечивает один governed-расчёт KPI. Вход: события и нарушения. Выход: actionable-дашборд, сводка соответствия.
- **↔ C3 Люди.** Stewardship, вовлечение снизу, change-management (≥20%) — governance человеческого слоя; чек-лист слепых зон балансирует KPI неизмеримой ценностью. Вход: владельцы узлов и steward. Выход: распределение ролей и автономии.

## 🛠️ Генератор внедрения

Контуры — не теория, а **станок**: каждый раздел детерминированно порождает 3 артефакта внедрения.

1. **ПЛАН** — собирается обходом контуров **снизу вверх** (C1 Карта → C2 Процессы → C3 Люди → D-минимум (журнал событий и состояние) → +A первые агенты (сборщик, черновик) → C4 Регламенты → +A агент-сверщик → C5 Контроль; правила Governance — сквозь все шаги): нельзя строить роли без процессов, агентов без ролей и без журнала, куда им писать, сверщика без регламента, дашборд без данных. Это единственный канонический порядок построения; разделы документа идут в логике слоёв, а не в порядке работ.
2. **ЧЕК-ЛИСТ готовности** — да/нет по каждому слою: блок «Как внедряется» каждого раздела → пункты приёмки. Пример инвариантов: *Карта помещается на экран и читается за 15 мин? · На каждый шаг ровно один A (RACI)? · У каждого агента есть owner+runbook+health? · KPI считается ВНЕ LLM? · SSOT — store состояния, не read-only RAG?*
3. **ВОПРОСЫ для подготовки** — извлекаются из «Сущностей» и «Антипаттернов»: каждая обязательная сущность → вопрос собственнику до старта.

**Сквозной пример (контур D · Данные), один проход вопрос→чек→шаг:**

- **Вопрос:** «Что в вашем бизнесе считается *клиентом* и по какому ключу опознаётся дубль?» (сущность Ontology/Identity из C1).
- **Чек (да/нет):** есть ли единое определение `клиент` + уникальный ключ во всех источниках? — **Нет** (у продаж контакт, у бухгалтерии юрлицо).
- **Шаг:** провести сессию онтологии (C1) → зафиксировать `04-glossary.md` → задать схему Event Log `case_id+activity+timestamp+actor` → поднять State Store (SQL/Airtable) → навесить агента-collector на канал, где люди уже работают, чтобы он порождал след с нуля → governed-расчёт KPI вне LLM → плитка на дашборде.
- **Замыкание:** если дашборд показывает «200 клиентов», а определения нет — это не метрика, а спор; вопрос→чек→шаг прогоняется заново. Так контур D из абстракции превращается в один проверяемый маршрут внедрения.

## 📚 Глоссарий сущностей

Карта всех именованных объектов системы (по разделам-источникам).

**C1 · Карта бизнеса**

- **Business Map (`00-MAP.md`)** — одностраничная карта бизнеса по слоям Рыбакова (продукт→процессы→люди→управление→инструменты); скелет-модель бизнеса, который повторяют все контуры.
- **Карточка продукта (Product Definition)** — за какой результат и единицу клиент платит; якорь всех потоков.
- **Реестр ценностных потоков (Value Streams)** — список сквозных потоков «триггер → ценность → узлы»; мост к C2.
- **Реестр узлов и владельцев (Nodes & Owners)** — отделы/функции как суверенные узлы, один владелец на узел.
- **Онтология / Глоссарий идентичности (`04-glossary.md`)** — единые определения сущностей + уникальные ключи дублей; ядро контура, источник `case_id`.
- **Границы бизнеса (Boundaries)** — что внутри/снаружи контура (своё/подрядчик/смежное).
- **Карта инструментов (Tooling Inventory)** — где физически живут данные каждого узла; вход для D.

**C2 · Процессы**

- **Карточка процесса (Process Card)** — атомарная единица: триггер→шаги→результат+владелец+статус.
- **SIPOC-таблица** — паспорт процесса: Supplier·Input·Process·Output·Customer.
- **Карта потока ценности (Value Stream)** — цепочка процессов от запроса до денег, со временем ожидания между шагами.
- **Реестр процессов (Process Registry)** — единая таблица всех карточек.
- **Карта handoffs** — точки передачи ответственности; самые хрупкие места разрывов.
- **Процесс vs проект** — правило сортировки: повторяемое регламентируют, уникальное ведут проектом.
- **Event Log** — журнал фактического исполнения, минимум `case_id+activity+timestamp+actor`; в SMB порождается агентами с нуля.

**C3 · Люди**

- **Реестр ролей (Role Registry)** — строка = роль (не человек): миссия, процессы, выход, канал.
- **Карта «роль → человек» (Role-Person Map)** — кто какие роли несёт; пометка риска ключевого лица.
- **RACI-матрица** — ответственные на шаги C2; инвариант «ровно один A на шаг».
- **Карточка роли (Role Card)** — паспорт роли: вход/выход, KPI, агенты-помощники, чек-лист слепых зон.
- **Friction Audit** — карта каналов и «двойного ввода»; где встроить агента (integration > innovation).
- **Реестр span of control** — кто кому подчинён, где перегруз.
- **Карта движения роли по value stack** — высота роли (исполнение→надзор→цели) до/после агентов.

**+A · Агенты**

- **5 архетипов агентов** — Collector (собирает след) · Drafter (черновик) · Qualifier (классифицирует/скорит) · Router (маршрутизирует) · Reconciler (сверяет регламент↔факт).
- **Карточка-стандарт агента (Agent Card)** — исполняемый паспорт: type, **mode** (помощник/цифровой сотрудник), input/output, autonomy, guardrails, gate, owner, **connectors/role_slot**, health (L2 zoo).
- **Режим агента (mode)** — `assistant` (AI-помощник/копайлот поверх человека) или `digital-employee` (цифровой сотрудник, занимает роль).
- **Цифровой сотрудник** — агент, занимающий роль-слот в оргструктуре и выполняющий работу вместо сотрудника; композиция архетипов + регламент (AOP) + коннекторы + человек-руководитель.
- **Коннекторы (цифрового сотрудника)** — «обвязка» агента-в-роли: кому подчиняется, с кем стыкуется (люди/агенты, handoffs), канал, эскалация; онбординг как у человека.
- **Реестр агентов (Agent Registry)** — единый список карточек; антидот зоопарку.
- **Инструменты (tools / MCP)** — коннекторы агента к каналам и хранилищам, ограничены guardrails.
- **Guardrails** — машинно-проверяемые запреты (куда нельзя писать, потолок трат $0); runtime-enforcement.
- **Human-in-the-loop gate** — точка обязательного подтверждения человеком перед необратимым действием.
- **Матрица «Автономия-по-риску»** — уровень автономии × обратимость/деньги.
- **Health-check / журнал прогонов** — поле `health` карточки (heartbeat, alert_if, last_ok) + журнал прогонов; ловит silent failures.

**C4 · Регламенты → AOP**

- **SOP** — человекочитаемый слой контракта (steps, definition_of_done).
- **AOP (Agent Operating Procedure)** — исполнимая проекция SOP для агента (tool, pre/postcondition, autonomy, risk_class).
- **Чек-лист обязательных пунктов (mandatory checklist)** — контроль ПОЛНОТЫ (лечит «пропустил пункт»), не детерминизма.
- **Drift-detector** — сверка event log (факт) с AOP (норма); выдаёт drift_events.
- **Версия регламента (versioned contract)** — semver+changelog; drift меряется против действующей версии.
- **Decision Memory** — лог прецедентов-отступлений от регламента с обоснованием.
- **Карточка владельца регламента (steward card)** — owner + review_cadence (фактор stewardship).

**D · Данные → SSOT**

- **Event Log** — append-only лента фактов «что произошло» (та же схема, общий с C2/C5).
- **State Store** — структурированный store ТЕКУЩЕГО состояния (SQL/граф), который агенты обновляют; System of Record для SMB.
- **Context Layer** — 5 компонентов Atlan: Semantic/Metrics Layer · Ontology/Identity · Operational Playbooks · Lineage · Decision Memory.
- **Предметные сущности (domain entities)** — типизированные карточки объектов (Сделка, Клиент, Инвойс, Задача…).
- **Data Contracts** — схема-договор на поток: обязательные поля, типы, владелец, свежесть; runtime-валидация.
- **AI-Ready Data** — профиль готовности слоя: unified · governed · contextually meaningful · continuously refreshed.
- **RAG-индекс** — векторный поиск ПОВЕРХ State Store (извлечение, не источник истины о состоянии).

**C5 · Контроль + Дашборд**

- **`metrics.yml` (Metrics layer)** — governed-определения KPI (паттерн dbt); один расчёт на метрику.
- **Карточка KPI** — что меряем, формула, target, owner, чек-лист слепых зон.
- **Плитки дашборда (tiles)** — рендер governed-числа + состояние; сами не считают.
- **Вид «ЧТО ДЕЛАТЬ СЕГОДНЯ» (action queue)** — очередь 🔥горит/⏳решение/💰деньги/🔧процесс.
- **Health-checks** — контракты живости следа (против silent failures).
- **Alerts** — правила тревог в канал, где человек уже живёт.
- **Variance-отчёт (Process Mining)** — «регламент/AOP vs факт» по Event Log.
- **Decision Memory (собственника)** — лог управленческих решений и их исходов.

**Сквозное · Правила и контроль (Governance)**

- **Конституция (`governance/CONSTITUTION.md`)** — 7 законов-инвариантов с runtime-проверкой (единый case_id, история только дописывается, автономия по риску, детерминизм, данные≠знания, data contract, у агента владелец и health-check) + блок принципов для людей.
- **Data Contract** — машиночитаемый контракт потока (см. D), как объект governance.
- **Реестр узлов и агентов (`registry`)** — карта федерации + соответствие конституции + bus-factor.
- **Политика автономии-по-риску (`autonomy-policy`)** — матрица действие × уровень автономии.
- **Health-check / drift-панель** — runtime-надзор поверх SSOT.
- **Steward** — три разные роли: *aop-steward* (владелец одного регламента: утверждает версии SOP/AOP), *data-steward* (владелец SSOT, онтологии, метрик и общего справочника клиентов), *transition-steward* (владелец перехода 3→4 по всей компании; в Приложении F — Transition Steward). Слово «steward» без уточнения в таблицах «Кто делает» = transition-steward.
- **Stewardship-план перехода 3→4 (`migration-3to4`)** — именованный владелец миграции из зоопарка в контур; ≥20% на change-management.
- **Реестр противоречий (`contradictions/`)** — явная фиксация расхождений вместо тихой перезаписи.
- **Чек-лист слепых зон под KPI** — Минцберг-оговорка: что метрики не видят (лояльность, репутация, неформальные связи).

**Сшивка с ZOO-фреймворком** *(приложение для автора — мост к другому фреймворку Дмитрия «зоопарк→контур»; новому читателю можно пропустить)*:

- **L0 карта** ↔ C1 · **L1 база знаний** (ОПИСАНИЕ как работает, ≠ данные) ↔ C4/Operational Playbooks · **L2 реестр+карточка-стандарт агента** ↔ +A · **L3 хаб данных** (факты) ↔ D · **L4 «клей»** (агент читает L1 → пишет L3) ↔ collector-агенты +A · **L5 actionable-дашборд** ↔ C5.

---

# Приложения (для внедренца)

*Готовые к применению артефакты — шаблоны, кейс, диагностика, чек-листы, runbook. Сквозной пример: сервисная компания «РемСервис».*

## Приложение A · Шаблоны

> Аудитория — внедренец AI-ориентированной организации (SMB без ERP). Каждый шаблон — copy-paste fenced-блок + строка «как пользоваться». Сквозной пример: сервисная компания «РемСервис» (выездной ремонт бытовой техники, 6 человек). Везде один `case_id` — ось сшивки данных через контуры.

---

### A.1 · Agent Card — паспорт агента (C+A)

```yaml
# agent-card · v1 · хранить в registry/agents/<id>.yaml
id: AG-007                       # стабильный ID, не меняется
name: "Сборщик заявок WhatsApp"
type: collector                  # collector|drafter|qualifier|router|reconciler
mode: digital-employee           # assistant (рядом с человеком) | digital-employee (по коннекторам сам)
purpose: >
  Снимает входящие заявки из WhatsApp/телефонии, нормализует в лид,
  заводит case_id, кладёт в Event Log. Человек продолжает работать как привык.
input:  ["whatsapp:incoming", "voip:call_ended"]   # триггеры/источники события
output: ["lead.created", "eventlog.append"]         # что порождает
data_source: ["whatsapp_api", "voip_cdr"]           # откуда читает (read)
data_sink:   ["state_store.leads", "event_log"]     # куда пишет (write)
schedule: "event-driven"          # event-driven | cron:"*/15 * * * *" | manual
runbook: "registry/runbooks/RB-collector-wa.md"     # AOP/SOP, по которому работает
autonomy: L1                      # L0 предлагает · L1 действует+уведомляет · L2 авто в зелёной зоне · L3 полностью авто
guardrails:                       # жёсткие запреты + лимиты
  - "не пишет клиенту от лица компании без gate"
  - "не трогает записи со status=closed"
  - "stop при >50 лидов/час (защита от шторма/дублей)"
gate: human-in-the-loop           # none | human-in-the-loop | dual-control
owner: "Оля (диспетчер)"          # владелец — роль и её текущий исполнитель; чинит при сбое
role_slot: "Приём заявок"         # роль из Role Card, НЕ конкретный человек
connectors: ["whatsapp-business", "binotel-voip"]
status: active                    # draft | active | paused | retired
version: "1.0.0"                  # меняешь права/коннекторы — бампаешь
health:                           # против silent failures
  heartbeat: "каждые 15 мин"
  alert_if: "0 событий за 2ч в рабочее время"
  last_ok: "2026-06-15T09:40:00+03:00"
```

Как пользоваться: один файл на агента в `registry/agents/`; узкий агент = один `type` + один `purpose`; перед запуском заполни `guardrails`/`gate`/`health` — без них агент не получает статус `active`. `autonomy` — одна шкала L0–L3 во всём документе; отдельный шаг AOP может быть строже общей ступени агента, но не мягче. Своим `id` агент подписывает события: `actor = agent:<id>`.

---

### A.2 · AOP — Agent Operating Procedure (C4: регламент как исполнимый контракт)

```yaml
# aop · v1 · исполнимый контракт, НЕ PDF · registry/aops/<aop_id>.yaml
aop_id: "AOP-qualify-lead"          # стабильный ID регламента
process: "P-02"                     # процесс из C2, который исполняет этот AOP
owner: "Оля (диспетчер)"            # владелец регламента (aop-steward): утверждает версии
goal: "каждый лид квалифицирован и направлен за 5 минут"
sop_ref: "docs/sop/lead-qualification.md"   # человекочитаемый первоисточник
trigger:
  on: "lead.created"
  filter: "source in [whatsapp, voip, site_form]"
steps:                              # детерминированные шаги; LLM только там, где помечено
  - id: s1
    do: "обогатить лид (адрес, тип техники, район)"
    tool: geo-normalizer
  - id: s2
    do: "классифицировать срочность/маржинальность"
    tool: llm-classifier            # ВЫВОД фиксируется, расчёт скоринга — вне LLM
  - id: s3
    do: "посчитать lead_score по metrics.yml"
    tool: metrics-engine            # детерминизм: формула вне модели
  - id: s4
    do: "роутить мастеру по району или в очередь"
    tool: router
    autonomy: L1                    # у шага свои autonomy / risk_class; autonomy шага не выше ступени агента-исполнителя из его карточки
tools: [geo-normalizer, llm-classifier, metrics-engine, router]
preconditions:                      # проверяются ДО запуска, иначе abort
  - "case_id присутствует и уникален"
  - "lead.phone валиден (E.164)"
postconditions:                     # проверяются ПОСЛЕ, иначе откат+алерт
  - "lead.status in [qualified, rejected]"
  - "ровно одна запись в event_log с activity=lead_qualified"
autonomy: L2                        # ступень по умолчанию для шагов (авто в зелёной зоне риска)
risk_class: green                   # green (обратимо/дёшево) | amber | red (деньги/клиент/право)
gate:
  amber: human-in-the-loop          # эскалация при amber
  red: dual-control                 # два подтверждения при red
drift_checks:                       # drift-detector вместо «PDF в шкафу»
  - "доля rejected растёт >2σ к недельной базе → алерт владельцу"
  - "среднее время s1→s4 > 5 мин → деградация, проверить коннектор"
  - "schema(lead) != data_contract:lead → стоп, контракт нарушен"
version: "1.3.0"                    # semver; меняешь шаги — бампаешь minor
```

Как пользоваться: один AOP на процесс из C2 (`process`), у каждого AOP есть владелец (`owner`); `sop_ref` — словесный регламент, сам AOP — то, что исполняет агент/движок; `risk_class` + `gate` дают автономию-по-риску, `drift_checks` ловят расхождение план/факт без ручного аудита.

---

### A.3 · Event Log — единый след (D: SSOT)

```sql
-- event_log · append-only · ядро SSOT · сшивка всех контуров по case_id
CREATE TABLE event_log (
  case_id    TEXT        NOT NULL,   -- сквозной ID сущности (лид/заказ/клиент)
  activity   TEXT        NOT NULL,   -- ЧТО произошло (глагол прош. вр., из словаря активностей)
  timestamp  TIMESTAMPTZ NOT NULL,   -- когда (UTC+смещение), для process mining
  actor      TEXT        NOT NULL,   -- КТО: human:<имя> / agent:<id карточки> / system
  payload    JSONB                   -- контекст события (суммы, статусы, ссылки)
);
CREATE INDEX ix_eventlog_case ON event_log (case_id, timestamp);
-- append-only: UPDATE/DELETE запрещены гайдрейлом; исправление = новое событие
```

```text
case_id   | activity         | timestamp                 | actor              | payload
----------+------------------+---------------------------+--------------------+--------------------------------------------
RS-2026-0421 | lead_created   | 2026-06-15T09:12:03+03:00 | agent:AG-007       | {"source":"whatsapp","tech":"стиралка"}
RS-2026-0421 | lead_qualified | 2026-06-15T09:13:48+03:00 | agent:AG-011       | {"score":78,"urgency":"high","district":"центр"}
RS-2026-0421 | visit_scheduled| 2026-06-15T10:05:20+03:00 | human:Кирилл       | {"slot":"2026-06-16T11:00","price_est":1200}
```

Как пользоваться: это и есть SSOT — каждый агент и человек дописывают строку (никогда не правят старую); три колонки `case_id+activity+timestamp` — минимум для process mining (план vs факт), `payload` свободный, но типы полей фиксирует Data Contract (A.7).

---

### A.4 · CONSTITUTION.md — законы-инварианты с runtime-проверкой (Governance)

```markdown
# CONSTITUTION · РемСервис · v1
> Инварианты, проверяемые ИСПОЛНЕНИЕМ (runtime-enforcement), а не комитетом.
> Нарушение = блокировка действия + алерт, не «обсудим на планёрке».

## Закон 1. Единый case_id
Любое событие/запись несёт валидный case_id из реестра своего узла; клиент — из общего справочника клиентов.
runtime: write в event_log/state_store без case_id → reject.

## Закон 2. Append-only история
Event Log не редактируется и не удаляется; исправление = компенсирующее событие.
runtime: UPDATE/DELETE на event_log → запрет на уровне прав БД.

## Закон 3. Автономия по риску
Действие класса red не выполняется без dual-control; amber — human-in-the-loop. Деньги наружу — всегда red;
на стадии 5 допускается автоплатёж только в жёстком лимите (белый список получателей, потолки, сверка).
runtime: шаг с risk_class выше разрешённого ступенью autonomy агента → действие уходит в очередь подтверждения.

## Закон 4. Расчёт вне LLM (детерминизм)
KPI и деньги считаются metrics-engine по metrics.yml, не языковой моделью.
runtime: число в отчёте без ссылки на metric_id → флаг «недоверенный расчёт».

## Закон 5. Данные ≠ знания
Агенты пишут в State Store (он живой), знания — в Context Layer; RAG не источник истины.
runtime: запись факта о состоянии бизнеса только через state_store API.

## Закон 6. Контракт данных обязателен
Каждый поток данных проходит валидацию по своему Data Contract.
runtime: schema-mismatch → стоп потока + алерт владельцу контракта.

## Закон 7. Каждый агент имеет владельца и health-check
Нет owner или heartbeat → агент не активируется; молчание дольше порога → авто-pause.
runtime: registry-валидатор отклоняет карточку без owner/health.

## Принципы (для людей; исполнением не проверяются, в законы не входят)
- Стандарт входа и выхода: у каждого агента и процесса они формализованы.
- Инструкция на сбой: у каждого критического процесса есть runbook.
- Истину создаёт человек, ИИ — усилитель: вовлечение снизу важнее приказа сверху.

## Поправки
Закон меняется PR в этот файл + обновление соответствующей runtime-проверки. Узлы федерации суверенны, но законы 1–2 (case_id, append-only) — общие для всех.
```

Как пользоваться: храни в корне governance/; каждый закон обязан иметь строку `runtime:` — если инвариант нельзя проверить исполнением, он не закон, а пожелание (в конституцию не идёт).

---

### A.5 · Role Card — паспорт роли (C3: роль ≠ исполнитель)

```yaml
# role-card · v1 · roles/<slot>.yaml · роль отделена от человека и от агента
slot: "Приём заявок"               # имя роли (slot), НЕ ФИО
mission: "Ни одна входящая заявка не потеряна и заведена в систему за <5 мин"
mode: assistant                    # human | assistant | digital-employee — тот же словарь, что у агента
human: ["Оля"]                     # текущие исполнители: один или несколько (сменяемы без правки роли)
ai_support: ["AG-007"]             # агенты, усиливающие роль (фоновый сбор)
raci:                              # на ключевых активностях процесса
  lead_created:    {R: AG-007, A: Оля, C: -,        I: РОП}
  lead_qualified:  {R: AG-011, A: Оля, C: мастер,   I: РОП}
  visit_scheduled: {R: Оля,    A: Оля, C: мастер,   I: клиент}
channels: ["whatsapp", "телефон", "crm-очередь"]   # где роль принимает работу
value_stack:                       # исполнение → надзор → цели
  execution: "снять и завести заявку"
  oversight: "проверить очередь, разрулить спорные/дубли (выход агента)"
  goals: "конверсия заявка→визит ≥ 60%"
kpi: ["lead_to_visit_rate", "avg_lead_intake_time"]   # из metrics.yml
backup: "Света"                    # кто подменяет; если исполнителей несколько — порядок подмены между ними
processes: ["P-01", "P-02"]        # процессы из C2, в которых участвует роль
role_id: "R-01"                    # стабильный код роли из реестра ролей
version: "1.0.0"
```

Как пользоваться: роль живёт дольше человека и агента — меняя `human`/`ai_support`, не трогаешь `mission`/`raci`; `value_stack` показывает, что по мере взросления человек уходит от исполнения к надзору за агентом и к целям.

---

### A.6 · metrics.yml — governed-определение KPI (C5: один расчёт)

```yaml
# metrics.yml · semantic/metrics layer · ОДНО governed-определение на метрику
metrics:
  - name: lead_to_visit_rate
    title: "Конверсия заявка → визит"
    formula: "count(case where activity=visit_scheduled) / count(case where activity=lead_created)"
    source: ["event_log"]              # считается ИЗ SSOT, не из «экселя Оли»
    grain: "за период, по району"       # разрез
    target: ">= 0.60"
    owner: "РОП"                        # кто отвечает за определение и цель
    refresh: "hourly"
    blind_spots:                        # Минцберг-чек: что метрика НЕ видит
      - "не учитывает отменённые клиентом визиты (выглядит лучше реальности)"
      - "дубли лидов завышают знаменатель → конверсия занижается"

  - name: avg_lead_intake_time
    title: "Среднее время приёма заявки"
    formula: "avg(ts(lead_qualified) - ts(lead_created)) per case"
    source: ["event_log"]
    grain: "за день"
    target: "<= 5m"
    owner: "Оля (роль: Приём заявок)"
    refresh: "hourly"
    blind_spots:
      - "медиана честнее среднего при единичных ночных заявках"
      - "не показывает заявки, не дошедшие до lead_created (потеря ДО системы)"
```

Как пользоваться: дашборд и агенты берут число ТОЛЬКО отсюда (никаких параллельных формул в отчётах); `formula` ссылается на activity из Event Log; `blind_spots` обязателен — метрика без явных слепых зон вводит в заблуждение и в layer не принимается.

---

### A.7 · Data Contract — контракт потока данных (D: data contracts)

```yaml
# data-contract · v1 · contracts/lead.yaml · договор между источником и потребителем
dataset: "lead"
owner: "Оля (роль: Приём заявок)"        # отвечает за качество и изменения схемы
producers: ["AG-007"]                    # кто пишет
consumers: ["AG-011", "metrics-engine", "dashboard"]  # кто читает
case_key: "case_id"                      # связь с Event Log / SSOT
fields:
  - {name: case_id,    type: string,   required: true,  desc: "сквозной ID, формат RS-YYYY-NNNN"}
  - {name: phone,      type: string,   required: true,  desc: "E.164, +380..."}
  - {name: source,     type: enum,     required: true,  values: [whatsapp, voip, site_form]}
  - {name: tech_type,  type: enum,     required: true,  values: [стиралка, холодильник, плита, духовка, другое]}
  - {name: district,   type: string,   required: false, desc: "район выезда"}
  - {name: created_at, type: timestamp,required: true,  desc: "UTC+смещение"}
  - {name: lead_score, type: integer,  required: false, desc: "0..100, ставит metrics-engine"}
freshness: "<= 2m от события до записи"   # SLA свежести
validation:                              # правила; провал → стоп потока + алерт owner
  - "phone matches ^\\+[1-9]\\d{7,14}$"
  - "source in enum"
  - "case_id уникален в пределах dataset"
  - "created_at не в будущем"
on_violation: "reject + alert owner + write activity=contract_violation в event_log"
version: "1.1.0"                          # ломающее изменение схемы → major + миграция
```

Как пользоваться: один контракт на каждый поток между агентами/системами; `validation` — это и есть runtime-страж закона 6 конституции; меняешь поля — бампаешь `version` и предупреждаешь всех `consumers`, иначе ломаешь их молча.

---

Связки шаблонов (для внедренца): `case_id` сшивает A.1–A.7 в один контур; Role Card (A.5) ссылается на Agent Card (A.1) и metrics.yml (A.6); AOP (A.2) исполняет процесс и валидирует по Data Contract (A.7), пишет в Event Log (A.3); CONSTITUTION (A.4) даёт runtime-инварианты, на которые опираются `validation` контракта и `gate` AOP; всё считается одним определением из metrics.yml (A.6). Заводи в порядке: Event Log → Data Contract → Agent Card → AOP → metrics.yml → Role Card → Constitution.

---

## Приложение B · Сквозной кейс (end-to-end)

> **Кому.** Внедренцу. **Что это.** Один SMB проходит переход **3→4** по **одному** процессу — «приём заказа» — через все контуры **C1→C5+A**. Везде формат **было (стадия 3) → стало (стадия 4)** с реальными экземплярами артефактов. Цифры и имена — примеры, замените на свои.
>
> **Объект.** Автосервис «Колесо», 14 человек, без ERP. Запись на ремонт идёт через: телефон, WhatsApp, Instagram-директ, форму на сайте, заход «с улицы». ~40 обращений/день, конверсия в заказ-наряд — на глаз, теряются заявки из директа в выходные.
>
> **Боль стадии 3 («зоопарк»).** Инструменты есть, контура нет: телефон, WhatsApp-Business на телефоне приёмщика, Instagram у маркетолога, форма сайта валится на почту, заказ-наряды — в 1С-подобной программе ремонта, остальное — Google-таблица «Заявки», которую ведут «когда успеваем». Один и тот же клиент = 3 разные записи. Где теряются заявки — никто не знает, потому что нет единого следа.

---

### B.0 · Карта перехода (одной таблицей)

| Контур | Было (3) | Стало (4) |
|---|---|---|
| **C1 Карта** | Процесс «в головах», клиент в 3 системах под 3 именами | Карта с узлом «Приём заказа», единый `case_id` сшивает каналы |
| **C2 Процесс** | Шаги непостоянны, handoff устный | Карточка процесса: триггер→7 шагов→результат, SIPOC, явные handoffs |
| **C3 Люди** | «Кто свободен, тот и принял» | Роль ≠ исполнитель: приёмщик-человек + 2 collector-агента + 1 цифровой сотрудник на квалификации |
| **D Данные/SSOT** | Google-таблица «когда успеем», 3 копии клиента | Event Log (`case_id+activity+timestamp+actor`) + State Store, который агенты **обновляют** |
| **+A Агенты** | Нет | 3 агента: `intake-collector`, `lead-qualifier` (digital-employee), `followup-reconciler`; у каждого Agent Card |
| **C4 Регламент** | PDF «как принимать» в чате, никто не читал | AOP — исполнимый контракт + drift-detector |
| **C5 Контроль** | Собственник спрашивает «как там заявки?» голосом | Дашборд «что делать сегодня»: плитки-действия, план vs факт |
| **Gov** | — | Автономия-по-риску: агент сам пишет, но запись клиента на подъёмник — через gate (человек) |

---

### B.1 · C1 — Карта бизнеса (фрагмент)

**Было (3).** Процесс существует только как навык приёмщика. Клиент Иван Петров заходит в WhatsApp как «+380...», в Instagram как `@ivan_p`, в программе ремонта как «Петров И.». Три карточки, ноль связи.

**Стало (4).** Фрагмент карты — ветка от продукта до инструмента, с единой идентичностью:

```
ПРОДУКТ: Ремонт и ТО легковых авто
  └─ ПРОЦЕСС: P-01 «Приём заказа»  [триггер обращения → заказ-наряд]
       ├─ ЛЮДИ (роли):  R-приёмщик · R-мастер-консультант · R-маркетолог
       ├─ УПРАВЛЕНИЕ:    владелец процесса = Сергей (старший приёмщик)
       └─ ИНСТРУМЕНТЫ:   телефон/АТС · WhatsApp Business API · Instagram · форма сайта
                         → всё нормализуется в SSOT под единым case_id

ИДЕНТИЧНОСТЬ (онтология):
  client_id  = c_00412  ──┬─ канал tel:  +380XXXXXXXXX
                          ├─ канал wa:   +380XXXXXXXXX
                          ├─ канал ig:   @ivan_p
                          └─ канал web:  ivan.petrov@…
  Любое обращение → разрешается в client_id → открывается case_id
```

**Единый `case_id`.** Формат `KOL-2026-0617-031` (компания-дата-порядковый). Один обращ = один кейс; повторный контакт того же клиента по тому же авто в окне 14 дней цепляется к открытому кейсу, а не плодит новый.

---

### B.2 · C2 — Карточка процесса P-01 «Приём заказа»

**Было (3).** «Берёшь трубку — записываешь — говоришь, когда подъехать». Если приёмщик занят/в обеде — заявка из директа лежит до вечера или теряется. Handoff к мастеру — крикнуть через цех.

**Стало (4). Карточка процесса (исполнимый экземпляр):**

| Поле | Значение |
|---|---|
| **ID / имя** | P-01 «Приём заказа» |
| **Триггер** | Входящее обращение в любом из 4 каналов |
| **Результат (DoD)** | Открыт заказ-наряд ИЛИ зафиксирован обоснованный отказ; клиент получил ответ ≤15 мин в рабочее время |
| **Владелец** | Сергей (R-приёмщик, старший) |
| **SLA** | Первый ответ ≤15 мин (раб. время) / ≤9:30 след. утра (нераб.) |

**Шаги (триггер → результат):**

| # | Шаг | Исполнитель | Тип |
|---|---|---|---|
| 1 | Захват обращения из канала, нормализация в `case_id` | `intake-collector` | агент (collector) |
| 2 | Разрешить `client_id` (новый/повторный), подтянуть историю авто | `intake-collector` | агент |
| 3 | Квалификация: что за авто, симптом, срочность, бюджетная вилка | `lead-qualifier` | цифровой сотрудник |
| 4 | Черновик ответа клиенту + предложенные слоты | `lead-qualifier` | цифровой сотрудник (drafter-режим) |
| 5 | **Gate:** проверить слот, цену, согласовать запись | Сергей | человек |
| 6 | Создать заказ-наряд в программе ремонта | Сергей | человек |
| 7 | Закрыть петлю: подтверждение клиенту, напоминание за день | `followup-reconciler` | агент (reconciler) |

**SIPOC:**

| S (поставщик) | I (вход) | P (процесс) | O (выход) | C (клиент) |
|---|---|---|---|---|
| Клиент, реклама, сарафан | Обращение + данные авто | P-01 шаги 1–7 | Заказ-наряд + слот | Цех (мастер), сам клиент |

**Handoffs (явные, с условием):**

- `lead-qualifier` → **Сергей** на шаге 5, когда: собран минимум (авто+симптом+канал связи) ИЛИ автономия исчерпана (см. AOP).
- Сергей → **цех** на шаге 6: заказ-наряд + симптом в State Store, мастеру падает уведомление.

---

### B.3 · C3 — Люди: роль ≠ исполнитель

**Было (3).** Роли нет, есть «кто свободен». Надзор отсутствует: никто не видит, сколько заявок не обработано.

**Стало (4). Расщепление роли R-приёмщик по value-stack:**

| Слой value-stack | Кто делает | Режим |
|---|---|---|
| **Исполнение** (рутинный захват, нормализация, черновик) | `intake-collector` + `lead-qualifier` | агенты |
| **Надзор** (проверка слота/цены, решение «брать ли») | Сергей, человек | human-in-the-loop |
| **Цели** (конверсия, загрузка цеха, why-метрики) | Владелец | человек |

**RACI на P-01:**

| Шаг | R | A | C | I |
|---|---|---|---|---|
| 1–2 Захват/нормализация | `intake-collector` | Сергей | — | — |
| 3–4 Квалификация/черновик | `lead-qualifier` | Сергей | мастер (по сложным) | — |
| 5–6 Gate + заказ-наряд | Сергей | Сергей | — | мастер |
| 7 Follow-up | `followup-reconciler` | Сергей | — | клиент |

**Каналы:** клиент общается там, где написал (WA/IG/тел/web); внутри — единый State Store. **Принцип адопшна:** Сергей работает как привык (видит карточку, жмёт «подтвердить»), агенты собирают и черновят фоном.

---

### B.4 · +A — Агенты: реестр и заполненная Agent Card

**Было (3).** Агентов нет. Автоответчик Instagram «Спасибо, скоро ответим» — и тишина.

**Стало (4). Реестр агентов P-01 (3 шт, узкие):**

| name | архетип | mode | назначение |
|---|---|---|---|
| `intake-collector` | collector | assistant | захват+нормализация обращений в `case_id` |
| `lead-qualifier` | qualifier | digital-employee | квалификация + черновик ответа со слотами |
| `followup-reconciler` | reconciler | digital-employee | сверка «ответили/записались/пришли», добивка |

**Заполненная Agent Card (стандарт, ключевой агент):**

```yaml
id:           lead-qualifier
name:         lead-qualifier
type:         qualifier
mode:         digital-employee
purpose:      Квалифицировать входящее обращение (авто, симптом, срочность,
              бюджетная вилка) и подготовить черновик ответа клиенту с 2–3 слотами.
input:        case_id (из intake-collector), текст обращения, история авто из State Store
output:       qualification{vehicle, symptom, urgency, budget_band, missing_fields},
              draft_reply{text, proposed_slots[]}
data_source:  State Store (clients, vehicles, slots_free), Context Layer (прайс-вилки, FAQ)
data_sink:    Event Log (activity=qualified / drafted), State Store (case.qualification)
schedule:     event-driven (по новому обращению) + добор раз в 5 мин по очереди
runbook:      RB-P01-Q-v3  (как квалифицировать, что спрашивать, когда эскалировать)
autonomy:     L2 — пишет черновик и отправляет авто-ответ «приняли, уточняю слот»;
              финальную запись/цену НЕ подтверждает (gate человека)
guardrails:   не называет цену вне утверждённой вилки; не обещает слот, пока не gate;
              стоп-темы (ДТП/страховая/буксир) → немедленная эскалация Сергею
gate:         human-in-the-loop   # шаг 5 P-01: слот и цену подтверждает человек (Сергей)
owner:        Сергей (R-приёмщик)
role_slot:    R-приёмщик / слой «исполнение»
connectors:   WhatsApp Business API (rw), Instagram Graph (rw), сайт-форма webhook (r),
              State Store (rw), Event Log (w)
status:       active
version:      1.0.0
health:
  heartbeat:  каждые 5 мин
  alert_if:   0 обработок за 30 мин в раб. время ИЛИ доля эскалаций >60% (признак silent failure / дрейфа)
  last_ok:    2026-06-17T08:04:39+03:00
```

> **Автономия-по-риску.** `intake-collector` = L3 (полностью авто: только пишет след, риск нулевой). `lead-qualifier` = L2 (авто-ответ + черновик, но цена/запись через gate). Запись на подъёмник деньгами клиента — всегда человек. **Health-check против silent failure:** если агент «молчит» в рабочее время — это инцидент, а не «тихо ок».

---

### B.5 · D — Данные → SSOT (Event Log + State Store)

**Было (3).** Google-таблица «Заявки», заполняется выборочно. Нет timestamp, нет actor, нет связи «обращение → заказ-наряд». Восстановить «где упала заявка» нельзя.

**Стало (4).** В SMB **след порождают агенты с нуля** — ERP нет, но Event Log есть.

**Event Log — 3 реальные строки (один кейс):**

| case_id | activity | timestamp | actor |
|---|---|---|---|
| KOL-2026-0617-031 | intake_captured (ig) | 2026-06-17T08:02:11+03:00 | agent:intake-collector |
| KOL-2026-0617-031 | qualified+drafted (Octavia, стук подвески, срочно, 4–7k) | 2026-06-17T08:04:39+03:00 | agent:lead-qualifier |
| KOL-2026-0617-031 | order_confirmed (слот 18.06 10:00, наряд #4471) | 2026-06-17T09:11:50+03:00 | human:Сергей |

**State Store (SQL, агенты ОБНОВЛЯЮТ, не read-only RAG):**
```
case        (case_id PK, client_id, vehicle_id, status, channel, opened_at, owner)
client      (client_id PK, name, channels_json)        ← дедуп идентичности из C1
vehicle     (vehicle_id PK, client_id, make, model, plate, history)
slot        (slot_id PK, datetime, bay, status)        ← qualifier читает free, человек ставит booked
```
- **Data contract** для `intake-collector`: на выходе обязательны `case_id, client_id, channel, raw_text, ts`; иначе запись отклоняется (drift в источнике ловится сразу).
- **Данные ≠ знания:** прайс-вилки и FAQ живут в **Context Layer** (для qualifier), а факты кейса — в State Store. Не смешиваются.

---

### B.6 · C4 — Регламент → AOP (исполнимый контракт)

**Было (3).** PDF «Регламент приёма звонка» переслан в рабочий чат полгода назад. Drift никем не отслеживается; по факту каждый принимает по-своему.

**Стало (4). AOP P-01 (фрагмент исполнимого контракта):**

```yaml
aop_id: "AOP-P01-intake"
process: "P-01"
owner: "Сергей (R-приёмщик)"
goal: "На каждое обращение — ответ ≤15 мин (раб.) / ≤9:30 утра (нераб.); квалификация и слот предложены до участия человека"
sop_ref: "docs/sop/P-01-priem-zakaza.md"
trigger:
  on: "new_message"
  filter: "channel in [wa, ig, web, tel]"
steps:
  - {id: s1, do: "захватить обращение, нормализовать в case_id", tool: intake-collector, autonomy: L3}
  - {id: s2, do: "разрешить client_id, подтянуть историю авто", tool: intake-collector, autonomy: L3}
  - {id: s3, do: "квалифицировать: авто, симптом, срочность, бюджетная вилка", tool: lead-qualifier}
  - {id: s4, do: "черновик ответа + предложенные слоты, авто-ответ «приняли, уточняю слот»", tool: lead-qualifier}
  - {id: s5, do: "GATE: проверить слот и цену, согласовать запись", tool: "human:Сергей", risk_class: amber}
  - {id: s6, do: "создать заказ-наряд в программе ремонта", tool: "human:Сергей"}
  - {id: s7, do: "закрыть петлю: подтверждение клиенту, напоминание за день", tool: followup-reconciler}
tools: [intake-collector, lead-qualifier, followup-reconciler]
preconditions:
  - "выход intake-collector содержит case_id, client_id, channel, raw_text, ts"
postconditions:
  - "order_created в Event Log только после qualified"
  - "клиент получил ответ в пределах SLA"
autonomy: L2                        # ступень по умолчанию; s1–s2 исполняет intake-collector со своей ступенью L3 (только запись следа), s5–s6 — человек
risk_class: green
gate:
  amber: human-in-the-loop
  red: dual-control
drift_checks:
  - "SLA_breach: first_reply > 15 мин (раб.) → flag + плитка дашборда"
  - "silent_fail: agent.health = stale 30 мин → инцидент"
  - "band_drift: цена названа вне approved_band → блок + ревью owner"
  - "bypass: order_created без qualified в Event Log → расхождение, ревью"
version: "3.0.0"
```

Чек-лист полноты (без него AOP не активируется): триггер однозначен · каждый шаг имеет исполнителя · каждый handoff с условием · gate расставлены по риску · источники и приёмники данных заданы в карточках агентов · метрика результата измерима (ответ ≤15 мин, конверсия) · drift-detector привязан. Запреты агентов (цена только в утверждённой вилке, не обещать слот до gate, эскалация тем «ДТП / страховая / буксир») живут в `guardrails` их карточек (B.4), а не в AOP.

> AOP — **не PDF, а контракт, который читает delivery-слой и сверяет факт**. Принцип «**research writes, delivery reads**»: квалификатор/черновики пишутся, исполнение (запись, наряд) читает и сверяет с AOP.

---

### B.7 · C5 — Контроль + Дашборд «Что делать сегодня»

**Было (3).** Контроль = собственник спрашивает голосом «как там с заявками?». Отчёт постфактум, не действие.

**Стало (4).** Дашборд = **actionable, не отчётность**. Process mining сверяет **план (AOP/P-01) vs факт (Event Log)**.

**Плитка дашборда «Что делать сегодня» (реальный экземпляр):**

```
┌─ ЧТО ДЕЛАТЬ СЕГОДНЯ · 17.06 09:15 ─────────────────────────────┐
│ 🔴 3 заявки ждут вашего gate >12 мин   → [Открыть очередь]      │
│    • KOL-…-031 Octavia, стук, срочно — черновик готов, слот 10:00│
│ 🟡 2 слота завтра пусты (бокс №2)       → [Раздать в follow-up]  │
│ 🟢 Конверсия обращение→наряд: 61% (нед.) ▲ план 55%             │
│ ⚠️ lead-qualifier: эскалаций 18% (норма <60%) — здоров          │
│ ❗ 1 заявка ig субботы без ответа 14ч    → process-mining: SLA-брешь│
└────────────────────────────────────────────────────────────────┘
```

- **Каждая плитка → действие** (кнопка/очередь), а не цифра «для отчёта».
- **Semantic / metrics layer:** «конверсия обращение→наряд» = один governed-расчёт (`count(order_confirmed)/count(intake_captured)` за окно), считается **вне LLM**, детерминированно — одно число для собственника и для дашборда.
- **Process mining** ловит `❗`: обращение в Event Log без последующего `qualified`/`order` = разрыв план-vs-факт, всплывает как действие, а не теряется.

---

### B.8 · Governance — что осталось у человека

- **Конституция узла** автосервиса: цена клиенту и запись ресурса (подъёмник, время мастера) — **всегда через gate человека**, независимо от уверенности агента.
- **Runtime-enforcement, не комитет:** правило «no_slot_promise_before_gate» живёт в guardrails агента и в AOP drift-detector — нарушение блокируется в моменте, а не обсуждается на планёрке.
- **Stewardship 3→4:** владелец процесса (Сергей) отвечает за версии AOP и Agent Card; изменение прайс-вилки = новая версия Context Layer + bump версии AOP.
- **Слепые зоны (чек-лист Минцберга):** проверить, что автоматизация приёма не убила «живой» канал для пожилых клиентов (телефон остаётся человеческим по умолчанию на стоп-темах).

---

### B.9 · Итог перехода 3→4 (что реально изменилось)

| Было (3) | Стало (4) |
|---|---|
| Заявка из IG в выходные теряется | Авто-ack ≤1 мин, запись в Event Log, утром — в очереди gate |
| Клиент в 3 системах под 3 именами | 1 `client_id`, каналы сшиты |
| «Где упала заявка?» — не ответить | Process mining показывает разрыв как действие |
| Конверсия «на глаз» | Governed-метрика 61%, одна для всех |
| Регламент-PDF, который не читают | AOP-контракт + drift-detector в runtime |
| Контроль голосом постфактум | Плитка «что делать сегодня» с кнопками |

**Минимальный порядок внедрения (для повторения):** C1 идентичность+`case_id` → C2 карточка процесса → C3 роль и её исполнители → D Event Log+State Store (фундамент следа) → +A узкие агенты-сборщики с Card → C4 AOP+drift → +A агент-сверщик → C5 плитка дашборда; Gov gate-правила — с первого шага. **Не наоборот:** агенты без SSOT и `case_id` = ещё один зверь в зоопарке.

---

## Приложение C · Диагностика зрелости (само-оценка)

→ Перенесено в начало файла: Часть 2 «Инструменты разбора».

---

## Приложение D · Матрица приоритизации

→ Перенесено в начало файла: Часть 2 «Инструменты разбора».

---

## Приложение E · Стартовый стек + экономика

> Аудитория — внедренец. Контекст — SMB без ERP. Задача приложения: дать **конкретный** стартовый стек по слоям контура (C1–C5 + A + D), назвать ценовые диапазоны, и перевести это на язык собственника — что каждый контур **стоит** и что **экономит**. Принцип фреймворка тот же: *system-first, простота инструмента, методология до инструмента*. Стек — это «как», а не «зачем»; сначала контур, потом тулза.

---

### E.0 Принцип выбора стека (для внедренца)

Три правила, которые не дают развалиться в «зоопарк» (зрелость 3):

1. **Один слой — один инструмент-владелец.** Не два State Store, не три места для регламентов. Дублирование источника правды = главная причина drift в SMB.
2. **SSOT — это то, что агенты ОБНОВЛЯЮТ, а не read-only база.** Если выбранный инструмент нельзя писать по API из оркестратора — он не SSOT, он витрина.
3. **Покупаем «скучное», строим только «клей».** Notion/Airtable/Telegram — готовые. Уникальная логика бизнеса живёт в L4-оркестрации и карточках агентов, не в самописном фронте.

Стартуем на managed-SaaS (быстро, дёшево тестировать). На self-host (Supabase/Postgres/n8n own) переезжаем только когда упёрлись в лимит или приватность данных — **не раньше**.

---

### E.1 Стартовый стек по слоям

Цены — порядок величины для SMB (1 владелец + 3–15 человек/агентов), USD/мес, на 2026. Это «вход», не «потолок».

| Слой контура | Стартовый выбор | Зачем именно он | Альтернатива (когда переезжать) | Порядок цены $/мес |
|---|---|---|---|---|
| **L1 · База знаний** (C1 карта, C4 регламенты, онтология) | **Notion** | Регламенты как живой текст с версиями; человеку читать, AI — парсить через API; дёшево, ноль порога входа. «Research writes, delivery reads» ложится 1:1 | Confluence/Obsidian-vault (если нужна жёсткая иерархия прав или offline) | $0–20/чел; типично **$30–150** |
| **L2 · State Store / SSOT** (D данные, единый case_id) | **Airtable** (старт) → **Supabase/Postgres** (рост) | Airtable: за день поднять Event Log (`case_id·activity·timestamp·actor`) + State Store, писать по API из n8n/агента. Supabase — когда нужен настоящий SQL, RLS, объёмы, граф-связи и реальные права | Postgres self-host (полный контроль, приватность, нет per-seat) | Airtable **$20–100**; Supabase **$0–25→100+**; Postgres-хостинг **$10–50** |
| **L4 · Клей / оркестрация** (C2 процессы, handoffs, расписания) | **n8n** (self-host) или **Make** (managed) | Тут живёт детерминизм: триггер→шаги→результат, ретраи, health-checks, расчёты ВНЕ LLM. n8n — дёшево на своём VPS, без лимита операций; Make — если не хотим админить | Собственные скрипты + cron (когда логика переросла визуальный билдер; версионирование в git) | n8n self-host **$5–20** (VPS); Make/n8n-cloud **$20–80** |
| **A · Агенты** (collector/drafter/qualifier/router/reconciler) | **Claude API + MCP-коннекторы** | Качество на дроблении задач; MCP — стандартный способ дать агенту руки (читать L1, писать L2). Узкие агенты по карточке-стандарту, не «один на всё» | Локальные/дешёвые LLM для массовой рутинной классификации (router/qualifier) | API по токенам: пилот **$20–100**, рабочий контур **$100–500+** |
| **Каналы** (C3 каналы людей и агентов) | **Telegram** (ядро) + **email** (IMAP/Gmail API); **WhatsApp** по нужде клиента | Telegram Bot API — бесплатно, мгновенный канал «агент↔человек» и human-in-the-loop апрувы. Email — там, где живут клиенты. WhatsApp — только если так ходит клиентский поток | WhatsApp Cloud API / Twilio (платный, но обязательный в ряде ниш) | Telegram **$0**; email **$0–10**; WhatsApp BSP **$30–100+** |
| **C5 · Дашборд / Контроль** | **Notion-дашборд** (старт) → лёгкий BI: **Metabase / Looker Studio** | Старт: actionable-страница «что делать сегодня» прямо над Airtable/Notion. BI — когда нужен process-mining (план vs факт) и governed metrics layer (один расчёт метрики) | Grafana / Superset (на Postgres, для метрик в реальном времени) | Notion **$0** (в L1); Metabase self-host **$10–30**; Looker Studio **$0** |

**Минимальный жизнеспособный контур (MVP-стек), типовой счёт собственника:**

| Что | $/мес |
|---|---|
| Notion (L1 + дашборд) | 30–60 |
| Airtable (SSOT) | 20–50 |
| n8n на VPS (оркестрация) | 10–20 |
| Claude API (агенты, рабочая нагрузка) | 100–300 |
| Telegram + email | 0–10 |
| **ИТОГО управляемый AI-контур** | **≈ $160–440/мес** |

Порядок величины: **полноценный AI-контур на отдел = цена одной подписки на CRM enterprise-уровня или ~10–15% оклада одного junior-сотрудника.** Это и есть аргумент окупаемости ниже.

---

### E.2 Экономика контуров: что стоит и что экономит

Считаем на языке денег. «Эффект» — это либо высвобожденные человеко-часы (по ставке роли), либо предотвращённые потери (упущенный лид, просроченный платёж, ошибка). Цифры — типовые для SMB; внедренец подставляет ставки клиента.

| Контур | Что СТОИТ ($/мес) | Что ДЕЛАЕТ агент | Что ЭКОНОМИТ / приносит | Окупаемость |
|---|---|---|---|---|
| **C1 Карта + L1 знания** | Notion 30–150 + разовая сборка карты | Держит онтологию, единый `case_id`, регламенты как живой контракт | Снимает «знание в голове владельца» как точку отказа; онбординг с недель до дней; убирает разнобой версий регламентов | Окупается на **первой замене/болезни ключевого человека** |
| **D · SSOT + Event Log** | Airtable 20–100 (или Postgres 10–50) | Каждый кейс оставляет след: кто·что·когда. Агенты пишут состояние, не теряют контекст | Видимость «где затык» в процессе → находишь узкое место, которое раньше стоило недель. База для всех остальных контуров | Базовый слой — окупается тем, что **без него остальные не работают** |
| **C2 Процессы + L4 оркестрация** (collector/router) | n8n 10–20 + Claude 50–150 | Сбор данных, маршрутизация заявок, ретраи, передача handoff между ролями | **15–40 ч/мес** ручной маршрутизации и копипасты. При ставке $15–30/ч → **$300–1200/мес** высвобождено | **2–5×** от затрат на контур |
| **A · Drafter** (черновики ответов, КП, писем) | Claude 50–200 | Готовит черновик, человек правит и отправляет (human-in-the-loop) | Скорость ответа клиенту ×3–5; **10–30 ч/мес** на письмах/КП. Быстрый ответ = выше конверсия лида | Окупается на **1–2 спасённых сделках/мес** |
| **A · Qualifier** (квалификация лидов) | Claude 30–150 | Скорит входящие, отсекает мусор, фокусирует людей на горячих | Менеджер не тратит время на холодных; меньше упущенных горячих лидов | Один не упущенный лид часто **= месяц затрат на весь стек** |
| **A · Reconciler** (сверки: платежи, остатки, долги) | Claude 30–150 + n8n | Сверяет данные между системами, ловит расхождения и silent failures (health-checks) | Предотвращённые ошибки: незамеченный неплатёж, расхождение склада. Одна пойманная ошибка ≫ годовой стоимости агента | Асимметрия: дёшево стоит — дорого спасает |
| **C5 · Контроль + дашборд** | Notion $0 → Metabase 10–30 | «Что делать сегодня», план vs факт, governed-метрики | Решения на данных, не на ощущениях; владелец перестаёт быть «ручным диспетчером» — высвобождает **собственное** время (самое дорогое) | Окупается высвобождением времени собственника |

**Как внедренец защищает бюджет перед собственником (формула):**
> Эффект (высвобожденные часы × ставка роли + предотвращённые потери) − Стоимость контура = чистая выгода/мес.
> Типовой первый рабочий контур (collector+drafter+router на одном отделе): **стоит $160–440/мес, высвобождает $1000–3000/мес.** ROI — кратный, окупаемость — недели, не годы.

Правило приоритизации внедрения: **первым строим контур с худшей асимметрией «дёшево стоит / дорого болит»** — обычно это Reconciler (сверки) или Qualifier (упущенные лиды), а не самый «модный» агент.

---

### E.3 Главный экономический тезис: AI как дешёвый испытательный стенд для орг-гипотез

Это аргумент уровня собственника, ради которого строится весь контур.

**Раньше** проверить организационную гипотезу — «а если выделить отдельную роль квалификатора лидов?», «а если сверять платежи каждый день, а не раз в неделю?», «а если ввести этот этап в процесс?» — стоило **реального эксперимента на 3–4 месяца**: нанять/переставить человека, переписать регламент, дождаться, пока процесс «прокрутится» достаточно раз, и только потом увидеть результат. Цена ошибки — квартал и зарплаты. Поэтому гипотезы либо не проверяли, либо проверяли по одной в год.

**С AI-контуром** гипотеза проверяется иначе и кардинально дешевле:

| | Реальный орг-эксперимент | AI-гипотеза на контуре |
|---|---|---|
| Срок до результата | 3–4 месяца | дни–недели |
| Стоимость попытки | найм + зарплаты + риск | часы внедренца + токены ($) |
| Цена ошибки | квартал и люди | откатил карточку агента |
| Сколько гипотез/год | 1–3 | десятки |

**Почему это работает именно на этом стеке:**

- **Event Log (SSOT)** уже копит фактический след процесса → у тебя есть **данные «как есть»**, чтобы симулировать «как будет».
- **Узкий агент по карточке-стандарту** = новую роль/правило можно «нанять» за час: завёл карточку (purpose·input·output·guardrails·gate), повесил на процесс, замерил. Не понравилось — `status: off`, откатил без увольнений.
- **Детерминизм в L4** даёт честный замер: метрика считается одинаково до/после (governed metrics layer), сравнение план/факт — это не «ощущение владельца».
- **Дробление и простота** → каждую гипотезу тестируешь изолированно, не ломая остальной контур.

**Вывод для собственника одной строкой:**
> AI-контур — это не «робот вместо людей». Это **испытательный стенд организации**: он превращает дорогой 4-месячный кадровый эксперимент в дешёвый цифровой прогон за недели. Стек за ~$200–400/мес окупается уже на высвобожденных часах и спасённых сделках — а сверх того даёт способность **перебирать орг-гипотезы десятками в год там, где раньше хватало сил на одну.** Это и есть переход зрелости 3→4: не «купили AI», а получили управляемую, измеримую, дешёвую в эксперименте организацию.

---

## Приложение F · Адопшн-контур (люди/доверие)

> **Зачем это приложение.** Контуры C1–C5, +A, D и Governance отвечают на вопрос «**что** строить». Это приложение отвечает на вопрос «**как сделать, чтобы этим пользовались**». Пилот не падает от плохой модели — он падает, потому что носитель роли не открыл агента, не доверился его выводу или тихо вернулся к Excel. По BCG 70% успеха AI-трансформации — это люди и процессы, и только 30% — алгоритмы/данные/технология. Адопшн — не финальный этап («раскатили — теперь обучим»), а **параллельная дорожка**, идущая с первого дня рядом с инженерной.

---

### F.1 Базовый тезис: организация — это сообщество, не машина

Минцберг: организация — не схема из коробочек, а **сообщество людей** (community), которое держится на вовлечённости и взаимном доверии, а не на приказе. Из этого три следствия для внедренца:

1. **Перемены устойчивее снизу, чем сверху.** Спущенное «приказом» внедрение даёт формальное согласие и тихий саботаж (люди кивают, но продолжают «как привыкли»). Изменение, в котором носитель роли поучаствовал, он защищает как своё. → Внедренец не «раскатывает агента на отдел», а **выращивает первого носителя-чемпиона** и даёт ему стать примером для соседей.
2. **Сопротивление — это сигнал, не помеха.** «Не хочу пользоваться» почти всегда означает «не понял выгоды для СЕБЯ» / «боюсь, что меня заменят» / «мне добавили работы». Это диагностируемо и снимается — см. F.4.
3. **Доверие к агенту строится так же, как к новому коллеге:** сначала под надзором, на мелких задачах, с правом перепроверить, потом — с расширением автономии. Нельзя выдать цифровому сотруднику полную автономию в день один — это как дать новичку ключи от кассы в первый час.

### F.2 Механика, снимающая сопротивление: «человек работает как привык — агент собирает фоном»

Это не лозунг, а **проектное требование к адопшну** (зеркало принципа +A). Главная причина, по которой человек отвергает инструмент — инструмент **меняет его рабочий день и добавляет шагов**. Антидот:

| Анти-паттерн внедрения | Адопшн-механика |
|---|---|
| «Теперь все заявки заводите в новой системе» | Человек продолжает писать в тот же чат/почту/CRM — **агент-collector снимает след фоном**, ничего нового открывать не надо |
| «Заполните 12 полей, чтобы агент сработал» | Агент достаёт поля из того, что человек **и так** пишет; ручной ввод — исключение, не норма |
| «Сначала переучимся, потом включим» | Включаем на реальном потоке **в shadow-режиме** (агент пишет, человек работает по-старому) — нагрузки ноль, доверие растёт на глазах |
| «Агент теперь решает» | Первые недели агент **только предлагает черновик** (drafter/qualifier), решение и подпись — за человеком |

Ключевой ход: **первая ценность приходит человеку раньше, чем первая нагрузка.** Если носитель роли в первую неделю получил «агент за меня собрал сводку / напомнил / подготовил черновик» и при этом НЕ открыл ни одного нового окна — сопротивление снято до того, как возникло.

### F.3 Бюджет, роль и стимулы адопшна

**Правило 20%+ (Deloitte).** Закладывай **минимум 20% усилий/времени/бюджета проекта на адопшн** (коммуникация, обучение, сопровождение носителей, разбор сопротивления), а не на код. Если в плане пилота этой строки нет — пилот в зоне риска по умолчанию. Практически: на каждые 4 дня инженерной работы — 1 день работы с людьми.

**Роль: Steward перехода (Transition Steward).** Отдельная именованная роль (не «по совместительству у техлида»). Это связка между +A/D-слоем и людьми. Не обязательно отдельный человек на фулл-тайм в SMB — но обязательно **названный ответственный**. Его зона:

- держит карту «кто из носителей где на кривой принятия» (см. F.5);
- проводит еженедельный 15-мин разбор сопротивления (кто перестал пользоваться и почему);
- ведёт ритуал «агент ошибся → что чиним» (см. F.6), чтобы ошибка агента не убивала доверие;
- собирает истории успеха и разносит их (peer-proof работает сильнее приказа).

В терминах Governance это **stewardship-уровень 3→4**: переход управляется живой ролью с runtime-обратной связью, а не разовым тренингом.

**Стимулы (что поощрять).** Стимул должен бить в **использование и улучшение агента**, а не в факт «прошёл тренинг»:

- ✅ поощряем: носителя, который **дал агенту обратную связь / нашёл ошибку / предложил правило** — он становится со-автором, а не подопытным;
- ✅ поощряем чемпиона, чей участок первым вышел на стабильное использование — публично, как пример;
- ❌ НЕ привязываем стимул к «экономии ФОТ» и НЕ анонсируем сокращение как цель — это мгновенно превращает агента во врага и гарантирует саботаж;
- ❌ НЕ наказываем за откат к старому способу — откат это диагностический сигнал для Steward, а не проступок.

### F.4 Вовлечение носителей в проектирование агента (co-design)

Агента для роли проектируют **вместе с носителем роли**, а не для него. Носитель — единственный, кто знает реальные edge-кейсы, негласные правила и «как тут на самом деле». Это одновременно снимает сопротивление (соавторство = собственность) и резко повышает качество guardrails.

Практика co-design на старте агента (заполняет карточку +A руками носителя, не за него):

1. **«Покажи, как ты делаешь это сейчас»** — наблюдаем реальный поток, фиксируем `input`/`output`/`data_source`, не идеализируем.
2. **«Где тут самое муторное / что бесит?»** — первая автоматизация бьёт в **боль носителя**, а не в метрику собственника. Так первая ценность достаётся человеку.
3. **«Когда агент НЕ должен решать сам?»** — носитель сам называет красные линии → это становится `guardrails` и `gate` в карточке. Человек, нарисовавший границы, доверяет тому, что внутри них.
4. **«Как поймём, что агент налажал?»** — носитель определяет health-check своими словами → защита от silent failures глазами того, кто заметит первым.

Эффект: к моменту запуска носитель уже считает агента «своим инструментом, который я настроил», а не «штукой, которую мне навязали сверху».

### F.5 Кривая принятия и как по ней вести

Steward держит каждого носителя на одной из стадий и знает следующий шаг:

| Стадия | Признак | Ход Steward'а |
|---|---|---|
| **0. Тревога** | «Меня заменят?» | Личный разговор: что освобождается, что остаётся за человеком (F.7). До снятия страха не обучаем |
| **1. Любопытство** | «Покажи, что оно может» | Демо на ЕГО задаче, не на абстрактной. Shadow-режим |
| **2. Проба под надзором** | пользуется, но всё перепроверяет | Это норма и хорошо. Не торопить с автономией. Фиксируем, где агент стабильно прав |
| **3. Доверие на узком участке** | перестал перепроверять рутину | Расширяем автономию агента **по риску**, точечно. Носитель сам предлагает «это можно отдать» |
| **4. Со-автор** | предлагает новые правила/агентов | Поощряем публично, делаем чемпионом, разносим его кейс соседям |

Правило: **автономию агента двигает не календарь проекта, а стадия носителя.** Нельзя перепрыгнуть стадию 2 «потому что дедлайн».

### F.6 Доверие после ошибки агента (ритуал)

Агент **ошибётся** — это вопрос «когда», не «если». Один разбор «агент налажал → мы тихо это спрятали» убивает адопшн быстрее десяти удачных кейсов. Ритуал Steward'а:

1. Ошибка фиксируется **открыто** в Event Log (`case_id`), не заметается.
2. Разбор без поиска виноватого: это сбой системы/правила, не вина носителя, что «доверился».
3. Чиним **guardrail/правило/health-check**, а не «накажем агента». Носитель видит, что его сигнал → реальное улучшение.
4. Откатываем автономию на участке на стадию назад, пока правило не подтвердилось. **Доверие возвращается дозами, а не объявлением.**

### F.7 Скрипты: что говорить команде

**Главное сообщение (одно, везде одинаково):** «Агент — это **помощник, который снимает с тебя муторное, а не замена тебе.** Он берёт сбор данных, черновики и напоминания — ты остаёшься на решениях, отношениях с клиентом и сложных случаях. Цель — **разгрузить, а не сократить.**»

**Что говорить (✅) / чего не говорить (❌):**

- ✅ «Освобождает твоё время от рутины» / ❌ «Делает твою работу»
- ✅ «Ты остаёшься тем, кто решает и подписывает» / ❌ «Теперь система решает»
- ✅ «Ты его настраиваешь под себя, ты находишь, где он врёт» / ❌ «Просто пользуйся, как сделали»
- ✅ «Сначала он просто подсказывает, ты проверяешь» / ❌ «С завтра работаем только так»
- ✅ «Перестало помогать — скажи, починим» / ❌ «Почему не пользуешься?»

**Ответы на 3 главных возражения:**

- *«Меня заменят»* → «Если бы цель была сократить — не вкладывались бы в то, чтобы ты стал сильнее. Агент снимает то, за что тебя никто не ценит (рутина), и оставляет то, за что ценит (суждение, клиент).»
- *«Мне добавили работы»* → «Если ты открываешь что-то новое или заполняешь поля — это баг, скажи Steward'у. Правильно настроенный агент работает фоном поверх того, что ты и так делаешь.»
- *«Он ошибается, я ему не верю»* → «И правильно, что проверяешь. Доверие — по частям: где он стабильно прав, отдаём ему; где врёт — ты ловишь, мы чиним. Ты не обязан верить ему больше, чем заслужил.»

---

### F.8 Чек-лист готовности адопшна (gate перед раскаткой пилота)

- [ ] Назначен **Steward перехода** (named, не «по совместительству молча»).
- [ ] В плане пилота **≥20%** усилий — на людей/адопшн, отдельной строкой.
- [ ] У каждого затронутого носителя роли проведён **co-design** (карточку агента заполняли его руками).
- [ ] Есть **чемпион** — первый носитель, на ком обкатываем и кого делаем примером.
- [ ] Старт в **shadow-режиме**: первая ценность человеку приходит раньше первой нагрузки.
- [ ] Стимулы бьют в **использование/улучшение**, НЕ в экономию ФОТ; сокращение не заявлено целью.
- [ ] Есть **ритуал разбора ошибки** агента (открыто, без виноватых, чиним правило).
- [ ] Сообщение «помощник, не замена» проговорено **лично** каждому, страх замены снят до обучения.
- [ ] Автономия агента привязана к **стадии носителя** (F.5), не к дедлайну проекта.

> **Анти-паттерн всего контура:** запустить технически идеального агента «приказом сверху», без Steward'а, без co-design, с анонсом экономии ФОТ. Технология сработает, адопшн — нет, пилот попадёт в те самые 95% MIT / 80% RAND провалов. Адопшн-контур — это и есть то, что отделяет работающий пилот от «демо, которым никто не пользуется».

---

## Приложение G · Чек-лист готовности (Definition of Done)

> **Кому.** Внедренцу. Один контур = один лист приёмки. Критерий формулируется как **проверяемое «да/нет»**: либо артефакт существует и проходит тест, либо контур **не готов** — частичной готовности нет. Контекст: SMB без ERP. Принцип сквозной проверки — **system-first**: контур готов не когда «настроен инструмент», а когда работает связка *люди + процесс + данные*.
>
> **Как пользоваться.** Блоки идут по слоям архитектуры, а не в порядке построения (порядок построения один — см. «Генератор внедрения»). Внутри блока идёшь сверху вниз. Контур считается принятым только если отмечены **ВСЕ** строки блока (П — обязательные) и пройден **gate-тест** в конце блока. Строки `(R)` — рекомендованные, не блокируют приёмку, но фиксируются как долг.
> Легенда: `[ ]` не сделано · `[~]` в работе · `[x]` принято.

---

### C1 · Карта бизнеса — `[ ]` контур готов

| ✓ | # | Критерий приёмки (проверяемо) |
|---|----|---|
| `[ ]` | 1 | Карта помещается на **1 экран / 1 лист** (продукт → процессы → люди → управление → инструменты) — без скролла и без второго листа. |
| `[ ]` | 2 | Незнакомый сотрудник **читает и понимает карту за ≤15 мин** без устных пояснений (проверено на живом человеке). |
| `[ ]` | 3 | Заведена **онтология / словарь идентичности**: ключевые сущности (клиент, заказ, лид…) названы **один раз и однозначно**, синонимы сведены. |
| `[ ]` | 4 | Определён **единый `case_id`** — сквозной идентификатор кейса/заказа, проходящий через все процессы. |
| `[ ]` | 5 | Каждый блок карты ссылается на **владельца** (кто отвечает) — нет «ничьих» зон. |
| `[ ]` | 6 (R) | Указан уровень зрелости по каждому блоку (1–5), видна цель скачка 3→4. |

**Gate-тест C1:** дай карту человеку «с улицы» → он за 15 мин называет продукт, 3 ключевых процесса и владельцев. Прошёл → `[x]`.

---

### C2 · Процессы — `[ ]` контур готов

| ✓ | # | Критерий приёмки (проверяемо) |
|---|----|---|
| `[ ]` | 1 | Каждый ключевой процесс описан как **триггер → шаги → результат** (а не «отдел делает X»). |
| `[ ]` | 2 | Для каждого процесса есть **SIPOC** (Supplier–Input–Process–Output–Customer) — заполнены все 5 колонок. |
| `[ ]` | 3 | Все **handoffs (передачи между ролями)** явно помечены: кто → кому → что передаёт. |
| `[ ]` | 4 | На каждой передаче зафиксирован **критерий «годен/не годен»** — что считается корректным входом следующего шага. |
| `[ ]` | 5 | Процесс привязан к `case_id` из C1 — видно, как кейс движется по шагам. |
| `[ ]` | 6 (R) | Помечены «узкие места» / точки накопления очереди для будущего process mining (C5). |

**Gate-тест C2:** возьми реальный кейс → пройди его по карте процесса от триггера до результата без «а тут спросим у Васи». Прошёл → `[x]`.

---

### C3 · Люди — `[ ]` контур готов

| ✓ | # | Критерий приёмки (проверяемо) |
|---|----|---|
| `[ ]` | 1 | **Роль отделена от исполнителя**: в карте — роли (role_slot), а не фамилии. |
| `[ ]` | 2 | Для каждой роли указан **тип исполнения**: `человек` / `человек + AI-помощник` / `цифровой сотрудник`. |
| `[ ]` | 3 | Построена **RACI** по ключевым процессам: на каждый шаг — ровно один **A** (Accountable). |
| `[ ]` | 4 | Зафиксированы **каналы** коммуникации/входа для каждой роли (где роль принимает работу). |
| `[ ]` | 5 | Прорисован **value-stack**: исполнение → надзор → цели (видно, кто исполняет, кто контролирует, чьи цели). |
| `[ ]` | 6 (R) | Нет роли без владельца и без канала; «осиротевшие» задачи не висят между ролями. |

**Gate-тест C3:** для любого шага процесса мгновенно отвечаешь «кто Accountable и каким типом исполнения закрыт». Прошёл → `[x]`.

---

### +A · Агенты (слой поверх людей) — `[ ]` контур готов

| ✓ | # | Критерий приёмки (проверяемо) |
|---|----|---|
| `[ ]` | 1 | Заведён **реестр агентов** — единый список, ничего «теневого» вне реестра. Кандидаты из очереди внедрения стоят в реестре со статусом `draft`; критерии ниже относятся к агентам со статусом `active`. |
| `[ ]` | 2 | У **каждого агента** заполнена **карточка-стандарт** (все поля): `id · name · type · mode(assistant\|digital-employee) · purpose · input · output · data_source · data_sink · schedule · runbook · autonomy · guardrails · gate · owner · role_slot · connectors · status · health`. |
| `[ ]` | 3 | У каждого агента есть **owner** (человек-владелец) — нет агентов «ничьих». |
| `[ ]` | 4 | У каждого агента есть **runbook** (что делает, как перезапустить, что при сбое) и привязка к **role_slot** из C3. |
| `[ ]` | 5 | Прописан **mode**: `assistant` (помощник при человеке) ИЛИ `digital-employee` (с коннекторами) — без размытости. |
| `[ ]` | 6 | Каждый агент относится к одному из **5 архетипов** (collector / drafter / qualifier / router / reconciler) и **узок** — одна задача, не «делает всё». |
| `[ ]` | 7 | Заданы **guardrails** и **human-in-the-loop gate** на действиях с последствиями. |
| `[ ]` | 8 | **Автономия выставлена по риску**: чем необратимее действие — тем ниже автономия. |
| `[ ]` | 9 | На **необратимых действиях автономия = 0** (всегда человек на gate); единственное исключение — платежи в жёстком лимите на стадии 5. Проверено перечнем необратимых операций. |
| `[ ]` | 10 | У каждого агента работает **health-check** против silent failures: видно «жив/мёртв», а не тишина. |
| `[ ]` | 11 | Соблюдён принцип адопшна: **человек работает как привык — агент собирает фоном** (агент не ломает существующий workflow). |
| `[ ]` | 12 (R) | Для `digital-employee` коннекторы перечислены и протестированы на тестовом кейсе. |

**Gate-тест +A:** выбери случайного агента со статусом `active` из реестра → у него есть owner, runbook, health горит «жив», автономия соответствует риску, на необратимом — ноль. Любой «нет» → контур **не готов**.

---

### C4 · Регламенты → AOP — `[ ]` контур готов

| ✓ | # | Критерий приёмки (проверяемо) |
|---|----|---|
| `[ ]` | 1 | Регламент оформлен как **исполнимый AOP-контракт** (машиночитаемый/исполнимый), **а не PDF** для чтения. |
| `[ ]` | 2 | Пройден **чек-лист полноты AOP**: вход, шаги, выход, исключения, владелец — ничего не пропущено. |
| `[ ]` | 3 | Подключён **drift-detector**: расхождение «регламент vs реальное исполнение» детектится, а не копится молча. |
| `[ ]` | 4 | Соблюдён принцип **«research writes, delivery reads»**: контур, который пишет регламент, и контур, который его исполняет, разделены. |
| `[ ]` | 5 | AOP привязан к процессу из C2 и ролям из C3 (исполнимый контракт лежит на реальном процессе). |
| `[ ]` | 6 (R) | При срабатывании drift есть назначенный owner-реакции (кто чинит расхождение). |

**Gate-тест C4:** внеси заведомое отклонение в исполнение → drift-detector его поймал и указал владельца. Прошёл → `[x]`.

---

### D · Данные → SSOT — `[ ]` контур готов

| ✓ | # | Критерий приёмки (проверяемо) |
|---|----|---|
| `[ ]` | 1 | Работает **Event Log**: каждая запись = `case_id + activity + timestamp + actor`. Все 4 поля заполняются. |
| `[ ]` | 2 | Event Log **живой** — события пишутся в реальном времени по факту работы, не задним числом и не вручную «для галочки». |
| `[ ]` | 3 | Есть **State Store** (SQL / граф), который **агенты ОБНОВЛЯЮТ** (write), — **а не read-only RAG**. Проверено: агент пишет состояние, оно меняется. |
| `[ ]` | 4 | Заведён **Context Layer** (слой контекста поверх State Store), к которому обращаются агенты. |
| `[ ]` | 5 | Определены **data contracts** на ключевые потоки: формат/поля/владелец каждого потока зафиксированы. |
| `[ ]` | 6 | Соблюдён принцип **данные ≠ знания**: сырые данные (Event Log/State) отделены от выводов/знаний. |
| `[ ]` | 7 | В SMB-режиме (нет ERP): подтверждено, что **агенты порождают цифровой след с нуля** — данные появляются от работы агентов, не из мифического ERP. |
| `[ ]` | 8 (R) | `case_id` сквозной: один кейс прослеживается из Event Log в State Store и обратно в C1/C2. |

**Gate-тест D:** запусти один кейс → событие появилось в Event Log (4 поля), State Store обновился агентом, контекст доступен. Если State Store read-only/RAG — контур **не готов**.

---

### C5 · Контроль + Дашборд — `[ ]` контур готов

| ✓ | # | Критерий приёмки (проверяемо) |
|---|----|---|
| `[ ]` | 1 | Дашборд **actionable**: отвечает на вопрос **«что делать сегодня»**, а не «как было в прошлом месяце» (≠ отчётность). |
| `[ ]` | 2 | Работает **process mining: план vs факт** — реальный ход процессов (из Event Log) сверяется с целевым из C2. |
| `[ ]` | 3 | Есть **semantic / metrics layer**: каждая метрика считается **один раз, governed** (одно определение, один источник расчёта). |
| `[ ]` | 4 | Соблюдён **детерминизм**: расчёт метрик **вне LLM** (цифры считает движок, не модель). |
| `[ ]` | 5 | Дашборд питается из SSOT (D), а не из ручных выгрузок/Excel «на коленке». |
| `[ ]` | 6 (R) | На каждом сигнале дашборда есть «следующее действие» и владелец действия. |

**Gate-тест C5:** открой дашборд → за 1 минуту называешь 3 конкретных действия «на сегодня» с владельцами, и каждая цифра имеет единственное governed-определение. Прошёл → `[x]`.

---

### Governance — `[ ]` контур готов

| ✓ | # | Критерий приёмки (проверяемо) |
|---|----|---|
| `[ ]` | 1 | Есть **конституция** — письменный набор правил, выше любого отдельного узла/агента. |
| `[ ]` | 2 | Архитектура — **федерация суверенных узлов**: узлы автономны, но подчинены конституции. |
| `[ ]` | 3 | Правила **enforced в runtime** (исполняются машиной/системой), **а не «комитетами»** и совещаниями. |
| `[ ]` | 4 | Выстроен **stewardship-уровень 3→4** (целевой скачок зрелости подтверждён, не остался на «зоопарке»). |
| `[ ]` | 5 | **Автономия-по-риску** действует на уровне governance, не только у отдельных агентов. |
| `[ ]` | 6 | Пройден **чек-лист слепых зон по Минцбергу** — конфигурации/координационные механизмы проверены, белых пятен в управлении нет. |
| `[ ]` | 7 (R) | Конституция версионируется и у неё есть владелец-стюард. |

**Gate-тест Governance:** введи правило в конституцию → оно срабатывает автоматически в runtime на реальном действии (а не «договорились на встрече»). Прошёл → `[x]`.

---

### Сводный лист приёмки фреймворка

| Контур | Готов? | Главный gate (одной строкой) |
|---|---|---|
| **C1** Карта | `[ ]` | 1 экран · читается за 15 мин · онтология + `case_id` |
| **C2** Процессы | `[ ]` | триггер→шаги→результат · SIPOC · handoffs с критерием годности |
| **C3** Люди | `[ ]` | роль≠исполнитель · RACI (1 A на шаг) · value-stack |
| **+A** Агенты | `[ ]` | owner + runbook + health у каждого · автономия-по-риску · **0 на необратимом** |
| **C4** AOP | `[ ]` | исполнимый контракт + drift-detector · «research writes, delivery reads» |
| **D** Данные | `[ ]` | Event Log живой · **State Store обновляется агентом, не RAG** |
| **C5** Контроль | `[ ]` | actionable «что сегодня» · process mining план/факт · 1 governed-расчёт |
| **Gov** | `[ ]` | конституция · федерация узлов · runtime-enforcement (не комитеты) |

**Definition of Done фреймворка:** все 8 строк сводного листа (7 контуров + сквозной слой Governance) = `[x]`. Один `[ ]` → организация **не AI-native**, а на предыдущем уровне зрелости — точку разрыва ищи в незакрытом контуре.

---

## Приложение H · Опросник подготовки

→ Перенесено в начало файла: Часть 2 «Инструменты разбора».

---

## Приложение I · Runbook / failure-playbook

> **Назначение.** Операционная инструкция для внедренца: что делать в момент, когда что-то сломалось. Каждый сценарий — по схеме **Признак → Немедленные шаги (≤30 мин, остановить кровь) → Как чинить (root cause) → Как предотвратить (встроить в систему)**. Контекст — SMB без ERP: данные и след агенты порождают с нуля, источник правды — SSOT (Event Log + State Store), контракт работы — AOP, надзор — Дашборд «что делать сегодня».
>
> **Общий рефлекс на любой инцидент:** (1) объяви severity (P1 деньги/клиент/необратимое · P2 сломан процесс · P3 деградация); (2) зафиксируй в Event Log событие `incident_open` с `case_id`; (3) если затронут агент — переведи его `autonomy` в `L0` (предлагает, не делает) или `status=paused`, не удаляй; (4) назначь одного владельца инцидента (не комитет); (5) закрой событием `incident_close` + строка в журнал инцидентов.
>
> **Журнал инцидентов (завести один на организацию):** `date · case_id · сценарий(1–6) · severity · агент/узел · признак · действие · root cause · превентив · owner · статус`.

---

### Сценарий 1 — Агент тихо перестал собирать след (silent failure)

Самый опасный класс: ничего не падает с ошибкой, агент просто не пишет в Event Log, и вы узнаёте об этом через недели по дырам в данных.

**Признаки**

- В Event Log по `case_id` нет событий от данного `actor`-агента за период, где они должны быть (план vs факт по process mining расходится «в ноль»).
- `health`-поле в карточке/реестре давно не обновлялось (нет heartbeat).
- Дашборд «что делать сегодня» по этому контуру пуст или подозрительно «чисто».
- Растёт ручная работа у человека, чьего агента-collector'а «не слышно».

**Немедленные шаги (≤30 мин)**

1. Проверь heartbeat: когда последний раз агент писал ЛЮБОЕ событие (включая `run_ok`)? Если давно — подтверждён silent failure.
2. Не доверяй пустоте: вручную дёрни один тестовый прогон (`runbook`-команда из карточки) на известном входе, посмотри, появляется ли событие в Event Log.
3. Оцени дыру: за какой период не собирался след, по каким `case_id`. Помечаем эти кейсы как `trail_gap` — данные за этот период считаем неполными, не строим на них решения.
4. Подними `autonomy` уведомлений: пока агент чинится, ответственный человек собирает след вручную (адопшн-принцип «человек работает как привык» — процесс не встаёт).

**Как чинить (root cause)**

- Триаж по слоям: (a) коннектор отвалился → см. Сценарий 6; (b) изменился вход (формат письма/файла/поля) → агент молча не матчит и выходит «пусто» — почини парсер/контракт входа; (c) сменился `schedule`/планировщик не триггерит → проверь cron/триггер; (d) тихой ловлей исключения агент глотает ошибку → убери «проглатывание», ошибка обязана стать событием.
- Бэкафилл: восстанови потерянный след, где возможно (из писем/CRM/файлов за период `trail_gap`), и допиши недостающие события в Event Log с пометкой `backfilled=true`.

**Как предотвратить**

- **Heartbeat обязателен.** Каждый агент при каждом прогоне пишет событие даже когда «делать нечего» (`run_ok, items=0`). Отсутствие heartbeat = алерт, а не тишина.
- **Health-check как отдельный watcher-агент** (reconciler-архетип): раз в N часов сверяет «когда каждый агент последний раз отчитывался» против его `schedule` и поднимает на Дашборд просроченные.
- **Dead-man's switch:** ноль событий там, где план их ждёт > X часов → P2-алерт владельцу.
- В карточке агента поле `health` делаем живым (`heartbeat`, `alert_if`, `last_ok`; число обработанных — в журнале прогонов), а не декоративным.
- Узкие агенты: чем уже агент, тем заметнее его молчание — не лепи «универсала», который частично работает и этим маскирует сбой.

---

### Сценарий 2 — Данные поплыли: дубли / противоречия в SSOT

Один `case_id` имеет два конфликтующих состояния; дубли сущностей; State Store разошёлся с реальностью.

**Признаки**

- Один и тот же клиент/сделка/заявка существует под двумя `case_id` (дубли).
- В State Store по одному `case_id` поля противоречат друг другу или последнему событию Event Log.
- Метрики на Дашборде «не бьются» (сумма частей ≠ целому); два агента пишут в одно поле разное.
- Жалоба от человека: «в системе не то, что на самом деле».

**Немедленные шаги (≤30 мин)**

1. **Заморозь запись** проблемной сущности: агенты-`reconciler`/`router`, пишущие в спорные `case_id`, → `L0`. Чтение не трогаем.
2. Зафиксируй расхождение в `contradictions/` (две версии + источник каждой), **не перезаписывай тихо** одну другой.
3. Определи «истину»: **Event Log — первичен** (это лог фактов), State Store — производная проекция. Если они разошлись — прав Event Log.
4. Останови «кровотечение дублей»: временно включи блокировку создания новой сущности без проверки на дубль (см. ниже dedup-ключ).

**Как чинить (root cause)**

- **Дубли:** определи естественный ключ дедупа (email+телефон / ИНН / номер заказа). Слей дубли: выбери выживающий `case_id`, перенаправь события второго на него (`merged_into`), архивируй дубль. Запиши событие `merge`.
- **Противоречия:** пересобери State Store из Event Log (replay событий по `case_id` в хронологии) — это вернёт согласованное состояние. Поле, которое пишут двое, — нарушение data contract: назначь **одного владельца записи** на поле (single-writer).
- Найди источник дрейфа: ручной ввод в обход агента? два агента без разграничения? отсутствие idempotency (повторный прогон создаёт второй экземпляр)?

**Как предотвратить**

- **Event Log = append-only, immutable.** State Store всегда выводим из него (можно пересобрать) — это и есть страховка от «поплывших» данных.
- **Data contracts:** на каждое поле — один writer-агент (`actor`), формат, допустимые значения, источник. Поле без владельца записи запрещено.
- **Dedup-ключ на входе:** перед `create` агент обязан искать существующую сущность по естественному ключу (upsert, не blind insert).
- **Idempotency:** повторный прогон на том же входе не создаёт дубль (ключ идемпотентности на событие).
- **Reconciler-агент** регулярно сверяет State Store ↔ Event Log ↔ внешние источники и поднимает расхождения в `contradictions/`, а не молча «решает».
- **Semantic/metrics layer:** одна governed-формула на метрику — «сумма не бьётся» обычно значит два разных расчёта, а не битые данные.

---

### Сценарий 3 — AOP нарушен / drift

AOP — исполнимый контракт процесса (триггер→шаги→результат, handoffs, gate'ы), а не PDF. «Drift» — фактический процесс разошёлся с тем, что записано в AOP.

**Признаки**

- Drift-detector / process mining показывает маршруты, которых нет в AOP (новые шаги, пропущенные шаги, обход gate'а).
- Handoff'ы случаются не туда / не тому `role_slot`, чем предписано.
- «Так уже все давно делают» — фактический регламент устно мутировал, AOP не обновлён.
- Шаг, помеченный как gate (human-in-the-loop), фактически проскакивается.

**Немедленные шаги (≤30 мин)**

1. Классифицируй drift: **(A) AOP отстал** (реальность лучше, контракт устарел) или **(B) процесс деградировал** (реальность хуже/опасна, контракт прав). Это разные диагнозы.
2. Если (B) и затронут gate/деньги/клиент — немедленно верни обязательность gate'а: агенты на этом шаге → `L0`, шаг проходит только через человека, пока не починим.
3. Локализуй: на каком шаге и в каком проценте кейсов расхождение (process mining: план vs факт).

**Как чинить (root cause)**

- **Случай (A):** реальный процесс улучшился — обнови AOP под факт (новая версия контракта, changelog), переразведи handoffs/gate'ы, перепривяжи агентов. AOP — живой документ, обновление = норма.
- **Случай (B):** процесс самовольно срезал углы — верни поведение к контракту: почини маршрутизацию `router`-агента, восстанови пропущенные шаги/гейты, разбери с исполнителями почему обходили (часто gate тормозит — тогда пересмотри его уместность, а не выключай).
- Проверь чек-лист полноты AOP: у каждого шага есть вход/выход, owner (`role_slot`), gate где нужно, и след пишется в Event Log.

**Как предотвратить**

- **Drift-detector включён постоянно** (continuous process mining план vs факт), а не разовый аудит. Drift — это сигнал на Дашборд, а не находка раз в квартал.
- **AOP исполним и версионируем:** контракт хранится рядом с процессом, у него changelog; «research writes, delivery reads» — синтез/правила пишутся в одном месте, исполнение читает оттуда (нет двух расходящихся копий).
- **Runtime-enforcement, не комитеты:** gate'ы зашиты в маршрут (router физически не пускает дальше без отметки человека), а не держатся на дисциплине.
- Регулярный review дрейфующих шагов: повторяющийся drift в одну сторону = AOP пора обновлять (узаконить факт).

---

### Сценарий 4 — Ушёл ключевой человек (риск ключевого лица / SPOF)

В SMB критичные знания, доступы и «как тут всё работает» часто завязаны на одном человеке. Уход = провал процесса, потеря следа, осиротевшие агенты.

**Признаки (в т.ч. до ухода — это управляемый риск)**

- Один `role_slot` держит несколько критичных процессов и не дублирован; нет преемника.
- Агенты с `owner` = этот человек; коннекторы/OAuth заведены под его личный аккаунт.
- Знания процесса — «в голове», AOP неполон, на него нет doc.
- Доступы (ключи, токены, пароли) персональные, не сервисные.

**Немедленные шаги (≤30 мин — режим «человек ушёл»)**

1. Инвентаризируй зону: какие процессы (C2), `role_slot`'ы (C3), агенты (+A), коннекторы/доступы (OAuth) висели на нём. Реестр агентов + карта бизнеса дают список за минуты.
2. **Спаси доступы первыми:** агенты с коннекторами под его аккаунтом отвалятся при отзыве учётки — переведи их на сервисные учётки или зафиксируй, что отзыв сломает интеграцию (синхронизируй с Сценарием 6, чтобы не получить каскад).
3. Переназначь `owner` всех его агентов и `role_slot`'ов на временного держателя; ничего не оставляй без владельца.
4. Подними AOP затронутых процессов: где не хватает шагов/знаний — пометь как `knowledge_gap`, временно усиль human-in-the-loop.

**Как чинить (root cause)**

- Перевести персональные интеграции на **сервисные/организационные учётки** (не личные).
- Достроить AOP осиротевших процессов до исполнимого состояния (чтобы преемник работал по контракту, а не по легенде).
- Распределить нагрузку `role_slot` между людьми/агентами; где знание было «в голове» — оцифровать в Context Layer / AOP.

**Как предотвратить**

- **Bus-factor аудит** (часть Governance / Минцберг-чек-лист слепых зон): для каждого критичного процесса — минимум двое, кто может его вести; для каждого агента — `owner` + заместитель.
- **Принцип «агент собирает след фоном» сам по себе снижает SPOF:** знание процесса материализуется в Event Log + AOP, а не остаётся приватным у человека. Это ключевая страховка — система переживает уход людей, потому что след и контракт внешние.
- Никаких личных учёток в интеграциях — только сервисные (см. Сценарий 6, превентив).
- Федерация суверенных узлов: узел не должен быть «одним человеком» — у узла есть конституция и реестр, переживающие смену исполнителя.
- Регулярно: «что сломается, если завтра не выйдет X?» — на Дашборд как управляемый риск, не как сюрприз.

---

### Сценарий 5 — Агент сделал необратимое без gate

Отправил письмо клиенту, провёл платёж, удалил данные, изменил запись у внешнего контрагента — действие, которое нельзя откатить, прошло без человеческой отметки. **P1 по умолчанию.**

**Признаки**

- В Event Log — событие необратимого действия (`sent`/`paid`/`deleted`/`pushed`) от агента БЕЗ предшествующего `gate_approved`.
- Жалоба извне: клиент/контрагент получил то, что не должен был.
- Автономия агента оказалась выше риска действия (делал сам там, где требовался human-in-the-loop).

**Немедленные шаги (≤30 мин)**

1. **Стоп-кран:** агент → `status=paused` немедленно (не `L0` — полная остановка), чтобы исключить повтор/серию.
2. Оцени масштаб: одно действие или серия? Сколько `case_id` затронуто? (запрос в Event Log по `actor` + типу события за окно).
3. **Containment / митигация ущерба:** что из необратимого можно частично смягчить — отзыв письма, стоп-платёж, уведомление контрагента, восстановление из бэкапа удалённого. Действуй по приоритету «деньги/клиент».
4. Уведоми владельца процесса и, если задет клиент/контрагент, подготовь коммуникацию.

**Как чинить (root cause)**

- Найди дыру в gate: в карточке агента `autonomy` была выставлена выше риска ИЛИ `gate` для этого действия не был объявлен ИЛИ gate был, но не enforced (декларация без runtime-проверки).
- Понизь `autonomy` агента до уровня действия: **необратимые операции = всегда human-in-the-loop** (suggest, человек подтверждает); единственное исключение — платежи в жёстком лимите на стадии 5.
- Зашей gate в маршрут так, чтобы действие физически не выполнялось без события `gate_approved` (runtime-enforcement).

**Как предотвратить**

- **Автономия-по-риску — главный принцип:** обратимое и дешёвое → агент сам; необратимое/деньги/внешняя коммуникация → обязательный human gate (единственное исключение — платежи в жёстком лимите на стадии 5). Уровень автономии в карточке выводится из риска действия, а не из удобства.
- **Gate как код, не как договорённость:** агент не имеет технической возможности совершить необратимое действие без `gate_approved` в Event Log. Нет отметки — действие блокируется на уровне коннектора.
- **Guardrails:** для каждого необратимого действия — отдельный guardrail (лимиты сумм, белые списки получателей, dry-run по умолчанию).
- **Узкие агенты + два режима:** агент-`drafter` готовит, человек/другой шаг отправляет — разделение «готовит ≠ совершает». Цифровой сотрудник с коннекторами получает право на необратимое только под явный gate.
- Регулярный аудит карточек: «у какого агента `autonomy` выше риска его действий?» — на Дашборд.

---

### Сценарий 6 — OAuth / интеграция отвалилась

Коннектор агента к внешнему сервису (почта, CRM, календарь, платёжка, мессенджер) перестал работать: протух токен, отозван доступ, сменился scope/API, упал rate-limit.

**Признаки**

- Ошибки авторизации (401/403, `invalid_grant`, `token expired`) в логах коннектора; `health` агента = degraded.
- Агент перестал собирать/писать через этот коннектор → часто проявляется как Сценарий 1 (silent failure), если коннектор глотает ошибку.
- Источник `data_source`/`data_sink` агента недоступен; рассинхрон с внешним сервисом.
- Массовый отвал нескольких агентов сразу = отозвана/просрочена общая учётка (часто следствие Сценария 4).

**Немедленные шаги (≤30 мин)**

1. Подтверди границу сбоя: один коннектор или несколько? Один агент или общая учётка? (если несколько разом — корень в учётке/доступе, не в агенте).
2. Затронутые агенты → `L0`/`paused`, чтобы не копили ошибочные/пустые прогоны и не маскировали дыру.
3. Включи ручной режим на критичный процесс (человек собирает след вручную за период недоступности — `trail_gap` пометка), процесс не встаёт.
4. Переавторизуй, если тривиально (повторный OAuth-flow / обновить refresh-token / поднять лимит). Проверь тестовым прогоном, что событие снова пишется.

**Как чинить (root cause)**

- Классифицируй: (a) истёк/отозван токен → переавторизация, ротация refresh-token; (b) сменился scope/permission → перевыдать доступ с нужным scope; (c) изменился внешний API/формат → обнови контракт коннектора и парсер (часто пересекается с Сценарием 2 — поплывшие данные); (d) rate-limit → бэкофф/троттлинг, разнести расписание; (e) учётка-человек отозвана → перевести на сервисную (Сценарий 4).
- Бэкафилл пропущенного за окно недоступности (из внешнего сервиса за период) в Event Log с `backfilled=true`.

**Как предотвратить**

- **Только сервисные/организационные учётки** для интеграций — не личные аккаунты сотрудников (это и анти-SPOF, Сценарий 4).
- **Мониторинг токенов:** алерт за N дней до истечения; авто-ротация refresh-token где возможно. Коннектор обязан превращать ошибку авторизации в событие + алерт, а не глотать (анти-silent-failure).
- **Контракт коннектора в карточке:** `connectors` фиксирует сервис, scope, тип учётки, владельца, срок; ревизия при смене API.
- **Health-check коннектора отдельно от логики агента:** «живость доступа» проверяется пингом, не только при рабочем прогоне.
- **Graceful degradation:** при отвале коннектора процесс падает на ручной режим с явной пометкой, а не делает вид, что работает (тихая пустота — худший исход).

---

### Шпаргалка-матрица (для печати у внедренца)

| # | Сценарий | Мгновенный рефлекс | Главный превентив |
|---|---|---|---|
| 1 | Silent failure | Проверь heartbeat → тестовый прогон → пометь `trail_gap` | Обязательный heartbeat + health-check watcher + dead-man's switch |
| 2 | Дубли / противоречия SSOT | Заморозь запись → в `contradictions/` → replay из Event Log | Event Log append-only + data contracts (single-writer) + dedup-ключ + idempotency |
| 3 | AOP drift | Классифицируй A(контракт отстал)/B(процесс деградировал) → верни gate если B | Drift-detector постоянно + AOP исполним/версионируем + runtime-enforcement |
| 4 | Ушёл ключевой человек | Инвентаризуй зону → спаси доступы → переназначь owner | Bus-factor ≥2 + сервисные учётки + знание в Event Log/AOP, не «в голове» |
| 5 | Необратимое без gate | `status=paused` → масштаб → containment | Автономия-по-риску + gate как код + guardrails + «готовит ≠ совершает» |
| 6 | OAuth / интеграция | Граница сбоя → L0 → переавторизация → бэкафилл | Сервисные учётки + мониторинг истечения токенов + health-check коннектора |

**Сквозные правила всех шести сценариев:** (1) при сбое агент **паузится, не удаляется** — карточка и история нужны для разбора; (2) потерянный след помечается `trail_gap` и по возможности бэкафиллится с `backfilled=true` — нельзя строить решения на дырявых данных; (3) каждый инцидент = строка в журнале инцидентов с root cause и превентивом; (4) превентив всегда встраивается в систему (heartbeat, contract, gate-as-code, drift-detector), а не в память человека — иначе он не переживёт Сценарий 4.

---

## Приложение J · Метрики-дерево (примеры)

> **Назначение.** Готовые деревья метрик под 3 типа SMB. Каждая метрика — *actionable*: ведёт к конкретному решению собственника, не к «отчёту ради отчёта» (C5: actionable ≠ reporting). Все берутся из SSOT (D: Event Log `case_id+activity+timestamp+actor` → State Store), считаются в **metrics layer** одним governed-расчётом — никаких LLM в числах (принцип «детерминизм: расчёт вне LLM»). Где метрика связана с агентом — указан источник-агент; «силент-фейл» агента ловится health-check'ом, а не глазами собственника.
>
> **Как читать «тревогу».** Тревога = триггер для решения, не для нервов. Сработала → собственник делает шаг из колонки, не «принимает к сведению».
>
> **Минцберговские «слепые зоны» 🔶** — там, где цифра выглядит здоровой, но прячет управленческий провал (метрика по-среднему маскирует хвост, ведущий показатель отсутствует, либо данные генерит сам исполнитель = конфликт интересов). В дашборде эти строки помечать значком и НЕ агрегировать вслепую.
>
> **Структура дерева (одинакова для всех типов):** вершина = **1 метрика собственника** (деньги/выживание) → 3–4 драйвера (что на неё влияет) → ведущие операционные метрики (на что можно повлиять сегодня). В дашборде: верх — крупно, драйверы — средне, операционка — мелко/по клику.

---

### J.1 · Услуги / сервис (агентство, студия, консалтинг, ремонт-под-ключ услугами)

**Вершина дерева:** `Маржинальная прибыль за месяц` ← объём оплаченных работ − себестоимость часов − простой.
**Драйверы:** загрузка людей · скорость денежного цикла · удержание клиента · качество (переделки).

| # | Метрика | Владелец | Источник (SSOT) | Норма / порог | 🔔 Тревога → решение | Частота |
|---|---|---|---|---|---|---|
| 1 | **Billable utilization** (оплачиваемые часы / доступные часы) | Операционный директор | Event Log: `activity=time_logged`, actor=исполнитель → State Store | 65–80% | <60% 2 нед → срезать найм / искать спрос; >90% → нанимать, риск выгорания | Неделя |
| 2 | **Маржа по проекту** (план vs факт часов) | Менеджер проекта | State Store: смета vs `time_logged`; process mining план/факт | факт ≤ 110% плана | факт >130% → стоп-ревью проекта, пересмотр сметы клиенту | По закрытии этапа |
| 3 🔶 | **Средний срок оплаты счёта (DSO)** | Финансы | Event Log: `invoice_sent` → `payment_received` (Δ дней) | ≤ 14 дней | >30 дней → стоп новых работ клиенту до предоплаты | Неделя |
| 4 | **Воронка: лид → счёт → оплата** (конверсия по стадиям) | Собственник / РОП | Event Log стадий сделки; агент-qualifier как `data_source` | конверсия лид→сделка ≥ 20% | провал любой стадии −30% м/м → разбор стадии, не «всей воронки» | Неделя |
| 5 | **Доля переделок / правок сверх контракта** | Тимлид | Event Log: `activity=rework`, тег причины | ≤ 8% часов | >15% → корневой разбор (бриф? компетенция? клиент?) | Неделя |
| 6 🔶 | **NPS / повторные обращения** (повтор + рекомендации) | Аккаунт | State Store: `repeat_order`, опрос (агент-collector) | повторных ≥ 35% | <20% → программа удержания, личные звонки топ-клиентам | Месяц |
| 7 | **Pipeline coverage** (сумма открытых сделок / план месяца) | Собственник | State Store: сумма сделок в стадиях | ≥ 3× плана | <2× → включить лидген/реактивацию сейчас, не в конце месяца | Неделя |
| 8 | **Концентрация выручки** (доля топ-1 клиента) | Собственник | State Store: revenue by client | ≤ 25% | >40% → диверсификация, риск потери ключевого | Месяц |

> 🔶 **Слепые зоны блока.** (3) DSO «по среднему» скрывает 1–2 хронических неплательщиков — рядом всегда держать *список* счётов >30 дней, не только среднее. (6) NPS, собранный самим исполнителем у клиента, завышен (конфликт интересов) — источник опроса = независимый агент-collector, не аккаунт-менеджер. Ведущий индикатор оттока — *снижение частоты заказов*, а не сам уход; следить за пунктом 6 как за **leading**, не lagging.

---

### J.2 · Стройка / монтаж / подряд (объекты, бригады, прорабы)

**Вершина дерева:** `Прибыль по объекту на момент сдачи` ← смета − факт затрат − штрафы за срыв − гарантийные переделки.
**Драйверы:** график (план/факт по этапам) · перерасход материалов · кассовый разрыв (авансы vs закупки) · качество приёмки.

| # | Метрика | Владелец | Источник (SSOT) | Норма / порог | 🔔 Тревога → решение | Частота |
|---|---|---|---|---|---|---|
| 1 🔶 | **Отклонение графика по этапам** (план/факт дни) | Прораб | Event Log: `stage_started/closed`, timestamp; process mining | ≤ +5% к плану | >2 этапа подряд просрочены → перебросить бригаду / эскалация заказчику | 2–3×/нед |
| 2 | **Перерасход материалов** (факт / смета по позиции) | Снабженец | Event Log: `material_issued`, накладные; State Store | ≤ 105% | >115% по позиции → проверка воровства/брака/пересчёта сметы | Неделя |
| 3 | **Маржа объекта в реальном времени** (смета − затраты на дату) | Собственник | State Store: бюджет vs `cost_booked` (труд+материал) | ≥ план − 5% | проседание к 0% при незакрытом объёме → стоп-совещание | Неделя |
| 4 🔶 | **Кассовый разрыв по объекту** (полученные авансы − оплаченные закупки/ЗП) | Финансы | Event Log: `payment_in` / `payment_out` по `case_id=объект` | ≥ 0 (не уходить в минус) | <0 → стоп-закупки, требовать транш заказчика | Неделя |
| 5 | **Выработка бригады** (объём работ / человеко-смена) | Прораб | Event Log: `work_done` (м²/п.м.) ÷ табель смен | ≥ норматив бригады | <80% норматива 2 нед → разбор: простой? материал? люди? | Неделя |
| 6 | **Простой по причинам** (часы: нет материала / нет фронта / погода / люди) | Прораб | Event Log: `idle` с тегом причины (агент-collector с объекта) | ≤ 10% времени | >20% → устранить топ-причину простоя по Парето | Неделя |
| 7 | **Дефекты на приёмке этапа** (замечаний / этап) | Технадзор | Event Log: `defect_logged` на приёмке | ≤ 3, критических 0 | критический дефект → стоп-этап, переделка до подписания | По этапу |
| 8 🔶 | **Дебиторка заказчиков** (подписанные акты без оплаты) | Финансы | Event Log: `act_signed` → `payment_received` | ≤ 21 день | >45 дней → юрист / приостановка работ | Неделя |

> 🔶 **Слепые зоны блока.** (1) График «в среднем по объекту в графике» скрывает критический путь — смотреть отклонение *этапа на критическом пути*, не среднее по всем. (4) Кассовый разрыв — главный убийца подрядчика, но *не виден в прибыли*: объект может быть прибыльным «на бумаге» и одновременно банкротить кассу — это **отдельная** ось, держать рядом с маржой. (8) Данные о готовности и простоях часто заполняет сам прораб (конфликт интересов: он же за это отвечает) — сверять фото-фиксацией/агентом-collector с объекта, а не верить ручному отчёту.

---

### J.3 · Торговля / e-commerce / опт-розница (товарка, склад, закупки)

**Вершина дерева:** `Валовая прибыль − стоимость замороженного капитала` (зарабатываем на обороте, не на складе).
**Драйверы:** оборачиваемость запаса · наличие ходовых SKU · маржинальность с учётом возвратов/скидок · стоимость привлечения.

| # | Метрика | Владелец | Источник (SSOT) | Норма / порог | 🔔 Тревога → решение | Частота |
|---|---|---|---|---|---|---|
| 1 🔶 | **Оборачиваемость запасов** (COGS / средний сток), дни | Закупки | State Store: остатки + `sale`/`purchase` из Event Log | ≤ 45 дней (по категории) | >90 дней → распродажа неликвида, стоп-закуп категории | Неделя |
| 2 | **Out-of-stock по ходовым SKU** (% топ-SKU с нулём) | Категорийный менеджер | Event Log: `stock_level` vs ABC-список; агент-reconciler склада | ≤ 3% по A-группе | любой A-SKU в нуле → срочный дозаказ, проверка точки заказа | Ежедневно |
| 3 | **Gross margin после возвратов и скидок** (чистая маржа сделки) | Собственник | Event Log: `sale − discount − return − cost` | ≥ целевой % категории | падение >5 п.п. м/м → ревизия закупочных цен/промо | Неделя |
| 4 🔶 | **Доля неликвида** (сток без продаж >X дней / весь сток) | Закупки | State Store: SKU с last_sale > порога | ≤ 10% капитала | >20% → списание/уценка, заморожен кэш | Месяц |
| 5 | **Маржа за вычетом CAC** (прибыль с заказа − стоимость привлечения) | Маркетинг | Event Log: `order_revenue` + расход на канал | положительная по каналу | канал в минусе 2 нед → отключить/пересобрать | Неделя |
| 6 | **AOV и доля повторных покупок** | Маркетинг | Event Log: `order` by customer | повторных ≥ 30% | повторных <15% → удержание (а не только разгон трафика) | Месяц |
| 7 | **Точность остатков** (учётный − фактический по инвентаризации) | Складом | Event Log: `inventory_count` vs State Store; агент-reconciler | расхождение ≤ 1% | >3% → разбор недостач/пересорта, ревизия процесса | По циклу инв. |
| 8 🔶 | **Кассовый цикл (CCC)** (дни запаса + дни дебиторки − дни кредиторки) | Финансы | Event Log закупок/продаж/оплат | минимизировать; ≤ 30 дней | рост >45 дней → пересмотр условий с поставщиками/клиентами | Месяц |

> 🔶 **Слепые зоны блока.** (1) Общая оборачиваемость «нормальна» — но среднее по складу маскирует две кучи: ходовое летает, неликвид лежит мёртвым грузом. Считать оборачиваемость **по категориям/ABC**, не котлом (пункт 4 — обязательная пара к пункту 1). (4) Прибыльный P&L при растущем неликвиде = деньги «съел» склад; неликвид не виден в марже, но виден в кассе. (8) Точность остатков, заполняемая кладовщиком вручную, — конфликт интересов; источник = инвентаризация + агент-reconciler, сверяющий учёт с фактом, а не доверие к ручному вводу.

---

### J.4 · Правила настройки дашборда (общие для всех типов)

1. **3 уровня на экране.** Вершина (1 число, цвет) → драйверы (3–4) → операционка (по клику). Собственник видит «деньги/выживание» сразу; внедренец прокидывает drill-down к Event Log.
2. **Источник = всегда SSOT.** Каждая метрика тянется из одного **governed-расчёта** в metrics layer (semantic layer). Один термин = одна формула на весь дашборд — иначе «маржа» в двух виджетах разойдётся.
3. **Тревога = действие, не цвет.** К каждому порогу прикреплён владелец и шаг. Светофор без закреплённого решения = отчётность, не control.
4. **🔶-метрики не агрегировать вслепую.** Рядом со средним всегда держать хвост/список (счета >30 дней, A-SKU в нуле, этап на крит-пути). Среднее лжёт — Минцберг-чек-лист слепых зон.
5. **Конфликт интересов в данных.** Где цифру генерит тот, кого она оценивает (прораб → график, кладовщик → остатки, исполнитель → NPS) — источник переключить на независимого **агента-collector/reconciler** + сверку (фото, инвентаризация). В SMB без ERP агенты порождают этот след с нуля (D).
6. **Health-check агентов-источников.** Метрика, питаемая агентом, ломается тихо, если агент упал (silent failure). На дашборде у таких строк — индикатор `agent.health` и `last_updated`; устаревшие данные подсвечивать, не показывать как «ОК».
7. **Частота = частоте решения.** Ежедневные метрики (OOS, отклонение графика) — для оперативки; недельные — для штаба собственника; месячные — для стратегии. Не чаще, чем по ним реально принимают решение.

---

## План работ (backlog)

Приложения A–J — это **v0 (скелеты)**. План доведения каждого до рабочего документа (+ новое приложение **K · Безопасность/GDPR**) — в отдельном **roadmap**: https://tdlife.club/ai-org/ai-org-framework-roadmap.html . Приоритет — **A · B · C** (ядро применимости).