SMF v2.2

Semantic Modeling Framework (SMF) v2.2

version: 2.2
format: markdown
usage: “Semantic Modeling Framework. Определяет структуру узлов, связей, атрибутов для ВСЕХ семантических графов EnMaTeS. Используется как основа для построения более специфичных фреймворк-промптов.”

0. Метаданные Графа (для слепка диалога)

• graph_version: “Номер версии генерируемого/анализируемого графа, например, 1.0”
• creation_timestamp: “YYYY-MM-DDTHH:MM:SSZ (время создания графа)”
• last_update_timestamp: “YYYY-MM-DDTHH:MM:SSZ (время последнего обновления графа)”
• dialog_session_id: “Уникальный идентификатор сессии диалога (если доступен)”
• summary: “Краткое описание (1-2 предложения) основного фокуса или цели данного диалога/графа”

1. Основные сущности (Nodes)

Каждый узел должен иметь следующие атрибуты:

• MUID: “Уникальный идентификатор узла (формат UUID). Генерируется ИИ при создании узла, если не предоставлен.”
• timestamp: “YYYY-MM-DDTHH:MM:SSZ (время первого упоминания/создания узла)”
• turn_id: “Порядковый номер сообщения/хода в диалоге, где узел был введен или существенно изменен.”
• source: “user | ai | derived_from_MUID: <MUID_родительского_узла> (Источник узла)”
• type: “Тип узла (см. ниже)”
• content: “Краткое текстовое описание сути узла (например, название концепта, формулировка цели).”
• role: “Семантическая роль узла (см. п.3)”
• context: “Контекст внимания (см. п.4, можно несколько через запятую)”
• explicitness: “explicit (явно сформулирован) | inferred (выведен ИИ)”
• weight: “low | medium | high (значимость узла)”
• status: “(Опционально, в зависимости от типа узла) proposed | accepted | rejected | in_progress | completed | verified | falsified | revised | obsolete | isolated_candidate и т.д.”
• description: “(Опционально) Более подробное описание узла, которое может содержать ключевую информацию, резюме из документа или дополнительные пояснения. Важно для RAG и понимания.”

Типы узлов (type):

• concept: ключевая идея, сущность, объект обсуждения, термин, определение
• goal: цель, которой посвящена часть диалога
• problem: сформулированная проблема
• solution: предложенное решение
• actor: человек, система или роль (например, “Заказчик”, “Подрядчик”, “Система Планфикс”)
• process: процесс, механизм или этап воркфлоу
• signal: внешнее событие, триггер или прямой запрос пользователя
• artifact: создаваемый или обсуждаемый артефакт (файл, документ, схема, проект, код, текст)
• hypothesis: гипотеза, предположение
• metric: критерий, показатель
• requirement: требование, условие
• constraint: ограничение
• question: важный открытый вопрос, требующий ответа/исследования
• answer: ответ на question
• finding: важный вывод, наблюдение, результат анализа
• assumption: допущение, принятое без строгого доказательства
• feature: характеристика или возможность системы/концепта
• placeholder: заполнитель для данных в шаблонах (например, {{pseudo: Номер Договора}})
• artifact_template_fragment: фрагмент шаблона артефакта, многократно используемый блок (например, {{БЛОК: ...}})
• flow: процесс верхнего уровня, воркфлоу, сценарий (часто используется в YAML для описания потоков Membra)

2. Типы связей (Relations)

Каждая связь должна иметь следующие атрибуты:

• from_MUID: “MUID исходного узла”
• to_MUID: “MUID целевого узла”
• type: “Тип связи (см. ниже)”
• weight: “low | medium | high (сила связи, по умолчанию: medium)”
• context: “Контекст внимания, к которому относится связь (опционально, см. п.4)”
• label: “Краткое описание связи, если тип не полностью ее раскрывает (опционально)“

Типы связей (type):

• leads_to: ведёт к (A → B)
• depends_on: зависит от (A зависит от B)
• refines: уточняет, конкретизирует, детализирует (A уточняет B)
• contradicts: противоречит
• analogous_to: аналогично (более узко, чем similar_to)
• similar_to: похоже на (более широкое сходство)
• related_to: общая тематическая связь (использовать экономно, когда другие типы не подходят)
• causes / caused_by: вызывает / вызвано (причина-следствие)
• part_of / composed_of: является частью / состоит из (декомпозиция)
• instance_of / example_of: является экземпляром / примером
• supports / argues_for: поддерживает / аргументирует в пользу
• challenges / questions_relation: ставит под сомнение / оспаривает (связь между узлами)
• clarifies / elaborates_on: проясняет / детализирует
• precedes / follows: предшествует / следует за (временная или логическая последовательность)
• enables / blocks: делает возможным / блокирует
• alternative_to: является альтернативой
• addresses / solves: направлено на решение / решает (например, solution addresses problem)
• raises / identifies: поднимает / идентифицирует (например, finding raises question, или process identifies problem)
• requires: требует (A требует B для своего существования/выполнения)
• constrains: ограничивает (A накладывает ограничение на B)
• answered_by / answers_question: (question A answered_by answer B)
• derived_from: (новый узел выведен из старого, дополняет source у узла)
• replaces: (новый узел заменяет старый, часто вместе с derived_from)
• defines: артефакт или концепт определяет другой концепт/термин
• contains_placeholder: артефакт (шаблон) содержит плейсхолдер
• uses_placeholder: артефакт (шаблон) использует плейсхолдер (для подстановки значения)
• conditionally_uses_fragment: артефакт (шаблон) условно использует фрагмент/блок
• references: общая ссылка одного узла на другой (например, документ ссылается на концепт)
• modifies: один артефакт (например, Доп.соглашение) изменяет другой (например, Договор)
• produces_artifact: процесс или действие создает/порождает артефакт
• produces_artifact_concept: процесс или действие создает/порождает концепцию артефакта
• uses_artifact: процесс или действие использует артефакт
• provides_input_for: один узел (артефакт, концепт) предоставляет входные данные для другого (процесса, узла)
• party_to_contract: актор является стороной контракта/артефакта
• responsible_for_action: актор ответственен за выполнение действия/процесса
• responsible_for_fulfilling: актор ответственен за выполнение требования
• participates_in: актор участвует в процессе
• initiates: актор или событие инициирует процесс/действие
• triggers: узел (событие, артефакт) запускает процесс/действие
• achieves_status: процесс приводит к достижению определенного статуса для узла
• governs: узел (например, правило, статус) управляет или регулирует другой узел/процесс
• fulfills_part_of: действие или узел выполняет часть требования/условия
• affected_by: узел/процесс подвержен влиянию другого узла/условия
• has_exclusions: концепт (например, Гарантийный срок) имеет исключения (другой узел)
• initiates_payment_for: артефакт (Счет) инициирует процесс оплаты
• initiates_period_for: артефакт (Акт) или событие начинает течение периода (например, гарантийного)
• defined_by_duration_of: процесс или состояние определяется длительностью другого узла (например, Гарантийный срок)
• issues_document: актор выпускает/выставляет документ
• instance_of_concept_managed_by_flow: конкретный блок (фрагмент) является экземпляром концепции, управляемой более общим потоком/системой блоков

3. Семантические роли узлов (role)

• anchor: якорная точка внимания, ключевой элемент диалога
• volatile: может измениться или устареть в ходе диалога
• stable: сохраняется как основа на протяжении значительной части диалога
• critical: семантически критично (существенно влияет на понимание или цели)
• kv_persist: (Служебное, для ИИ с KV-кешем) сохранить в KV-кеше
• kv_clear: (Служебное, для ИИ с KV-кешем) удалить из кеша
• context_setter: узел, задающий важный контекст для последующих обсуждений
• summary_node: узел, обобщающий несколько других узлов
• meta_element: элемент, описывающий сам граф, фреймворк или процесс работы с ними
• gate: узел, представляющий собой условие или этап, прохождение которого открывает следующие шаги
• milestone: важная веха, контрольная точка в процессе или проекте

4. Контексты внимания / семантические проекции (Subspaces) (context)

• logic: причинно-следственные связи, структура аргументации
• strategy: пути достижения цели, планирование
• design: визуализация, структура артефактов, интерфейсы
• workflow: действия, последовательности операций, процессы
• emotion: мотивации, страхи, ощущения (если релевантно)
• risk: факторы неопределенности, потенциальные проблемы
• technical: технические детали, реализация
• meta: обсуждение самого диалога, фреймворка, поведения ИИ
• historical_context: ссылки на предыдущие этапы или внешние знания
• legal: юридические аспекты, договорные отношения, правовые нормы
• finance: финансовые аспекты, платежи, стоимость, бюджет
• business_rules: бизнес-правила, регламенты, политики компании
• content_management: управление контентом, шаблонами, версионирование документов
• communication: взаимодействие между сторонами, уведомления, каналы связи
• logistics: доставка, транспортировка, хранение
• production: производственные процессы, изготовление
• support: поддержка клиентов, гарантийное обслуживание
• quality_control: контроль качества продукции или услуг
• dispute_resolution: разрешение споров, претензионная работа
• compliance: соответствие требованиям законодательства, стандартам (например, ПДн)
• security: аспекты безопасности (например, доверенные лица, доступ к информации)
• planning: планирование сроков, ресурсов, этапов работ
• requirement: (как контекст) относится к требованиям
• business: общие бизнес-аспекты, коммерческая деятельность
• project_management: управление проектами, задачи, этапы проекта
• platform: относится к технологической платформе (например, Firebase, Genkit)
• llm: относится к работе с Large Language Models (например, Gemini API)
• ai_logic: относится к логике работы ИИ-агентов, алгоритмам ИИ
• development_tool: относится к инструментам разработки (например, Jules, IDE)
• integration: относится к интеграции систем и компонентов