Сценарии

NOUZ полезен в разных ситуациях: когда база знаний только создаётся, и когда она уже большая, живая и местами неоднородная. Это разные режимы работы.

Кому подходит

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

Подходит:

• исследователям и авторам, которые ведут заметки по нескольким областям и хотят видеть пересечения;
• разработчикам и командам, которым нужен MCP-доступ к живой проектной памяти;
• людям с Obsidian vault или другой папкой Markdown, где часть связей уже есть, но многое осталось только “в голове”;
• базам, где важно различать структуру и содержание: что заметка должна была означать и о чём она фактически говорит.

Не лучший вариант:

• для маленькой базы из 20–30 заметок без устойчивых тем;
• если нужен только полнотекстовый поиск;
• если нет готовности один раз настроить домены и проверить качество эталонов.

Новая база

Ситуация: вы начинаете базу с нуля или переносите небольшой набор материалов. Структура ещё не заросла случайными связями, поэтому NOUZ можно подключать мягко: граф растёт вместе с базой.

Как работать:

1. Начать с LUCA: YAML, родители, граф, формула сущности.
2. Добавлять новые заметки обычным способом.
3. Для новых заметок вызывать suggest_metadata (предложить разметку) или suggest_parents (предложить родителей).
4. Когда накопится достаточно материала, включить PRIZMA: эталоны, embeddings, мосты и core_mix — доменный состав узлов.

Минимальная заметка:

---
type: квант
level: 4
parents:
  - "[[Название модуля]]"
parents_meta:
  - entity: Название модуля
    link_type: hierarchy
tags:
  - тема
---

Что получает агент:

suggest_metadata("Новая заметка.md")
→ {
    sign: "E",
    level: 4,
    suggested_parents: ["Архитектура/Паттерны.md"],
    bridges: [
      {type: "semantic", target: "Design/CQRS.md", cosine: 0.74, proposed: true}
    ]
  }

Идея: вы задаёте структуру по мере роста базы, а NOUZ предлагает место, домен, теги и мосты. Решение остаётся за вами.

---

Существующая база

Ситуация: у вас уже есть большая база: сотни заметок, старые папки, разные стили записи, частично заполненный YAML. Здесь нельзя просто включить автоматику и доверить ей всё сразу. Настройки сильно зависят от реальных данных.

Как работать:

1. Сначала проиндексировать базу без массовых правок.
2. Посмотреть реальные домены, типы заметок, уровни и разрыв между папками и содержанием.
3. Написать эталоны под эту базу, а не под абстрактный пример.
4. Запустить calibrate_cores и проверить сырые / mean-centered косинусы.
5. Настроить пороги классификации и связей: sign_spread, pattern_second_sign_threshold, semantic_bridge_threshold, parent_link_threshold.
6. Запускать recalc_signs, suggest_metadata и process_orphans партиями, проверяя результаты.

Пример:

index_all()
calibrate_cores()
recalc_signs()
suggest_metadata("Технический долг.md")

bridges:
  - semantic: "Энтропия.md" (cosine: 0.71)
  - semantic: "Трагедия общин.md" (cosine: 0.63)

Идея: NOUZ показывает состояние уже существующей базы: потерянные связи, неразмеченные заметки, слабые родители, дрифт между sign и core_mix. Новая структура появляется после вашего решения, а не вместо него.

---

Дрифт: когда структура расходится с реальностью

Ситуация: модуль «Машинное обучение» начинался как технический, но последние заметки всё чаще про философию ИИ, этику и системные ограничения. Название и YAML говорят одно, содержимое уже другое.

format_entity_compact("ML/Машинное обучение.md")
# → sign: E (Engineering), core_mix: {S: 61%, E: 39%}
# → предупреждение о дрифте: sign=E, core_mix показывает доминанту S

core_drift показывает расхождение между замыслом и фактическим содержанием. Это повод посмотреть на модуль внимательнее: переименовать, разделить на два, перенести часть заметок или принять новую траекторию.

---

AI-агент: структурная память

Ситуация: агенту нужен графовый контекст: где заметка находится, с чем связана и какие материалы лежат вокруг неё.

{
  "mcpServers": {
    "nouz": {
      "command": "python",
      "args": ["-m", "nouz_mcp"],
      "env": {
        "OBSIDIAN_ROOT": "/path/to/vault",
        "EMBED_API_URL": "http://127.0.0.1:1234/v1"
      }
    }
  }
}

Пользователь: "Расскажи про архитектуру мониторинга"

Агент использует NOUZ:
1. list_files(subfolder="infrastructure") → 12 файлов
2. get_children("Infrastructure/Мониторинг.md") → [Prometheus.md, Grafana.md, Alerting.md]
3. format_entity_compact("Infrastructure/Мониторинг.md") → (S2E)[E]{E}
4. read_file каждого потомка → полный контекст

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

---

Документация живого проекта

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

Проект/
├── Архитектура.md       # L3 модуль
├── Решения/
│   ├── ADR-001.md       # L4 квант
│   ├── ADR-002.md
├── Баги/
│   ├── Bug-tracker.md   # L3 модуль
│   ├── Issue-42.md      # L4 квант
└── Ретроспективы/
    └── 2026-Q1.md       # L5 артефакт

get_children("Проект/Архитектура.md") даёт агенту иерархию. suggest_parents("Новый баг.md") ищет похожие прошлые случаи. format_entity_compact показывает, где любая заметка находится в структуре проекта.

Что остаётся у вас

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

Дальше обычно идут три шага: настроить эталоны под свою базу, проверить их качество через calibrate_cores, затем подключить MCP-клиент и дать агенту доступ к графовому контексту.