Спецификация DSL 7H, версия 1.0

Полная спецификация предметно-ориентированного языка фреймворка 7 Горизонтов

Версия 1.0 — октябрь 2026. То же содержание, что в Приложении D первой версии книги «7 Горизонтов» Сергея Каткова. Основная версия — английская, этот текст — перевод; при расхождении действует английская. Ссылки вида «глава 9» или «Приложение F» ведут на главы и приложения книги.

Граф — это недостающий средний слой между стратегией и софтом. Стратегия слишком абстрактна для кода; код слишком конкретен для стратегии.

DSL — не документация, а исполняемое управление.

Для кого этот документ. Для тех, кто строит граф компании по 7H, и для тех, кто будет писать софт для поддержки этого графа. Каждый горизонт — набор типов узлов, атрибутов, связей и правил валидации. Всё наследует общую базовую схему.

Статус этой нотации. Семь слоёв и направление каскада выведены из практики. Эта нотация — нет. Я написал её задним числом, обкатал на своих проектах, и она ещё не прошла ни одного полного внедрения снаружи. Первое же реальное внедрение покажет, что часть полей здесь лишняя, часть используется не так, как описано, а какой-то части не хватает вовсе. С нотацией v1 так и бывает, и это не задевает то, что важно: какой слой какой порождает и что ломается, когда связи нет. Считайте семантику слоёв утверждением, а перечни полей — черновиком для старта. Если поле мешает — выбросьте его и запишите почему; эта запись ценнее самого поля.

1. Базовая схема узла

Каждый узел в графе наследует эти поля. Типы конкретных горизонтов добавляют свои.

В таблицах полей * отмечает обязательное поле.

Что не является узлом. Наблюдение, что граф разошёлся с реальностью — клиент назвал боль, которой нет на карте; процесс на деле идёт не так, как описан, — не узел и не ребро. Это вход в процесс изменения графа (гл. 13: спринты графа, версионирование, ревью). Породить такой сигнал может любой узел. Не хранит его ни один.

Опциональные универсальные блоки

Эти опциональные блоки навешиваются на любой узел, на любом горизонте. Они делают свежесть, управляемость и поведение ИИ (искусственного интеллекта) явными и машинно-исполняемыми. Три блока — ядро: freshness, assumption_log, ai_tests. Один — расширение для случаев, когда граф напрямую управляет софтом: data_policy (см. также promise_policy в §10, на позициях, и runtime_binding в §7, на процессах).

freshness — ядро

Объявляет, когда данные узла устаревают и что тогда происходит. Заменяет нестрогое правило «updated_at > 12 месяцев», использовавшееся в этом справочнике.

freshness:
  review_cadence: quarterly        # как часто этот узел нужно перепроверять
  expires_at: 2026-09-30           # по умолчанию last_verified_at + review_cadence; можно задать вручную
  stale_action: warn               # warn | block | require_owner_review
  last_verified_by: ref: h7/position_x   # ответственность -> H7.position, не H6.role
  last_verified_at: 2026-06-03

stale_action: block оставляйте для узлов, где устаревание опасно — цены, комплаенс, SLA (соглашение об уровне сервиса).

assumption_log — ядро

Фиксирует допущения, на которых граф работает, но которые не подтверждены — особенно те, что ИИ вывел по ходу задачи. Захват, затем курирование: предложенное допущение проверяет его owner и либо переводит в evidence узла (поднимая confidence), либо отклоняет.

assumption_log:
  - assumption: "Клиент хочет телефонную поддержку"
    source: "ИИ вывел по ходу задачи"
    status: proposed              # proposed | accepted | rejected
    owner: ref: h7/position_marketing_owner   # ответственность -> H7.position
    evidence_required: true

При accepted — внести в evidence и поднять confidence. При rejected — оставить в логе, чтобы то же допущение не выводилось снова.

ai_tests — ядро

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

ai_tests:
  - scenario: "Лид спрашивает про интеграцию, которую мы не поддерживаем"
    expected_behavior: "Не обещать. Эскалировать инженеру решений."
    forbidden_behavior: "Сказать, что мы можем интегрироваться с чем угодно."

Работает в паре с data_policy.allowed_ai_use: то поле говорит, что ИИ можно; ai_tests — как проверить, что он сделал это правильно.

blast_radius — ядро

Объявляет, что ломается ниже по потоку, когда этот узел отказывает. Навешивается на любой узел, на любом горизонте — процесс, результат, точку контакта, решение о способе выполнения, позицию. Это то самое поле, которое стоит за каждым вопросом «что будет, если это сломается» в этой книге.

blast_radius:
  affected_deliverables: 3         # сколько результатов H3 встанет или деградирует
  affected_segments: 2             # сколько контрагентов H1 это почувствуют
  detection_lag: 4h                # через какое время это вообще заметят
  recovery_mode: "ручной резервный режим через старшего инженера"

Числа, а не прилагательные. «Критичный процесс» — это мнение; affected_deliverables: 3 — число, которое можно сравнить с другим узлом.

data_policy — расширение

Объявляет классификацию данных и какие роли и виды ИИ-использования разрешены. DSL декларирует намерение; энфорсмент — задача софта — не стройте движок контроля доступа внутри графа.

data_policy:
  classification: confidential     # public | internal | confidential | pii | regulated
  allowed_roles: [ref: h6/role_x]  # доступ — это способность -> H6.role; positions наследуют через role_refs
  allowed_ai_use: retrieval_only   # none | retrieval_only | generation | automation
  redaction_required: true

2. Базовая схема ребра

Каждое ребро (связь) в графе наследует эти поля.

Примечание об атрибутах-ссылках. В YAML-примерах связи часто записываются как атрибуты на узле (например, triggered_by: [ref: h3/del_xxx]). Каждый такой атрибут — связь в графе. Имя в канонической таблице рёбер (раздел 11) есть только у части из них: у тех, по которым вы ходите, когда читаете граф или применяете правило валидации. Остальные — обычные ссылки: они соединяют узлы, но по ним в этой книге ходить не требуется. В софте вы дадите имена большему числу связей, чем это приложение.

3. Три механизма контроля качества

Книга использует три разных механизма контроля. Все три связаны с качеством, но работают по-разному и на разных уровнях.

3.1 Стадия квалификации (универсальная, любой горизонт)

Фильтр на данных и результатах: сырой → проверенный → пригодный (raw → gated → qualified). Отвечает на вопрос: «это годная единица для подсчёта / для передачи дальше?»

Применим к любому узлу любого горизонта:

• H1: не все заявленные боли реальные (сырая боль → проверенная → подтверждённая)
• H2: не все визиты целевые (сырой визит → вовлечённый → конверсия)
• H3: не все закрытые тикеты решили проблему (сырой → проверенный → подтверждённый клиентом)
• H4: не все выходы процесса годные (сырой выход → прошёл контроль качества → принят)

Без этого механизма все метрики — мусор. «У нас 500 лидов» — сырой. «80 квалифицированных» — проверенный. «23 с контрактом» — пригодный.

# Опциональный блок на ЛЮБОМ узле
qualification_stage:
  stages:
    - stage: raw
      criteria: "Элемент зафиксирован, но не проверен"
    - stage: gated
      criteria: "Прошёл внутреннюю проверку"
      checker: "автотест + выборочная проверка"
    - stage: qualified
      criteria: "Подтверждён потребителем результата"
      checker: "клиент / внутренний заказчик"
  current_stage: gated
  pass_rates:
    raw_to_gated: 0.45
    gated_to_qualified: 0.82

3.2 Контрольная точка (H4/H5 — процессы)

Проверка процесса изнутри. Отвечает на два вопроса (см. Глава 7, глава 12 — «два качества»):

• process_design — правильно ли спроектирован процесс?
• execution_discipline — выполняется ли по описанию?

Регламент без контроля = ноль. Контроль без регламента возможен (наблюдаешь за результатом).

# Атрибут на backstage_process / support_process
control_points:
  - id: cp_channel_verification
    check_type: process_design | execution_discipline
    criteria: "Тестовый звонок проходит, MOS ≥ 4.0"
    checker: "Старший инженер"
    frequency: per_execution | sampling | periodic
    duration: 30min
    consequence_of_failure: "Возврат на предыдущую операцию"

3.3 Допуск (H6 — способ выполнения)

Проверка на входе: допущен ли исполнитель к выполнению операции?

Три стратегии:

• admission_gate — допуск на входе (аттестация, тест, сертификация)
• output_deviation — контроль по отклонению результата
• discipline_monitoring — контроль дисциплины исполнения

# Атрибут на sourcing_decision
admission_control:
  type: admission_gate
  description: "Аттестация: настроить тестовый SIP-транк за 2 часа"

Сводная таблица: три механизма

Контрольная точка качества. Где: любой горизонт. Проверяет: результат/данные годные? Когда: на выходе узла. Пример: «Тикет закрыт — но решена ли проблема?»

Точка контроля процесса. Где: H4, H5. Проверяет: процесс идёт правильно? Когда: внутри процесса. Пример: «Инженер следует процедуре или импровизирует?»

Контроль допуска. Где: H6. Проверяет: исполнитель допущен? Когда: на входе в операцию. Пример: «Сотрудник прошёл аттестацию?»

4. Горизонт 1: Понимание клиента

Корней два, а не один. H1 описывает мир того, перед кем компания отвечает. Почти всегда это клиент, и вся остальная книга написана про этот случай. Но регулятор, банк или контрагент по договору тоже навязывают сроки, форматы и последствия — и эта цепочка идёт ровно через те же слои: шаг со сроком сдачи, точка контакта, где вы сдаёте, результат, чей SLA — это законный срок, процесс, который его производит, и обеспечение под ним. Пометьте корень через stakeholder_type — остальная модель работает без изменений. Одна инверсия, о которой стоит помнить: у не-клиентского корня pain_point фиксирует последствие для вас — штраф, отозванную лицензию, — а не проблему, которую переживает контрагент. И ведут себя два корня по-разному. Клиентский спрос порождает структуру. Внешнее обязательство потребляет мощность.

counterparty и «персона». Тип узла называется counterparty. Там, где в тексте книги написано персона, имеется в виду контрагент с stakeholder_type: customer — подавляющее большинство случаев. В DSL взято более широкое имя, потому что регулятор — не персона.

Типы узлов

counterparty

Сторона, перед которой компания отвечает, с выраженным паттерном боли. Поведенческий профиль, не демографический. При stakeholder_type: customer это то, что в тексте книги называется персоной.

Валидация: каждый counterparty → ≥1 pain_point с confidence > 0.

pain_point

Конкретная проблема, привязанная к контрагенту. Для клиента — проблема, которую переживает он. Для не-клиентского корня — последствие для вас, если обязательство не выполнено.

Валидация: pain_point с severity = critical и confidence < 0.5 — красный флаг.

trigger

Событие, делающее боль невозможной для игнорирования.

Валидация: trigger без связи activates → бесполезен. Связать или удалить.

step

Группа вершин, объединённых одним глобальным вопросом. Пять стандартных шагов:

Валидация: step без readiness_signal — не узел, а мнение.

question_node

Конкретный вопрос внутри шага.

Структура edge_rule: condition (text), target (node_id), effect (text).

alternative

Другой способ решить проблему. Включает конкурентов, другие категории, «ничего не менять», «активно избегать».

Валидация: на каждом шаге 1–3 → ≥1 alternative с category = do_nothing.

evaluation_criterion

Фильтр, которым клиент отсекает варианты.

entry_point

Боковой вход на шаг (минуя предыдущие).

Рёбра H1

Правила валидации H1

1. Каждая persona → ≥1 pain_point → ≥1 trigger
2. Каждый step → readiness_signal (иначе не узел, а мнение)
3. Шаги 1–3 → ≥1 alternative с category = do_nothing
4. Нет узлов-сирот (каждый узел связан хотя бы с одним другим)
5. Связь loops_to от step 5 к step 1 существует
6. question_node с worldview_impact = breaks → должно быть ребро returns_to
7. Каждый question_node с info_needs → ≥1 touchpoint на H2 (связь generates). Если нет — информационный разрыв.

Чеклист H1

• ≥1 persona с confidence ≥ 0.5
• У каждой персоны — ≥1 pain_point с severity и evidence
• ≥1 trigger с activates-связью
• Все 5 шагов определены (хотя бы global_question)
• do_nothing есть на шагах 1–3
• У каждого шага — readiness_signal
• ≥1 entry_point
• loops_to от step 5 к step 1
• Нет узлов-сирот
• confidence заполнен — вы знаете, что проверять первым

5. Горизонт 2: Точки контакта

Типы узлов

touchpoint

Точка взаимодействия клиента с кем-либо по поводу его проблемы (H1). Не путать с каналом.

Валидация:

• touchpoint без generates → H3 = декорация
• B2B touchpoint без counterparty_ref = «немой touchpoint»
• friction_level = high на step 1–2 = красный флаг

channel

Среда, в которой существуют точки контакта. Контейнер, не точка взаимодействия.

Рёбра H2

Правила валидации H2

1. Каждый touchpoint → step_ref + ≥1 info_need_ref
2. Каждый touchpoint → generates → H3 (иначе декорация)
3. Каждый touchpoint → outcome заполнен
4. Каждый active channel → ≥1 touchpoint
5. B2B: каждый touchpoint → counterparty_ref заполнен
6. Проверка на сирот (H1→H2): каждый question_node из H1 → ≥1 touchpoint. Нет = информационный разрыв.
7. Проверка несоответствия: touchpoint.step_ref = step_ref связанных question_nodes
8. Проверка на зомби: touchpoint с outcome_metric = 0 и confidence < 0.3 = кандидат на ликвидацию
9. Проверка устаревания: touchpoint с истёкшим freshness.expires_at (или критичный touchpoint без блока freshness) = кандидат на ревью. См. §1, Опциональные универсальные блоки.

Чеклист H2

• Для каждого question_node из H1 — ≥1 touchpoint (нет дыр)
• Все touchpoint привязаны к step_ref
• B2B: все touchpoint имеют counterparty_ref
• Все touchpoint имеют generates → H3
• Все touchpoint имеют outcome
• MoT-флаги (момент истины) расставлены (≥1 MoT на шаг)
• Враждебные и сторонние точки контакта нанесены на карту
• Нет friction_level = high на шагах 1–2 без обоснования
• Нет зомби-каналов (active = false с touchpoint)
• Для каждого generates → H3 существует узел на H3

6. Горизонт 3: Поставляемые результаты

Типы узлов

deliverable

Конкретный результат в конкретной точке контакта: ответ, расчёт, демо, документ, установка, поддержка.

sla_object: target (duration), inherited_from (ref → H2.touchpoint), clock_starts (on_trigger | on_inputs_received), conflict (enum), conflict_resolution (text).

customer_input: input_name (string), format (string), deadline (duration), fallback (string).

cost_object: amount (number), currency (string), includes (list[string]), marginal_cost (number).

deliverable_variant

Вариант «упаковки» для конкретного контрагента. Общий процесс один — «последняя миля» разная.

Рёбра H3

С H3 вверх рёбер нет. Новая способность на H3 не создаёт точку контакта на H2, а результат не создаёт боль на H1. Когда отгрузка чего-то нового показывает, что H2 или H1 устарели, — это сигнал, а не ребро: он идёт в процесс изменения графа (гл. 13), который затем добавляет узлы на H1 и H2 в обычном порядке. Добавлять точку контакта имеет смысл, только если она отвечает реальной потребности с H1.

Правила валидации H3 (аудит обещаний + аудит сирот)

1. Аудит обещаний: для каждого owned/earned touchpoint с generates → H3 — существует deliverable
2. Согласованность SLA (соглашения об уровне сервиса): deliverable.sla.target ≤ touchpoint.latency
3. Конфликт SLA: если conflict = exceeds_expectation — заполнено conflict_resolution
4. Аудит сирот: каждый deliverable должен быть достижим от H2 — либо напрямую через triggered_by, либо через другой deliverable, который достижим, по depends_on. Компонент, который сам по себе не отгружается, но который потребляют три результата, — не сирота. Недостижим ни от чего на H2 = сирота.
5. Готовность H3→H4: каждый deliverable → ≥1 requires → H4. Без = либо self_service, либо пустое обещание.

Чеклист H3

• Аудит обещаний завершён: для каждого touchpoint с generates — есть deliverable
• Аудит сирот завершён: результаты без triggered_by — с решением
• SLA привязаны к H2 и не превышают ожидания
• SLA-конфликты зафиксированы с решением
• customer_inputs зафиксированы
• acceptance_criteria и qualification_signals определены
• variants проверены
• Восстановление после сбоя продумано для критических результатов
• requires (H4) заполнен

7. Горизонт 4: Ключевые процессы

Типы узлов

backstage_process

Процесс, непосредственно производящий результаты из H3.

operation

Элементарное действие внутри процесса. Не декомпозируется дальше в рамках H4.

runtime_binding — расширение (на backstage_process, support_process или operation)

Мост от графа к работающему софту: какие системы, контракты событий и эндпоинты реализуют этот узел. Здесь граф перестаёт описывать и становится исполняемым. Самый дрейф-опасный блок справочника — привязанные системы меняются под вами. Всегда навешивайте freshness на узел с runtime_binding и относитесь к графу как к декларации контракта, а не зеркалу руками собранной системы.

runtime_binding:
  system_refs: [crm.hubspot, queue.nats]
  event_schemas: [lead.created.v1, proposal.sent.v2]
  api_endpoints: [POST /proposals]
  module_owner: ref: h7/position_automation_engineer   # ответственность -> H7.position

event_schemas — контракты на стыках модулей; это ваши контрольные точки, если строите событийную архитектуру.

Рёбра H4

Правила валидации H4

1. Проверка на сирот: каждый backstage_process должен быть достижим от H3 — либо напрямую через delivers, либо через другой процесс, который поставляет результат, по depends_on. Процесс, производящий упаковку, которая сама не отгружается, но используется процессами, которые отгружают, — не сирота. Недостижим ни от чего на H3 = кандидат на H5 или ликвидацию.
2. Проверка покрытия: каждый H3.deliverable с requires → H4 должен иметь соответствующий процесс.
3. Каскад SLA: sum(operation.duration) + sum(control_point.duration) + буфер 20% ≤ deliverable.SLA.
4. Сигнал общего процесса: процесс с delivers к 3+ результатам = анализ скрытых зависимостей.
5. Проверка владельца: каждый backstage_process → owner заполнен.

Чеклист H4

• Каждый результат с requires → H4 имеет соответствующий процесс
• Каждый backstage_process → ≥1 delivers на H3
• У каждого процесса заполнен владелец
• Операции разложены, у каждой записана duration
• Каскад SLA проверен: операции + контрольные точки + буфер ≤ SLA результата — размер буфера выбран осознанно (в правилах валидации 20% как отправная точка)
• Общие процессы (3+ результата) проверены на скрытую связанность
• Контрольные точки стоят на входах и выходах, а не только в конце
• Узкое место найдено — вы можете назвать процесс, который ограничивает пропускную способность
• Для каждого процесса помечено: создание (Build) или эксплуатация (Run)
• Граница H4 / H5 проведена осознанно, а не досталась по умолчанию

8. Горизонт 5: Поддерживающие процессы

Типы узлов

support_process

Поддерживающий процесс — обслуживает H4, но не создаёт результат, видимый клиенту.

internal_sla: deadline (string), quality_criteria (string), fallback (string).

cost_alloc_object: type (fixed | variable | mixed), annual_cost (number), variable_component (string).

admission_object: required (boolean), knowledge_requirements (list[string]), conditions_check (list[string]), certification_cadence (enum).

policy

Формализованное правило, определяющее поведение в процессах.

Свежесть. Политики используют универсальный блок freshness (§1, Опциональные универсальные блоки). last_reviewed / review_cadence здесь — частная поверхность того же механизма; держите их синхронными.

compliance_rule

Внешнее требование (регулятор, закон, стандарт).

Рёбра H5

Правила валидации H5

1. Проверка на сирот: каждый обслуживающий процесс должен стоять на цепочке enables, которая заканчивается процессом H4. Обслуживать только другие обслуживающие процессы — нормально: найм обслуживает и ключевые, и обслуживающие. Цепочка, которая никуда не приводит, или процесс вне всякой цепочки — кандидат на ликвидацию. Отчёт, который никто не читает, живёт здесь.
2. Проверка раздувания: COUNT(H5) > 2 × COUNT(H4) = сигнал раздувания H5.
3. Сигнал персонального процесса: process_type = personal = риск ключевого человека.
4. Проверка на зомби: H5 с enables, но target не использует результат = зомби.
5. Каскад SLA: H5.internal_sla.deadline не позднее SLA потребителя.
6. Покрытие допуском: если admission.required = true — knowledge_requirements и certification_cadence заполнены.

Чеклист H5

• Каждый H5 → ≥1 enables → H4 или H5, и цепочка заканчивается процессом H4
• У каждого H5 назначен owner
• process_type указан (personal → задокументировать риск)
• internal_sla заполнен
• cost_allocation заполнен
• Для критических процессов заполнен admission
• Политики привязаны к процессам
• У каждого compliance_rule актуальный last_change
• Межгоризонтные проверки пройдены

9. Горизонт 6: Решения о способе выполнения

Типы узлов

role

Набор операций, требующих определённого профиля компетенций.

context_profile_object: attention_type (deep | reactive), toolset (list[string]), feedback_rhythm (minutes | hours | days | weeks).

Роль против позиции (глава 9, глава 10, глава 16). Роль = набор операций + компетенции. Позиция = роль + ответственность (одна позиция, совмещение — только ролей). Должность = позиция, вписанная в H7.

competency

Конкретный проверяемый навык или знание.

sourcing_decision

Решение свои силы (Make) / купить результат (Buy) / аутсорс (Outsource) / автоматизировать (Automate) для конкретного варианта операции.

admission_control_object: type (admission_gate | output_deviation | discipline_monitoring), description (string).

team_type против labor_type. labor_type фиксирует, является ли работа самим человеком (person_as_process) или проходит через человека (person_in_process). team_type фиксирует, как несколько человек внутри одного блока соотносятся между собой, когда decision = make. Три значения, внутри одного блока никогда не смешиваются: разделение труда (выход одного человека — вход следующего); бригада (универсалы под координатором, любой может взять любую задачу); артель автономных (каждый ведёт свой участок от начала до конца). Полный разбор — в главе 9.

Рёбра H6

controls не создаёт процесс. Решение об аутсорсе делает контрольный процесс необходимым, но узел H5 не порождается ребром — он добавляется через процесс изменения графа (гл. 13), как любой другой узел, и только после этого решение на него ссылается. H6 читает с H4 и H5; вверх он ничего не порождает. Если контрольного процесса ещё нет, решение неполно — правило 6 ниже ловит ровно это.

Правила валидации H6

1. Покрытие: каждая операция из H4/H5 → ≥1 sourcing_decision. Без = серая зона.
2. Компетенции для make: если decision = make → roles_required не пуст, у роли — required_competencies.
3. Покрытие вариантов: если H3 deliverable имеет несколько вариантов → каждый → собственный sourcing_decision.
4. Совместимость ролей: две роли на одной позиции → проверить attention_type, toolset, feedback_rhythm. Время до продуктивности после переключения: минуты = ок, часы = осторожно, дни = несовместимо.
5. Компетенция-сирота: competency без ссылок из role = кандидат на удаление.
6. Контроль outsource: decision = outsource → указан механизм контроля (ссылка на H5 или admission_control).
7. Приёмка buy: decision = buy → зафиксированы критерии оценки результата.
8. Тип команды для make: если decision = make, team_type задан; если decision != make, team_type можно опустить.

Чеклист H6

• Каждая операция из H4/H5 → ≥1 решение о способе выполнения — серых зон нет
• Для каждой записано решение: свои силы / покупка результата / аутсорс / автоматизация
• Для своих сил: задан team_type, roles_required не пуст
• У каждой роли заполнены required_competencies
• У каждой роли заполнен context_profile: тип внимания, набор инструментов, ритм обратной связи
• Совместимость ролей проверена везде, где две роли сходятся на одной должности
• Для аутсорса: указан механизм контроля (связь с H5 или admission_control)
• Для покупки результата: критерии приёмки задокументированы
• Допуск (admission_control) определён везде, где высока цена ошибки
• Записан bus_factor; операции с единственным носителем знания помечены
• Для каждого решения заполнены fallback (резервный режим) и review_trigger
• По компетенциям-сиротам (на них не ссылается ни одна роль) принято решение

10. Горизонт 7: Организационная структура

Типы узлов

organizational_unit

Структурное подразделение: отдел, команда, группа, департамент.

position

Должность — группировка ролей из H6.

accountability_level соответствует лестнице кресел из главы 16 (execution → tasks_plans → goals_budgets → strategy). Два случая лежат вне её: присутствие (ниже execution — кандидат предъявляет регалии вместо продукта; это не наёмное кресло) и владение (выше strategy — партнёр/доля, не позиция на зарплате). Охват и ориентация кандидата сопоставляются с креслом при найме; они не объекты графа, потому что граф моделирует компанию, а не соискателей.

promise_policy — расширение (на position)

Полномочие на внешние обязательства: что эта позиция вправе пообещать клиенту и когда обязана эскалировать. Отличается от authority_scope выше, который смотрит внутрь (что позиция вправе требовать внутри). Две оси: требование (внутрь) против обещания (наружу).

promise_policy:
  can_promise: true
  max_discount: "10%"
  max_sla: "48h"
  requires_approval_if:
    - "кастомная интеграция"
    - "юридическое обязательство"
    - "цена ниже пола"

Конкретные лимиты (скидка %, SLA) — иллюстративные; держите их в отраслевых примерах (Приложение F), а не в общей схеме.

reporting_line

Формальная линия подчинения.

dependency_line

Линия зависимости — кто от кого зависит для получения результата.

Рёбра H7

Правила валидации H7

1. Позиция без ролей: position без role_refs = не выполняет операций. Кандидат на ликвидацию.
2. Оторванное подразделение: organizational_unit, у позиций которого нет dependency_line к/от других подразделений И нет role_refs к H4 = оторвано от графа.
3. Подчинение без зависимости: A подчиняется B, но ни одна операция A не зависит от B и наоборот → зачем подчинение?
4. Диапазон зависимостей: входящих dependency_line с criticality = high/blocking > 10 на одну позицию = перегрузка.
5. Право без возможности: reporting_line с right_type = formal, но authority_scope пуст = подчинение без инструментов контроля.
6. Неформальная критическая зависимость: dependency_line с criticality = high + formalization_status = informal = критичная зависимость на личных договорённостях.
7. Разрыв между подчинением и зависимостью: > 50% critical dependency_lines идут вне reporting_line цепочки = расхождение формальной и реальной структуры.

Чеклист H7

• У каждой должности → ≥1 role_refs — должностей, которые ничего не исполняют, нет
• В каждом контуре принятия решения ответственность лежит ровно на одном человеке
• По каждой должности проверены три условия: понимаю / решаю / отвечаю
• Каждое организационное подразделение связано с графом через role_refs или dependency_lines
• За каждой линией подчинения стоит реальная операционная зависимость
• authority_scope заполнен везде, где right_type = formal
• По критическим неформальным зависимостям принято решение о формализации
• Входящие критические зависимости на должность сопоставлены с порогом, который вы задали сами (в правилах валидации 10 как отправная точка)
• Формальная и фактическая структуры сопоставлены: доля критических зависимостей вне цепочки подчинения посчитана и признана приемлемой (в правилах валидации 50% как отправная точка)
• Тип команды в подразделении соответствует работе, которая там реально делается

11. Каноническая таблица рёбер

Именованные типы рёбер — те, по которым вы ходите, когда читаете граф или применяете правило валидации. Каждое определено один раз, в одном направлении. Атрибуты-ссылки на узлах (раздел 2) тоже связывают узлы, но здесь не перечислены.

Внутри горизонтов

Между горизонтами

Обратная пара requires ↔ delivers: Это одно и то же ребро, видимое с двух сторон. В графе хранится один раз. requires — представление со стороны H3 («мне нужен процесс»). delivers — представление со стороны H4 («я произвожу результат»). В софте — одно ребро с направлением.

12. Кросс-горизонтные правила валидации (сводные)

Сквозная прослеживаемость

FOR EACH counterparty IN H1:
  trace = counterparty → pain_points → triggers → steps → question_nodes 
          → touchpoints(H2) → deliverables(H3) → processes(H4) 
          → support(H5) → sourcing(H6) → positions(H7)
  IF any link in trace is broken:
    FLAG "Разорванная трасса для контрагента {counterparty.name} на {broken_link}"

Каскад покрытия (сверху вниз)

Каскад SLA (сверху вниз)

FOR EACH deliverable IN H3:
  expected = deliverable.sla.target
  actual = SUM(processes.cycle_time) + SUM(control_points.duration) + buffer(20%)
  IF actual > expected:
    FLAG "Нарушение SLA: {deliverable.name} обещает {expected}, процессам нужно {actual}"

Проверки на сирот (снизу вверх)

Проверки согласованности

13. Шаблоны ИИ-промптов

Готовые промпты для заполнения и валидации графа через ИИ.

Промпт 1: заполнение узла H4

У меня есть deliverable на H3:
- name: [название]
- SLA: [целевое время]
- acceptance_criteria: [критерии]

Опиши backstage_process для производства этого deliverable в формате DSL:
- inputs (включая customer_inputs)
- outputs
- operations (список элементарных действий)
- control_points (с check_type: process_design или execution_discipline)
- cycle_time (оценка)
- mode (Build или Run)
- role (Execute или Control)

Формат: YAML. Не придумывай данные — где не знаешь, пиши "unknown" или "estimate".

Промпт 2: аудит сирот и раздувания

Вот список узлов H5 и H4 (core processes) моей компании:

H4: [список]
H5: [список]

Проведи три проверки:
1. Orphan check: какие H5 не имеют связи enables → H4?
2. Bloat check: соотношение H5/H4 (норма: ≤ 2:1)
3. Zombie check: какие H5 перечислены как enables, но H4-потребитель не использует их результат?

Для каждого найденного — рекомендация: ликвидировать, объединить, или пересмотреть связь.

Промпт 3: проверка каскада SLA

Вот deliverable с H3 и процесс, который его производит:

Deliverable: [YAML]
Process: [YAML с operations и control_points]

Проверь:
1. SUM(operation.duration) + SUM(control_point.duration) + 20% buffer ≤ deliverable.sla.target?
2. Если нет — какие операции являются bottleneck?
3. Предложи варианты: (a) упростить процесс, (b) пересмотреть SLA, (c) автоматизировать bottleneck.

Промпт 4: решение о способе выполнения H6

У меня есть операция из H4:
- name: [название]
- inputs: [входы]
- outputs: [выходы]
- duration: [длительность]
- текущий исполнитель: [кто делает сейчас]

Помоги сформулировать sourcing_decision в формате DSL:
- decision: make / buy / outsource / automate (с обоснованием)
- Для каждого варианта: pros, cons, bus_factor, fallback, review_trigger
- Критерии выбора: частота, вариативность, цена ошибки, скорость, доступность на рынке

Формат: YAML. Где нужна информация, которой у тебя нет — задай вопрос.

Промпт 5: проверка совместимости ролей H7

Я хочу совместить две роли на одной позиции:

Роль 1: [YAML с context_profile]
Роль 2: [YAML с context_profile]

Проверь совместимость по трём критериям:
1. attention_type: обе deep из разных областей? → несовместимы
2. toolset: работа в разных средах, разный словарь? → маркер
3. feedback_rhythm: одна «быстрая» (минуты), другая «медленная» (недели)? → рискованно

Практический тест: время до продуктивности после переключения.
Минуты — ок. Часы — осторожно. Дни — несовместимо.

Дай вердикт и обоснование.

14. Пример YAML: SaaS-компания (ПО как услуга), сквозной фрагмент H1→H4

# === H1 ===
counterparty:
  id: p_ops_manager
  name: "Операционный директор, B2B SaaS, 50-200 сотрудников"
  horizon: H1
  node_type: counterparty
  role: "Руководитель операционного отдела"
  context: "Быстро растущий SaaS, 80 сотрудников, процессы в головах"
  confidence: 0.8
  evidence: ["12 интервью", "анализ поддержки: 40% тикетов — про процессы"]
  pain_refs: [pp_tribal_knowledge]

pain_point:
  id: pp_tribal_knowledge
  name: "Знания в головах, не в системе"
  horizon: H1
  node_type: pain_point
  severity: high
  frequency: constant
  cost_estimate: "2-3 недели онбординг нового менеджера вместо 3 дней"
  awareness: aware_active
  trigger_refs: [tr_key_person_quit]
  confidence: 0.85
  evidence: ["выходные интервью", "опросы после онбординга"]

trigger:
  id: tr_key_person_quit
  name: "Ключевой сотрудник увольняется"
  horizon: H1
  node_type: trigger
  event: "Тимлид подал заявление, команда из 8 человек осталась без носителя контекста"
  source: internal
  urgency: high
  activates: [step_2]

# === H2 ===
touchpoint:
  id: tp_process_audit_landing
  name: "Лендинг: 'Сколько стоит хаос в процессах?'"
  horizon: H2
  node_type: touchpoint
  ownership_type: owned
  step_ref: step_2
  info_need_ref: [qn_cost_of_chaos]
  counterparty_ref: [p_ops_manager]
  channel_ref: ch_website
  moment_of_truth: true
  customer_expectation: "Понять масштаб проблемы в деньгах"
  content_type: self_serve_tool
  friction_level: low
  latency: "мгновенно"
  outcome: "Калькулятор показал: хаос стоит $180K/год. Запрос демо."
  outcome_type: progress
  confidence: 0.7
  evidence: ["GA: 200 визитов/мес", "конверсия в демо: 8%"]

# === H3 ===
deliverable:
  id: del_chaos_calculator
  name: "Калькулятор стоимости процессного хаоса"
  horizon: H3
  node_type: deliverable
  outcome_type: education
  triggered_by: [tp_process_audit_landing]
  customer_inputs:
    - input_name: "Количество сотрудников"
      format: "число"
    - input_name: "Средняя зарплата"
      format: "число"
    - input_name: "Сколько ключевых людей ушло за год"
      format: "число"
  sla:
    target: "мгновенно"
    inherited_from: tp_process_audit_landing
    clock_starts: on_trigger
    conflict: none
  acceptance_criteria:
    - "Формула расчёта корректна"
    - "Результат правдоподобен (не пугает и не занижает)"
  qualification_signals:
    - "Пользователь запрашивает демо после расчёта"
  requires: [bp_calculator_maintenance]
  scalability_class: fixed

# === H4 ===
backstage_process:
  id: bp_calculator_maintenance
  name: "Поддержка калькулятора стоимости хаоса"
  horizon: H4
  node_type: backstage_process
  purpose: "Обеспечить актуальность формул и бенчмарков в калькуляторе"
  mode: Run
  role: Execute
  triggered_by: [del_chaos_calculator]
  inputs:
    - "Отраслевые бенчмарки (ежеквартально)"
    - "Обратная связь от пользователей"
  outputs:
    - "Обновлённые формулы"
    - "Актуальные коэффициенты"
  composed_of:
    - op_collect_benchmarks
    - op_update_formulas
    - op_regression_test
  control_points:
    - id: cp_formula_accuracy
      check_type: process_design
      criteria: "Результат калькулятора отклоняется от ручного расчёта не более чем на 15%"
      checker: "Менеджер продукта"
      frequency: quarterly
  cycle_time: "2 дня/квартал"
  owner: "Менеджер продукта"
  delivers: [del_chaos_calculator]

Полная спецификация. Для отраслевых примеров — см. Приложение F.