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

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 = «німа точка контакту»
• 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 (або критична точка контакту без блоку 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 точки контакту з 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.

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 не пізніше рівня сервісу споживача.
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 має кілька варіантів → кожен → власний 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

У мене є результат на 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

# === 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.