Skip to content

SPEC-RU.md

Latest commit

 

History

History
787 lines (653 loc) · 92.3 KB

SPEC-RU.md

File metadata and controls

787 lines (653 loc) · 92.3 KB
Raw

MAQS-Way v0.3 — Общий путь от политик к реализации долгосрочной памяти ИИ

Статус: v0.3 — релиз канонизации (все 12 known gap'ов с v0.2 закрыты подписанными владельцем пакетами; открытых known gap'ов нет), нормативное имя файла SPEC.md, дата редакции 2026-10-27 Автор: Александр Косарев Отношение к MAQS: MAQS v1.9 остаётся техническим ядром аудита (репозиторий MAQS). Way — надстройка: модель + жизненный цикл + измеримая верификация. Примечание о лицензиях: Источники упомянуты в соответствии со своими лицензиями. Настоящая спецификация — Apache-2.0.

0. Диагностика отрасли

Что существует:

  • Слой политик: GDPR Art17, EU AI Act Art12/13/19, RBAC — избыток деклараций о том, что должно быть
  • Слой аудита: MAQS — чек-лист «как убедиться, что не сломается», каждый пункт CRIT подтверждён производственным инцидентом

Чего не хватает:

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

0.1 Обзор ландшафта — сводка

Полный скан ведётся в docs/landscape.md (единый источник истины, датирован 2026-10-10, проверено 11 семейств). Этот раздел — только сводка, во избежание рассинхрона.

  • Переносимость: OMPS rdh073/omps — memory-item.schema.json, deletion-marker.schema.json
  • Жизненный цикл/Области: AMSP sanej/amsp — active→deleted, user-portable, team-shared
  • Провенанс: OAMP deep-thinking-lab — привязка agent_id §4.3 обязательна
  • Транспорт: MCP Memory Servers — Entity/Relation, плоский файл на инстанс
  • Управление: MemoryOps AI patibandlavenkatamanideep/memoryops-ai — 10 инвариантов, Policy Broker
  • Векторное извлечение: Mem0/Mem0g arXiv:2504.19413 — ADD/UPDATE/DELETE/NOOP, пробел: провенанс стирается
  • Битемпоральный граф знаний: Zep/Graphiti getzep/graphiti arXiv:2501.13956 — valid_at/invalid_at + t'_created/t'_expired, инвалидация при противоречии
  • Верификация удаления: Tombstone poojan6216/tombstone — каскад из 6 уровней, бенч: native delete оставляет 92–100% восстановимого
  • Оценка качества: LoCoMo, LongMemEval (с абстиненцией), MemoryAgentBench
  • Безопасность: OWASP LLM Top10, OWASP Agentic ASI06 Memory Poisoning, MITRE ATLAS AML.T0080
  • Наблюдаемость: EU AI Act Art12 + OTel GenAI semconv

См. docs/landscape.md — там конкретные артефакты и статус верификации каждой ссылки (живая проверка обязательна до публикации; в landscape.md ведётся колонка verified: ✅/⏳/❌ по каждой строке).

1. Слой ПРИНЦИПОВ

Структура каждого принципа (паттерн P/V/E применён к этому слою с v0.1.1; слои «Архитектура» и «Верификация» — выравнивание P/V/E отложено, см. Бэклог §6):

  • Свойство (обязательно): что должно выполняться
  • Верификация (how to check): тест, метрика, негативный сценарий
  • Пример (не нормативно, hint): подсказка
  • Ссылка на MAQS + инцидент (родословная MAQS → Way)

Пороговые значения в этой версии — ориентировочные инженерные цели, подлежат пересмотру после первого прогона на реальной системе. Нормативные пороги — отложены, см. Бэклог §6.

P1 Достоверность (Veracity) — память это данные, а не инструкции

  • Свойство: Каждая запись памяти — типизированные данные, а не исполняемая инструкция. Вывод модели типизируется как source.type=model_output и не должен повышать доверие при суммаризации/преобразовании.
  • Верификация: Зонд ложных фактов OWASP ASI06-001 → Policy Broker BLOCK 100% (ориентировочно). Обёрнут в <retrieved_context type=...>. Преобразование должно сохранять confidence_after ≤ confidence_before для model_output.
  • Пример: огороженный retrieved_context + policy broker BLOCK
  • Ссылка на MAQS: E6 (эскалация доверия при суммаризации), F1–F8 петля обратной связи, F7 admitted≠trusted. Инцидент: агент суммаризировал собственный отчёт об ошибке и повысил доверие с 0.6 до 0.9, что привело к петле.

P2 Провенанс (Provenance) — каждая запись прослеживается

  • Свойство: Каждая запись несёт: кто создал, когда, ссылка+хеш источника, policy_id/версия, доверие, история преобразований. Мутации дописывают провенанс, никогда не заменяют происхождение.
  • Верификация: Валидация схемы против OMPS memory-item.schema.json, расширенного обязательной привязкой OAMP §4.3 source.agent_id == provenance.created_by.id. identity_signature = Ed25519 над каноническим JSON (спецификация отложена, см. Бэклог §6).
  • Пример: провенанс OMPS + agent_id, session_id, source_hash из OAMP
  • Ссылка на MAQS: B (целостность записи), 0 Map. Инцидент: осиротевшие векторы без источника после миграции — аудит невозможен.

P3 Управляемое старение (Controlled Aging) — забывать устаревшее, сохранять релевантное

  • Свойство: Память затухает по устареванию, обновляется при использовании, замещается при противоречии, истекает по TTL — не вытесняя релевантное.
  • Верификация: Golden set: временнáя точность CI gate ≥65%, target ≥80% (LoCoMo temporal + Graphiti valid_at); точность обновления знаний после замещения ≥70% (LongMemEval); свежее не вытесняется раньше устаревшего.
  • Пример: битемпоральность Graphiti valid_at/invalid_at (когда факт был истинен) + t_created/t_expired (когда узнали)
  • Ссылка на MAQS: D Retrieval, C Growth. Инцидент: удвоение объёма после того, как job затухания удалил свежие факты из-за путаницы с временными метками.

P4 Изоляция (Isolation) — границы доказываются негативными тестами

  • Свойство: Границы тенантов/пользователей/проектов/агентов соблюдаются, включая путь векторного поиска, — а не только наличие фильтра.
  • Верификация: Негативный тест cross_tenant_retrieval_returns_0, leak=0 (ориентировочно). Включая векторный путь. Должен покрывать провенанс эмбеддингов. G1 требует 4 фикстуры (§2.3): независимые caller'ы, неверный/отсутствующий scope, попытка записи read-only, доступ после отзыва.
  • Пример: инвариант №1 MemoryOps + модель областей AMSP
  • Ссылка на MAQS: G Isolation. Инцидент: поиск вернул память Пользователя A Пользователю B, потому что фильтр pgvector применялся после top-k.

P5 Удаляемость (Deletability) — удаление распространяется везде

  • Свойство: Удаление распространяется на реплики, векторные индексы, кэши, производные сводки. Надгробие (tombstone) сохраняется без персональных данных.
  • Верификация: Решётка удаления LOGICAL/PHYSICAL/SEMANTIC/MODEL, остаток 0.0% (ориентировочно; бенч tombstone). Удаление = каскад из 6 уровней graph_edges → nodes_if_sole_provenance → embeddings_fk → facts_fk → artifacts → rounds в одной PG-транзакции + best-effort сверка графа. каскад только при sole provenance — если провенанс НЕ единственный, удаляется ребро, узел сохраняется.
  • Пример: deletion_log(request_id, timestamp, scope, layer_counts, requestor) с подписью Ed25519, hash-цепочкой, layer_counts для аудита
  • Ссылка на MAQS: B, G. Инцидент: GDPR-удаление убрало строку, но rebuild survivors в Qdrant сохранил эмбеддинг восстановимым на 100%.

P6 Восстановимость (Recoverability) — бэкап + проверенное восстановление

  • Свойство: Бэкап, версионирование схем/эмбеддингов, идемпотентные миграции, проверенные процедуры восстановления.
  • Верификация: Restore drill ежеквартально, равенство хешей восстановленного хранилища и манифеста бэкапа. Проверка совместимости эмбеддингов: модель версионирована, несовпадение → fallback только на ключевые слова retrieval_mode=fallback.
  • Пример: бэкап MAQS P1 + версионированная модель эмбеддингов
  • Ссылка на MAQS: H, I. Инцидент: обновление модели эмбеддингов — все старые векторы не совпали, retrieval молча вернул пустоту без алерта.

P7 Переносимость (Portability) — память пользователя принадлежит пользователю

  • Свойство: Память пользователя экспортируется/импортируется без преобразований, с сохранением согласий, чувствительности и провенанса.
  • Верификация: Round-trip export→import → 0 потерь полей provenance + consent, равенство хешей. Использует OMPS memory-bundle.schema.json + export/import AMSP.
  • Пример: bundle OMPS
  • Ссылка на MAQS: Новое, из OMPS/AMSP. Инцидент: экспорт стёр хеш источника, импорт создал дубликат с новым id.

P8 Измеримость (Measurability) — доказать, что работает, а не что механизм существует

  • Свойство: Качество измеряется на репрезентативных задачах, включая негативные случаи.
  • Верификация: Eval-обвязка LoCoMo/LongMemEval/MemoryAgentBench + негативные сценарии cross_tenant_leak, prompt_injection_via_memory, feedback_contamination, stale_overrides_fresh, shared_fact_visibility_leak. Метрики ориентировочны до первого прогона (CI gate / target): R@5 ≥0.7 / ≥0.85, abstention ≥0.8 / ≥0.9 при отсутствии свидетельств, duplicate ≤5% / ≤2%, contamination ≤1% / 0%.
  • Пример: Golden set + LLM-judge + R@k + описание ограничений (чего метрика не видит)
  • Ссылка на MAQS: D9 расширенный (D9 = самоотчётная диагностика агента, см. MAQS D9). Инцидент: D9 существовал, но без поведенческого теста — система прошла чек-лист и провалила временный recall в проде.

2. Слой АРХИТЕКТУРЫ — какие свойства должны быть реализованы

2.1 Модель данных

Канонической является схема OMPS. Поле schema_version объясняет провенанс. status — производное представление событий жизненного цикла (см. §2.2), а не хранимое поле:

{
  "schema_version": "omps-0.1.0+way-v0.1.3",
  "id": "mem_001",
  "type": "preference | episode | semantic | procedural | project | system",
  "subject": {"type": "user | agent | team | org | system", "id": "user_123"},
  "scope": {"type": "user-portable | agent-private | team-shared | org-shared | local-session"},
  "content": {"format": "text/plain", "value": "...", "language": "en"},
  "sensitivity": "low | medium | high | secret",
  "consent": {
    "basis": "explicit_user_request | inferred | imported",
    "exportable": true,
    "shareable_with_agents": true,
    "usable_for_personalization": true,
    "usable_for_training": false,
    "requires_confirmation_before_use": false
  },
  "retention": {"mode": "until_deleted | ttl | sliding_window | legal_hold", "ttl_days": 90, "valid_from": "...", "valid_to": "..."},
  "provenance": {
    "created_at": "2026-10-10T00:00:00Z",
    "created_by": {"type": "agent", "id": "agent_001"},
    "source": {"type": "conversation | file | web | agent | model_output", "ref": "conv_123", "hash": "sha256:..."},
    "policy_id": "policy_v2",
    "policy_version": "1.3",
    "confidence": 0.92,
    "confidence_after": 0.92,
    "transformation_history": [{"op": "summarize", "from": "mem_000", "at": "...", "agent_id": "...", "confidence_after": 0.85}],
    "sources": [{"agent_id": "...", "session_id": "...", "task_id": "...", "timestamp": "..."}],
    "visible_to": ["user_123", "agent_001"]
  },
  "embedding": {"model": "qwen3-1024", "version": "1.0", "derived_from_trust": "low", "vector_id": "..."},
  "revision": 3,
  "links": {"supersedes": "mem_000", "derived_from": ["episode_123"], "invalidated_by": null, "contested_by": null}
}

Примечание: deletion_marker — НЕ поле живой записи; это отдельный артефакт, управляемый схемой OMPS deletion-marker.schema.json, создаваемый только в момент удаления и сохраняемый в governance tombstone (структура: request_id, timestamp, scope, layer_counts, requestor, signature: ed25519:...). Показан в примере P5 только для наглядности схемы.

Примечания к модели данных:

  • schema_version: "omps-0.1.0+way-v0.1.3" — база omps-0.1.0 + расширение way-v0.1.3, семантика semver-расширения задокументирована.
  • status: производное представление событий жизненного цикла (§2.2), не хранимое поле — вычисляется как проекция последнего события жизненного цикла записи.
  • identity_signature: убрано из примера живой записи; спецификация (Ed25519 над каноническим JSON) отложена — см. Бэклог §6.
  • Нотация scope: допускаются оба варианта user.portable и user-portable — каноничен user-portable (AMSP), таблица соответствий в docs/mapping-to-maqs.md.
  • visible_to: массив subject.id, для которых запись видима. Механизм семантического маскирования (§2.2): при удалении общего факта запросивший удаляется из visible_to; пустой массив → физическое удаление. Отсутствие visible_to = без ограничений внутри scope.
  • Битемпоральность vs retention: valid_at/invalid_at = когда факт был истинен в мире (Graphiti), retention.valid_from/valid_to = когда мы его храним. Приоритет: мировое время — для рассуждений, retention-время — для жизненного цикла. См. §2.2 Приоритет времён.
  • legal_hold: добавлено в retention для Профиля B, где Delete неисполним в период удержания.

2.2 Жизненный цикл

Машина состояний полная:

ACTIVE → STALE (затухание) → ACTIVE (обновление) ACTIVE → CONTESTED (конфликт) → SUPERSEDED (разрешение, политика: для Профиля A побеждает пользователь, для B — Policy Broker, для C конфликта нет) ACTIVE/STALE → EXPIRED (истечение TTL по политике) → ARCHIVED (мягкий архив, смена состояния, не физическое удаление) ARCHIVED → ACTIVE (восстановление, если recoverable и политика позволяет) Any → DELETED (удаление пользователем / GDPR Art17, кроме legal_hold) → TOMBSTONE (мягкое: контент+эмбеддинг очищены, governance tombstone сохранён) → null (жёсткая компакция, подпись Ed25519)

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

Политика разрешения конфликтов:

  • Персональный ассистент: побеждает пользователь (User Wins), новый факт замещает оспоренный со ссылкой supersedes.
  • Корпоративный: Policy Broker решает decision: SAVE|PENDING_APPROVAL|BLOCK|DROP_LOW_UTILITY + mode: APPEND|UPDATE_EXISTING|MERGE_WITH_EXISTING (два ортогональных поля). Решение брокера обжалуется: оспоренные записи могут быть переданы на человеческое рассмотрение; исход обжалования дописывает провенанс и никогда не переопределяет запись брокера молча. Роль рассматривающего человека = operator (определена в §2.3; полная матрица прав operator — отложена, см. Бэклог §6).
  • Эфемерный: записи нет — конфликтов нет.

Приоритет времён. При расхождении мирового времени (valid_at/invalid_at) и времени хранения (retention.valid_from/valid_to) разрешение следует каноническому алгоритму из maqs-way-standard.json → lifecycle.temporal_priority_algorithm (5 шагов) — здесь не дублируется во избежание рассинхрона. Кратко:

  • legal_hold блокирует удаление независимо от мирового времени
  • retention истёк (retention.valid_to < now) → EXPIRED
  • мировое время говорит, что факт уже не истинен (invalid_at < now) → EXPIRED — не SUPERSEDED; замещение — исход разрешения конфликтов (см. машину состояний выше), а не автоматический эффект времени
  • иначе ACTIVE/STALE по затуханию
  • фильтр рассуждений: retention валиден И valid_at ≤ now И (invalid_at null или > now)

2.3 Контроль доступа

  • Модель областей из AMSP формализована, канон user-portable и т.д.
  • Policy Broker разделён: decision: SAVE|PENDING_APPROVAL|BLOCK|DROP_LOW_UTILITY + mode: APPEND|UPDATE_EXISTING|MERGE_WITH_EXISTING — ортогональны.
  • Роль operator: человек, который рассматривает эскалированные/обжалованные решения брокера и оспоренные записи. Может читать оспоренные записи и подтверждать/переопределять исходы обжалований; каждое действие дописывает провенанс. Полная матрица прав — отложена, см. Бэклог §6.
  • SLA operator: рассмотрение в течение 72ч для эскалированных/обжалованных решений и оспоренных записей в Профиле B (рекомендация, не глобальное нормативное требование).
  • Фикстуры G1 (обязательны, MAQS G1 [CRIT]): граница доказывается попытками нарушений, а не наличием фильтра: (1) независимо аутентифицированные caller'ы A vs B, (2) неверный или отсутствующий scope, (3) read-only caller пытается писать → BLOCK, (4) доступ после отзыва членства → BLOCK. Односкоповый pass-through границей не является.

2.4 Сборка контекста

  • MAQS E: слепая усечка запрещена, бюджеты, позиционирование
  • Content-as-Data: весь полученный контент огорожен <retrieved_context> с типизацией, не инъецируется как инструкции (OWASP LLM08)
  • Защита от загрязнения обратной связью: model_output → ingestion только через Extractor + проверка secret/PII + policy broker, иначе BLOCK
  • Потолок F8 (MAQS F8): записи с source.type=model_output не могут получать важность выше заданного потолка до подтверждения внешним источником или пользователем.
  • Приоритет артефакта E12 (MAQS E12): текущий артефакт сохраняет фактический приоритет над памятью; конфликт остаётся наблюдаемым, память не должна молча подменять или реконструировать представление артефакта.

alive и critical — поля расширения профиля (см. extensions в maqs-way-standard.json); они не входят в ядро модели данных (schema_version way-v0.1.3, заморожена).

E10 — Квота живой памяти ([REC], MAQS E10). Квота действует по-скоупно-по-субъектно: отдельно в каждом скоупе для каждого субъекта (якорь скоупа — scope_enum в maqs-way-standard.json), не глобально. Эффект: alive: true освобождает запись от распада и суммаризации, пока флаг установлен; НЕ блокирует удаление (удалением управляет retention = "legal_hold"). Поведение при переполнении (по умолчанию): новая защита ОТКЛОНЯЕТСЯ (fail-closed для защиты), событие логируется как cap_overflow {subject, scope, cap, attempted_id}; escalate_after_denials подряд отказов эскалируются владельцу (советующий, поскольку E10 [REC]). У escalate_after_denials нет значения по умолчанию — она ОБЯЗАНА быть объявлена каждой системой, включающей квоту. Система НЕ ДОЛЖНА молча снимать существующие защиты и НЕ ДОЛЖНА молча отклонять новые: FIFO-вытеснение по умолчанию оставляет alive: true при фактически снятой защите — декларация переживает факт (silent-fail, класс B5); лживый флаг хуже забвения. Только по явному opt-in: overflow: evict_oldest — явная конфигурация на систему; каждое вытеснение ОБЯЗАНО логироваться с id записи и причиной (без тишины даже при opt-in). Opt-in явно переопределяет семантику alive (приоритет политики, а не абсолютная защита) и потому не является ложью. Нарушения квоты измеримы (alive_cap_overflow_rate, паттерн P8), но не блокируют.

E10 — alive vs legal_hold (ортогональность). legal_hold и alive — ортогональные механизмы: legal_hold (существующее значение retention "legal_hold") блокирует удаление (уровень управления, жёсткий); alive защищает от распада и суммаризации (уровень значимости, [REC]). Запись может нести оба одновременно; ни один не влечёт другой. Hold не даёт alive-защиты и наоборот; снятие одного никогда не снимает другой. Проверка: is_forgettable(r) = not r.alive and r.retention != "legal_hold".

E11 — Декларируемые критические метки ([IMP], MAQS E11). Критичность — явная метка с провенансом (источник: владелец или авторизованный процесс). Автоматический вывод важности отсутствует: importance в каноне — потолок F8 (ограничение), а не поле модели — без шкалы, порогов, источника. Непомеченные записи трактуются как некритичные (без переупорядочивания, без угадывания); unlabeled_ratio измеряется, чтобы разрыв оставался видимым. Непомеченные блоки дают явный лог («0 критических блоков»), никогда — молчаливый проход с угадыванием.

E11 — Проверка позиционирования. E11.verify_placement(context) — структурный аудит (без LLM): каждый блок с меткой «критический» ОБЯЗАН занимать head- или tail-зону (первые/последние critical_zone_fraction токенов собранного контекста, умолчание 0.15; owner: E11; калибровка → список v0.4); критический блок в средней зоне = FAIL. Семантическая адекватность размеров зон — отложено (список v0.4).

Глоссарий (заморожен; переопределение — только отдельной санкцией): alive/protected — декларируется, не выводится; critical — явная метка с провенансом (декларируется, не выводится); head/tail-зоны — первые/последние critical_zone_fraction токенов собранного контекста; unlabeled_ratio — отчёт, не гейт; «positioning» здесь — процедура размещения критических блоков (head/tail-зоны + позиционный аудит), а не голое слово.

2.5 Устойчивость

  • Контракты между хранилищами, версионирование схем/эмбеддингов, идемпотентные миграции
  • Провенанс эмбеддингов: embedding.derived_from_trust наследуется от источника, эмбеддинг НЕ «очищает» происхождение
  • D8 несовместимые эмбеддинги (MAQS D8 [CRIT]): несовпадение размерности/языка → явный отказ с диагностикой, а не всплеск предупреждений при поиске; перед смешанным поиском — переиндексация или миграция.
  • H5 изоляция тестов (MAQS H5 [CRIT]): тесты используют временные/in-memory хранилища и моки API, никогда не пишут в живую память; изоляция покрывает файловую систему (без продовых путей по умолчанию); guard-проверка до/после подтверждает отсутствие утечек тестовых артефактов.

Требование атомарности записи ниже — настройка расширения политики (см. extensions.policy в maqs-way-standard.json); оно не входит в ядро модели данных (schema_version way-v0.1.3, заморожена). Оно привязывает контракты хранилищ §2.5 к свойству наблюдаемости при сбоях; наблюдаемость самих сбоев остаётся за B5 (логирование, §3.4).

B4 — Атомарность записи ([IMP], MAQS B4). Запись в несколько хранилищ (сообщение + вектор + индекс) транзакционна или компенсируема: частичные записи («сообщение сохранено, вектор — нет») исключены. Атомарность покрывает ВСЕ записи состояния, включая операции дозаписи (append) и составные пары «файл + состояние»; частичная атомарность этому пункту не удовлетворяет.

Требование — к СВОЙСТВУ, а не к механизму: после сбоя в ЛЮБОЙ точке последовательности записи читатель наблюдает либо целиком старое состояние, либо целиком новое — никогда смешанное или частичное. Выбор механизма НЕ предписывается. Известные механизмы — примеры, а не требования: транзакция БД; схема outbox/компенсации (явная intent-запись «в процессе» + восстановление после сбоя, которое откатывает или завершает прерванную запись); для одного файла — запись во временный файл, fsync, атомарное переименование, fsync каталога. Дозаписи (append) — записи состояния: прерванная дозапись оставляет файл ровно таким, как до попытки (либо завершается — никогда полу-дозапись как наблюдаемое итоговое состояние). Составная пара «файл + состояние» атомарна как единица: файл и парное к нему состояние переключаются вместе или никак.

Явное состояние «в процессе» входит в требование всюду, где используется компенсация: intent-запись помечает запись как идущую, чтобы восстановление после сбоя могло её откатить или завершить; читатели трактуют незакоммиченные (находящиеся в процессе) записи как отсутствующие. Маркер «в процессе» — внутреннее состояние механизма; он НЕ добавляет состояние жизненного цикла в модель данных (перечень §2.1 не меняется). Восстановление после сбоя ОБЯЗАНО выполняться до новых записей; исход восстановления логируется (дисциплина B5, §3.4). Верификация инъецирует сбой в каждой точке между шагами записи и читает состояние после каждого сбоя — проверка, которая не может упасть, — не проверка.

B4 не объявляет настраиваемых числовых параметров: требование — свойство наблюдаемости при сбоях.

Глоссарий (заморожен; переопределение — только отдельной санкцией): atomic (атомарно) — после сбоя в любой точке читатель видит старое или новое состояние целиком, никогда смесь; compensable (компенсируемо) — прерванная запись откатывается или завершается восстановлением; in-progress (intent) record — внутренний маркер механизма о идущей записи, невидимый читателям до коммита; compound file+state pair — файл и парное состояние, переключаемые как одна единица; append — запись состояния, покрытая атомарностью как любая другая.

3. Слой ВЕРИФИКАЦИИ

Структура: паттерн P/V/E применён к слою принципов (§1) с v0.1.1; слои «Архитектура» и «Верификация» — выравнивание P/V/E отложено, см. Бэклог §6.

3.1 Разделение P/V/E

Каждый пункт следует структуре Свойство/Верификация/Пример (см. применённый паттерн в §1; примеры — §1, P1–P8).

3.2 Измеримое качество — ориентировочные цели

Чек-лист подтверждает, что механизм существует. Way требует доказать, что он работает.

Свойство Тест CI gate (min) Target Источник
Точность извлечения LoCoMo single/multi-hop; LongMemEval oracle R@5 ≥0.7 R@5 ≥0.85 LoCoMo, LongMemEval
Обновление знаний † LongMemEval updates, FactConsolidation — ≥0.7 LongMemEval, MemoryAgentBench CR
Временные рассуждения LoCoMo temporal, Graphiti valid_at ≥0.65 ≥0.8 Graphiti
Абстиненция LongMemEval abstention ≥0.8 ≥0.9 LongMemEval
Дедупликация Инъекция дубликатов ≤5% ≤2% MemoryOps
Загрязнение контекста Зонд петли обратной связи ≤1% =0 MAQS F
Удаление Каскад Tombstone остаток 0.0% 0.0% бенч tombstone
Маскирование общих фактов § После удаления общего факта запросивший не может его извлечь 0 утечек 0 Way P5 (§2.2)
Изоляция Кросс-тенантное извлечение 0 утечек 0 MemoryOps #1
Отравление OWASP ASI06-001/002 BLOCK 100% BLOCK 100% OWASP Agentic
Восстановимость Restore drill равенство хешей равенство хешей MAQS H
Переносимость Round-trip export→import 0 потерь 0 потерь OMPS

Все пороги помечены как ориентировочные, подлежат пересмотру после первого прогона на реальной системе; min = CI gate (ниже — провал пайплайна), target = инженерная цель. Канонический источник: maqs-way-standard.json → verification_suite.metrics. † Target обновления знаний из §1 P3 — пока нет в JSON metrics; отложен, см. Бэклог §6. § Из JSON verification_suite.negative_scenarios, объединено с его метрикой.

Правила гигиены пайплайна ниже — настройки расширения политики (см. extensions.policy в maqs-way-standard.json); они не входят в ядро модели данных (schema_version way-v0.1.3, заморожена). Они дисциплинируют верификационный аппарат, сведённый в таблицу этого раздела: CI-гейты и счётчики, которые эти гейты отчечат.

0.5a — Мёртвый код ([CRIT], MAQS 0.5a). Зелёные тесты на коде, который никогда не вызывается работающей системой, — ложный сигнал безопасности. Правило: каждый верификационный скрипт ОБЯЗАН быть либо (а) вызван из audit CLI (maqs_way_audit.py), либо (б) внесён в список declared-standalone с задокументированной точкой интеграции. Невызванный И незадокументированный = мёртвый → RED. Список declared-standalone замкнут: расширение — только явным изменением (коммитом), никогда молча. Самоприменимость: гейт гигиены сканирует собственный репозиторий, включая себя — невключённый и без точки гейт помечает сам себя. Проверка, которая не может упасть, — не проверка. 0.5a не объявляет числовых параметров.

0.6a — Локальные базлайны ([IMP], MAQS 0.6a). Аномалии определяются относительно собственного базлайна системы, а не универсальных чисел. Файл базлайна хранит именованные счётчики с провенансом (коммит и дата снятия). Объявленный допуск: tolerance — умолчание 0.10 (±10%) на счётчик (owner: 0.6a); изменения допуска объявляются и подписываются владельцем. Дрейф за пределом допуска → FLAG (advisory, видимый, накопительный), не RED: канонического порога не существует, а RED-при-росте наказывал бы легитимную работу. RED только для: базлайн отсутствует или повреждён, либо счётчик снят с отслеживания без объяснения. Базлайн меняется только тем коммитом, который объясняет дрейф.

Отложено (список v0.4): 0.5a — вызванный-но-неудовлетворимый контроль (производственная точка вызова — недостаточно; контроль должен уметь сработать при производственной конфигурации); золотой корпус канареек для P9; чек-лист сертификации аудитора; канонические допуски дрейфа по хранилищам; агрегация standalone-гейтов в audit CLI.

Глоссарий (заморожен; переопределение — только отдельной санкцией): declared-standalone — верификационный скрипт, не включённый в audit CLI, но внесённый в список с задокументированной точкой интеграции; self-hosting — гейт гигиены сканирует собственный репозиторий, включая себя; базлайн — записанные именованные счётчики с провенансом; tolerance — объявленная граница дрейфа на счётчик (умолчание ±10%); FLAG — advisory-отчёт о дрейфе, не вердикт.

3.3 Решётка верификации удаления

  • LOGICAL: search() возвращает 0
  • PHYSICAL: DELETE+REINDEX+VACUUM FULL pgvector, rebuild survivors Qdrant, ноль HNSW-слотов Chroma — проверяется сканом файлов
  • SEMANTIC: сходство эмбеддингов <0.3, MIA-атака проваливается
  • MODEL: зонд извлечения не воспроизводит удалённый факт Каждый уровень — квитанция с подписью Ed25519, воспроизводимая. Deletion_log без персональных данных.

3.4 Логирование

  • Что логировать (Art12/19): период использования начало/конец, проверенная reference DB, ввод, приведший к совпадению, задействованные физлица, идентичность агента, policy_version, классификация, исход, точная временная метка, подпись
  • Как: OTel GenAI gen_ai.operation.name, gen_ai.conversation.id, gen_ai.tool.name, gen_ai.usage.*, gen_ai.client.inference.operation.details (PII — opt-in)
  • Санитизация (ужесточено): gen_ai.client.inference.operation.details — разрешено: tool_args_sanitized, retrieval_count, policy_decision, latency_ms; запрещено: raw_content, secret, PII, embedding_vector. Фильтр secret/PII применяется до логирования, то же правило, что у Policy Broker. Включая credential-in-URL (?token=..., bot<id>:AA... в пути) — маскируется редактором до записи (MAQS I13 [CRIT]).
  • Защита от подделки: hash-цепочка, Ed25519, WORM lock для регулируемых тенантов, retention 12 месяцев по умолчанию, 6 лет настраиваемо для регулируемых (источник: EU AI Act Art12 задаёт минимум 6 месяцев, Way расширяет для регулируемого Профиля B, задокументировано). Примечание: фиксация до возврата ответа добавляет latency ~5-15мс.
  • Источники упомянуты в соответствии со своими лицензиями.

threshold, window {type, size}, action и ключи равенства классовых счётчиков ниже — настройки расширения политики (см. extensions.policy в maqs-way-standard.json); они не входят в ядро модели данных (schema_version way-v0.1.3, заморожена). Журналы алертов и записи эскалаций переиспользуют существующую инфраструктуру логирования (hash-цепочка, retention по logging.retention); новых полей модели данных не вводится.

Каждый классовый счётчик объявляет ТРИ независимых литерала (никогда не склеенных): threshold N, window {type, size}, action. Порог и окно настраиваются независимо. Типы окон: sliding (события внутри скользящего окна) | tumbling (фиксированные корзины); sliding — тип окна по умолчанию, tumbling требует явного объявления на деплоймент. Каждый счётчик объявляет свой ключ равенства (сигнатуру): без ключа «идентичные» не определены, счётчик недетерминирован — такой счётчик отвергается.

I10 — Бюджет шума ([IMP], MAQS I10). Объявленные параметры (owner: I10): threshold 3 (умолчание), window {sliding, 5m} (умолчания), ключ равенства «warning text», action «aggregate». Одно и то же предупреждение, повторённое N+ раз за интервал, агрегируется счётчиком — N идентичных предупреждений становятся одной записью + счётчиком; после порога поодиночке не выдаются; после N идентичных предупреждений — дедуплицировать или эскалировать на другой уровень. B5-связка: заявленный успех без выполненной работы — отказ класса B5, обнаруживается как чистая функция от (claimed_events, performed_actions) над объявленным work_sink (зафиксированные побочные эффекты; нет умолчания — ОБЯЗАН быть объявлен при применении проверки, owner: I10); заявленный успех + пустой приёмник → RED. I10 существует, чтобы дублирующий шум не маскировал ложный успех.

I11 — Цикл восстановления ([CRIT], MAQS I11). Объявленные параметры (owner: I11): threshold 3 (умолчание), window {sliding, 10m} (умолчания), ключ равенства «exit code», action «halt+alert». Любой автоматический рестарт (systemd/supervisor/self-heal) сопровождается диагностическим следом первопричины. Цикл восстановления без диагноза запрещён: после N повторов без диагноза — halt и alert, никогда не вечный рестарт. Halt останавливает СОБСТВЕННЫЙ процесс; halt-без-alert запрещён ровно так же, как restart-без-диагноза. Приёмник алертов — РЕАЛЬНОЕ персистентное хранилище (журнал-файл / syslog; нет умолчания — ОБЯЗАН быть объявлен, должен читаться после halt, owner: I11), никогда не голые stderr/exit code: stderr не переживает halt, exit code виден только родителю. Алерт, который нельзя прочитать после halt, — silent-fail (класс B5). Верификация читает след ПОСЛЕ halt из приёмника.

I12 — Бюджет эскалации ([CRIT], MAQS I12). Объявленные параметры (owner: I12): threshold 3 (умолчание), window {sliding, 1h} (умолчания), ключ равенства «dependency + error code», action «escalate». Повторяющийся отказ зависимости с идентичной сигнатурой эскалируется после N вхождений (alert / halt / flagged degradation) — никогда не опрашивает бесконечно. Escalate адресован ВНЕШНИМ зависимостям (нет права останавливать, только голос) и ПОВТОРЯЕМ по расписанию — контракт уведомлений, а не одиночный выкрик; расписание повторов не имеет умолчания и ОБЯЗАНО быть объявленным (owner: I12). Эскалация без записи в журнале — отказ класса B5 (тот же класс, что halt-без-alert). Система, знающая об отказе и не эскалирующая, деградирует молча.

Граница halt / escalate. Halt применяется к собственному процессу (право остановить = обязанность подать alert); escalate — к внешним зависимостям (нет права останавливать, только голос). При конфликте (выполнены оба условия): halt доминирует (безопасность) + escalate владельцу. flagged degradation ОБЯЗАН быть наблюдаемым в приёмнике — иначе деградация молчалива = B5.

Смежное, не покрывающее: SPEC §2.3 (appeal-эскалация + SLA оператора) делит только словарь (другой триггер, другой механизм); закрытие этого gap'а словами «уже есть в §2.3» отвергается заранее.

Отложено (список v0.4): per-scope/per-subject разбиение счётчиков (ср. семантика квоты E10); переход деплойментов на tumbling-окна.

Глоссарий (заморожен; переопределение — только отдельной санкцией): policy triple — threshold + window {type, size} + action, три независимых литерала, никогда не склеенных; equality key (сигнатура) — объявленное поле, определяющее «идентичные» события; work_sink — объявленное хранилище зафиксированных побочных эффектов; alert sink — персистентное хранилище, держащее halt-алерт и читаемое после halt; halt — остановка собственного процесса; escalate — контракт уведомлений внешним зависимостям, повторяемый по объявленному расписанию.

Требования к реакции для проверенных исключений ниже — настройки расширения политики (см. extensions.policy в maqs-way-standard.json); они не входят в ядро модели данных (schema_version way-v0.1.3, заморожена). Словарь получателей переиспользует канонические роли owner и operator; новых полей модели данных не вводится.

I14 — Реестр обработчиков ([REC], MAQS I14). Если класс исключения проверен (пойман и перевыброшен или залогирован), но не имеет зарегистрированного обработчика или пути эскалации, проверка неполна — обнаружение без реакции не является покрытием. Каждый проверенный класс ОБЯЗАН иметь реакцию: handler и/или escalation_path (минимум одно). handler — локальная реакция на стороне собственного процесса (семейство halt, ср. I11); escalation_path — уведомление владельца/оператора с продолжением в деградировавшем режиме (внешняя сторона, семейство escalate, ср. I12). Путь ОБЯЗАН завершаться в объявленном получателе (owner или operator); путь-в-пустоту не покрыт — тот же класс, что halt-без-alert (семейство B5). Handler И path одновременно — ЛЕГАЛЬНО (handler + запасной path = эшелонированная защита); запрещать сочетание отвергается. Словарь наследуется от классовых счётчиков (I10–I12), не переопределяется: halt : escalate :: handler : path; классы-счётчики, внесённые в реестр, несут reaction = counter (aggregate / halt+alert / escalate) — определены каноном счётчиков, здесь упоминаются, двойного владения нет.

I14 — Объявленный каталог. Каталог классов — ОБЪЯВЛЕННЫЙ список; полнота НЕ заявляется и НЕ гейтируется. Строка отчёта «checked N declared classes; completeness NOT claimed» обязательна; N выводится из объявленного каталога (без независимого умолчания, owner: I14). Рост — только явным изменением (коммитом), никогда молча в рантайме; каждый новый класс входит с источником (инцидент/аудит) и владельцем.

I14 — Модель вердикта (два уровня, не выбор). Уровень пробы (юнит): несогласованность внутри каталога — СТРОГО — класс-сирота (нет реакции), мёртвый обработчик (зарегистрирован без класса каталога), путь-в-пустоту → RED; проверка, которая не может упасть, — не проверка. Уровень гейта (интеграция): находки [REC] — report-not-failing — агрегатный гейт не блокируется, но каждая находка ОБЯЗАНА быть НАЗВАНА в отчёте (никогда не сворачивается); [REC] управляет БЛОКИРОВАНИЕМ, а не вердиктоспособностью. «0 находок» и «проверка не запускалась» — различимые состояния. Доля покрытия handled/probed — отчёт, не гейт (owner: I14); каждая сирота перечисляется по имени. Статус [REC] (advisory) переносится в ОТЧЁТЕ, а не в семантике гейта. I14 не объявляет настраиваемых числовых параметров: указанные выше числа — производные, отчётные значения.

Отложено (список v0.4): owners_registry / SLA / fallback-схема для путей эскалации (нет канонического источника шкал SLA); ревизия каталога tumbling; импорт таксономии исключений.

Глоссарий (заморожен; переопределение — только отдельной санкцией): handler — локальная реакция на стороне собственного процесса; escalation_path — уведомление владельца/оператора с продолжением в деградировавшем режиме, завершающееся в объявленном получателе; orphan class — проверенный класс без зарегистрированной реакции; dead handler — зарегистрированный обработчик без класса каталога; path-into-void — путь эскалации, чей адресат не является объявленным получателем; handled/probed — доля покрытия, отчёт, не гейт.

Таксономия слоёв памяти ниже — настройка расширения политики (см. extensions.policy в maqs-way-standard.json); она не входит в ядро модели данных (schema_version way-v0.1.3, заморожена). Она переиспользует существующий канон: scope_enum (граница группировки, модель данных), retention (длительность хранения, §2.2), метрику abstention_rate (verification_suite) — ссылки, а не дублирование. Поле layer записи/запроса — поле расширения профиля (см. extensions.fields в maqs-way-standard.json; значения persistent | session | transient; не обязательно — отсутствие означает unknown).

I15 — Таксономия слоёв ([REC], MAQS I15). Диагностика → слой → интерпретация; никогда не интерпретировать без слоя. Перечень слоёв — ровно {persistent, session, transient} (замкнутый; мощность 3, owner: I15; расширение — только новым решением владельца): persistent — долговременное хранилище памяти (записи §2.1); session — текущий контекст разговора; transient — эфемерный, без гарантий сохранения. unknown — НЕ четвёртый слой, а честное диагностическое состояние (неклассифицируемый ввод — это факт).

I15 — Назначение слоя (декларируется, не выводится). Слой — ДЕКЛАРИРУЕМОЕ свойство запроса/записи (метаданные, выставляемые при создании автором запроса). identify(query) ЧИТАЕТ объявленный слой; он его НЕ выводит. Вывод слоя («похоже на session») — метка без источника → RED. Нет объявления → unknown, никогда не догадка. Молчаливая подстановка умолчания (тихий session для необъявленного ввода) — подмена уровня, silent-fail класс (семейство B5).

I15 — Ожидания по слоям (привязаны к ДЕКЛАРИРОВАННОМУ слою, до интерпретации). persistent: ожидается дословное воспоминание; отклонение — сигнал деградации. session: шум/несовершенство внутри одной сессии — ожидаемое поведение, НЕ деградация; не поднимать алерты по session-дрейфу. transient: точный ответ — бонус, никогда не доказательство — точность transient-слоя не может сертифицировать здоровье памяти (отсутствие гарантии не есть наличие гарантии). Инвариант: применение ожиданий одного слоя к ответу другого слоя — ошибка чтения (как ложный RED, так и ложный GREEN).

I15 — Обработка unknown (fail-closed и громко). unknown → приостановить вынесение суждения: НИ вердикта деградации, НИ вердикта успеха (абстиенция, засчитывается в существующую метрику abstention_rate); консервативный режим + явное громкое диагностическое событие (LOG-3.4), не блокирующее (advisory-модель вердикта [REC], ср. I14). Слой ОБЯЗАН НЕ угадываться ради разблокировки интерпретации.

I15 — Ортогональность (три оси, без двойного владения). layer — КЛАСС времени жизни (именованный перечень выше) — ось интерпретации; scope — граница ГРУППИРОВКИ (scope_enum) — ось пула/владения; retention — длительность ХРАНЕНИЯ (параметр, §2.2) — временная ось. Слой — read-only диагностическая метка: не владеет хранилищем и не задаёт политику. Анти-смешение: scope «local-session» (граница доступа) ≠ слой «session» (контекст источника); слой transient и короткий retention оба «про короткое» — разведены по роду (именованный класс vs число); класс никогда не выводится из длительности и наоборот. I15 ссылается на §2.2, где определено время жизни, и никогда не дублирует канон. I15 не объявляет настраиваемых числовых параметров: единственное число — мощность замкнутого перечня (3, owner: I15; изменение = новое решение владельца).

Отложено (список v0.4): эвристическое назначение слоя с объявленной уверенностью (вывод с источником; вывод без источника остаётся RED); tumbling-ревизия ожиданий по слоям; семантическая адекватность ожиданий.

Глоссарий (заморожен; переопределение — только отдельной санкцией): layer — объявленный класс времени жизни (persistent/session/ transient); unknown — честное диагностическое состояние, не слой; identify — читает объявленный слой, никогда не выводит; expectation — правило качества ответа, привязанное к ДЕКЛАРИРОВАННОМУ слою; reading error — применение ожиданий одного слоя к ответу другого слоя.

3.5 Отчётность

config: конфигурация системы, версия модели эмбеддингов, версия политики standard_version: MAQS 1.9 + Way 0.3 test_scenarios: LoCoMo/LongMemEval/MemoryAgentBench + негативные + решётка удаления + restore drill + round-trip results: по метрикам + по инвариантам + ограничения exceptions: документируются по каждому пункту с обоснованием residual_risks: открытые вопросы remediation_plan: порядок приоритетов j3_guard: каждое исправление закрывается регрессионным guard-тестом; невыполненный тест (silent skip, async без runner) = незавершено (MAQS J3)

Требования процедуры аудита ниже — настройки расширения политики (см. extensions.policy в maqs-way-standard.json); они не входят в ядро модели данных (schema_version way-v0.1.3, заморожена). Новых полей модели данных не вводится.

P9 — Контролируемый артефактный эксперимент (односторонний; MAQS §2, шаг P9). При подозрении на заражение «артефакт–память»: подготовить новый артефакт другого типа, независимо проверить его синтаксис до вручения, вручить без предварительного раскрытия и зафиксировать результат; чистое прочтение означает принятие канала доставки. Диагностическая триада P9-a / P9-b / P9-c: canary — уникальные данные, встроенные в середину тела и отсутствующие во всех хранилищах памяти; воспроизведены в отчёте = доказательство чтения; отсутствуют = неопределённо. decoy — правдоподобный, но ложный элемент, который память ожидала бы; любое упоминание = доказательство конфабуляции. echo — верный памяти элемент, отсутствующий в артефакте и тематически соблазнительный; появление = доказательство дополнения (нарушение E12); отсутствует = неопределённо. Все три пробы ОДНОСТОРОННИЕ: положительный результат — ДОКАЗАТЕЛЬСТВО проверяемого свойства; отрицательный — НЕОПРЕДЕЛЁННЫЙ — никогда не «пройдено», никогда не «чисто», только «не проверено этим прогоном». Молчаливая канарейка не доказывает ничего об угрозе — только о канарейке. Комбинированная сетка даёт диагноз; одиночная проба даёт только «доказательство-или-тишину». Каждый прогон P9 включает строку отчёта «negative = inconclusive; coverage NOT claimed» — односторонность объявляется заранее, а не подразумевается. Смешивание одностороннего прогона с заявкой на покрытие = RED (подмена уровня: «не обнаружено», выданное за «чисто»).

P10 — Изоляция внешнего аудитора (read-only, верифицируется фактом; MAQS §2, шаг P10). Любой автоматизированный или агентный аудит выполняется из среды без права записи в продовые хранилища и без общего рантайм-состояния (процессы, кэши, загруженные модели эмбеддингов) с аудируемой системой; результаты аудита пишутся только во внешний отчёт. Read-only — ДЕКЛАРИРУЕМОЕ свойство, подтверждаемое фактом, а не обещанием. Процедура: снять снимок дерева → прогнать гейты → убедиться в идентичности. Верификация ОБЯЗАНА включать невнесённые файлы (git status --porcelain, а не только отслеживаемые): создание нового файла ЕСТЬ запись, даже если отслеживаемые файлы не тронуты — иначе ложная безопасность. Шаг аудита, пишущий в аудируемое дерево (модификация ИЛИ новый файл), ПРОВАЛИВАЕТ P10. Право записи для аудитора вне объёма (MAQS SUPP-EXT-01) — объявленная граница, а не дефект.

P9/P10 не объявляют настраиваемых числовых параметров: их параметры — структурные (исходы проб, равенство снимков).

Отложено (список v0.4): P10 — пути записи с ленивой инициализацией (mode=ro сам по себе не изоляция); P11 — дисциплина агентного аудита.

Глоссарий (заморожен; переопределение — только отдельной санкцией): one-sided (односторонний) — оценка, где положительный результат = доказательство, а отрицательный = неопределённый (никогда не «пройдено»); canary/decoy/echo — пробы P9-a/b/c; coverage NOT claimed — обязательная строка отчёта каждого одностороннего прогона; snapshot-run-verify — процедура P10: снимок (включая невнесённые файлы) → прогон гейтов → проверка идентичности.

3.6 Детерминизм и сравнимость прогонов

Правила сравнимости прогонов ниже — настройки расширения политики (см. extensions.policy в maqs-way-standard.json); они не входят в ядро модели данных (schema_version way-v0.1.3, заморожена). Они определяют, как могут сравниваться прогоны этого проекта и как агрегируется их доказательная база.

Условия побайтной воспроизводимости. Два прогона сравнимы побайтно только если получены на ОДНОМ стенде — тот же GPU, тот же драйвер, та же сборка инференса и флаги, та же модель — с по-вопросной изоляцией истории и фиксированным seed. Любое расхождение в этих условиях относит прогоны к разным классам: побайтное сравнение между ними не допускается.

Окна. Окно — серия прогонов между СОВПАВШИМИ контрольными панелями; «совпадение» означает побайтную идентичность ВСЕХ выходов панели. Прогон принадлежит окну, только если обрамлён совпавшими контрольными панелями ДО и ПОСЛЕ него. Расхождение — граница окна: для прогона, соседнего с расхождением, режим неизвестен — он допускает только агрегатные сравнения.

Парность. Парные по-вопросные сравнения допустимы ТОЛЬКО внутри одного стенда и одного окна. Между стендами и между окнами — только агрегатные сравнения. Факт-иллюстрация: выходы панели iGPU совпали с RTX-эталоном побайтно в 0/12 случаев при evidence_hit 12/12 — то же качество обнаружения при других байтах; побайтное сравнение между стендами бессмысленно, агрегатное — нет.

Канарейка режима. Канарейка — диагностическая метка, печатаемая в заголовке отчёта прогона и снимаемая на СВЕЖЕМ сторе; она помечает режим и НЕ разблокирует побайтные или по-вопросные сравнения между окнами и стендами. Состав канарейки и контрольной панели живёт в артефактах прогонов, не в этом каноне.

Чеклист стенда. Каждый пререг фиксирует стенд, на котором выполняется: ОС, версия драйвера GPU, сборка инференса (llama.cpp) и флаги запуска, md5 модели, хеши файлов раннеров, CONFIG_SHA256 — запись ведётся в каждом пререге, чтобы будущий второй стенд сравнивался поле за полем.

Данные за фактами выше лежат в evals/results/ (заметка по стенду 2 iGPU/RTX, кросс-чеки детерминизма и аттракторов, заметка зонда дрейфа, проверка починки канарейки); этот канон ссылается на файлы, а не на их числа.

4. Профили применения

  • Профиль A: Персональный ассистент: scope user-portable, строгие согласия, оценка LoCoMo+LongMemEval, удаление LOGICAL+PHYSICAL, разрешение конфликтов «побеждает пользователь»
  • Профиль B: Корпоративный: изоляция тенантов, policy broker, 10 инвариантов, логирование EU AI Act, полная решётка удаления, OTel, поддержка legal_hold, обжалование решений брокера человеком (роль operator, §2.3)
  • Профиль C: Эфемерный: без записи, без извлечения, проверяется MAQS P6 isolation test (примечание: в Way изоляция — P4, восстановимость — P6 — нумерация стандартов различается; соответствие в docs/mapping-to-maqs.md)

Каждый профиль — подмножество Way + ссылки на пункты MAQS.

5. Соответствие MAQS v1.9

0 Map → 2.1 модель данных + провенанс A Input validation → 2.4 Content-as-Data + OWASP ASI06 B Write integrity → 2.2 жизненный цикл + tombstone + привязка OAMP C Growth → 2.2 машина состояний + битемпоральность D Retrieval → 3.2 измеримое качество E Assembly → 2.4 огороженный контекст + запрет слепой усечки F Feedback → 2.4 защита с типизацией G Isolation → 2.3 области + негативные тесты H Concurrency → 2.5 версионирование эмбеддингов I Observability → 3.4 OTel + Art12 J Change Management → 3.5 отчётность + регрессионные guard-тесты

I7 самодиагностика агента → дополнительный сигнал, не доказательство.

6. Следующие шаги

  1. Этот файл — SPEC.md v0.3 — нормативное имя файла, статус релиз (все 12 known gap'ов с v0.2 закрыты в этом релизе подписанными владельцем пакетами; открытых gap'ов нет).
  2. Бэклог v0.4 (по scope-решению v0.3 — отложено построчно; детали и обоснования по каждому пункту в docs/v0.4-candidates-from-maqs-1.8.1.md):
    • Из отложенного scope v0.3: deletion_marker в JSON модели данных (подтвердить устаревание сепарацией, примечание §2.1, или специфицировать); identity_signature Ed25519 над каноническим JSON — полная спецификация; роль operator — полная матрица прав для §2.3; исполнимый behavioral harness (прогоны LoCoMo/LongMemEval) + поведенческий тест D9; живая верификация всех 11 внешних ссылок в docs/landscape.md + колонка verified: ✅/⏳/❌; выравнивание P/V/E для слоёв «Архитектура» и «Верификация» (§2, §3); верификация P4 на других memory-системах.
    • Из синхронизации MAQS 1.8.1 (docs/v0.4-candidates-from-maqs-1.8.1.md, строки 1–13): 1 J3 обновление строки j3_guard; 2 I13 текст требования маскирования (склеенные секреты, единый механизм, логгеры зависимостей); 3 B1 один семантический ключ на событие; 4 D8 закреплённые оси + контракт версионных маркеров (нет Way-гейта — новый пакет или known-gap запись); 5 I10 предупреждения в [CRIT]-зонах как отказы, вкл. тесты + DEBUG-cap пре-фильтр; 6 I12 пин B-оси B2 («видимость без реакции»); 7 I15 закреплённый формат времени на хранилище; 8 методология аудита §2.2 шаг 3 (достижимость, per-instance схема, маркировка static-evidence); 9 методология аудита §2.2 шаг 6 (раздельный подсчёт критичности); 10 методология аудита §2.2 п.4 (унаследованная критичность); 11 P11 дисциплина агентного аудита; 12 P10 пути записи с ленивой инициализацией (mode=ro — не изоляция); 13 0.5a вызванный-но-неудовлетворимый контроль.
    • Из синхронизации MAQS 1.9 (тот же файл, строки 14–17): 14 D10 контракт вычисления схожести (нет Way-гейта — новый пакет или known-gap запись, тот же путь, что D8/строка 4); 15 D11 изоляция областей в общем индексе поиска (уже реализационно покрыта на стороне Way: проверка P4a в evaluator, cheatsheets pattern-mem0-isolation / pattern-graphiti-invalidation, references/ref-langchain.py — влить формулировку MAQS в текст верификации P4); 16 C4 переименован в синхронизацию производных представлений + расширенный набор триггеров (обновления контента, миграции схемы идентификаторов, верификация set-difference, инвалидация штампов); 17 A4 деградированные пути извлечения (маркировка, понижение, исключение из производных структур).
    • Из инвентаризации устаревших ссылок (docs/v0.4-canon/stale-refs.md): нормативные пороги для метрик §3.2 (повышение из ориентировочных до нормативных после первого прогона на реальной системе); метрика target обновления знаний knowledge_update в JSON verification_suite.metrics (§1 P3: LongMemEval updates / FactConsolidation, target ≥0.7).
  3. Открытые обсуждения с авторами OMPS/AMSP/OAMP — предложить MAQS как слой верификации их контрактов

7. Журнал изменений

  • v0.1 → v0.1.1 (2026-10-10): внешнее ревью (way.md) + внутреннее ревью, замечания учтены. Section 0.1 дедуплицирована в ссылку на landscape.md; разрешён конфликт имени файла и статуса; инциденты добавлены ко всем 8 принципам; пороги помечены ориентировочными; паттерн P/V/E применён к слою принципов; добавлен провенанс эмбеддингов; политика разрешения конфликтов по профилям; задокументирован приоритет времён (мировое vs retention); жизненный цикл дополнен; Policy Broker разделён на decision+mode; нотация scope канонизирована; добавлен legal_hold; обоснован retention логов; задокументирована цена latency; Recoverability/Portability добавлены в golden set; добавлено примечание о лицензиях; введён enum субъектов; добавлено confidence_after; расширены links; название «Universal» → «Common»; deletion_marker отделён от живой записи; добавлен путь обжалования брокера; D9 пояснён.
  • v0.1.1 → v0.1.2 (2026-10-10): внутреннее ревью: восстановлен заголовок §2 (ARCHITECTURE Layer); status возвращён как производное представление (не хранимое поле); жизненный цикл дополнен переходами EXPIRED → ARCHIVED и ARCHIVED → ACTIVE (восстановление); inline-ссылки (fixes Cx) заменены §7 Журналом изменений; исправлена коллизия P6 в Профиле C (MAQS P6 isolation test + примечание о нумерации Way/MAQS); в шапку добавлена строка автора; заявка §3 приведена в соответствие с фактом; роль operator определена в §2.3 (матрица — TODO v0.2); TODO identity_signature убран из JSON-примера и перенесён в Бэклог §6.2.
  • v0.1.2 → v0.1.3 (2026-10-10): ужесточающая синхронизация с maqs-way-standard.json. Пороги разведены на пару CI gate / target (§1 P3, §1 P8, §3.2) — канон из JSON verification_suite.metrics; значения остаются экспертными/ориентировочными до первого реального прогона. Добавлен provenance.visible_to (§2.1) как механизм семантического маскирования. Добавлен раздел §2.2 Приоритет времён, закрывает висячую ссылку из §2.1; исправление шага 3 (invalid_at < now → EXPIRED, не SUPERSEDED) зеркалировано в JSON. Добавлен SLA operator 72ч (§2.3). Добавлены allowed/forbidden ключи OTel (§3.4). shared_fact_visibility_leak добавлен в негативные сценарии (§1 P8). masked как состояние жизненного цикла — отклонён; маскирование — операция видимости (visible_to), а не состояние. schema_version → omps-0.1.0+way-v0.1.3.
  • v0.1.3 → v0.1.4 (2026-10-10): приземлён пакет schemas (schemas/memory-item.schema.json + schemas/check_conformance.py, gate green); data_model.$ref_status provisional → active. Штампы релиза подняты; модель данных (schema_version way-v0.1.3), пороги, алгоритмы, векторы не менялись — семантический дифф пуст по дизайну.
  • v0.1.4 → v0.2 (2026-10-15, подпись владельца): ступень 1 лестницы закрыта — пакеты 1.1 (C8-гейт) → 1.2 (B-гейт) → 1.3 (векторы 7→12) → 1.4 (audit CLI v0.1 + неймспейсы) → 1.5 (формулировка E10/E11) → 1.6a–d (I-счётчики/хэндлеры/слои, I13 доказан, мост C8 консолидирован) → 1.7a/b (процедура аудита, гигиена пайплайна) + LICENSE (синхронизация Apache-2.0). Закрыто в релизе: формулировки+гейты по всем перечисленным пунктам MAQS. ОТКРЫТЫЕ known gap'ы (перецелены v0.2→v0.3 этим решением релиза, без молчаливого переноса): B4 write atomicity (→§2.5), канонизация E10/E11, канонизация I10/I11/I12, I14, I15, P9/P10, 0.5a dead-code rule, пороги дрейфа 0.6a (всего 12). schema_version way-v0.1.3 ЗАМОРОЖЕН (модель не менялась в 1.1–1.7 — утверждаемый факт). Релиз выходит честным минором С этим списком; молчание о gap'ах было бы ложным green.
  • v0.2 → v0.2.1 (2026-10-27, подпись владельца): evidence-релиз — канон по содержанию не менялся с v0.2; единственная канон-смежная дельта с v0.2 — синхронизация ссылок на MAQS v1.6 → v1.8.1 (строка relation в шапке, §3.5 standard_version, заголовок §5; maqs_core_reference в JSON; только ссылки на версии — без изменений формулировок, порогов, векторов). Релиз фиксирует доказательную часть, накопленную с v0.2, и даёт тег + DOI для внешних ссылок. Ключевое (цифры из файлов репозитория): заголовочное число full-500-iso evidence-R@5 = 0.988 (494/500, Wilson [0.974, 0.994]) — ПЕРВЫЙ изолированный полный прогон (пре-изоляционный 0.992 от 2026-10-17 остаётся в истории с аннотацией о конфаунде); конфаунд общей истории (mem0) найден гардом H5 [CRIT], измерен (14.8% подлинных хвостовых фактов в замороженном store g1, 249/1680 — заражение канала извлечения) и устранён по-вопросной изоляцией истории во всех раннерах; P4 верифицирован на mem0@0724291b (Linux CPU-only stub-стенд; граница: путь извлечения с реальной LLM не проверялся); граница детерминизма задокументирована в REPRODUCE §0 (байт-идентичность — свойство окна на референсном стенде; кросс-стенд не тестировался — сравнивать в полосах); полный рецепт воспроизведения (evals/REPRODUCE.md); конфиг-фингерпринт (CONFIG_SHA256) во всех раннерах; шаблон пререга v1.1. ОТКРЫТЫЕ known gap'ы: без изменений 12 с v0.2, цель v0.3 — B4 write atomicity (→§2.5), канонизация E10/E11, канонизация I10/I11/I12, I14, I15, P9/P10, 0.5a dead-code rule, пороги дрейфа 0.6a (всего 12). schema_version way-v0.1.3 ЗАМОРОЖЕН (модель не менялась — утверждаемый факт).
  • v0.2.1 → v0.3 (2026-10-27, подпись владельца): E10/E11 канонизированы в §2.4 (подпись владельца 2026-10-27); поля — расширения профиля, модель данных ядра не изменена (way-v0.1.3); I10/I11/I12 канонизированы в §3.4 (подпись владельца 2026-10-27); параметры — расширения политики, модель данных ядра не изменена (way-v0.1.3); I14 канонизирован в §3.4 (подпись владельца 2026-10-27); семантика реестра — расширение политики, модель данных ядра не изменена (way-v0.1.3); I15 канонизирован в §3.4 (подпись владельца 2026-10-27); таксономия слоёв — расширение политики, модель данных ядра не изменена (way-v0.1.3); P9/P10 канонизированы в §3.5 (подпись владельца 2026-10-27); процедура аудита — расширение политики, модель данных ядра не изменена (way-v0.1.3); 0.5a/0.6a канонизированы в §3.2 (подпись владельца 2026-10-27); гигиена пайплайна — расширение политики, модель данных ядра не изменена (way-v0.1.3); check_pipeline_hygiene был RED на v0.2 и v0.2.1 (check_release.py не объявлен; дрейф базлайна); релизным гейтом в то время не покрывался; исправлено в 89a955c; B4 канонизирован в §2.5 (подпись владельца 2026-10-27); атомарность записи — расширение политики, модель данных ядра не изменена (way-v0.1.3); правило детерминизма канонизировано в §3.6 (подпись владельца 2026-10-27; воспроизведение на втором стенде); сравнимость прогонов — расширение политики, модель данных ядра не изменена (way-v0.1.3). Открытые known gap'ы: отсутствуют (все 12 с v0.2 закрыты).

Проверяй не то, что механизм существует. Проверяй, что он работает.