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

*Повна специфікація предметно-орієнтованої мови фреймворку 7 Горизонтів*

> **Версія 1.0 — жовтень 2026.** Той самий зміст, що в Додатку D першої версії книги «7 Горизонтів» Сергія Каткова. Основна версія — англійська, цей текст — переклад; у разі розбіжностей діє англійська. Посилання на кшталт «глава 9» чи «Додаток F» ведуть на глави й додатки книги.

> *Граф — це відсутній середній шар між стратегією і софтом. Стратегія надто абстрактна для коду; код надто конкретний для стратегії.*
>
> *DSL — не документація, а виконуване управління.*

> **Для кого цей документ.** Для тих, хто будує граф компанії за 7H, і для тих, хто писатиме софт для підтримки цього графа. Кожен горизонт — набір типів вузлів, атрибутів, зв’язків і правил валідації. Усе успадковує спільну базову схему.

> **Статус цієї нотації.** Сім шарів і напрям каскаду виведені з практики. Ця нотація — ні. Я написав її заднім числом, обкатав на своїх проєктах, і вона ще не пройшла жодного повного впровадження ззовні. Перше ж реальне впровадження покаже, що частина полів тут зайва, частина використовується не так, як описано, а якоїсь частини бракує зовсім. З нотацією v1 так і буває, і це не зачіпає того, що важливо: який шар який породжує і що ламається, коли зв’язку немає. Вважайте семантику шарів твердженням, а переліки полів — чернеткою для старту. Якщо поле заважає — викиньте його і запишіть чому; цей запис цінніший за саме поле.

---

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

Кожен вузол у графі успадковує ці поля. Типи конкретних горизонтів додають свої.

У таблицях полів `*` позначає обов’язкове поле.

| Поле | Тип | Опис |
|------|------|-------------|
| `id` \* | `string` | Унікальний ідентифікатор |
| `name` \* | `string` | Людинозрозуміла назва |
| `horizon` \* | `enum` | `H1` \| `H2` \| `H3` \| `H4` \| `H5` \| `H6` \| `H7` |
| `node_type` \* | `string` | Тип вузла (визначається горизонтом) |
| `purpose` | `string` | Навіщо цей вузол існує (одне речення) |
| `description` | `text` | Розгорнутий опис |
| `owner` | `string` \| `ref` | Відповідальний за актуальність. `string` на ранньому етапі; `ref` → `H6.role` або `H7.position` на зрілому графі |
| `confidence` | `float` 0.0–1.0 | Рівень упевненості в даних. 0 = гіпотеза, 1 = підтверджено. Активно використовується в H1–H3; опційно в H4–H7 |
| `evidence` | `list[string]` | Джерела даних: інтерв’ю, тікети, аналітика, спостереження |
| `status` | `enum` | `draft` \| `active` \| `deprecated` \| `archived` |
| `created_at` \* | `date` | Дата створення |
| `updated_at` \* | `date` | Дата останнього оновлення |
| `version` | `semver` | Версія (`major.minor.patch`) — див. Главу 13, семантичне версіонування |
| `tags` | `list[string]` | Вільні мітки для фільтрації |

> **Що не є вузлом.** Спостереження, що граф розійшовся з реальністю — клієнт назвав біль, якої немає на карті; процес насправді йде не так, як описаний, — не вузол і не ребро. Це вхід у процес зміни графа (гл. 13: спринти графа, версіонування, ревʼю). Породити такий сигнал може будь-який вузол. Не зберігає його жоден.

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

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

#### `freshness` — ядро

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

```yaml
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` залишайте для вузлів, де застарівання небезпечне — ціни, комплаєнс, рівень сервісу.

#### `assumption_log` — ядро

Фіксує припущення, на яких граф працює, але які не підтверджені — особливо ті, що ШІ вивів під час задачі. Захоплення, потім кураторство: запропоноване припущення перевіряє його `owner` і або переводить в `evidence` вузла (піднімаючи `confidence`), або відхиляє.

```yaml
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` — ядро

Поведінкові приймальні тести для будь-якого ШІ, що діє на вузлі або з нього. Недетермінізм закривається перевіркою результату, а не надією на детерміновану генерацію.

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

Працює в парі з `data_policy.allowed_ai_use`: те поле каже, *що* ШІ можна; `ai_tests` — *як перевірити*, що він зробив це правильно.

#### `blast_radius` — ядро

Оголошує, що ламається нижче за потоком, коли цей вузол відмовляє. Навішується на будь-який вузол, на будь-якому горизонті — процес, результат, точку контакту, рішення щодо способу виконання, позицію. Це те саме поле, яке стоїть за кожним питанням «що буде, якщо це зламається» у цій книзі.

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

Числа, а не прикметники. «Критичний процес» — це думка; `affected_deliverables: 3` — число, яке можна порівняти з іншим вузлом.

#### `data_policy` — розширення

Оголошує класифікацію даних і які ролі та види використання ШІ дозволені. DSL **декларує намір; примусове виконання — задача софту** — не будуйте двигун контролю доступу всередині графа.

```yaml
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. Базова схема ребра

Кожне ребро (зв’язок) у графі успадковує ці поля.

| Поле | Тип | Опис |
|------|------|-------------|
| `id` \* | `string` | Унікальний ідентифікатор ребра |
| `from` \* | `node_id` | Вузол-джерело |
| `to` \* | `node_id` | Вузол-призначення |
| `edge_type` \* | `enum` | Тип зв’язку (див. канонічну таблицю ребер, секція 11) |
| `label` | `string` | Опис ребра в контексті |
| `condition` | `text` | Умова, за якої зв’язок активний |
| `weight` | `float` 0.0–1.0 | Відносна частота/важливість |
| `criticality` | `enum` | `low` \| `medium` \| `high` \| `blocking` |

> **Примітка про атрибути-посилання.** У YAML-прикладах зв’язки часто записуються як атрибути на вузлі (наприклад, `triggered_by: [ref: h3/del_xxx]`). Кожен такий атрибут — зв’язок у графі. Ім’я в канонічній таблиці ребер (розділ 11) має лише частина з них: ті, якими ви ходите, коли читаєте граф або застосовуєте правило валідації. Решта — звичайні посилання: вони з’єднують вузли, але ходити ними в цій книзі не потрібно. У софті ви дасте імена більшій кількості зв’язків, ніж це доповнення.

---

## 3. Три механізми контролю якості

Книга використовує три різні механізми контролю. Усі три пов’язані з якістю, але працюють по-різному і на різних рівнях.

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

Фільтр на даних і результатах: **сирий → перевірений → придатний (raw → gated → qualified)**. Відповідає на питання: «це придатний елемент для підрахунку / для передачі далі?»

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

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

```yaml
# Опційний блок на БУДЬ-ЯКОМУ вузлі
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`** — чи виконується за описом?

Регламент без контролю = нуль. Контроль без регламенту можливий (спостерігаєш за результатом).

```yaml
# Атрибут на 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` — контроль дисципліни виконання

```yaml
# Атрибут на 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` це те, що в тексті книги зветься персоною.

| Поле | Тип | Опис |
|------|------|-------------|
| `role` \* | `string` | Роль у контексті рішення («VP з HR (управління персоналом), 200 людей») |
| `context` \* | `text` | Ситуація: галузь, розмір, стадія |
| `pain_refs` \* | `ref`[] → `pain_point` | Пов’язані болі |
| `segment` | `string` | Сегмент (якщо використовується кластеризація) |
| `buying_role` | `enum` | B2B (міжкорпоративний): `initiator` \| `evaluator` \| `decision_maker` \| `blocker` \| `user` |
| `volume_estimate` | `string` | Оцінка розміру аудиторії |
| `stakeholder_type` | `enum` | `customer` (за замовчуванням) \| `regulator` \| `contractual_party` \| `investor` — перед ким компанія відповідає |

**Валідація:** кожен `counterparty` → ≥1 `pain_point` з `confidence` > 0.

#### `pain_point`

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

| Поле | Тип | Опис |
|------|------|-------------|
| `severity` \* | `enum` | `low` \| `medium` \| `high` \| `critical` |
| `frequency` \* | `enum` | `rare` \| `periodic` \| `frequent` \| `constant` |
| `cost_estimate` | `string` | Вартість проблеми (гроші, час, втрачене) |
| `awareness` | `enum` | `unaware` \| `aware_passive` \| `aware_active` \| `seeking_solution` |
| `trigger_refs` | `ref`[] → `trigger` | Що активує біль |

**Валідація:** `pain_point` із `severity` = `critical` і `confidence` < 0.5 — червоний прапорець.

#### `trigger`

Подія, яка робить біль неможливим для ігнорування.

| Поле | Тип | Опис |
|------|------|-------------|
| `event` \* | `text` | Що сталося |
| `source` \* | `enum` | `internal` \| `external` \| `competitor` |
| `urgency` \* | `enum` | `low` \| `medium` \| `high` \| `deadline` |
| `recurrence` | `string` | Як часто буває |
| `activates` \* | `ref`[] → `step` | Які кроки запускає |

**Валідація:** `trigger` без зв’язку `activates` → марний. Зв’язати або видалити.

#### `step`

Група вершин, об’єднаних одним глобальним питанням. П’ять стандартних кроків:

| # | Глобальне питання |
|:-:|-------------------|
| 1 | Чи треба взагалі це вирішувати? |
| 2 | Яким способом? |
| 3 | У кого замовити? |
| 4 | Чи отримаю я те, за що заплатив? |
| 5 | Чи варто продовжувати з цим постачальником? |

| Поле | Тип | Опис |
|------|------|-------------|
| `step_number` \* | 1–5 | Номер кроку |
| `global_question` \* | `text` | Основне питання клієнта |
| `info_needs` \* | `list`[`text`] | Яка інформація потрібна для відповіді |
| `avoidance_triggers` | `list`[`text`] | Що змушує клієнта зупинитися |
| `readiness_signal` \* | `text` | Подія, що означає перехід до наступного кроку |
| `readiness_detection` | `text` | Як компанія може виявити цей сигнал |
| `typical_duration` | `string` | Типова тривалість (діапазон) |
| `education_need` | `text` | Що клієнту потрібно дізнатися |
| `sub_questions` | `ref`[] → `question_node` | Детальні питання всередині кроку |

**Валідація:** `step` без `readiness_signal` — не вузол, а думка.

#### `question_node`

Конкретне питання всередині кроку.

| Поле | Тип | Опис |
|------|------|-------------|
| `question` \* | `text` | Питання, яке клієнт намагається вирішити |
| `step_ref` \* | `ref` → `step` | До якого кроку належить |
| `answer_type` | `enum` | `factual` \| `evaluative` \| `emotional` |
| `edge_conditions` | `list`[`edge_rule`] | Правила: «якщо відповідь X → ребро до Y» |
| `worldview_impact` | `enum` | `confirms` \| `extends` \| `breaks` |

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

#### `alternative`

Інший спосіб вирішити проблему. Включає конкурентів, інші категорії, «нічого не змінювати», «активно уникати».

| Поле | Тип | Опис |
|------|------|-------------|
| `category` \* | `enum` | `competitor` \| `different_approach` \| `do_nothing` \| `actively_avoid` \| `diy` |
| `why_chosen` | `text` | Чому клієнт може вибрати |
| `why_rejected` | `text` | Чому може відкинути |
| `switching_cost` | `text` | Вартість переходу |
| `step_refs` \* | `ref`[] → `step` | На яких кроках актуальна |
| `negative_experience` | `text` | Для `actively_avoid`: що пішло не так |

**Валідація:** на кожному кроці 1–3 → ≥1 `alternative` з `category` = `do_nothing`.

#### `evaluation_criterion`

Фільтр, яким клієнт відсікає варіанти.

| Поле | Тип | Опис |
|------|------|-------------|
| `criterion` \* | `text` | Що оцінюється |
| `threshold` \* | `text` | Поріг («не дорожче $500/міс») |
| `fail_action` \* | `text` | Що відбувається при непроходженні |
| `fail_target` | `ref` → `node` | Куди веде при непроходженні |
| `importance` | `enum` | `must_have` \| `nice_to_have` \| `tiebreaker` |
| `step_ref` \* | `ref` → `step` | На якому кроці застосовується |

#### `entry_point`

Бічний вхід на крок (оминаючи попередні).

| Поле | Тип | Опис |
|------|------|-------------|
| `source` \* | `text` | Звідки приходить |
| `source_type` \* | `enum` | `referral` \| `competitor_failure` \| `regulatory` \| `crisis` \| `event` \| `content` |
| `lands_on` \* | `ref` → `step` | На який крок потрапляє |
| `context_carried` | `list`[`text`] | Який контекст приносить |
| `context_missing` | `list`[`text`] | Якого контексту бракує |
| `frequency` | `enum` | Як часто використовується |
| `development_actions` | `list`[`text`] | Як розвивати цей канал |

### Ребра H1

| Тип зв’язку | Від → До | Опис |
|-----------|--------|----------|
| `experiences` | `persona` → `pain_point` | Персона переживає біль |
| `activates` | `trigger` → `step` | Тригер запускає крок |
| `escalates` | `trigger` → `pain_point` | Тригер посилює наявний біль |
| `leads_to` | `step` → `step` | Перехід між кроками (вперед) |
| `returns_to` | `step` → `step` | Повернення назад (при зламі картини світу) |
| `considers` | `step` → `alternative` | На кроці розглядається альтернатива |
| `filters` | `evaluation_criterion` → `alternative` | Критерій відсікає альтернативу |
| `enters_via` | `entry_point` → `step` | Бічний вхід |
| `generates` | `question_node` → `H2.touchpoint` | Породжує потребу в точці контакту |
| `loops_to` | `step`(5) → `step`(1) | Петля повернення (новий цикл) |

### Правила валідації 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). Не плутати з каналом.

| Поле | Тип | Опис |
|------|------|-------------|
| `ownership_type` \* | `enum` | `owned` \| `earned` \| `third_party` \| `hostile` \| `algorithmic` |
| `step_ref` \* | `ref` → `H1.step` | На якому кроці стоїть |
| `info_need_ref` \* | `ref`[] → `H1.question_node` | На які питання відповідає |
| `counterparty_ref` \* | `ref`[] → `H1.counterparty` | Для яких контрагентів призначена (B2B) |
| `channel_ref` | `ref` → `channel` | У якому каналі живе |
| `moment_of_truth` \* | `boolean` | Наслідок змінює траєкторію клієнта? |
| `customer_expectation` \* | `text` | Що клієнт очікує отримати |
| `content_type` \* | `enum` | `info` \| `demo` \| `consultation` \| `self_serve_tool` \| `document` \| `service` \| `social_proof` |
| `friction_level` \* | `enum` | `low` \| `medium` \| `high` |
| `friction_type` | `enum` | `technical` \| `cognitive` \| `procedural` |
| `latency` | `string` | Час від запиту до відповіді |
| `outcome` \* | `text` | Що клієнт отримує або з чим іде |
| `outcome_type` | `enum` | `progress` \| `risk_reduction` \| `education` |
| `competitor_alternatives` | `list[string]` | Хто ще відповідає на це питання на цьому кроці |
| `reach_metric` | `string` | Як вимірюється охоплення |
| `engage_metric` | `string` | Як вимірюється залучення |
| `outcome_metric` | `string` | Як вимірюється результат |

**Валідація:**
- `touchpoint` без `generates` → H3 = декорація
- B2B `touchpoint` без `counterparty_ref` = «німа точка контакту»
- `friction_level` = `high` на `step` 1–2 = червоний прапорець

#### `channel`

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

| Поле | Тип | Опис |
|------|------|-------------|
| `medium` \* | `enum` | `web` \| `email` \| `phone` \| `chat` \| `in_person` \| `social` \| `event` \| `print` \| `ai_assistant` |
| `ownership_type` \* | `enum` | `owned` \| `earned` \| `third_party` \| `hostile` \| `algorithmic` |
| `active` \* | `boolean` | Канал підтримується? (`false` = кандидат у зомбі) |
| `cost_per_contact` | `string` | Середня вартість однієї взаємодії |
| `capacity` | `string` | Пропускна здатність |
| `touchpoint_refs` | `ref`[] → `touchpoint` | Які точки контакту в цьому каналі |

### Ребра H2

| Тип зв’язку | Від → До | Опис |
|-----------|--------|----------|
| `generates` | `H1.question_node` → `touchpoint` | Потреба в інформації породжує точку контакту |
| `generates` | `touchpoint` → `H3.deliverable` | Точка контакту породжує вимогу до результату (`deliverable`) |
| `contains` | `channel` → `touchpoint` | Канал містить точку контакту |
| `competes_with` | `touchpoint` → `touchpoint` | Конкуренція за увагу на одному кроці |
| `leads_to` | `touchpoint` → `touchpoint` | Послідовність точок контакту |
| `redirects_to` | `touchpoint` → `H1.alternative` | Перенаправлення до альтернативи |

### Правила валідації 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` (або критична точка контакту без блоку `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`

Конкретний результат у конкретній точці контакту: відповідь, розрахунок, демо, документ, встановлення, підтримка.

| Поле | Тип | Опис |
|------|------|-------------|
| `outcome_type` \* | `enum` | `progress` \| `risk_reduction` \| `education` |
| `triggered_by` \* | `ref`[] → `H2.touchpoint` | Які точки контакту запускають |
| `variants` | `ref`[] → `deliverable_variant` | Варіанти «пакування» для контрагентів |
| `customer_inputs` | `list`[`customer_input`] | Що потрібно від клієнта на вході |
| `sla` \* | `sla_object` | Рівень сервісу, успадкований із H2 |
| `acceptance_criteria` \* | `list[string]` | Критерії сирий → перевірений |
| `qualification_signals` \* | `list[string]` | Сигнали перевірений → придатний |
| `cost_per_unit` | `cost_object` | Собівартість |
| `scalability_class` | `enum` | `linear` \| `leveraged` \| `fixed` |
| `requires` | `ref`[] → `H4.backstage_process` | Які процеси потрібні для виробництва |
| `service_recovery_ref` | `ref` → `deliverable` | Що відвантажується при збої |
| `promise_status` | `enum` | `delivered` \| `underdelivered` \| `missing` — результат аудиту обіцянок проти обіцянки на H2 |

**`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`

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

| Поле | Тип | Опис |
|------|------|-------------|
| `base_deliverable` \* | `ref` → `deliverable` | Базовий результат |
| `counterparty_ref` \* | `ref` → `H1.counterparty` | Для якого контрагента |
| `delta` \* | `text` | Що відрізняється: фокус, мова, формат, глибина |
| `additional_cost` | `number` | Додаткова вартість |

### Ребра H3

| Тип зв’язку | Від → До | Опис |
|-----------|--------|----------|
| `generates` | `H2.touchpoint` → `deliverable` | Точка контакту породжує результат |
| `requires` | `deliverable` → `H4.backstage_process` | Результат потребує процесу |
| `depends_on` | `deliverable` → `deliverable` | Проміжний результат, який споживає інший результат |
| `recovers` | `deliverable` → `deliverable` | Відновлення сервісу |
| `variant_of` | `deliverable_variant` → `deliverable` | Варіант базового |

> **З H3 вгору ребер немає.** Нова здатність на H3 не створює точку контакту на H2, а результат не створює біль на H1. Коли відвантаження чогось нового показує, що H2 або H1 застаріли, — це сигнал, а не ребро: він іде в процес зміни графа (гл. 13), який потім додає вузли на H1 і H2 у звичайному порядку. Додавати точку контакту має сенс, лише якщо вона відповідає реальній потребі з H1.

### Правила валідації H3 (аудит обіцянок + аудит сиріт)

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

### Контрольний список H3

- [ ] Аудит обіцянок завершено: для кожної точки контакту з `generates` — є результат
- [ ] Аудит сиріт завершено: результати без `triggered_by` — з рішенням
- [ ] Рівні сервісу прив’язані до H2 і не перевищують очікування
- [ ] Конфлікти рівнів сервісу зафіксовані з рішенням
- [ ] Входи від клієнта зафіксовані
- [ ] Критерії приймання і сигнали кваліфікації визначені
- [ ] `variants` перевірені
- [ ] Відновлення сервісу продумано для критичних результатів
- [ ] Зв’язок `requires` (H4) заповнений

---

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

### Типи вузлів

#### `backstage_process`

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

| Поле | Тип | Опис |
|------|------|-------------|
| `triggered_by` \* | `ref`[] → `H3.deliverable` \| `H4.backstage_process` | Що запускає |
| `inputs` \* | `list`[`input`] | Вхідні дані/матеріали |
| `outputs` \* | `list`[`output`] | Результати процесу |
| `composed_of` \* | `ref`[] → `operation` | Список операцій |
| `control_points` \* | `list`[`control_point`] | Точки контролю (див. секцію 3.2) |
| `mode` \* | `enum` | `Build` \| `Run` |
| `role` \* | `enum` | `Execute` \| `Control` |
| `cycle_time` | `duration` \| "`estimate`" \| "`unknown`" | Типовий час виконання |
| `capacity` | `number` \| "`estimate`" \| "`unknown`" | Пропускна здатність |
| `error_rate` | `percentage` \| "`unknown`" | Частка переробок |
| `systems` | `list[string]` | Використовувані інформаційні системи |
| `process_debt_flag` | `boolean` | Тимчасове рішення, що стало постійним |
| `delivers` \* | `ref`[] → `H3.deliverable` | Які результати виробляє |
| `requires_support` | `ref`[] → `H5.support_process` | Які підтримувальні процеси потрібні |

#### `operation`

Елементарна дія всередині процесу. Не декомпозується далі в межах H4.

| Поле | Тип | Опис |
|------|------|-------------|
| `inputs` \* | `list`[`input`] | Входи |
| `outputs` \* | `list`[`output`] | Виходи |
| `performer` \* | `string` \| `ref` → `H6.role` \| "TBD" | Хто/що виконує |
| `duration` | `duration` \| "`estimate`" | Типова тривалість |
| `waiting_states` | `enum`[] | `waiting_customer_input` \| `waiting_external` \| `waiting_internal` |

#### `runtime_binding` — розширення (на `backstage_process`, `support_process` або `operation`)

Міст від графа до працюючого софту: які системи, контракти подій і кінцеві точки реалізують цей вузол. Тут граф перестає описувати і стає виконуваним. **Найбільш схильний до дрейфу блок довідника** — прив’язані системи змінюються під вами. Завжди навішуйте `freshness` на вузол із `runtime_binding` і ставтеся до графа як до *декларації* контракту, а не дзеркала вручну зібраної системи.

```yaml
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

| Тип зв’язку | Від → До | Опис |
|-----------|--------|----------|
| `delivers` | `backstage_process` → `H3.deliverable` | Процес виробляє результат |
| `requires` | `H3.deliverable` → `backstage_process` | Результат потребує процесу |
| `composed_of` | `backstage_process` → `operation` | Процес складається з операцій |
| `requires_support` | `backstage_process` → `H5.support_process` | Потрібен процес підтримки |
| `depends_on` | `backstage_process` → `backstage_process` | Залежність всередині 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, але не створює результат, видимий клієнту.

| Поле | Тип | Опис |
|------|------|-------------|
| `process_type` \* | `enum` | `reglament` \| `personal`. `personal` = червоний прапорець |
| `mode` \* | `enum` | `Run` \| `Build`. Переважна більшість — експлуатація (Run) |
| `cadence` \* | `enum` | `daily` \| `weekly` \| `monthly` \| `quarterly` \| `annual` \| `on_demand` |
| `internal_sla` \* | `sla_object` | Строки, критерії якості, резервний режим |
| `cost_allocation` \* | `cost_alloc_object` | Тип витрат і сума |
| `enables` \* | `ref`[] → `H4.backstage_process` \| `H5.support_process` | Що обслуговує. **Порожній список = сирота** |
| `control_points` | `list`[`control_point`] | Точки контролю (див. секцію 3.2) |
| `admission` | `admission_object` | Критерії допуску до процесу (реалізація → H6) |

**`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`

Формалізоване правило, що визначає поведінку в процесах.

| Поле | Тип | Опис |
|------|------|-------------|
| `scope` \* | `ref`[] → H4/H5 `process` | Які процеси регулює |
| `last_reviewed` \* | `date` | Дата останнього перегляду |
| `review_cadence` \* | `enum` | Періодичність перегляду |
| `compliance_type` \* | `enum` | `internal` \| `regulatory` \| `contractual` |

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

#### `compliance_rule`

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

| Поле | Тип | Опис |
|------|------|-------------|
| `regulator` \* | `string` | Хто вимагає |
| `deadline_pattern` \* | `string` | Коли здавати |
| `penalty_for_violation` \* | `string` | Ціна порушення |
| `enables` \* | `ref`[] → `H5.support_process` | Який процес забезпечує |
| `last_change` \* | `date` | Дата останньої зміни вимоги |

### Ребра H5

| Тип зв’язку | Від → До | Опис |
|-----------|--------|----------|
| `enables` | `support_process` → `H4.backstage_process` | Обслуговує ключовий процес |
| `enables` | `support_process` → `H5.support_process` | H5 обслуговує інший H5 |
| `governed_by` | `H5.process` → `policy` | Регулюється політикою |
| `complies_with` | `H5.process` → `compliance_rule` | Виконує вимогу регулятора |

### Правила валідації 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` не пізніше рівня сервісу споживача.
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`

Набір операцій, що потребують певного профілю компетенцій.

| Поле | Тип | Опис |
|------|------|-------------|
| `performs` \* | `ref`[] → H4/`H5.operation` | Які операції виконує |
| `required_competencies` \* | `ref`[] → `competency` | Необхідні компетенції |
| `labor_type` \* | `enum` | `person_as_process` \| `person_in_process` |
| `work_instructions_ref` | `list[string]` | Посилання на робочі інструкції |
| `context_profile` | `context_profile_object` | Профіль для перевірки сумісності ролей |

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

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

#### `competency`

Конкретна перевірювана навичка або знання.

| Поле | Тип | Опис |
|------|------|-------------|
| `level` \* | `enum` | `basic` \| `intermediate` \| `expert` |
| `verification` \* | `string` | Як перевіряється (атестація, тест, демонстрація) |
| `training_path` | `list[string]` | Шлях навчання |

#### `sourcing_decision`

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

| Поле | Тип | Опис |
|------|------|-------------|
| `operation_ref` \* | `ref` → H4/`H5.operation` | Для якої операції |
| `variant` \* | `string` | Опис варіанта (сегмент, тариф, географія) |
| `decision` \* | `enum` | `make` \| `buy` \| `outsource` \| `automate` |
| `rationale` \* | `string` | Обґрунтування |
| `labor_type` | `enum` | `person_as_process` \| `person_in_process` (для `make`/`outsource`) |
| `team_type` | `enum` | `division_of_labor` \| `crew` \| `independent_operators` (тільки для `make`) |
| `roles_required` | `ref`[] → `role` | Які ролі потрібні (для `make`) |
| `required_competencies` | `ref`[] → `competency` | Які компетенції |
| `admission_control` \* | `admission_control_object` | Тип контролю (див. секцію 3.3) |
| `bus_factor` | `integer` | Скільки людей можуть виконати (для `make`) |
| `fallback` \* | `string` | План відкату |
| `transition_cost` | `string` | Вартість переходу |
| `review_trigger` \* | `string` | Умова перегляду рішення |

**`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

| Тип зв’язку | Від → До | Опис |
|-----------|--------|----------|
| `performs` | `role` → H4/`H5.operation` | Роль виконує операцію |
| `requires` | `sourcing_decision` → `competency` | Рішення потребує компетенції |
| `composes` | `role` → `H7.position` | Ролі групуються в позиції |
| `depends_on` | `sourcing_decision` → `sourcing_decision` | Залежність рішень |
| `controls` | `sourcing_decision` → `H5.support_process` | Для `outsource`: контрольний процес |

> **`controls` не створює процес.** Рішення про аутсорс робить контрольний процес необхідним, але вузол H5 не породжується ребром — він додається через процес зміни графа (гл. 13), як будь-який інший вузол, і лише після цього рішення на нього посилається. H6 читає з H4 і H5; угору він нічого не породжує. Якщо контрольного процесу ще немає, рішення неповне — правило 6 нижче ловить саме це.

### Правила валідації H6


1. **Покриття:** кожна операція з H4/H5 → ≥1 `sourcing_decision`. Без = сіра зона.
2. **Компетенції для `make`:** якщо `decision` = `make` → `roles_required` не порожній, у ролі — `required_competencies`.
3. **Покриття варіантів:** якщо результат H3 має кілька варіантів → кожен → власний `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`

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

| Поле | Тип | Опис |
|------|------|-------------|
| `type` \* | `enum` | `department` \| `team` \| `group` \| `division` |
| `parent_unit_ref` | `ref` → `organizational_unit` | Вища одиниця (`null` для верхнього рівня) |
| `position_refs` \* | `ref`[] → `position` | Позиції в підрозділі |
| `segment_scope` | `ref`[] → `H1.counterparty` | Для яких сегментів; `null` = для всіх |
| `mode` | `enum` | `Build` \| `Run` \| `Mixed` |
| `cost_center` | `string` | Прив’язка до центру витрат |
| `creation_rationale` | `string` | Чому створено (посилання на залежності H4–H6) |
| `sunset_condition` | `string` | За яких умов розформувати |

#### `position`

Посада — групування ролей із H6.

| Поле | Тип | Опис |
|------|------|-------------|
| `role_refs` \* | `ref`[] → `H6.role` | Ролі, що складають посаду |
| `reports_to` \* | `ref` → `position` | Лінія підпорядкування |
| `demands_from` | `ref`[] → `position` | Позиції, від яких вимагає результат |
| `authority_scope` \* | `text` | Що має право вимагати — конкретні результати |
| `accountability_level` | `enum` | `strategy` \| `goals_budgets` \| `tasks_plans` \| `execution` — рівень відповідальності, якого потребує крісло (глави 10, 16) |
| `min_orientation` | `enum` | `transactional` \| `contributive` — мінімально допустима орієнтація на внесок; `extractive` недопустимий для крісла з автономією або доступом до важелів (глава 16) |
| `unit_ref` \* | `ref` → `organizational_unit` | Підрозділ |
| `current_holder` | `string` | Хто зараз займає |
| `headcount` | `integer` | Кількість людей |
| `substitution_plan` | `string` | Хто заміщує за відсутності |
| `decision_rights` | `list[string]` | Рішення без ескалації |
| `escalation_path` | `string` | Куди ескалується |

> **`accountability_level`** відповідає сходам крісел із глави 16 (`execution` → `tasks_plans` → `goals_budgets` → `strategy`). Два випадки лежать поза ними: *присутність* (нижче execution — кандидат пред’являє регалії замість продукту; це не наймане крісло) і *володіння* (вище strategy — партнер/частка, не позиція на зарплаті). Охоплення та орієнтація кандидата зіставляються з кріслом під час найму; вони не об’єкти графа, тому що граф моделює компанію, а не кандидатів.

#### `promise_policy` — розширення (на `position`)

Повноваження на зовнішні зобов’язання: що ця позиція має право пообіцяти клієнту і коли зобов’язана ескалювати. Відрізняється від `authority_scope` вище, який дивиться *всередину* (що позиція має право вимагати всередині). Дві осі: вимога (всередину) проти обіцянки (назовні).

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

Конкретні ліміти (знижка %, SLA) — ілюстративні; тримайте їх у галузевих прикладах (Додаток F), а не в загальній схемі.

#### `reporting_line`

Формальна лінія підпорядкування.

| Поле | Тип | Опис |
|------|------|-------------|
| `from_position` \* | `ref` → `position` | Підпорядкована |
| `to_position` \* | `ref` → `position` | Вища |
| `right_type` \* | `enum` | `formal` \| `functional` \| `dotted` |
| `right_source` \* | `string` | На чому ґрунтується право |
| `scope` | `enum` | `full` \| `project` \| `temporary` |
| `valid_until` | `date` | Для тимчасових |
| `legitimacy_check` | `object` | Чи підтверджено реальним правом (`boolean` + `comment`) |

#### `dependency_line`

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

| Поле | Тип | Опис |
|------|------|-------------|
| `from_position` \* | `ref` → `position` | Кому потрібен результат |
| `to_position` \* | `ref` → `position` | Хто постачає результат |
| `process_ref` \* | `ref` → H4/`H5.process` | Який процес породжує залежність |
| `frequency` \* | `enum` | `daily` \| `weekly` \| `per_event` \| `on_demand` |
| `criticality` \* | `enum` | `low` \| `medium` \| `high` \| `blocking` |
| `sla_ref` | `ref` → sla | Внутрішній SLA |
| `escalation_mechanism` | `string` | Як ескалується |
| `formalization_status` | `enum` | `informal` \| `agreed` \| `contracted` |
| `cost_of_failure` | `string` | Що відбувається при збої |

### Ребра H7

| Тип зв’язку | Від → До | Опис |
|-----------|--------|----------|
| `composes` | `H6.role` → `position` | Ролі збираються в позицію |
| `reports_to` | `position` → `position` | Лінія підпорядкування |
| `depends_on` | `position` → `position` | Лінія залежності (з конкретного процесу) |
| `segment_scope` | `organizational_unit` → `H1.counterparty` | Прив’язка до клієнтського сегменту |

### Правила валідації 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) теж пов’язують вузли, але тут не перелічені.

### Всередині горизонтів

| `edge_type` | Від → До | Опис |
|-----------|--------|----------|
| `experiences` | `counterparty` → `pain_point` | Контрагент переживає біль (H1) |
| `activates` | `trigger` → `step` | Тригер запускає крок (H1) |
| `escalates` | `trigger` → `pain_point` | Тригер посилює біль (H1) |
| `leads_to` | `step` → `step`, `touchpoint` → `touchpoint` | Перехід уперед (H1, H2) |
| `returns_to` | `step` → `step` | Повернення назад (H1) |
| `considers` | `step` → `alternative` | Розгляд альтернативи (H1) |
| `filters` | `evaluation_criterion` → `alternative` | Відсікання за критерієм (H1) |
| `enters_via` | `entry_point` → `step` | Бічний вхід (H1) |
| `loops_to` | `step`(5) → `step`(1) | Петля повернення (H1) |
| `contains` | `channel` → `touchpoint` | Канал містить точку контакту (H2) |
| `competes_with` | `touchpoint` → `touchpoint` | Конкуренція (H2) |
| `redirects_to` | `touchpoint` → `H1.alternative` | Перенаправлення (H2) |
| `recovers` | `deliverable` → `deliverable` | Відновлення сервісу (H3) |
| `variant_of` | `deliverable_variant` → `deliverable` | Варіант (H3) |
| `composed_of` | `backstage_process` → `operation` | Складається з (H4) |
| `governed_by` | `process` → `policy` | Регулюється (H5) |
| `complies_with` | `process` → `compliance_rule` | Відповідає вимозі (H5) |
| `depends_on` | `node` → `node`, один горизонт | Вихід одного вузла живить інший на тому ж горизонті. Припустимо на будь-якому горизонті — так виражаються проміжні результати: результат, який споживає інший результат; процес, що виробляє пакування для інших процесів |
| `reports_to` | `position` → `position` | Підпорядкування (H7) |

### Між горизонтами

| `edge_type`        | Від → До                                   | Опис                                                                                                |
| ------------------ | ------------------------------------------ | --------------------------------------------------------------------------------------------------- |
| `generates`        | H1 → H2                                    | `question_node` породжує точку контакту                                                             |
| `generates`        | H2 → H3                                    | точка контакту породжує результат                                                                   |
| `requires`         | H3 → H4                                    | Результат потребує процесу                                                                          |
| `delivers`         | H4 → H3                                    | Процес виробляє результат                                                                           |
| `requires_support` | H4 → H5                                    | Ключовий процес потребує обслуговуючого                                                             |
| `enables`          | H5 → H4, H5 → H5                           | Обслуговуючий процес обслуговує ключовий (або інший обслуговуючий)                                  |
| `performs`         | `H6.role` → H4/`H5.operation`              | Роль виконує операцію                                                                               |
| `composes`         | `H6.role` → `H7.position`                  | Ролі збираються в позицію                                                                           |
| `controls`         | `H6.sourcing_decision` → H5                | Контрольний процес для `outsource`                                                                  |
| `segment_scope`    | `H7.unit` → `H1.counterparty`              | Прив’язка до сегменту                                                                               |
| `sourced_by`       | H4/`H5.operation` → `H6.sourcing_decision` | Тут вирішується, яким способом виконується ця операція (зворотний вид — `operation_ref` на рішенні) |
> **Зворотна пара `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}"
```

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

| Перевірка | Правило | Рівень |
|----------|---------|---------|
| H1→H2 | Кожен `question_node` → ≥1 `touchpoint` | Критично |
| H2→H3 | Кожна `owned`-точка контакту з `generates` → результат існує | Критично |
| H3→H4 | Кожен результат → ≥1 `process` (або самообслуговування) | Критично |
| H4→H5 | H4 з `requires_support` → H5 існує | Попередження |
| H4/H5→H6 | Кожна `operation` → ≥1 `sourced_by` → `sourcing_decision` | Попередження |
| H6→H7 | Кожна `role` (`make`) → ≥1 `position` | Попередження |

### Каскад 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}"
```

### Перевірки на сиріт (знизу вгору)

| Горизонт | Правило | Дія |
|----------|---------|----------|
| H2 | `touchpoint` без `info_need_ref` на H1 | Ліквідувати — вона відповідає на питання, якого ніхто не ставить |
| H3 | результат (`deliverable`) недосяжний від H2 за `triggered_by`, напряму або через `depends_on` | Ліквідувати або лишити як оголошений проміжний результат |
| H4 | `process` недосяжний від H3 за `delivers`, напряму або через `depends_on` | Перемістити в H5 або ліквідувати |
| H5 | обслуговуючий процес, чий ланцюжок `enables` не закінчується процесом H4 | Ліквідувати |
| H6 | `competency` без посилань із `role` | Видалити |
| H7 | `position` без `role_refs` | Ліквідувати |
| H7 | `unit` без `dependency_lines` до інших `unit` | Перевірити на відрив |

### Перевірки узгодженості

| Перевірка | Правило |
|----------|---------|
| Формат власника | `maturity` ≥ 3 → `owner` = `ref`, не `string` |
| Свіжість | вузол за `freshness.expires_at` → застосувати `stale_action` (`warn` / `block` / `require_owner_review`) |
| Термінологія | `delivers` → `H3.deliverable` (не сервіс, не процес) |

---

## 13. Шаблони промптів для ШІ

Готові промпти для заповнення і валідації графа через ШІ.

### Промпт 1: Заповнення вузла H4

```
У мене є результат на H3:
- name: [назва]
- SLA: [цільовий час]
- acceptance_criteria: [критерії]

Опиши backstage_process для виробництва цього результату у форматі 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 (supporting processes) і 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

```
Ось результат з H3 і процес, який його виробляє:

Результат: [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

```yaml
# === 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.*