Связи и Граф

Если уровни отвечают за роли сущностей, а знаки — за их доменную принадлежность, то связи отвечают за движение смысла между ними.

В NOUZ-MCP связь — это утверждение о том, как одна заметка относится к другой: принадлежит, происходит из источника, временно опирается, перекликается, повторяет форму или похожий смысл.

Именно связи превращают Markdown-папку в граф.

---

hierarchy: позвоночник базы

hierarchy — главная структурная связь. Она строит основной DAG-граф: ядро держит паттерны, паттерн держит модули, модуль держит кванты и артефакты.

В текущей модели у заметки должен быть один основной hierarchy-родитель: это ее место в структурном конвейере. Если у материала несколько источников, контекстов или смысловых соседей, их лучше фиксировать через derived_from, semantic, temporary, tag или analogy.

parents:
  - '[[Маркетинг]]'
parents_meta:
  - entity: Маркетинг
    link_type: hierarchy

parents_meta — источник истины для NOUZ. parents нужны, чтобы Obsidian и другие Markdown-инструменты видели обычные wiki-ссылки.

Хорошая иерархическая связь должна быть прямой. Если квант принадлежит модулю, достаточно связать его с модулем. Не нужно добавлять в каждую заметку всю цепочку предков до ядра: граф сам поднимется вверх.

---

derived_from: след происхождения

derived_from показывает, что одна сущность была получена из другой. Такую связь удобно использовать, когда из сырого артефакта появляются разные кванты: тезис, задача, пост, решение, спецификация или другой завершенный результат.

parents_meta:
  - entity: Onboarding
    link_type: hierarchy
  - entity: Лог разговора с пользователем
    link_type: derived_from

В этом примере Onboarding отвечает на вопрос «где лежит квант?», а Лог разговора с пользователем отвечает на вопрос «из чего он появился?».

derived_from лучше не ограничивать только артефактами. Чаще всего источником действительно будет L5-артефакт, но иногда квант может быть выведен из другого кванта, спецификация — из решения, а задача — из отчета или поста.

---

temporary: временная заметка

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

parents_meta:
  - entity: Входящие идеи
    link_type: temporary

В режиме LUCA временные связи особенно полезны. На старте базы лучше не потерять материал, чем ждать идеальной онтологии.

---

semantic: смысловой мост

semantic связывает сущности, которые близки по смыслу, но не обязательно находятся в одной ветке иерархии. В PRIZMA и SLOI такие мосты может предлагать автоматика.

Если derived_from отвечает на вопрос «из чего это произошло?», то semantic отвечает на вопрос «с чем это похоже по смыслу?».

---

tag: мост через локальный словарь

tag это повторяющийся термин. Общий тег помогает агенту увидеть похожую тему.

---

analogy: подтвержденная аналогия

analogy — это ручная связь для случаев, когда сущности похожи не просто словами, а структурой.

parents_meta:
  - entity: Технический долг
    link_type: analogy

Такой мост говорит агенту: здесь есть подтвержденное сходство формы. Автоматически такие связи лучше не раздавать слишком смело, аналогия требует вашего понимания формы.

---

error: служебная красная лампочка

error — служебный сигнал для диагностики: нарушенная иерархия, конфликт, невозможная структура, ошибка в графе.

В нормальной ручной разметке пользователь почти никогда не должен создавать error сам. В режиме SLOI ошибка возникает при поломке 5-ступенчатой структуры.

---

Почему нужны разные типы связей

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

Если все связи сделать свободными, база распадется в сеть случайных переходов.

NOUZ держит середину:

• hierarchy дает позвоночник;
• derived_from сохраняет происхождение;
• temporary сохраняет незавершенные дела;
• semantic показывает смысловые мосты;
• tag соединяет локальный словарь;
• analogy фиксирует глубокое сходство формы.

Так агент может двигаться по базе разными способами: сверху вниз, снизу вверх, от результата к источнику, поперек доменов, через термины или через аналогии.

---

LUCA, PRIZMA и SLOI

В luca связи в основном явные. Сервер держит YAML, граф и проверку циклов, но не решает какие сущности семантически близки.

В prizma появляются эталоны, эмбеддинги, семантические мосты, теговые мосты, sign_auto и core_mix.

В sloi к этому добавляется строгая проверка уровней. Это режим для дисциплинированных баз, в которых важно, чтобы структура не расползалась.