Arcanada — Управление смыслами в автономных ИИ-системах: архитектура Knowledge Contract

Статус этой публикации

Research 17 — Russian Semantic Source v1 Frozen. Каноническая русская версия концептуальной архитектуры и спецификации пререгистрации. Эмпирическая проверка архитектуры ещё не выполнена.

DOI: 10.5281/zenodo.22013923 — англоязычный препринт депонирован в Zenodo (CERN) под лицензией CC BY 4.0. Цитировать следует по DOI.

Статус не означает готовую реализацию, доказанное превосходство или production readiness. Английская версия — перевод замороженного русского источника через общий глоссарий Arcanada, а не самостоятельная академическая переработка.

I. Проблема, границы и вклад

Аннотация

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

Центральный вклад — Управление смыслами как архитектурный слой жизненного цикла task-specific смысловых обязательств (semantic commitments). Выбор фиксирует Resolution Receipt; Knowledge Contract отделён от issuance; post-issuance Binding отделён от текущей Authorization. Variant A, BKG, Resolver, identity model, Expansion/Evolution и execution gate формально задают поддерживающие механизмы этой декомпозиции.

Проверенный целенаправленный корпус покрывает prompting, retrieval, memory, orchestration, provenance, workflows, policy evaluation и knowledge representation по отдельности, но не даёт единой модели такого управляемого перехода; вывод ограничен корпусом и не утверждает исторического первенства. Практическую полезность проверяют девять гипотез и девять протоколов HYP/EXP-001–009. Эксперименты не выполнены, поэтому снижение ошибок, улучшение диагностики и приемлемость стоимости не доказаны.

Введение

Автономная система получает неоднородный семантический контекст: запросы, документы, память, правила, описания задач и доступные инструменты имеют разные версии, происхождение, доказательства и область применимости. Их совместное присутствие в prompt не объясняет, какие утверждения стали обязательными для конкретной задачи.

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

Управление смыслами вводится как слой, который формирует task-specific semantic commitments и фиксирует их в неизменяемом Knowledge Contract. Context, proposals, commitments, ResolutionCore, Explanation, semantic Contract, issuance, binding и authorization-at-t различны; Contract не заменяет repository, runtime или policy engine.

Следующий исследовательский вопрос состоит в том, как сделать этот переход версионируемым, объяснимым и аудируемым, не смешивая semantic selection, issuance, runtime realization и authorization. Формальная модель задаёт проверяемые границы; экспериментальная программа допускает опровержение их практической полезности. Готовая реализация или превосходство над baseline не заявлены.

Схема перехода от prompt-driven системы через retrieval к Knowledge Contract с графиками предполагаемых свойств. — **Рисунок 1.** Визуальная гипотеза перехода от найденного контекста к Knowledge Contract. Нижние кривые не измерены и не являются результатом.

Статус утверждений

Нужно различить три слоя утверждений. Первый слой — зафиксированные проектные решения: состав Variant A, пять названий Resolver, запрет мгновенного доверия к синтезированному знанию, различие Expansion и Evolution, а также разделение контракта, привязки и авторизации. Второй слой — формализованные предложения: модель BKG, предикаты совместимости, структура записей и протоколы экспериментов. Третий слой — неполученные результаты: влияние архитектуры на число нарушений, стоимость, воспроизводимость и согласие рецензентов.

Определение: Нормативное значение термина внутри этой архитектуры; не эмпирический результат.
Проектная гипотеза: Архитектурное решение, полезность которого должна быть проверена сравнением.
Производное свойство: Следствие принятых определений или формальной конструкции при указанных предпосылках.
Предложение реализации: Один допустимый способ воплощения, не обязательный элемент ядра.
Эмпирическое наблюдение: Фактически измеренный результат; в текущем цикле относится только к публикационному пакету.
Непроверенное ожидание: Предполагаемое направление эффекта, которое нельзя читать как outcome.
Открытый вопрос: Исследовательская неопределённость без принятого ответа.

Техническая сборка страницы, проверка хешей исходных изображений и прохождение тестов подтверждают только целостность публикационного пакета. Они не подтверждают HYP-001–HYP-009, не измеряют качество поведения агента и не превращают формальную запись в реализованную систему. Синтетическая проверка механики отличается от эмпирической валидации так же, как компиляция протокола эксперимента отличается от его исполнения.

Короткая формула границы: доступный контекст не равен разрешённому смыслу; разрешённый смысл не равен исполняемой реализации; найденная реализация не равна разрешённому действию; корректная сборка текста не равна подтверждённой архитектуре.

Постановка проблемы

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

Сбой возникает в переходе между «материал доступен» и «система обязана действовать именно так». Если этот переход не представлен отдельными объектами и квитанциями, после выполнения трудно ответить:

какие версии роли, навыков, плана, ограничений, политик, критериев успеха и описаний способностей были выбраны;
какой источник предложил каждый элемент и какая проверка признала его пригодным;
какие конфликты и пробелы были обнаружены, а какие могли исчезнуть в длинном prompt;
почему конкретный adapter считался реализацией абстрактной способности;
какой principal имел право выпустить контракт, одобрить binding и разрешить действие;
можно ли воспроизвести выбор после изменения репозитория знаний или отзыва полномочия.

Длина контекста, качество retrieval и точность генерации проблему не исчерпывают: версии могут конфликтовать, способность — не иметь проверенной реализации, а право — быть отозвано после выпуска Contract. Требуется явное управление смысловыми обязательствами.

Исследовательский вопрос и область

Основной вопрос: как автономная ИИ-система может выделить из неоднородного доступного материала совместимый, трассируемый и версионируемый смысловой срез конкретной задачи, закрепить его без ретроактивного изменения и при этом не смешать выбор смысла с runtime-привязкой и авторизацией действия?

Подзадачи: определить типы артефактов; вычислить bounded transitive requirements; различать отсутствие, конфликт, неоднозначность и binding failure; эволюционировать знания без переписывания истории; обеспечить replay и независимый аудит.

Концептуальные исключения

Работа не моделирует человеческую семантику, сознание, внутренние нейронные представления, общую теорию машинного понимания или универсальный AGI control plane.

Не-цели

Архитектура не гарантирует успешность действия в открытом мире, отсутствие внешней неопределённости, доступность всех runtime providers или полный operational replay внешней инфраструктуры.

Нейтральность к реализации

Нормативное ядро не выбирает graph store, RDF/SHACL, relational database, policy engine, orchestrator, MCP, CLI, A2A, transport, конкретный agent framework или LLM vendor.

Объект исследования — автономные системы, которые формируют task-specific executable semantic commitments из версионируемых управляемых знаний и отделяют эти commitments от runtime realization и authorization.

Вклад этой архитектуры

Основной вклад — Управление смыслами как архитектурный слой, который делает явным жизненный цикл task-specific semantic commitments: от доступного контекста и выбора до выпуска, concrete runtime realization и текущего разрешения действия.

Поддерживающие вклады:

типизированная онтология семи управляемых артефактов Variant A;
Blueprint Knowledge Graph с bounded closure и compatibility;
пятистадийный Resolver protocol;
Resolution Receipt с отдельным R_id;
неизменяемый Knowledge Contract с K_id;
независимая issuance identity I_id;
scoped Knowledge Expansion и governed Artifact Evolution;
разделение Binding и action-specific Authorization;
модель semantic, decision и operational reproducibility;
фальсифицируемая preregistration-программа HYP/EXP-001–009.

Эти механизмы конкретизируют декомпозицию, не образуя claim исторического первенства.

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

Сравнительная визуальная гипотеза о prompting, in-context learning, RAG, tool-augmented agents и Knowledge Contract с неподтверждёнными галочками и трендами. — **Рисунок 13.** Визуальная гипотеза Related Work, не результат сравнения. Галочки и тренды не измерены; научное сопоставление выполняет таблица источников и механизмов ниже.

Область	Класс и источники	Что уже дано	Остающаяся граница
Prompt engineering	Direct [1]	Типологии task prompts.	Нет lifecycle версий/evidence/authority обязательств.
In-context learning	Direct [2] [3]	Контекст меняет поведение без retraining; важен его формат.	Пример не отделён от принятого artifact/Receipt.
Retrieval-augmented generation	Direct [4]	Generation использует retrieved non-parametric memory.	Relevance не доказывает compatibility/evidence/eligibility.
Agent planning and action	Direct [5]	ReAct чередует reasoning и actions.	Trajectory не является Contract или Auth_t.
Multi-agent systems	Direct [6] [7]	Roles и conversations координируют agents.	Нет Variant A, BKG cut и pinned identity.
Agent memory	Direct [8] [9]	Memory/retrieval/reflection поддерживают длительный context.	Доступность не присваивает governance status.
Knowledge graphs and validation	Direct [10]; Supporting [11] [22]	Typed graphs и constraint validation.	Нет bounded task closure, selection Receipt и Issue.
Provenance	Supporting [12]	Entities, activities, agents и derivation.	Не определяет evidence threshold, approver или conflict resolution.
Workflow languages	Direct [13]; Supporting [14]	Portable workflows и process notation.	Шаги уже заданы; semantic candidates не разрешаются.
Software architecture	Supporting [15]; Direct [16]	Viewpoints, elements, interfaces, behavior, rationale.	Описание не является Resolver, Binding или Auth.
Policy-as-code	Supporting [17] [18]	Decisions по structured request/data.	Нет полного SemanticCut или binding equivalence.
Reproducible systems	Supporting [19]	Явные source/environment/instructions/comparison.	Нужны semantic inputs/receipts; outcome не обязан совпасть.
Governance frameworks	Supporting [20]	Govern/map/measure/manage AI risks.	Нет artifact calculus, graph cut или Contract identity.
Semantic service descriptions	Supporting [21]	Profile, process model, grounding.	Нет полного Variant A lifecycle и текущей Auth.

Variant A конкретизирует декомпозицию через typed artifacts, BKG, Resolver, Receipt, Contract, Expansion/Evolution и execution gate; сочетание supporting mechanics не доказывает исторического первенства. Receipt профилирует provenance, Evidence Profiles остаются proposal, а OPA/Cedar не заменяют semantic selection, binding proof или authority governance.

Корпус выбран целенаправленно. Вывод ограничен проверенным корпусом и не является утверждением исторического первенства. Близкая система должна сузить вывод; отсутствие найденного объекта не доказывает его отсутствие. Границы 22 источников и процедура обновления вынесены в Supplement.

III. Понятийная модель

Принципы проектирования

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

Сначала кандидат. Search, memory, model и tool output становятся обязательствами только после Verify и Select.
Типизированные обязательства. Семь типов не сливаются: тип задаёт поля, связи, проверки и governance.
Раздельная неизменяемость. Contract bytes и issuance metadata имеют независимые identities; исправление создаёт новую запись.
Именованный отказ. Missing, Conflict, Ambiguous, Evidence-Insufficient, Search-Incomplete, Unbound и Unauthorized нельзя скрывать fallback.
Нет самосертификации. Producer не принимает собственный синтез единолично; независимость зависит от риска.
Expansion ≠ Evolution. Закрытие task gap не меняет repository; Evolution создаёт governed successor.
Три границы. Contract задаёт обязательное, Binding — реализацию, Auth — разрешение сейчас.
Квитанция. Аудит использует сохранённые входы и решения, а не реконструкцию скрытого reasoning.

Терминология

Определение. Термины ниже имеют нормативное значение только внутри предлагаемого профиля Управления смыслами (Meaning Management).

На узком экране таблица прокручивается по горизонтали.

Термин	Определение в этой версии	Не означает
Управление смыслами (Meaning Management)	Публичное название архитектурного слоя, который преобразует разнородную и изменяющуюся семантическую информацию в управляемые, версионируемые и специфичные для задачи обязательства.	Универсальную теорию значения, внутреннее состояние модели или название одного программного продукта.
Доступный контекст	Все материалы, которые Resolver может рассмотреть при заданных границах поиска.	Набор уже принятых истин или полномочий.
Proposal	Кандидат на включение с источником, версией и заявленным типом.	Принятый артефакт.
Смысловое обязательство	Более узкая формальная единица Meaning Management: выбранное типизированное утверждение, которое входит в task cut и влияет на допустимое исполнение.	Любой текст в prompt или всё содержимое доступного контекста.
Managed Artifact	Версионируемый объект одного из семи типов, имеющий identity, provenance, evidence и lifecycle status.	Файл как таковой; один файл может кодировать несколько объектов.
CapabilityDescription	Управляемое абстрактное описание нужной способности, входов, выходов, эффектов и требований.	Конкретный инструмент или endpoint.
CapabilityType	В Variant A это производный нормализованный тип, вычисленный из CapabilityDescription и профиля графа для сопоставления.	Самостоятельный управляемый артефакт или конкретная реализация. Возможное повышение статуса относится только к будущему исследованию.
Binding Record	Runtime-запись, связывающая обязательство и CapabilityType с точным adapter, транспортом, средой и доказательством эквивалентности.	Разрешение вызвать adapter.
Knowledge Contract	Неизменяемый content-addressed семантический срез выбранных версий, связей и обязательств одной задачи; его identity — `K_id`.	Метаданные выпуска, весь BKG, mutable workspace или лицензию на выполнение.
Resolution Receipt	Аудиторская запись выбора: неизменяемый ResolutionCore имеет `R_id`, а человекочитаемая Explanation не меняет его.	Managed artifact, стадию Resolver, Contract или скрытый chain-of-thought.
IssueRecord	Неизменяемая запись события выпуска внутри Assemble: issuance identity `I_id` ссылается на `K_id`.	Часть `K_id`, managed artifact, шестую стадию Resolver или Resolution Receipt.
AuthorityCut(t)	Предлагаемый срез действующих в момент t полномочий, делегирований и отзывов для principal, ресурса и действия.	Завершённую формальную модель власти, Role или список возможностей среды.
PolicyCut(t)	Предлагаемый срез точных версий и условий Policy, применимых к principal, ресурсу и действию в момент t.	Policy, зафиксированные при выборе/выпуске Contract, или завершённую policy-engine/IAM реализацию.
Gap Record	Запись дефицита с `GapKind`: Semantic, Evidence, Version, Policy либо операционный BindingProvider.	Разрешение молча заполнить дефицит или считать authority failure пробелом знания.

Управление смыслами (Meaning Management) — публичное название архитектурного слоя. Смысловое обязательство — более узкая формальная единица. Доступный материал получает этот статус только после проверяемого выбора.

Онтология управляемых артефактов: Variant A

Формальные поля, идентичность и сквозной пример семи типов приведены в Приложении A.

Пусть множество управляемых типов равно T = T_primary ∪ T_operational. В текущей версии T_primary = {Role, Skill, Blueprint}, а T_operational = {Constraint, Policy, SuccessCriterion, CapabilityDescription}. Деление показывает назначение, но не создаёт отношение важности: контракт может быть корректным только при наличии требуемых экземпляров из обеих групп.

Role, Skill и Blueprint как три равноправных первичных переиспользуемых управляемых артефакта Variant A. — **Рисунок 2.** Архитектурная классификация Role, Skill и Blueprint как первичных переиспользуемых артефактов Variant A. Роль рисунка ограничена этой классификацией; окружающий pipeline не задаёт формальную границу архитектуры.

Первичные переиспользуемые смысловые артефакты

Role фиксирует ответственность, ownership, decision scope, governance boundary и handoff, но не задаёт access rights, authority, профессию, должность или identity исполнителя; principal авторизуется отдельно.

Skill задаёт reusable способ: предусловия, входы, стратегию, выходы, эффекты, failures и способности. Он не равен инструменту и не скрывает Policy.

Blueprint соединяет роли и навыки, зависимости, checkpoints, данные, ветвления и recovery. Его ссылки запускают closure, но не копируют весь граф.

Операционные и управленческие артефакты

Constraint задаёт проверяемое условие или ресурсную границу; нарушение делает композицию недопустимой.

Policy задаёт versioned governance rule для principal/resource/action, условий и precedence. Constraint проверяет состояние; Policy — применимое решение allow/deny.

SuccessCriterion определяет subject, процедуру, порог, время и неопределённость; отсутствие метрики не означает успех.

CapabilityDescription описывает абстрактную способность. CapabilityType выводится профильными правилами; post-issuance Bind доказывает соответствие конкретного adapter.

Производное свойство. Если CapabilityDescription и правила нормализации зафиксированы точными версиями, CapabilityType должен воспроизводиться из тех же входов; это следует из выбранного статуса типа, но ещё требует executable conformance test.

Запрещённые слияния

Следующие различия являются нормативными инвариантами Variant A. Они не зависят от выбранного graph store, transport или agent framework.

Policy != Constraint. Policy задаёт правило управления и применимость власти; Constraint задаёт проверяемое условие допустимости композиции или результата.
Role != Authority. Role описывает ответственность; право предложить, проверить, опубликовать, выпустить, связать или выполнить определяется отдельно.
CapabilityDescription != CapabilityType. Первое является управляемым описанием; второе в Variant A выводится нормализацией для сопоставления.
Expansion != Evolution. Первая закрывает пробел разрешения; вторая публикует новую переиспользуемую версию после самостоятельного governance-процесса.
Contract != Repository. Контракт содержит точные ссылки и обязательства одной задачи, а не живую копию всего BKG.
Binding != Authorization. Соответствие абстрактной способности реализации не даёт principal права на действие.
Available Context != Selected Commitment. Найденный, извлечённый или сгенерированный материал остаётся кандидатом до проверки и выбора.

Дополнительные запреты следуют из этих инвариантов: Skill не скрывает Policy, Blueprint не обозначает весь репозиторий, Binding Record не служит токеном доступа, а SuccessCriterion не является обещанием результата. Возможное превращение CapabilityType в самостоятельный managed artifact допустимо исследовать только при наличии собственных независимых владения, governance, versioning и lifecycle; текущая онтология такого статуса не приписывает.

Контрпримеры архитектурных слияний

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

На узком экране таблица прокручивается по горизонтали.

Граница	Минимальный контрпример	Следствие
Available Context ≠ Selected Commitment	Retrieved Blueprint семантически близок задаче, но несовместим с текущим набором Policy и версий.	Присутствие в retrieval не делает объект смысловым обязательством.
Role ≠ Authority	Principal сохраняет ту же Role, но authority grant отозван между t1 и t2.	Role не может содержать runtime permission.
Binding ≠ Authorization	Проверенный provider найден и `BindingValid=true`, но `Auth_t=Deny`.	Техническая реализуемость не означает разрешённость действия.
`K_id ≠ I_id`	Один `K_sem` легитимно выпускается двумя разными authorized issuance events.	Семантическая identity контракта не равна identity выпуска.
Expansion ≠ Evolution	Полностью отсутствующий Skill требует Expansion; существующий Skill с неполной validation procedure требует successor через Evolution.	Создание нового знания и новая версия существующего знания являются разными lifecycle operations.

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

IV. Семантическая архитектура

Жизненный цикл Управления смыслами (Meaning Management)

Концептуальный обзор Управления смыслами: источники знания, Resolver, Knowledge Contract и исполнение. — **Рисунок 3.** Архитектурная схема — Концептуальный обзор Управления смыслами между доступными источниками и исполнением. Она показывает распределение ответственности, но не задаёт формальную границу между Resolver, contract, binding и authorization.

Объектная линия отделена от операций Resolver:

На узком экране формула прокручивается по горизонтали.

C_available → P_candidates → SemanticCut(q,r) → ResolutionCore/R_id → K_sem/K_id → I/I_id → B_runtime → Auth(a,t)

C_available — материалы; P_candidates — proposals; SemanticCut(q,r) — выбранные обязательства; ResolutionCore/R_id — проверяемая запись выбора; K_sem/K_id — семантический Contract; I/I_id — его выпуск; B_runtime — реализация; Auth(a,t) — решение. Стрелка обозначает границу, не доверие.

SemanticCut(q,r): Выбранный совместимый набор точных версий для задачи q в BKG revision r; его выбор объясняет Resolution Receipt.
BindingCut(K_id,e): Множество проверенных runtime realizers для обязательств K_id в среде e; оно фиксируется отдельным Binding Record.
AuthorityCut(t): Адресуемый входной срез действующих полномочий, делегирований и отзывов в момент t; он не входит в Contract и не формализует внутреннюю IAM-модель поставщика authority.
PolicyCut(t): Адресуемый входной срез действующих Policy versions и условий применимости в момент t; он не входит в Contract. Это не отменяет точных Policy versions, которые Contract фиксирует как evidence выбора и выпуска.

Propose создаёт candidates; Verify проверяет их; Select вычисляет SemanticCut(q,r) и ResolutionCore; Assemble завершает semantic resolution, канонизирует K_sem и фиксирует выпуск I. Bind — пятая стадия общего протокола, но post-issuance boundary: она делегирует конкретную реализацию runtime/harness. Issue — событие внутри Assemble, Receipt — запись, а не стадии. Authorization остаётся снаружи.

Поэтому similarity не делает знание обязательным, а найденный инструмент — разрешённым.

Blueprint Knowledge Graph

Архитектурная конструкция. BKG — versioned typed multigraph G_r = (V_r, E_r, Π_r): узел (artifact_id, type, version, digest, status, provenance, evidence, authority_scope), ребро (source, relation_type, target, version_constraint, evidence, status), Π_r — types, compatibility, closure bounds, precedence. RDF/SHACL, typed/property/relational/purpose-built/hybrid — implementation choices.

Нормативная область имени. Историческое название BKG обозначает типизированный граф всех управляемых смысловых артефактов; Blueprint является композиционным узлом, а не единственным классом узлов.

Сетевой Blueprint Knowledge Graph с узлами разных типов, типизированными отношениями и легендой. — **Рисунок 7.** Архитектурная схема BKG как графа, а не дерева. Исходная сеть показывает неоднородные узлы; формальная конструкция ниже добавляет версии, edge domains, invariants, bounded closure и compatibility.

Типы связей

Минимальный словарь: requires, provides, instantiates, delegatesTo, governedBy, constrainedBy, evaluatedBy, conflictsWith, supersedes, derivedFrom. У каждого relation type есть domain/range; неизвестное ребро не считается безопасным.

Инварианты

Type soundness: тип каждого узла известен профилю, а domain/range каждого выбранного ребра допустимы.
Identity integrity: digest соответствует каноническим байтам версии; две разные записи не делят один identity без доказанной эквивалентности.
No dangling obligations: обязательное ребро выбранного узла либо разрешено подходящим узлом, либо порождает Gap/Search-Incomplete.
Version coherence: все version constraints в срезе удовлетворены одновременно; mutable aliases раскрыты в точные версии.
Evidence and authority: принятие узла и критического ребра имеет квитанцию проверки и допустимого approver.
Dependency termination: отношение транзитивных обязательных зависимостей в task cut ациклично либо содержит явно разрешённую итерацию с мерой убывания и пределом.
Historical stability: снимок G_r и выпущенный срез остаются доступными после появления successor.

Bounded closure

Из семян S₀ Resolver добавляет required dependencies/providers, применимые Policy/Constraint и SuccessCriterion до fixed point или B = (max_depth, max_nodes, time_budget, provider_budget). Результат: {Closed, Gap, Conflict, Ambiguous, Search-Incomplete}; исчерпание B не означает Closed.

На узком экране формула прокручивается по горизонтали.

C₀ = S₀
Cₖ₊₁ = Cₖ ∪ Required(Cₖ) ∪ ApplicableGovernance(Cₖ) ∪ CandidateProviders(Cₖ)

Compatible(C) проверяет types, versions, hard constraints, policy applicability, declared artifact scope, exclusions, Evidence Profile и issuer. Ranking применяется только к совместимым cuts; ResolutionCore фиксирует identities и reason codes отклонений.

Версии и отношение к контракту

BKG изменяем, Contract — нет: Assemble сохраняет identities из G_r, а не live link. Published bytes неизменяемы; версии сосуществуют со статусами deprecated, superseded, revoked; Contracts pinned. Будущий selector — только latest compatible approved version, никогда plain latest.

Полнота и complexity solver не доказаны. Alternative providers, exclusions и negative edges создают combinatorial search, поэтому стратегия, budgets и Search-Incomplete обязательны; purpose-built graph ещё предстоит сравнить с RDF/SHACL [11] [22].

Resolver: Propose → Verify → Select → Assemble → Bind

Полный пример разрешения кандидатов и граница выпуска приведены в Приложении B.

Конвейер отбора Blueprint-кандидатов от анализа задачи через проверку ограничений и ранжирование к выбранному набору. — **Рисунок 5.** Архитектурный workflow Selection внутри Resolver. Top-N означает ранжированный набор кандидатов после проверки покрытия и совместимости, а не фиксированное число Blueprint.

Propose

Из task intent, bounds и BKG snapshot операция возвращает candidates с declared type, source/version или retrieval time, producer, digest и relevance reason. Model output остаётся proposal при любой confidence.

Verify

Verify проверяет schema, digest, provenance, evidence, validity, relation domain/range, source authority и заявленный ExpansionArtifact scope. Verify проверяет scope относительно task, lineage и namespace. Возможны Verified, Rejected, Evidence-Insufficient, Gap, Search-Incomplete и Scope-Mismatch.

Select

Select применяет precedence, exclusions, scope и version constraints до ranking. Select отклоняет scope mismatch состоянием Scope-Mismatch; равноправные cuts дают Ambiguous, несовместимые hard requirements — Conflict.

Граница детерминизма. В этой статье детерминированное разрешение над зафиксированными кандидатами и Policy inputs означает воспроизводимое применение frozen verification/selection rules, assembly, canonical identities и replay. Детерминизм не приписывается stochastic model или search внутри Propose.

Assemble и событие Issue

Assemble завершает semantic resolution: замораживает ResolutionCore/R_id, создаёт K_sem/K_id, затем событие Issue связывает K_id с issuer, authority evidence, timestamp и signature в отдельной I/I_id записи. IssueRecord материализует I, не меняя K_id. Нет права выпуска — Issue-Unauthorized.

Bind

Bind остаётся пятой стадией Resolver protocol, но находится после выпуска: runtime/harness выбирает adapter/transport/interface/environment и записывает B_id, equivalence evidence и validity. Несовместимость даёт Unbound; успех не разрешает действие.

Исходный Knowledge Resolver с анализом задачи, подбором артефактов, проверкой полноты, веткой missing knowledge и сборкой контракта. — **Рисунок 6.** Архитектурный workflow Resolver с проверкой полноты и ветвью пробела. Нормативная последовательность — Propose → Verify → Select → Assemble → Bind с типизированными отказами.

Терминальные состояния

Contract не обязателен: Missing, Gap, Evidence-Insufficient, Conflict, Ambiguous, Search-Incomplete, Scope-Mismatch, Issue-Unauthorized, Unbound, Policy-Conflict, Unauthorized — допустимые terminal states и остаются в denominator.

Resolution Receipt: граница между выбором и выпуском

После Select система создаёт неизменяемую Resolution Receipt. Это самостоятельная аудиторская запись выбора, но не managed semantic artifact и не стадия Resolver. Квитанция существует и при отказе продолжать сборку: она позволяет различить конфликт, неполный поиск, недостаток evidence и отсутствие права выпуска.

ResolutionCore = canon(candidate_ids, search_bounds, selected_versions, rejection_reason_codes, precedence, conflicts, uncertainty, Search-Incomplete, policy_ids)
R_id = H(bytes(ResolutionCore))

Explanation = narrative(decision_summary, audience_profile, redactions) · E_id = H(bytes(Explanation))

ResolutionCore содержит только канонические идентификаторы и reason codes, достаточные для машинной реконструкции выбора. Narrative Explanation может переформулироваться, переводиться или редактироваться без изменения R_id; если её фиксируют, отдельный E_id связывается с R_id.

Candidate set: Точные identities всех рассмотренных кандидатов.
Search scope and bounds: Источники, namespaces, глубина, budgets и момент остановки.
Selected versions: Точные версии и digests выбранных артефактов и связей.
Rejected alternatives: Точные identities и машиночитаемые reason codes.
Conflicts and resolutions: Обнаруженные конфликты, их ядра и применённые разрешения.
Precedence: Правила приоритета и tie-break, использованные Select.
Compatibility: Проверенные предикаты совместимости и версии валидаторов.
Policies: Точные Policy identities, применённые к выбору.
Uncertainty: Структурированная остаточная неопределённость внутри ResolutionCore.
Search-Incomplete: Отдельный признак исчерпания границ поиска; его отсутствие нельзя выводить из наличия результата.
Narrative Explanation: Человекочитаемое объяснение без скрытого chain-of-thought; находится вне R_id.

Открыты canonical encoding ResolutionCore, vocabulary reason codes, privacy-профиль и допустимость остаточной неопределённости. Стабильный digest фиксирует решение, но не доказывает его правильность; Explanation не должна маскировать расхождение core.

Knowledge Contract

Для задачи q и снимка G_r семантический Contract и его выпуск имеют разные канонические записи:

На узком экране формула прокручивается по горизонтали.

K_sem = canon(q_id, G_r[SemanticCut(q,r)], obligations, exclusions, R_id, schema_version) K_id = H(bytes(K_sem))

На узком экране формула прокручивается по горизонтали.

I = canon(K_id, issuer, authority_evidence, timestamp, signature, issuance_schema_version) I_id = H(bytes(I))

Внутренняя структура Knowledge Contract: task, selected artifacts, constraints, success criteria, metadata и связи с BKG и runtime. — **Рисунок 4.** Архитектурная схема Knowledge Contract как task-specific semantic cut. Стрелки к графу обозначают разрешение и трассировку; выпущенный контракт не изменяет BKG.

SemanticCut(q,r) содержит точные identities/digests узлов, необходимые рёбра, unresolved declarations, exclusions и критерии успеха. Contract ссылается на неизменяемый идентификатор Resolution Receipt: Knowledge Contract закрепляет точный R_id, но не копирует Receipt. I ссылается только на готовый K_id; I_id не входит в собственные канонические входы, поэтому рекурсивной identity нет.

Task-specific: одна задача и identity.
Immutable/content-addressed: исправление создаёт новый digest.
Exactly versioned: только точные версии объектов и связей.
Inspectable/replayable: cut, exclusions, R_id и semantic canonicalization profile проверяются независимо от I/I_id.
Provenance-aware: обязательства связаны с evidence неизменяемыми записями.

Issue metadata не входит в K_id: другой issuer, timestamp, authority evidence или signature создаёт новый I_id, но не меняет тот же K_sem/K_id. Новые обязательства меняют K_id; повторный выпуск тех же байтов меняет только issuance domain. Contract не является prompt, repository, Binding Record, credential или authorization.

Interoperable profile ещё должен выбрать canonical serialization, hash, artifact schema, BKG snapshot identity, ordering, time и external evidence handling.

Gap Detection и Expansion

Gap Record фиксирует required type/relation, origin, searched scopes, bounds, Evidence Profile, risk class, kind и terminal status. GapKind — закрытая классификация записи, а не новый managed artifact:

Semantic: Нет требуемого артефакта или связи.
Evidence: Кандидат есть, но Evidence Profile не выполнен.
Version: Нет совместимой approved версии в bounds.
Policy: Требуемая применимая Policy отсутствует или неоднозначна; известный конфликт остаётся Policy-Conflict.
BindingProvider: BindingGap является операционной диагностикой Bind с исходом Unbound и не запускает Knowledge Expansion автоматически.

Недостаточная authority является отказом авторизации, а не Gap: применяются Issue-Unauthorized либо Unauthorized. Scope mismatch также сохраняет самостоятельный terminal outcome.

Gap Detection: проверка полноты, обнаружение отсутствующего знания, предложение нового артефакта и повторная проверка. — **Рисунок 8.** Архитектурный workflow Gap Detection с обязательной validation: кандидат не получает мгновенного доверия, а локальная Expansion не равна Evolution репозитория.

Область ExpansionArtifact

ExpansionArtifact получает один scope из закрытого канонического множества:

task-local: Доступен только повторному разрешению той же task identity.
lineage-local: Доступен объявленной цепочке производных задач.
namespace-local: Доступен только указанному governed namespace.
globally-reusable: Запрошенная глобальная область; eligibility возникает лишь после Evolution/promotion.

session-local требует явного обоснования и допустим только как более короткая retention-модификация task-local; он не образует пятую область promotion. До governance-перехода объект eligible только внутри effective scope. Ограниченная публикация не делает объект globally-reusable и не добавляет его в глобально переиспользуемый BKG.

Последовательность Expansion

Gap Detection. Gap Record фиксирует недостающее требование, выполненный поиск и границы.
Synthesis/Acquisition. Система получает кандидата, сохраняет происхождение и объявляет ExpansionArtifact scope.
Quarantine. Новый объект недоступен Resolver как принятый артефакт и не наследует доверие producer.
Evidence. Собираются предусмотренные профилем доказательства, тесты, сценарии и рецензии.
Verification. Независимые проверки подтверждают содержание, evidence и соответствие scope.
Governance Review. Уполномоченная сторона решает, допустима ли публикация в заданной области.
Versioned Publication. Принятый объект получает immutable identity и ограниченную область видимости.
Resolver Eligibility. Профиль разрешает повторный выбор только внутри effective scope.

Promotion за пределы scope требует governed Evolution. Синтезированный Skill/Policy проходит quarantine, а producer не может быть единственным verifier, reviewer и publisher risk-sensitive артефакта.

Evidence Profiles

Evidence Profile задаётся парой тип артефакта × класс риска и может требовать provenance, независимых verifiers, tests, scenarios, security/Policy/human/domain review, compatibility и replay. Inputs, independence и thresholds версионируются; универсального confidence числа нет.

Expansion разрешает повторить closure, но может завершиться Reject, Ambiguous или Search-Incomplete; локальный cache не является Evolution.

Lifecycle Meaning Management с основной сборкой и отдельными ветвями Knowledge Expansion и Knowledge Evolution. — **Рисунок 9.** Архитектурный workflow разделяет Expansion, закрывающую пробел текущего разрешения, и Evolution, изменяющую reusable knowledge только через новый принятый versioned artifact.

Самоисправление агента сохраняется как observation/proposal, но без независимой проверки не изменяет общий Skill.

Контролируемая Evolution

Evolution публикует successor с новым digest, provenance и supersedes, не редактируя прежнюю версию:

Execution Evidence. Наблюдения связываются с точным контрактом, binding, средой и outcome.
Deficiency. Формулируется проверяемый дефект существующего артефакта или профиля.
Root Cause. Отделяется причина в reusable knowledge от ошибки поиска, binding, среды или авторизации.
Versioned Proposal. Создаётся кандидат successor с новым digest и семантическим diff.
Validation/Regression. Выполняются профильные проверки, включая влияние на зависимые Blueprints и исторические fixtures.
Governance Approval. Уполномоченный publisher принимает или отклоняет новую версию; producer не утверждает её единолично.
Versioned Publication. Одобренная immutable версия публикуется рядом с предшественниками.
BKG Update. Новый graph snapshot добавляет successor и статусы применимости без удаления истории.
Resolver Adoption. Только будущие разрешения могут выбрать новую версию по правилу latest compatible approved version.

Исторический Contract остаётся pinned; successor доступен лишь в новом BKG snapshot. Deprecation, supersession и revocation не удаляют историю; текущая Auth может запретить повторное действие.

Expansion ≠ Evolution. Первая закрывает task gap, вторая допускает reusable knowledge после независимой оценки, tests и authority decision. Frequency/model score переход не заменяют. Deployment profile отдельно задаёт retention snapshots, receipts, blobs, hashes и удалённых источников.

Governance и власть

Governance loop вокруг Knowledge Contract: policy engine, planner, runtime, observability, validation и evolution. — **Рисунок 10.** Архитектурная схема governance-контура вокруг Knowledge Contract. Авторизация конкретного действия и принятие новой версии остаются отдельными решениями власти.

Открытый вопрос. Authority model не завершена. Она должна различать producer, verifier, publisher, contract issuer, binding approver, runtime action authority и human authority. Role не является authority; risk-sensitive профиль обосновывает segregation of duties и governance independence.

AuthorityCut(t) — снимок полномочий для principal/action/resource; PolicyCut(t) — снимок действующих правил. Будущая модель должна задать versioned AuthorityGrant, delegation, scope, expiry, human chain, revocation, emergency override, conflicts и independence proof. Это внешний governance-интерфейс, не типы Variant A и не завершённая IAM-модель.

Cedar и OPA могут вычислять policy decision [18] [17]; Contract поставляет им identities, но не заменяет их. CapabilityDescription, Binding Record и Role не дают права действия. Недостаточная authority — допустимый terminal outcome, не повод форсировать Issue или execution.

Runtime binding и граница авторизации

Контрастные случаи binding и authorization для единого примера приведены в Приложении C.

Execution architecture: Knowledge Contract, agent runtime, tools and services, observability, validation и результат. — **Рисунок 12.** Архитектурная runtime-схема исполнения. Binding доказывает конкретную реализацию обязательств, а отдельная проверка authority-at-time-t решает, можно ли выполнить действие.

CapabilityDescription нормализуется в CapabilityType; Bind ищет adapter по inputs, outputs, effects и trust properties. Function, CLI, API или agent protocol могут реализовать один тип, но transport не доказывает equivalence или authority. OWL-S аналогично различает profile, process model и grounding [21].

Binding Record хранит K_id, obligation, CapabilityType, adapter/version, interface digest, transport, environment, equivalence evidence, verifier, validity и digest. Секреты заменены безопасной ссылкой; изменение adapter/interface/environment требует rebind.

Авторизация формулируется отдельно:

На узком экране формула прокручивается по горизонтали.

Auth(principal, action, resource, t | AuthorityCut(t), PolicyCut(t)) -> Allow | Deny(reason) | Indeterminate(reason)

На узком экране формула прокручивается по горизонтали.

Executable(K,B,a,t) = ContractPermits(K,a) AND BindingValid(B,K,a) AND Auth(principal,action,resource,t | AuthorityCut(t),PolicyCut(t)) = Allow

Action не входит в Contract: ContractPermits лишь проверяет его против обязательств и запретов. BindingValid = false запрещает исполнение; Deny или Indeterminate запрещают действие. Недоступность Auth никогда не преобразуется в Allow.

Decision = canon(K_id, B_id, I_id?, AuthorityCut_id, PolicyCut_id, principal, action, resource, timestamp, outcome, reason). I_id включается, когда профиль требует доказать конкретный выпуск; отсутствие этого поля не соединяет semantic и issuance identities.

Provenance, evidence и versioning

PROV-O задаёт Entity, Activity и Agent [12]. Task-specific transition record добавляет input/output identities, operation/version, actor/service, time, decision/reasons, evidence, policy/authority identities и failure class.

На узком экране таблица прокручивается по горизонтали.

Переход	Что сохраняется	Что нельзя выводить задним числом
Propose	Source locator, producer, retrieval parameters, raw digest, заявленный тип.	Что источник был принят или истинен.
Verify	Проверки схемы/evidence/authority, версии валидаторов, verdict.	Что все возможные источники были найдены.
Select	Кандидаты, hard constraints, precedence, rejected alternatives, conflict core.	Что ranking был единственно возможным.
Resolution Receipt	ResolutionCore: candidate identities, bounds, selection, reason codes, conflicts, precedence, uncertainty, Policy identities и Search-Incomplete; Explanation и `E_id` отдельно.	Что narrative является частью `R_id` или доказывает правильность выбора.
Assemble/Issue	`K_sem/K_id`, затем отдельные issuer, authority evidence, time, signature и `I/I_id`.	Что issue metadata входит в `K_id` или контракт исполним после изменения среды.
Bind	`K_id`, adapter/interface/environment identity, equivalence evidence, validity и `B_id`.	Что вызов разрешён.
Authorize	`K_id/B_id`, при необходимости `I_id`, action, principal/resource, cut identities, timestamp, outcome и reason.	Что action входит в Contract или будет разрешён позже.

Provenance не доказывает relevance или authority. ResolutionCore хранит проверяемые поля выбора; Explanation обслуживает человека; issuance и execution records отдельно фиксируют власть и решение во времени.

Digest — окончательная content identity; semantic version лишь помогает человеку. Mutable «current» допустим в search, но Contract содержит exact version и не меняет прежний K_id.

Уровни воспроизводимости

Слово «воспроизводимость» без уровня создаёт ложное обещание. Архитектура различает три научных уровня; воспроизводимость сборки публикационного пакета проверяется отдельно и не служит заменой ни одному из них.

Семантическая воспроизводимость. При frozen candidates, BKG snapshot, profiles, bounds и canonical rules сравниваются SemanticCut, ResolutionCore/R_id и K_sem/K_id. Это производное свойство фиксированных входов, а не доказательство правильности выбранного смысла.
Воспроизводимость решения. При frozen issue inputs отдельно сравниваются I/I_id, а для runtime decision — K_id, B_id, identities AuthorityCut(t)/PolicyCut(t), timestamp, outcome и reason. Один Contract может иметь разные легитимные выпуски; HYP-003 проверяет отсутствие cross-domain identity drift, но пока не исполнена.
Операционная воспроизводимость. При тех же K_id, B_id, environment и runtime cuts система пытается повторить trace и domain outcome либо объяснить divergence. Время, внешние сервисы и удалённые providers могут исключить byte-identical replay или независимую replication результата.

Наблюдение о пакете. Frozen tree/toolchain дают проверяемую сборку; reproducibility требует inputs, environment, instructions, comparison [19]. Приватный корпус — 63 raw images; публичный атлас — 62 hashed versions. Доказаны лишь сборка/boundary, не Resolver replay, правильность решения или полезность Contract.

Сквозная архитектура

Available context становится candidates в Propose; Verify проверяет identity/type/evidence/validity/scope; Select создаёт compatible cut и ResolutionCore; Assemble канонизирует K_sem/K_id и, при authority, создаёт I/I_id. Runtime adapter ещё не выбран.

Post-issuance Bind поручает runtime/harness создать Binding Record. Перед действием authorization interface оценивает principal/action/resource по AuthorityCut(t)/PolicyCut(t); traces/outcomes могут инициировать Gap или Evolution Proposal, но не менять Contract.

Model + Harness + Meaning Management — ответственность, не identity: Model предлагает, Harness исполняет/наблюдает, Meaning Management фиксирует commitments. MCP, CLI, A2A, API, databases и adapters — runtime/harness. Ядро задаёт types, relations, invariants, closure, compatibility, provenance, versioning, validation, но не graph/database/transport/framework/provider/orchestrator.

V. Оценка и фальсификация

Экспериментальная программа

Полная единая спецификация HYP-001–009 и EXP-001–009 приведена в Приложении D.

Непроверенное ожидание. Ниже описан preregistration draft. Датасеты не заморожены, power analysis не выполнен, эксперименты не запускались. Ожидаемые направления не являются результатами.

Наборы и fixtures

D1 — Canonical task fixtures: Задачи исходного Research 17 corpus с вручную зафиксированными required artifacts, связями и допустимыми terminal states.
D2 — Adversarial semantic fixtures: Omissions, conflicting versions, malicious Policy, misleading retrieval, underspecified SuccessCriterion и plausible synthesized gaps.
D3 — Evolution histories: Цепочки successors, revocations, delayed evidence и historical replay points.
D4 — Transport and binding fixtures: Семантически эквивалентные и неэквивалентные CLI, API, MCP и A2A adapters с контролируемыми различиями эффектов.
D5 — Double-annotation corpus: Независимая экспертная разметка Role, Skill, Blueprint и четырёх operational/governance types.
D6 — External Naturalistic Task Corpus: Независимый от устройства Variant A будущий корпус с естественной неоднозначностью, недостающим знанием, конфликтами Policy и tool bindings. На момент semantic/preregistration freeze корпус D6 не собран; результаты отсутствуют.

Версия dataset требует digest, data statement, inclusion/exclusion rules, labels, adjudication log и frozen split. D1–D4 проверяют synthetic mechanics; D5 требует квалификации annotators и разрешения разногласий. D6 предстоит независимо собрать и preregister.

Сопоставимые baseline

B0 — Prompt-only: Контекст без typed artifacts и receipts.
B1 — Retrieval + planner: RAG и planner без contract cut.
B2 — Flat manifest: Точные версии без BKG closure, typed failures и отдельного Auth.
B3 — Workflow + policy engine: Workflow и policy-as-code без provenance-aware semantic selection.
B4 — Full proposed profile: Полная конструкция Meaning Management v1.

Task inputs, candidate universe, budgets и adapters одинаковы. Дополнительные retrieval calls или разметка учитываются как treatment cost; failures и abstentions остаются в denominator.

Ограниченный набор абляций B4

До запуска фиксируются четыре одиночные абляции; набор не является полным факторным планом. Остальные компоненты B4, входы и budgets сохраняются.

На узком экране таблица прокручивается по горизонтали.

Абляция	Что изолирует	Интерпретация
B4 без Resolution Receipt	Вклад decision provenance и diagnosability.	Меняются ли replay выбора, восстановление причин и диагностика при сохранении Contract и остальных проверок?
B4 без bounded BKG closure	Вклад structured bounded semantic resolution.	Меняются ли completeness, conflict detection, Search-Incomplete и стоимость при том же candidate universe?
B4 без отдельной Authorization	Вклад разделения semantic permission и runtime authority.	Меняются ли policy violations и ложные allow/deny, если Auth_t не отделён от Contract и Binding?
B4 без Evidence Profiles	Вклад risk/type-dependent admission governance.	Меняются ли false acceptance, abstention и human-review cost без профильных требований evidence?

Переменные и метрики

Независимые переменные: architecture condition B0–B4, task family, risk class, candidate noise, conflict density, graph depth, evolution distance, transport и authority change. Контрольные переменные: model/version, decoding, tool versions, time/retrieval budget, initial BKG snapshot и random seed, где он применим.

На узком экране таблица прокручивается по горизонтали.

Метрика	Определение	Единица	Агрегация	Направление	Ограничение
Resolution/context overhead	Дополнительные latency, model tokens, memory, graph operations и human-review time относительно сопоставимого baseline.	ms, tokens, bytes, graph operations, person-minutes	Median, tail quantiles и stratified paired difference по task/risk class.	Ниже при сохранении error/replay gain.	Нужны одинаковые task budget и candidate universe; first resolution и replay считаются отдельно.
Critical-error gain	Изменение частоты критических semantic, policy и binding errors относительно baseline.	percentage points и relative risk	По risk class с failures и abstentions в denominator.	Больше положительное сокращение ошибок.	Severity weighting и practically meaningful minimum должны быть заморожены до main outcomes.
Replay gain	Изменение доли повторов с тем же terminal state и раздельно R_id, K_id и I_id при frozen inputs соответствующего domain.	proportion и percentage-point difference	По identity domain и классу допустимого divergence.	Выше при неизменных frozen inputs.	Narrative drift не меняет R_id; issue metadata drift не должен менять K_id.
Search-Incomplete rate	Доля задач, закончившихся явным Search-Incomplete при объявленных bounds.	proportion	По bounds, risk class и graph depth.	Ниже без скрытого принуждения к Closed.	Нулевая доля может означать дефект наблюдаемости, а не полноту.
Assembly failure rate	Доля выбранных cuts, не выпущенных из-за canonicalization, Receipt, schema или Issue authority failure.	proportion по failure class	Раздельно technical assembly и Issue-Unauthorized.	Ниже при сохранении fail-closed semantics.	Issue-Unauthorized нельзя считать ошибкой сериализации или удалять из denominator.
Inter-annotator agreement	Согласие независимых экспертов по семи типам, relation types, conflicts и terminal states.	Cohen’s kappa либо Krippendorff’s alpha и confusion matrix	Коэффициент и confidence interval по заранее выбранному профилю.	Выше при отсутствии систематических смешений.	Метрика и lower bound выбираются до запуска; class imbalance анализируется отдельно.
Compatibility accuracy	Precision/recall совместимости semantic cuts и bindings против adjudicated fixtures.	precision, recall, false-accept rate	По типам relation, adapter effects и risk class.	Выше precision/recall и ниже false accepts.	Совпадение interface name или transport не доказывает semantic compatibility.
Governance false-positive rate	Доля допустимых публикаций, выпусков, bindings или действий, ошибочно отклонённых governance profile.	proportion	По decision surface и risk class.	Ниже без тривиального разрешения всего.	Нужно отличать governance reject от technical failure и считать human-review cost.
Governance false-negative rate	Доля недопустимых публикаций, выпусков, bindings или действий, ошибочно разрешённых governance profile.	proportion с severity weighting	По decision surface, risk class и consequence class.	Ниже.	Средняя доля без severity может скрыть редкие критические ошибки.

Пороги для preregistration

Численные пороги ниже намеренно не выбраны. Их следует зафиксировать до первого основного запуска на основании pilot data, power analysis, стоимости ошибок и risk appetite. После просмотра основных outcomes менять порог нельзя без регистрации новой гипотезы.

На узком экране таблица прокручивается по горизонтали.

Показатель	Статус порога	Что должно быть заморожено до запуска
Resolution/context overhead	TBD before preregistration	Нужны одинаковые task budget и candidate universe; first resolution и replay считаются отдельно.
Critical-error gain	TBD before preregistration	Severity weighting и practically meaningful minimum должны быть заморожены до main outcomes.
Replay gain	TBD before preregistration	Narrative drift не меняет R_id; issue metadata drift не должен менять K_id.
Search-Incomplete rate	TBD before preregistration	Нулевая доля может означать дефект наблюдаемости, а не полноту.
Assembly failure rate	TBD before preregistration	Issue-Unauthorized нельзя считать ошибкой сериализации или удалять из denominator.
Inter-annotator agreement	TBD before preregistration	Метрика и lower bound выбираются до запуска; class imbalance анализируется отдельно.
Compatibility accuracy	TBD before preregistration	Совпадение interface name или transport не доказывает semantic compatibility.
Governance false-positive rate	TBD before preregistration	Нужно отличать governance reject от technical failure и считать human-review cost.
Governance false-negative rate	TBD before preregistration	Средняя доля без severity может скрыть редкие критические ошибки.

Фальсифицируемые гипотезы

Матрица связывает девять гипотез с девятью отдельными протоколами. Численные границы остаются TBD до pilot, power analysis и preregistration; HYP-004 и HYP-006 проверяются как детерминированные свойства.

На узком экране таблица прокручивается по горизонтали.

Гипотеза / протокол	Исследовательский вопрос	Ожидаемое направление	Условие фальсификации
HYP-001 · EXP-001 Completeness	Повышает ли B4 полноту корректного semantic cut относительно retrieval/flat-manifest baselines?	Выше precision/recall без роста конфликтующих включений.	Preregistered margin/gain не достигнут либо эффект исчезает на holdout.
HYP-002 · EXP-002 Policy safety	Снижает ли разделение Contract, Binding и Auth_t число hard-policy violations?	Ниже violations и governance false negatives.	Нет preregistered reduction либо появляется privilege amplification.
HYP-003 · EXP-003 Replay	Повышают ли отдельные ResolutionCore, Contract и issuance identities воспроизводимость решений?	Выше replay каждого frozen identity domain без cross-domain drift.	Issue metadata меняет K_id, narrative меняет R_id или frozen domain не воспроизводится.
HYP-004 · EXP-004 Revocation without history rewrite	Сохраняются ли historical bytes при изменении текущей authority?	Historical identity stable; revoked action is not allowed.	Любое изменение historical bytes либо Allow после effective revocation.
HYP-005 · EXP-005 Conflict diagnostics	Улучшает ли typed Select plus Receipt воспроизводимую диагностику конфликтов и gaps?	Выше reconstruction adequacy и gap precision/recall.	Конфликт не восстанавливается либо диагностика не превосходит baseline.
HYP-006 · EXP-006 Bounded recursion	Завершается ли BKG traversal в bounds с честным terminal state?	Termination within B and explicit Search-Incomplete when closure is not established.	Timeout/overrun, hidden incompleteness или forced Closed.
HYP-007 · EXP-007 Transport equivalence	Улучшает ли semantic BindingCut распознавание эквивалентных и неэквивалентных providers?	Выше compatibility precision/recall и ниже false accepts.	Несовместимый adapter принят либо effects расходятся.
HYP-008 · EXP-008 Cost	Оправдан ли overhead B4 наблюдаемым error/replay gain?	Не задано; приемлемость зависит от preregistered risk-class trade-off.	Overhead превышает gain либо B2/B3 эквивалентен дешевле.
HYP-009 · EXP-009 Ontology agreement	Повышают ли правила Variant A межэкспертное согласие по типам и запрещённым слияниям?	Выше agreement и меньше systematic conflations.	Низкое agreement либо устойчивое смешение типов.

Анализ и отчётность

До запуска нужно заморозить primary/secondary outcomes, margins, sample size, stopping rules и exclusion policy. Для rates следует публиковать effect size и confidence interval, а не только p-value. Для каждого seed и failed run сохраняются inputs, terminal state, receipts и logs с безопасной редактировкой секретов. Analysis script, schemas, container/toolchain identities и raw denominators входят в replication package.

Качественные условия отклонения применяются независимо от того, какие числа позднее будут выбраны.

Нет материального сокращения критических semantic, policy или binding errors.
Resolution/context overhead чрезмерен относительно предотвращённых ошибок.
Независимые annotators не достигают устойчивого согласия.
Search-Incomplete систематически сохраняется на naturalistic tasks при разумных bounds.
Frozen inputs не воспроизводят terminal state и соответствующий R_id/K_id/I_id.
Стоимость и ошибки governance превышают наблюдаемые gains.
B2 или B3 даёт эквивалентные гарантии существенно дешевле.

Любой из этих результатов требует упростить или отвергнуть соответствующую часть B4, а не менять метрику после анализа. Отсутствие заранее выбранных чисел в текущей статье является ограничением preregistration draft, а не разрешением интерпретировать любой outcome как успех.

VI. Обсуждение и ограничения

Обсуждение

Что архитектура формально задаёт: Различия available context/selected commitment, semantic Contract/issuance, Contract/Binding/Auth, Expansion/Evolution; identity и lifecycle записей; допустимые terminal states и историческую фиксацию точных версий.
Что остаётся гипотезой: Снижение critical errors, улучшение replay и диагностики, приемлемая стоимость, естественная обобщаемость и преимущество B4 над baseline.
Что намеренно вне области: Human-like meaning, AGI control plane, полный operational replay открытого мира и выбор конкретных storage, graph, policy, transport, framework или model technologies.
Что может быть упрощено: Receipt, bounded closure, отдельная authorization или Evidence Profiles должны быть сокращены либо исключены, если preregistered ablations не покажут собственного вклада или стоимость превысит измеримый выигрыш.

Управление смыслами переносит скрытую prompt-интеграцию в types, relations, receipts, versions и terminal states. Это полезно только при более раннем обнаружении или лучшем объяснении ошибок; записи без снижения существенных нарушений — административная нагрузка. Тяжесть профиля зависит от риска: read-only задача со стабильным Skill допускает малый Contract/binding, а внешние эффекты и несколько principals требуют подробных receipts и segregation of duties.

Ошибка retrieval относится к Propose, semantic/evidence/version/policy deficit — к GapKind, scope mismatch — к Verify/Select, issuer authority — к Assemble, BindingGap — к Bind/Unbound, revocation — к Auth. Authority failure не является Gap. Цена различимости — combinatorial BKG и governance surface; плохое agreement отвергает усложнённую ontology.

На узком экране таблица прокручивается по горизонтали.

Тип утверждения	Текущий статус
Архитектурная декомпозиция	Предложена и формально специфицирована.
Модель идентичности	Формально специфицирована.
Жизненный цикл разрешения	Формально специфицирован.
Исторический semantic replay	Производное свойство при зафиксированных входах.
Снижение critical errors	Гипотеза.
Улучшение диагностики	Гипотеза.
Приемлемая стоимость	Гипотеза.
Обобщение на naturalistic tasks	Открытый эмпирический вопрос.

Ограничения

Нет implementation или outcomes. API, schemas, solver, девять гипотез и девять протоколов не исполнены; D6 не собран.
Solver properties не доказаны. Soundness, completeness и complexity открыты; bounded search допускает Search-Incomplete.
Review purposive. Корпус может пропустить близкую или новую систему.
Ontology и governance неполны. Нужны независимая разметка, risk-specific authority, thresholds и retention.
Open world ограничивает вывод. Ненайденный provider может существовать; receipts не гарантируют outcome replication.
Графика неоднородна. Приватный корпус — 63 raw images; Main — 13 схем, register — 14, публичный атлас — 62. Нормативен текст.

Открытый мир. Search-Incomplete является допустимым результатом; отсутствие найденного объекта не доказывает его отсутствие, а архитектура не гарантирует полноту поиска в открытом мире.

Будущие исследования

Программа включает executable serialization/schema/hash/fixtures; независимый naturalistic D6; сравнение purpose-built BKG с RDF/SHACL; authority profiles; semantic binding; composition Contracts; privacy-preserving receipts; сравнение memory/RAG с BKG resolution. Poincaré embeddings, MCP, CLI и A2A остаются вариантами indexing/binding/transport.

Композиции смысловых артефактов более высокого порядка

Ненормативное направление будущего исследования. Variant A не расширяется. Competency — higher-order domain concept, представляющий заявленную или подтверждаемую способность субъекта выполнять определённый класс профессиональной работы в заданном контексте и до требуемого стандарта качества. Верифицированное утверждение о Competency требует отдельно определённого Competency Evidence. Competency может компоновать Roles, Skills, Blueprints, Constraints, Policies, SuccessCriteria, CapabilityDescriptions и требования к evidence. Profession — устойчивый широкий класс профессиональной деятельности, а не Role и не просто переиспользуемый контекст.

На узком экране таблица прокручивается по горизонтали.

Понятие	Основной вопрос	Граница в этой версии
Profession	К какому устойчивому широкому классу профессиональной деятельности относится работа?	Будущий внешний слой; Profession ≠ Role.
Role	Какая ответственность и область решений принимаются в этом контексте?	Управляемый артефакт Variant A; не профессия и не authority.
Competency	Способен ли субъект выполнять определённый класс профессиональной работы в заданном контексте и до требуемого стандарта?	Будущая evidence-aware композиция; Skill ≠ Competency.
Skill	Как выполняется конкретная операция или класс операций?	Управляемый артефакт Variant A; наличие ссылки не доказывает Competency.
Capability	Может ли runtime реализовать требуемую операцию?	CapabilityType выводится из CapabilityDescription; Capability ≠ Competency.
Blueprint	Какой управляемый паттерн направляет работу?	Управляемый артефакт Variant A, а не профессия или профиль субъекта.
Agent/Worker	Кто или что выполняет работу?	Не смысловой артефакт, Role, Profession, Competency или Contract.
Knowledge Contract	Какие смысловые обязательства управляют этим исполнением задачи?	Task-specific исполнимая спецификация, а не CV, профиль или паспорт.

Компактный пример. Profession Lawyer; Competency Commercial Contract Review; Role Contract Reviewer; Skills Clause Extraction, Legal Interpretation, Risk Classification; Blueprint Commercial Contract Review; Policy определяется юрисдикцией; SuccessCriteria измеряют coverage и risk detection; Evidence состоит из валидированных результатов review. Ссылка на Skill не доказывает Competency: Artifact Evidence подтверждает артефакт, Competency Evidence — заявленную композицию и уровень.

AgentProfile/WorkerProfile и CompetencyProfile остаются возможными внешними профилями. Связи образуют типизированный many-to-many graph, не строгую иерархию. Knowledge Contract остаётся task-specific исполнимой смысловой спецификацией и не является CV, профилем или паспортом.

Не выбраны matching-модели «точная профессия», «композиция компетенций» или «прямой task cut»; их следует сравнить эмпирически. Profession Repository не входит в v1: возможная профессиональная база знаний является отдельным верхним слоем и потенциальной областью применения, а не marketplace, pricing model или новым ядром архитектуры.

Семантика.: Как выбирать representation для Competency; как задавать proficiency и domain; как учитывать recency, decay и revalidation?
Evidence и субъекты.: Как отделять Artifact Evidence, подтверждающее управляемый артефакт, от Competency Evidence для верифицированного утверждения о компетентности человека, ИИ-системы или гибридного субъекта?
Профессиональная композиция и сопоставление.: Как Profession, CompetencyProfile, WorkerProfile и BKG участвуют в композиции и когда именно выполнять matching относительно Resolver и выпуска Knowledge Contract?

Открытые исследовательские вопросы

Authority: как связать AuthorityCut(t), PolicyCut(t), AuthorityGrant, delegation, revocation, human authority и segregation без скрытого переноса IAM внутрь Contract?
Evidence: какие проверки достаточны для каждой пары «тип × риск»?
Receipt: как канонизировать identity, uncertainty, Search-Incomplete и privacy?
Falsification: какие gains, overhead/error limits, sample size и stopping rules preregister?
Governance independence: что предотвращает producer self-approval и conflict of interest?
CapabilityType: когда independent ownership/governance/version/lifecycle оправдают promotion?
Composition/disclosure: как проверять межконтрактные конфликты и digests/Policy без раскрытия secret, personal data или hidden reasoning?

VII. Заключение

Полученный концептуальный результат. Предложенная модель отделяет available context от selected semantic commitment; фиксирует выбор через Resolution Receipt; разделяет Knowledge Contract и issuance; отделяет semantic Contract от Binding, а Binding — от runtime Authorization. Reusable artifacts получают identity, versioning, governance и provenance; Expansion отделена от Evolution; исторические смысловые обязательства могут быть pinned и replayed при сохранённых предпосылках.

Не полученный эмпирический результат. Пока не установлены снижение critical execution errors, улучшение replayability и diagnosability, приемлемость overhead или превосходство B4 относительно baseline. Девять протоколов остаются пререгистрационной спецификацией без outcomes.

Практическая ценность этой декомпозиции должна быть проверена экспериментально; при отсутствии измеримого выигрыша соответствующие механизмы должны быть упрощены или отвергнуты. Основной научный результат работы — путь от доступного знания к выбранному смысловому обязательству, от обязательства к конкретной реализации и от реализации к разрешённому действию, сделанный явным, версионируемым, объяснимым и аудируемым и представленный как формально заданный объект исследования, а не как эмпирически подтверждённое превосходство.

Источники

Корпус ограничен непосредственно релевантными научными работами и официальными спецификациями, проверенными в этом цикле; ссылки ведут к авторам, издателям или органам стандартизации.

Prompt engineering · класс: Direct. P. Liu, W. Yuan, J. Fu, Z. Jiang, H. Hayashi, G. Neubig. Pre-train, Prompt, and Predict: A Systematic Survey of Prompting Methods in Natural Language Processing. ACM Computing Surveys 55(9), 2023. DOI 10.1145/3560815. Научная работа или официальная спецификация. Использовано здесь: Систематизирует prompt-based learning и способы задания задачи текстовым шаблоном; не задаёт управляемый versioned semantic cut.
In-context learning · класс: Direct. T. Brown et al. Language Models are Few-Shot Learners. Advances in Neural Information Processing Systems 33, 2020. Научная работа или официальная спецификация. Использовано здесь: Демонстрации и инструкции задаются в inference context без изменения параметров; принятие, версия и власть не становятся отдельными объектами.
In-context learning · класс: Direct. S. Min et al. Rethinking the Role of Demonstrations: What Makes In-Context Learning Work? EMNLP 2022, pp. 11048–11064. DOI 10.18653/v1/2022.emnlp-main.759. Научная работа или официальная спецификация. Использовано здесь: Показывает, что формат, input distribution и label space могут влиять сильнее соответствия labels; это подчёркивает риск приравнивания доступного контекста к принятому смыслу.
Retrieval-augmented generation · класс: Direct. P. Lewis et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Advances in Neural Information Processing Systems 33, 2020. Научная работа или официальная спецификация. Использовано здесь: Соединяет parametric и non-parametric memory и retrieved passages; релевантность retrieval не является governance-принятием обязательства.
Agent planning and action · класс: Direct. S. Yao et al. ReAct: Synergizing Reasoning and Acting in Language Models. ICLR 2023. Научная работа или официальная спецификация. Использовано здесь: Чередует reasoning traces и действия с внешней средой; не выпускает независимый immutable contract с versioned authority boundary.
Multi-agent systems · класс: Direct. G. Li, H. A. K. Hammoud, H. Itani, D. Khizbullin, B. Ghanem. CAMEL: Communicative Agents for “Mind” Exploration of Large Language Model Society. NeurIPS 2023. Научная работа или официальная спецификация. Использовано здесь: Role-playing и communicative cooperation формируют поведение агентов; роли остаются prompt-level механизмом, а не independently governed artifact graph.
Multi-agent orchestration · класс: Direct. Q. Wu et al. AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversations. Conference on Language Modeling, 2024. Научная работа или официальная спецификация. Использовано здесь: Conversable agents, roles, capabilities, tools и conversation programming; не определяет общий resolver lifecycle и исторически закреплённый semantic cut.
Agent memory · класс: Direct. J. S. Park et al. Generative Agents: Interactive Simulacra of Human Behavior. UIST 2023. DOI 10.1145/3586183.3606763. Научная работа или официальная спецификация. Использовано здесь: Observation, memory retrieval, reflection и planning поддерживают длительное поведение; память не равна утверждённому набору task obligations.
Agent memory · класс: Direct. C. Packer et al. MemGPT: Towards LLMs as Operating Systems. arXiv:2310.08560, v2, 2024. Научная работа или официальная спецификация. Использовано здесь: Virtual context management перемещает материал между memory tiers; доступность материала не решает его evidence, compatibility или authority status.
Knowledge graphs and ontologies · класс: Direct. A. Hogan et al. Knowledge Graphs. ACM Computing Surveys 54(4), Article 71, 2021. DOI 10.1145/3447772. Научная работа или официальная спецификация. Использовано здесь: Обобщает graph data models, schema, identity, context, deduction, quality и evolution; BKG-профиль добавляет task-specific resolution и contract issuance.
Knowledge graphs and ontologies · класс: Supporting. W3C. Shapes Constraint Language (SHACL). W3C Recommendation, 20 July 2017. Научная работа или официальная спецификация. Использовано здесь: Определяет shapes и validation reports для RDF graphs; пригоден для части Verify, но не выбирает task cut и не выдаёт контракт.
Provenance · класс: Supporting. T. Lebo, S. Sahoo, D. McGuinness, eds. PROV-O: The PROV Ontology. W3C Recommendation, 30 April 2013. Научная работа или официальная спецификация. Использовано здесь: Представляет Entities, Activities, Agents и provenance relations; candidate set, bounds, alternatives, Search-Incomplete и immutable Resolution Receipt остаются прикладным профилем этой архитектуры.
Workflow languages · класс: Direct. P. Amstutz et al. Methods Included: Standardizing Computational Reuse and Portability with the Common Workflow Language. Communications of the ACM 65(6), 2022. Научная работа или официальная спецификация. Использовано здесь: CWL описывает переносимые command-line tools и directed workflows; semantic commitments и полномочия до исполнения находятся вне его основного объекта.
Workflow languages · класс: Supporting. Object Management Group. Business Process Model and Notation (BPMN), version 2.0.2. Formal specification, 2014. Научная работа или официальная спецификация. Использовано здесь: Стандартизирует процессы, collaborations и choreographies; не разрешает неоднородное знание в immutable task contract.
Software architecture · класс: Supporting. ISO/IEC/IEEE 42010:2022. Software, systems and enterprise — Architecture description. Second edition, 2022. Научная работа или официальная спецификация. Использовано здесь: Задаёт требования к architecture descriptions, viewpoints и model kinds; Blueprint в этой работе является versioned reusable input to resolution, а не всей architecture description.
Software architecture · класс: Direct. P. Clements et al. Documenting Software Architectures: Views and Beyond. Second edition. Addison-Wesley / Carnegie Mellon SEI, 2010. Научная работа или официальная спецификация. Использовано здесь: Связывает views, interfaces, behavior и rationale в документационный пакет; не задаёт runtime semantic resolver или action authorization.
Policy-as-code · класс: Supporting. Open Policy Agent Project. Policy Language: Rego. Official language documentation. Научная работа или официальная спецификация. Использовано здесь: Декларативно оценивает rules над structured input/data; является возможным механизмом Verify/Auth, но не формирует semantic cut, Resolution Receipt или Knowledge Contract.
Policy-as-code · класс: Supporting. Cedar Policy Project. Cedar Policy Language Reference Guide, version 4.5. Научная работа или официальная спецификация. Использовано здесь: Решение по principal, action, resource и context прямо поддерживает action-specific authorization boundary; AuthorityCut(t), semantic selection и binding остаются отдельными конструкциями.
Reproducible systems · класс: Supporting. Reproducible Builds Project. Making plans for reproducible builds. Official project documentation. Научная работа или официальная спецификация. Использовано здесь: Фиксирует source, environment, instructions и comparison protocol; статья переносит дисциплину точных входов на semantic assembly, не приравнивая runtime outcome к byte identity.
Governance · класс: Supporting. National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, 2023. Научная работа или официальная спецификация. Использовано здесь: Описывает govern/map/measure/manage для AI risk; не задаёт Evidence Profiles по artifact type × risk class, versioned artifact calculus или Resolver.
Semantic service descriptions · класс: Supporting. OWL Services Coalition. OWL-S: Semantic Markup for Web Services. W3C Member Submission, 2004. Научная работа или официальная спецификация. Использовано здесь: Различает service profile, process model и grounding; это полезный предшественник разделения CapabilityDescription, abstract type и concrete binding.
Knowledge graphs and ontologies · класс: Supporting. R. Cyganiak, D. Wood, M. Lanthaler, eds. RDF 1.1 Concepts and Abstract Syntax. W3C Recommendation, 25 February 2014. Научная работа или официальная спецификация. Использовано здесь: Даёт графовую модель triples и datasets; версии, authority, compatibility и contract identity требуют прикладного профиля поверх неё.

Приложение A. Формальная спецификация управляемого артефакта

Назначение. Задать минимальные свойства объекта, позволяющие считать его управляемым смысловым артефактом в Meaning Management v1.

Область. Нормативное ядро охватывает семь типов Variant A; concrete serialization, repository layout и transport остаются вариантами реализации.

Связь с основной статьёй. Приложение конкретизирует терминологию и онтологию управляемых артефактов и не вводит дополнительных нормативных требований к архитектуре.

Нормативное содержание. Поля и различия ниже относятся к профилю v1. Примеры конкретных значений помечены как иллюстративные и не образуют обязательный wire format.

A.1. Generic Managed Artifact

Управляемый артефакт является семантическим объектом, а не способом его хранения. Его нормативное ядро содержит следующие поля:

artifact_id
artifact_type
version
content_identity
schema_version
status
provenance
evidence_profile
compatibility
governance_status
created_at
supersedes
derived_from

На узком экране таблица прокручивается по горизонтали.

Класс	Содержимое	Архитектурный статус
Normative core fields	Identity, type, version, content identity, schema, lifecycle status, provenance, evidence, compatibility, governance, time и lineage.	Обязательны по смыслу; конкретное кодирование определяется interoperability profile.
Implementation-specific metadata	Storage URI, database key, cache hint, index embedding, UI label, transport locator и local retention marker.	Не меняют архитектуру и не становятся частью content identity без явного profile decision.

A.2. Artifact Identity

Logical artifact identity: Стабильная линия объекта, например role:api-maintainer, объединяющая совместимые версии.
Artifact version: Неизменяемая опубликованная ревизия этой линии, например @2.1.0. Successor сосуществует с предшественником и связывается через supersedes.
Content identity: Digest канонических байтов конкретной версии. Изменение содержимого создаёт другой digest независимо от человекочитаемой версии.

Опубликованная версия immutable. Статусы deprecated, superseded и, где safety profile это поддерживает, revoked изменяют применимость, но не переписывают её прежние байты и historical Contract references. Полная семантика withdrawal остаётся открытым исследованием, если runtime safety требует различать эти статусы сильнее.

A.3. Artifact Types

На узком экране таблица прокручивается по горизонтали.

Тип	Класс Variant A
`Role`	Первичный переиспользуемый смысловой артефакт
`Skill`	Первичный переиспользуемый смысловой артефакт
`Blueprint`	Первичный переиспользуемый смысловой артефакт
`Constraint`	Дополнительный типизированный операционный/управленческий артефакт
`Policy`	Дополнительный типизированный операционный/управленческий артефакт
`SuccessCriterion`	Дополнительный типизированный операционный/управленческий артефакт
`CapabilityDescription`	Дополнительный типизированный операционный/управленческий артефакт

CapabilityDescription — managed и versioned; CapabilityType — derived representation, получаемая нормализацией. Отношение имеет направление CapabilityDescription → normalization/derivation → CapabilityType, а не равенство. Возможная будущая promotion требует независимых ownership, governance, version и lifecycle и не входит в v1.

A.4–A.9. Сквозной иллюстративный пример

Сконструированный иллюстративный пример. Задача task:protected-endpoint-change:2026-08 требует изменить защищённый административный endpoint, не меняя публичный API contract, и проверить authorization, validation, отрицательные сценарии и audit evidence. Это не empirical dataset и не измеренный outcome.

На узком экране таблица прокручивается по горизонтали.

Тип	Иллюстративная точная ссылка
`Role`	`role:api-maintainer@2.1.0`
`Skill`	`skill:modify-protected-endpoint@3.0.1`
`Blueprint`	`blueprint:protected-endpoint-authorization@4.2.0`
`Constraint`	`constraint:public-api-compatibility@1.4.0`
`Policy`	`policy:current-explicit-admin-authorization@5.0.0`
`SuccessCriterion`	`success:protected-endpoint-security-regression@2.0.0`
`CapabilityDescription`	`capability:source-code-modification-and-test@1.3.0`

A.4. Role

Responsibility: Сохранить архитектурную целостность защищённого endpoint и передать проверяемое изменение.
Decision scope: Выбор допустимого patch внутри указанного endpoint и связанных security tests; изменение публичного API исключено.
Ownership: Линия артефакта принадлежит governed namespace архитектурных ролей.
Governance boundaries: Role не публикует собственную версию, не выдаёт credentials и не принимает runtime authorization decision.
Compatibility: Совместима с Blueprint major 4 и Skill major 3 при выполненном Evidence Profile.
Version and provenance: role:api-maintainer@2.1.0; source, producer, verifier и publication event адресуются отдельно.

Role ≠ Authority. Право principal изменить endpoint появляется только через AuthorityCut(t), PolicyCut(t) и Auth_t в Appendix C.

A.5. Skill

skill:modify-protected-endpoint@3.0.1 задаёт reusable procedure: принять task diff и frozen contract references; проверить preconditions; подготовить минимальное изменение; выполнить validation и negative tests; вернуть patch, test evidence и failure class. Required abstract capabilities — чтение и модификация исходного кода, запуск scoped tests и формирование audit evidence. CLI, MCP server, API client и vendor SDK отсутствуют в Skill и выбираются позднее Binding.

A.6. Blueprint

blueprint:protected-endpoint-authorization@4.2.0 описывает framework-neutral architectural pattern: authentication до защищённой операции; explicit permission enforcement; authorization guard; fail-closed denial; validation boundary; audit event; positive и negative test cases. Dependencies указывают на Role, Skill, Policy, Constraint, SuccessCriterion и CapabilityDescription точными version constraints. Blueprint не объявляет конкретную middleware library и не является authority grant.

A.7. Policy / Constraint Contrast

На узком экране таблица прокручивается по горизонтали.

Объект	Иллюстративное содержание	Функция
Policy	Protected administrative endpoints require explicit authorization evaluated against current authority and policy state.	Задаёт правило принятия governance/runtime decision и его применимость.
Constraint	Публичные request/response schemas и documented status codes endpoint нельзя изменять в этой задаче.	Ограничивает допустимое пространство решений независимо от того, кто имеет право их выполнить.

Policy ≠ Constraint. Policy отвечает на вопрос о применимом решении; Constraint — о допустимой форме композиции или результата.

A.8. SuccessCriterion

На узком экране таблица прокручивается по горизонтали.

Проверяемое обязательство	Evidence requirement	Validation method
Неавторизованный principal получает denial.	Negative-test trace и authorization decision record.	Вызов с frozen denied AuthorityCut/PolicyCut; outcome не Allow.
Авторизованный principal проходит до domain operation.	Positive-test trace и action-specific Allow.	Вызов с frozen allowed cuts и валидным Binding.
Публичный API contract не изменён.	Schema diff и compatibility report.	Сравнение frozen API snapshot до/после.
Security regression suite проходит.	Версия harness, test list и raw outcomes.	Все mandatory cases проходят; skipped cases сохраняются как failure evidence.
Audit evidence выпущено.	Decision identity, trace digest и retention receipt.	Schema validation и проверка ссылок K_id/B_id/cuts/time/reason.

A.9. CapabilityDescription and Evidence Profile

capability:source-code-modification-and-test@1.3.0 описывает inputs, outputs, effects, failure classes и trust properties абстрактной способности. Нормализация выводит capability-type:repository-change-with-protected-endpoint-tests. Concrete provider появляется только в BindingCut.

Artifact type × risk class: Blueprint/Skill/Policy для security-sensitive endpoint.
Required evidence: Provenance, independent verifier, executable tests, negative scenarios, compatibility report и current Policy review.
Independence: Producer self-approval недостаточен; verifier и publisher должны соответствовать governance profile.
Thresholds: Не задан универсальный confidence threshold; численные границы остаются empirical/governance research.

Ограничения. Объекты выше не являются стандартизованными JSON/YAML schemas; illustrative identifiers не обещают существующий repository или runtime. Security остаётся эмпирическим свойством реализации.

Итог. Управляемые артефакты независимо идентифицируются, версионируются, регулируются и сохраняют provenance. Knowledge Contract ссылается на точные совместимые версии, а не дублирует их семантическое содержание.

Приложение B. Сквозной пример семантического разрешения

Назначение. Показать полный переход от доступного контекста к Resolution Receipt, semantic Contract и отдельному IssueRecord.

Область. Пример заканчивается выпуском; runtime binding и authorization рассматриваются только в Appendix C.

Связь с основной статьёй. Приложение операционализирует Knowledge Resolver, Resolution Receipt и Knowledge Contract и не вводит дополнительных нормативных требований.

Сконструированный иллюстративный пример. Используется та же task identity и те же семь artifact lines, что в Appendix A. Значения identifiers показывают структуру решения, но не являются measured evidence.

B.1–B.2. Example Task and Available Context

Agent должен изменить api:/v1/admin/accounts/{account_id}, сохранив публичный contract, validation, authorization guard, negative tests и audit evidence. Available Context содержит approved repository records, старые versions, retrieved notes, model proposal и runtime tool catalog.

Available Context ≠ Selected Commitment. Материал может быть доступен, релевантен и даже формально корректен, но не войти в task cut из-за версии, compatibility, scope, evidence или conflict.

Approved records: Точные версии семи артефактов Appendix A и их typed relations.
Historical records: Role 1.8, Skill 2.4 и Blueprint 3.9, оставленные для replay, но не совместимые с текущими requirements.
Retrieved context: Design note для публичного read-only endpoint; терминологически близка, но task-irrelevant.
Model output: Proposal пропустить negative authorization test как «избыточный»; provenance and evidence отсутствуют.
Runtime catalog: CLI, MCP и internal adapters; наличие provider ещё не входит в semantic selection.

B.3. Propose

На узком экране таблица прокручивается по горизонтали.

Candidate	Тип / версия	Источник	Предварительный статус
R-new	Role 2.1.0	Approved governed namespace.	Проверить.
R-old	Role 1.8.0	Historical snapshot.	Outdated для Blueprint major 4.
S-new	Skill 3.0.1	Approved governed namespace.	Проверить.
S-fast	Skill proposal 3.1.0-rc	Model synthesis.	Insufficient evidence; producer self-approval.
B-protected	Blueprint 4.2.0	Approved architecture namespace.	Проверить closure.
B-public-read	Blueprint 5.0.0	Другой namespace.	Incompatible action/effects.
P-legacy	Policy 4.7.0	Historical policy set.	Conflicts with current explicit authorization Policy.

B.4. Verify

Verify воспроизводимо проверяет identity/digest, version, provenance, Evidence Profile, type/relation schema, compatibility, applicable Policy и authority to publish/use where profile requires it. Candidate не получает trust из одного высокого model score.

R-new, S-new, B-protected и четыре operational/governance references проходят schema, evidence и compatibility.
R-old остаётся исторически валидным, но не удовлетворяет version constraint текущего Blueprint.
S-fast помещён в quarantine: нужные independent tests и verifier отсутствуют.
B-public-read отклонён по несовпадающим action/effect requirements.
P-legacy сохраняется как рассмотренная версия, но precedence profile указывает current Policy 5.0.0.

B.5. Select

Select применяет hard constraints до ranking. Search bounds ограничены approved namespace, historical lineage выбранных candidates, depth 4, node budget 120 и provider budget 3; эти значения иллюстративны и не объявлены универсальными defaults. Выбраны точные семь references Appendix A. Отклонения записаны reason codes VERSION_INCOMPATIBLE, EVIDENCE_INSUFFICIENT, EFFECT_MISMATCH и SUPERSEDED_BY_APPLICABLE_POLICY. Остаточная неопределённость: external repository вне bounds не обследован; Search-Incomplete=false относится только к объявленным bounds.

B.6. SemanticCut

SemanticCut(q,r) содержит семь exact artifact references, обязательные typed edges, exclusions для публичного API change и обхода authorization, а также unresolved declaration о concrete runtime provider. Ни один отвергнутый candidate и никакой narrative rationale в cut не включены.

B.7. ResolutionCore

На узком экране формула прокручивается по горизонтали.

ResolutionCore = canon(candidate_ids, search_bounds, selected_versions, rejection_reason_codes, precedence, conflicts, uncertainty, Search-Incomplete, policy_ids)

На узком экране формула прокручивается по горизонтали.

R_id = H(bytes(ResolutionCore))

B.8. Resolution Receipt

Candidate Set: Точные identities R-new/R-old, S-new/S-fast, B-protected/B-public-read, Policy versions и required operational artifacts.
Verification Results: Verdicts, validator versions, evidence identities и scope checks для каждого candidate.
Selected Commitments: Семь exact references Appendix A и closure edges.
Rejected Alternatives: R-old, S-fast, B-public-read и P-legacy.
Reason Codes and Precedence: Machine-readable codes и current-approved precedence rule.
Conflicts and Resolution: Legacy Policy conflict разрешён выбором applicable approved version; bypass proposal исключён hard constraint.
Search Bounds: Namespaces, lineage, depth, node/provider budgets и момент остановки.
Uncertainty State: Неисследованные sources вне bounds не объявляются отсутствующими.

Explanation = narrative(decision_summary, audience_profile, redactions) может иметь отдельный E_id. Перевод или редактура Explanation не изменяет R_id; core и explanation сверяются на отсутствие смыслового расхождения.

B.9. Knowledge Contract

На узком экране формула прокручивается по горизонтали.

K_sem = canon(q_id, G_r[SemanticCut(q,r)], obligations, exclusions, R_id, schema_version) K_id = H(bytes(K_sem))

K_sem содержит task identity, exact Role/Skill/Blueprint/Constraint/Policy/SuccessCriterion/CapabilityDescription references, required graph edges, obligations, exclusions, R_id и schema version. Он содержит ссылки, а не копии artifact content; issuer, timestamp, signature, runtime adapter и current authority отсутствуют.

B.10. Issue Event

На узком экране формула прокручивается по горизонтали.

I = canon(K_id, issuer, authority_evidence, timestamp, signature, issuance_schema_version) I_id = H(bytes(I))

K_id ≠ I_id. IssueRecord фиксирует K_id, issuer principal, issuance authority evidence, timestamp, optional signature и issuance schema. Повторный authorized issue тех же K_sem bytes другим issuer или в другое время создаёт новый I_id, но не меняет K_id и не создаёт новый semantic Contract.

B.11. Rejection Example

Если S-fast — единственный Skill в bounds, Verify возвращает Insufficient-Evidence. Если B-protected и current Policy несовместимы без precedence resolution, Select возвращает Conflict. Если budget исчерпан до closure, результат — Search-Incomplete. Во всех трёх случаях Contract и IssueRecord не создаются; система не форсирует closure.

Ограничения. Digest literals сокращены и не являются вычисленными hashes; bounds и reason-code vocabulary иллюстративны. Propose может быть stochastic, а детерминированность начинается с frozen candidate set, inputs, rules и canonicalization profile.

Итог. Context → Candidates → Verified Candidates → SemanticCut → ResolutionCore/R_id → K_sem/K_id → IssueRecord/I_id. Каждая стрелка обозначает проверяемую границу, а не автоматическое доверие.

Приложение C. Пример связывания и авторизации исполнения

Назначение. Продолжить тот же пример после выпуска и показать независимость Contract, Binding и action-specific Authorization.

Область. Appendix C использует существующие K_id/I_id и не повторяет Resolution; IAM internals и конкретный transport не формализуются.

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

Сконструированный иллюстративный пример. Входами являются digest:K-protected-endpoint-v1 и digest:I-protected-endpoint-issue-01. Semantic commitments не пересобираются.

C.1–C.2. Input and BindingCut

BindingCut(K_id,e) рассматривает providers для derived CapabilityType repository-change-with-protected-endpoint-tests в environment staging:api-service@2026-08.

На узком экране таблица прокручивается по горизонтали.

Provider	Transport	Semantic/effect evidence	Verdict
repository-change-adapter@7.2	Internal API	Supports scoped patch, frozen tests, audit output и no-deploy effect.	Выбран.
maintenance-cli@4.6	CLI	Эквивалентные patch/test effects, но environment policy запрещает interactive credential path.	Compatible semantics; ineligible environment.
generic-mcp-editor@2.0	MCP	Нет доказательства negative-test coverage и resource-scope enforcement.	Evidence-Insufficient.

Ни один transport не является нормативным. Смена provider при неизменных semantic commitments не меняет K_id; она создаёт другой BindingCut/B_id.

C.3. Binding Identity

B = canon(K_id, obligation_id, CapabilityType, provider_id, interface_digest, environment_id, equivalence_evidence, verifier, validity, binding_schema_version); B_id = H(bytes(B)). Эта запись не содержит runtime credentials, а только безопасные references. Изменение provider, interface digest или environment требует rebind.

C.4. Contract Permission

ContractPermits(K, action) проверяет, входит ли protected-endpoint:update в obligations/exclusions frozen Contract. Predicate не принимает решение о текущем principal и не доказывает наличие реализации.

C.5. Binding Validity

BindingValid(B,K,action) проверяет связь с exact K_id, semantic/effect equivalence, provider/interface/environment identities, evidence и срок применимости. Missing provider либо invalid evidence дают Unbound.

C.6. Runtime Authorization

На узком экране формула прокручивается по горизонтали.

Auth(principal, action, resource, t | AuthorityCut(t), PolicyCut(t)) -> Allow | Deny(reason) | Indeterminate(reason)

Входами служат principal principal:maintenance-agent-17, action protected-endpoint:update, resource api:/v1/admin/accounts/{account_id}, moment t и exact identities текущих cuts. Результат Indeterminate fail-closed и не сводится к Deny без сохранения причины.

C.7. Execution Gate

На узком экране формула прокручивается по горизонтали.

Executable(K,B,a,t) = ContractPermits(K,a) AND BindingValid(B,K,a) AND Auth(principal,action,resource,t | AuthorityCut(t),PolicyCut(t)) = Allow

Action находится вне Contract. Decision фиксирует K_id, B_id, при необходимости I_id, AuthorityCut/PolicyCut identities, principal/action/resource, timestamp, outcome и reason. Invalid Binding и любое non-Allow запрещают execution.

C.8. Three Contrastive Cases

На узком экране таблица прокручивается по горизонтали.

Case	ContractPermits	BindingValid	Auth_t	Outcome
1. Unbound	true	false / отсутствует	не вычисляет permission to execute без valid binding	Действие не выполняется.
2. Deny	true	true	Deny(reason)	Действие не выполняется.
3. Allow	true	true	Allow	Действие допускается к исполнению.

C.9. Authority Change Over Time

В t1 AuthorityCut содержит действующий scoped grant и Auth_t1=Allow. В t2 тот же grant отозван, поэтому при неизменных K_id и B_id получается Auth_t2=Deny(REVOKED_GRANT). Semantic validity Contract не переписывается; меняется runtime executability.

C.10. Binding Gap

Если ни один provider не подтверждает required effects/trust properties в environment, GapKind=BindingProvider остаётся operational BindingGap и завершается Unbound. Он не запускает Knowledge Expansion автоматически: сначала требуется различить отсутствующую реализацию, недоступную среду и недостаточное evidence. Недостаточная authority остаётся authorization failure, а не Gap.

C.11. Historical Replay

Semantic reproducibility: Восстанавливаются exact artifact versions, SemanticCut, R_id и K_id.
Decision reproducibility: Receipt, rejected alternatives, bounds, precedence, conflicts, I_id и применимые cut identities объясняют выбор и допуск.
Operational reproducibility: Воспроизводятся B_id, environment, action decision и execution evidence, если provider/runtime dependency всё ещё доступны.

Если внешний provider удалён, semantic и decision replay могут оставаться возможными, а bit-for-bit operational replay — нет. Architecture не обещает абсолютную воспроизводимость внешней инфраструктуры.

Ограничения. AuthorityCut/PolicyCut являются bounded interfaces, а не завершённой IAM formalization. Пример не доказывает security; он делает policy, evidence, authority boundaries и decisions явными и проверяемыми.

Итог. Knowledge Contract задаёт, что семантически разрешено и требуется; Binding определяет реализацию абстрактной способности; Auth_t определяет, разрешено ли результирующее действие во время исполнения.

Приложение D. Детали оценки и пререгистрации

Назначение. Зафиксировать воспроизводимую, но ещё не исполненную экспериментальную программу Meaning Management v1.

Область. Приложение содержит hypotheses, protocols, datasets, baselines, ablations, metrics и decision rules; outcomes отсутствуют.

Связь с основной статьёй. Приложение конкретизирует экспериментальную программу Part V и не вводит дополнительных нормативных требований в архитектуру.

Экспериментальное содержание. Это preregistration specification. Ни D1–D6, ни EXP-001–009 не объявлены исполненными; synthetic mechanics checks публикационного пакета не являются experimental outcomes.

D.1. Hypotheses

На узком экране таблица прокручивается по горизонтали.

Гипотеза	Research question	Expected direction	Falsification condition
HYP-001 · Completeness	Повышает ли B4 полноту корректного semantic cut относительно retrieval/flat-manifest baselines?	Выше precision/recall без роста конфликтующих включений.	Preregistered margin/gain не достигнут либо эффект исчезает на holdout.
HYP-002 · Policy safety	Снижает ли разделение Contract, Binding и Auth_t число hard-policy violations?	Ниже violations и governance false negatives.	Нет preregistered reduction либо появляется privilege amplification.
HYP-003 · Replay	Повышают ли отдельные ResolutionCore, Contract и issuance identities воспроизводимость решений?	Выше replay каждого frozen identity domain без cross-domain drift.	Issue metadata меняет K_id, narrative меняет R_id или frozen domain не воспроизводится.
HYP-004 · Revocation without history rewrite	Сохраняются ли historical bytes при изменении текущей authority?	Historical identity stable; revoked action is not allowed.	Любое изменение historical bytes либо Allow после effective revocation.
HYP-005 · Conflict diagnostics	Улучшает ли typed Select plus Receipt воспроизводимую диагностику конфликтов и gaps?	Выше reconstruction adequacy и gap precision/recall.	Конфликт не восстанавливается либо диагностика не превосходит baseline.
HYP-006 · Bounded recursion	Завершается ли BKG traversal в bounds с честным terminal state?	Termination within B and explicit Search-Incomplete when closure is not established.	Timeout/overrun, hidden incompleteness или forced Closed.
HYP-007 · Transport equivalence	Улучшает ли semantic BindingCut распознавание эквивалентных и неэквивалентных providers?	Выше compatibility precision/recall и ниже false accepts.	Несовместимый adapter принят либо effects расходятся.
HYP-008 · Cost	Оправдан ли overhead B4 наблюдаемым error/replay gain?	Не задано; приемлемость зависит от preregistered risk-class trade-off.	Overhead превышает gain либо B2/B3 эквивалентен дешевле.
HYP-009 · Ontology agreement	Повышают ли правила Variant A межэкспертное согласие по типам и запрещённым слияниям?	Выше agreement и меньше systematic conflations.	Низкое agreement либо устойчивое смешение типов.

D.2. Experimental Protocols

На узком экране таблица прокручивается по горизонтали.

Hypothesis	Protocol	Dataset	Baseline	Intervention	Primary metric	Threshold status	Decision rule
HYP-001	EXP-001	D1: frozen stratified split и holdout.	B1/B2, тот же universe и budget.	B4 с closure, Receipt и Contract.	Artifact precision/recall; terminal states.	TBD before preregistration: precision margin и meaningful recall gain.	Парный stratified bootstrap confidence interval; обе границы и holdout.
HYP-002	EXP-002	D2: fixed policy attacks по risk strata.	B0/B1; B3 как сильный comparator.	B4 с отдельными Contract, BindingCut и Auth_t.	Critical-error gain и governance false negatives.	TBD before preregistration: maximum rate и meaningful reduction.	Парный exact McNemar и confidence interval; failures/abstentions в denominator.
HYP-003	EXP-003	D1: frozen semantic/issue inputs и seeds.	B1/B3.	B4 с ResolutionCore/R_id, K_sem/K_id и I/I_id.	Replay gain по трём identity domains.	TBD before preregistration: replay gain; canonical drift всегда failure.	Парный bootstrap confidence interval, exact identity comparison и divergence classes.
HYP-004	EXP-004	D3: histories до/после effective revocation.	B3 с mutable state.	B4 с pinned identities, current cuts и Auth_t.	Historical byte stability; current Auth outcome.	Defined invariant: bytes stable; revoked action not Allow.	Property-based replay; любой контрпример отвергает свойство.
HYP-005	EXP-005	D2: conflicts/gaps с adjudicated oracle.	B1 free-text planner.	B4 typed Select и Receipt.	Conflict reconstruction и GapKind precision/recall.	TBD before preregistration: improvement и blinded agreement bound.	Слепая парная оценка; заранее выбранный permutation test либо bootstrap interval.
HYP-006	EXP-006	D2: cyclic/deep graphs и bounds B.	B1 без terminal-state contract.	B4 bounded traversal и Search-Incomplete.	Termination, state, expansions, budget overrun.	Defined invariant: declared state within B without completeness promise.	Property-based traversal; любой counterexample отвергает свойство.
HYP-007	EXP-007	D4: positive/negative adapter pairs.	B3 по interface/transport.	B4 BindingCut по semantics и trust domain.	Compatibility accuracy и effect agreement.	TBD before preregistration: precision/recall и false-accept maximum.	Adjudicated oracle; McNemar и confidence interval effect agreement.
HYP-008	EXP-008	D1-D4: полные cost logs.	B3 при равных budgets/adapters.	B4: first resolution и replay отдельно.	Resolution/context overhead с critical-error/replay gain.	TBD before preregistration: overhead и gain по risk class.	Парные bootstrap intervals и preregistered cost-effectiveness rule.
HYP-009	EXP-009	D5: independent double annotation и adjudication.	Разметка без правил Variant A.	Семь типов и запрещённые conflations.	Inter-annotator agreement и confusion matrix.	TBD before preregistration: agreement и lower confidence bound.	Kappa/alpha выбирается до запуска; bootstrap interval и permutation comparison.

D.3. Datasets

D1 — Canonical task fixtures: Задачи исходного Research 17 corpus с вручную зафиксированными required artifacts, связями и допустимыми terminal states.
D2 — Adversarial semantic fixtures: Omissions, conflicting versions, malicious Policy, misleading retrieval, underspecified SuccessCriterion и plausible synthesized gaps.
D3 — Evolution histories: Цепочки successors, revocations, delayed evidence и historical replay points.
D4 — Transport and binding fixtures: Семантически эквивалентные и неэквивалентные CLI, API, MCP и A2A adapters с контролируемыми различиями эффектов.
D5 — Double-annotation corpus: Независимая экспертная разметка Role, Skill, Blueprint и четырёх operational/governance types.
D6 — External Naturalistic Task Corpus: Независимый от устройства Variant A будущий корпус с естественной неоднозначностью, недостающим знанием, конфликтами Policy и tool bindings. На момент semantic/preregistration freeze корпус D6 не собран; результаты отсутствуют.

Каждая frozen dataset version требует digest, data statement, inclusion/exclusion rules, label schema, adjudication log и split identity. D6 является future external naturalistic corpus; он не собран, и outcomes отсутствуют.

D.4. Baselines

B0 — Prompt-only: Контекст без typed artifacts и receipts.
B1 — Retrieval + planner: RAG и planner без contract cut.
B2 — Flat manifest: Точные версии без BKG closure, typed failures и отдельного Auth.
B3 — Workflow + policy engine: Workflow и policy-as-code без provenance-aware semantic selection.
B4 — Full proposed profile: Полная конструкция Meaning Management v1.

Task inputs, candidate universe, budgets и adapters должны совпадать там, где сравнение их не изменяет намеренно. Дополнительные retrieval calls, human review и storage учитываются как treatment cost.

D.5. Ablations

Четыре single-component ablations не образуют full factorial design и не предрешают полезность компонента.

На узком экране таблица прокручивается по горизонтали.

Абляция	Что изолирует	Causal question
B4 без Resolution Receipt	Вклад decision provenance и diagnosability.	Меняются ли replay выбора, восстановление причин и диагностика при сохранении Contract и остальных проверок?
B4 без bounded BKG closure	Вклад structured bounded semantic resolution.	Меняются ли completeness, conflict detection, Search-Incomplete и стоимость при том же candidate universe?
B4 без отдельной Authorization	Вклад разделения semantic permission и runtime authority.	Меняются ли policy violations и ложные allow/deny, если Auth_t не отделён от Contract и Binding?
B4 без Evidence Profiles	Вклад risk/type-dependent admission governance.	Меняются ли false acceptance, abstention и human-review cost без профильных требований evidence?

D.6. Metrics

На узком экране таблица прокручивается по горизонтали.

Metric group	Definition	Unit	Aggregation	Direction	Known limitations
Resolution/context overhead	Дополнительные latency, model tokens, memory, graph operations и human-review time относительно сопоставимого baseline.	ms, tokens, bytes, graph operations, person-minutes	Median, tail quantiles и stratified paired difference по task/risk class.	Ниже при сохранении error/replay gain.	Нужны одинаковые task budget и candidate universe; first resolution и replay считаются отдельно.
Critical-error gain	Изменение частоты критических semantic, policy и binding errors относительно baseline.	percentage points и relative risk	По risk class с failures и abstentions в denominator.	Больше положительное сокращение ошибок.	Severity weighting и practically meaningful minimum должны быть заморожены до main outcomes.
Replay gain	Изменение доли повторов с тем же terminal state и раздельно R_id, K_id и I_id при frozen inputs соответствующего domain.	proportion и percentage-point difference	По identity domain и классу допустимого divergence.	Выше при неизменных frozen inputs.	Narrative drift не меняет R_id; issue metadata drift не должен менять K_id.
Search-Incomplete rate	Доля задач, закончившихся явным Search-Incomplete при объявленных bounds.	proportion	По bounds, risk class и graph depth.	Ниже без скрытого принуждения к Closed.	Нулевая доля может означать дефект наблюдаемости, а не полноту.
Assembly failure rate	Доля выбранных cuts, не выпущенных из-за canonicalization, Receipt, schema или Issue authority failure.	proportion по failure class	Раздельно technical assembly и Issue-Unauthorized.	Ниже при сохранении fail-closed semantics.	Issue-Unauthorized нельзя считать ошибкой сериализации или удалять из denominator.
Inter-annotator agreement	Согласие независимых экспертов по семи типам, relation types, conflicts и terminal states.	Cohen’s kappa либо Krippendorff’s alpha и confusion matrix	Коэффициент и confidence interval по заранее выбранному профилю.	Выше при отсутствии систематических смешений.	Метрика и lower bound выбираются до запуска; class imbalance анализируется отдельно.
Compatibility accuracy	Precision/recall совместимости semantic cuts и bindings против adjudicated fixtures.	precision, recall, false-accept rate	По типам relation, adapter effects и risk class.	Выше precision/recall и ниже false accepts.	Совпадение interface name или transport не доказывает semantic compatibility.
Governance false-positive rate	Доля допустимых публикаций, выпусков, bindings или действий, ошибочно отклонённых governance profile.	proportion	По decision surface и risk class.	Ниже без тривиального разрешения всего.	Нужно отличать governance reject от technical failure и считать human-review cost.
Governance false-negative rate	Доля недопустимых публикаций, выпусков, bindings или действий, ошибочно разрешённых governance profile.	proportion с severity weighting	По decision surface, risk class и consequence class.	Ниже.	Средняя доля без severity может скрыть редкие критические ошибки.

D.7. Thresholds and Preregistration Freeze

Любой численный threshold без definition-derived invariant имеет статус TBD before preregistration. Он выбирается по pilot data, power analysis, consequence severity и risk appetite до просмотра main outcomes; последующее изменение маркируется exploratory analysis.

На узком экране таблица прокручивается по горизонтали.

Показатель	Статус	Ограничение выбора
Resolution/context overhead	TBD before preregistration	Нужны одинаковые task budget и candidate universe; first resolution и replay считаются отдельно.
Critical-error gain	TBD before preregistration	Severity weighting и practically meaningful minimum должны быть заморожены до main outcomes.
Replay gain	TBD before preregistration	Narrative drift не меняет R_id; issue metadata drift не должен менять K_id.
Search-Incomplete rate	TBD before preregistration	Нулевая доля может означать дефект наблюдаемости, а не полноту.
Assembly failure rate	TBD before preregistration	Issue-Unauthorized нельзя считать ошибкой сериализации или удалять из denominator.
Inter-annotator agreement	TBD before preregistration	Метрика и lower bound выбираются до запуска; class imbalance анализируется отдельно.
Compatibility accuracy	TBD before preregistration	Совпадение interface name или transport не доказывает semantic compatibility.
Governance false-positive rate	TBD before preregistration	Нужно отличать governance reject от technical failure и считать human-review cost.
Governance false-negative rate	TBD before preregistration	Средняя доля без severity может скрыть редкие критические ошибки.

До main experiment замораживаются:

dataset versions
baseline implementations
model/runtime versions
prompts where applicable
artifact repository snapshot
metrics
aggregation rules
thresholds
exclusions
stopping rules
statistical procedure
random seeds where applicable

D.8. Decision Rules

На узком экране таблица прокручивается по горизонтали.

Protocol	Success	Failure	Inconclusive
EXP-001	Заранее заданное правило решения подтверждает ожидаемое направление и frozen threshold.	Preregistered margin/gain не достигнут либо эффект исчезает на holdout.	Качество или объём frozen data недостаточны либо интервал не позволяет классифицировать результат относительно frozen threshold.
EXP-002	Заранее заданное правило решения подтверждает ожидаемое направление и frozen threshold.	Нет preregistered reduction либо появляется privilege amplification.	Качество или объём frozen data недостаточны либо интервал не позволяет классифицировать результат относительно frozen threshold.
EXP-003	Заранее заданное правило решения подтверждает ожидаемое направление и frozen threshold.	Issue metadata меняет K_id, narrative меняет R_id или frozen domain не воспроизводится.	Качество или объём frozen data недостаточны либо интервал не позволяет классифицировать результат относительно frozen threshold.
EXP-004	Заранее заданное правило решения подтверждает ожидаемое направление и frozen threshold.	Любое изменение historical bytes либо Allow после effective revocation.	Качество или объём frozen data недостаточны либо интервал не позволяет классифицировать результат относительно frozen threshold.
EXP-005	Заранее заданное правило решения подтверждает ожидаемое направление и frozen threshold.	Конфликт не восстанавливается либо диагностика не превосходит baseline.	Качество или объём frozen data недостаточны либо интервал не позволяет классифицировать результат относительно frozen threshold.
EXP-006	Заранее заданное правило решения подтверждает ожидаемое направление и frozen threshold.	Timeout/overrun, hidden incompleteness или forced Closed.	Качество или объём frozen data недостаточны либо интервал не позволяет классифицировать результат относительно frozen threshold.
EXP-007	Заранее заданное правило решения подтверждает ожидаемое направление и frozen threshold.	Несовместимый adapter принят либо effects расходятся.	Качество или объём frozen data недостаточны либо интервал не позволяет классифицировать результат относительно frozen threshold.
EXP-008	Заранее заданное правило решения подтверждает ожидаемое направление и frozen threshold.	Overhead превышает gain либо B2/B3 эквивалентен дешевле.	Качество или объём frozen data недостаточны либо интервал не позволяет классифицировать результат относительно frozen threshold.
EXP-009	Заранее заданное правило решения подтверждает ожидаемое направление и frozen threshold.	Низкое agreement либо устойчивое смешение типов.	Качество или объём frozen data недостаточны либо интервал не позволяет классифицировать результат относительно frozen threshold.

D.9. Failure Interpretation

Отрицательный или inconclusive outcome не сводится к одной фразе «hypothesis rejected». До интерпретации различаются следующие объяснения:

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

D.10. Architecture Rejection Criteria

Соответствующий компонент или вся Meaning Management v1 должны быть упрощены, частично отвергнуты либо отвергнуты целиком, если выполняется preregistered условие:

Нет материального сокращения критических semantic, policy или binding errors.
Resolution/context overhead чрезмерен относительно предотвращённых ошибок.
Независимые annotators не достигают устойчивого согласия.
Search-Incomplete систематически сохраняется на naturalistic tasks при разумных bounds.
Frozen inputs не воспроизводят terminal state и соответствующий R_id/K_id/I_id.
Стоимость и ошибки governance превышают наблюдаемые gains.
B2 или B3 даёт эквивалентные гарантии существенно дешевле.

После main outcomes нельзя менять dataset, metric, threshold или denominator, чтобы превратить такой outcome в успех.

Ограничения. Dataset versions, sample sizes, thresholds, statistical profiles и implementation under test ещё не заморожены. Ни одна строка не является результатом; D6 не существует как corpus.

Итог. Appendix D связывает девять гипотез с девятью протоколами и заранее допускает failure, inconclusive outcome, упрощение компонента и отказ от архитектуры.

Данные и дополнительные материалы

Research Supplement содержит compilation methodology, source traceability, implementation questions, review decisions, ecosystem mapping, complete figure register, reviewer simulation, literature-search procedure и publication/licensing notes. Эти материалы ненормативны и не заменяют аргумент основной работы.

Figure Atlas сохраняет историю 62 допустимых к публикации графических артефактов. Historical presence не означает нормативность; canonical, accepted, superseded, historical и unresolved являются semantic statuses, а не licensing statuses. Provenance не доказывает public reuse permission. Main Paper использует только выбранные scientific schemes; остальные допустимые версии сохранены для provenance, traceability и исследования эволюции архитектуры.