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

Статус рукописи. Это русская рабочая версия статьи для авторской вычитки. Она сохраняет структуру, определения, трассировку источников, приложения и 13 рисунков из исследовательского пакета Research 17. Авторы, аффилиация, лицензия, категория arXiv и публикационная авторизация ещё не назначены. Эксперименты по оценке архитектуры не проводились.

Расширенная рабочая статья «Управление смыслами в автономных ИИ-системах» является основным текстом текущей смысловой вычитки. Эта страница сохраняется как более ранняя сопроводительная проектная записка о Knowledge Contract.

Аннотация

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

В статье формулируется более узкое архитектурное предложение: Meaning Management как жизненный цикл, в котором неоднородные версионируемые смысловые артефакты собираются на границе выполнения в неизменяемый, привязанный к происхождению Knowledge Contract. Контракт фиксирует, что должно выполняться для конкретной задачи; отдельная привязка фиксирует, как уполномоченный рантайм может действовать. Определены идентичность артефакта, содержательная целостность, совместимость, фазы Propose — Validate — Select — Assemble — Bind, неизменяемость контракта, текущая авторизация, недопустимые состояния и эволюция через наследующие версии.

Работа включает синтетический пример, обязательства соответствия и программу заранее заданных проверок. Вклад на этом этапе — формальная архитектура и набор фальсифицируемых гипотез, а не реализованная система, эмпирическое улучшение или установленный результат новизны.

1. Введение

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

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

Эта статья исследует архитектурный шов между развивающимися смысловыми артефактами и одним ограниченным выполнением. Здесь слово смысл используется в операционном значении: это интерпретация, обязательство или отношение, наличие которого может изменить выбор кандидатов, проверку, разрешение выполнения или оценку результата. Жизненный цикл, управляющий такими объектами, называется Meaning Management. Его главный результат для выполнения — Knowledge Contract, неизменяемая спецификация задачи, собранная из явно выбранных версий артефактов.

Различие между контрактом и привязкой намеренно консервативно. Работы по контрактам автономных агентов уже формализуют обязательства выполнения и ресурсные ограничения [1]; Agent Behavioral Contracts задают предусловия, инварианты, управление и восстановление [2]; ToolGate использует предусловия и постусловия в стиле Хоара для допуска вызова инструментов [3]. Поэтому статья не утверждает, что контракт, навык, происхождение или управление впервые появляются в агентных системах. Вопрос уже: возникает ли полезная граница, когда неоднородные классы артефактов собираются в одном версионируемом жизненном цикле, а снимок конкретного выполнения остаётся неизменяемым даже после изменения репозитория и авторизации.

Статья делает четыре предложения.

1. Вводится типизированная модель артефакта и версии, разделяющая смысловую идентичность, идентичность содержимого, совместимость, доказательства и текущие полномочия.
2. Определяется пятифазный жизненный цикл резолвера — Propose, Validate, Select, Assemble и Bind — с явными состояниями пробела и ошибки вместо молчаливого отката.
3. Формулируется неизменяемая модель Knowledge Contract, происхождение которой может быть сопоставлено с существующими словарями provenance, а ограничения графа — проверено без заявления о новом стандарте происхождения или валидации.
4. Задаётся фальсифицируемая исследовательская программа для проверки полноты, повторного запуска, безопасности политики, стоимости контекста, объяснения конфликтов и ограниченной рекурсивной декомпозиции.

История дизайна содержит большой визуальный материал. В статье показаны 13 рисунков, отнесённых к тем разделам, где обсуждаются соответствующие семейства понятий. Номера IMG-XXX в подписях сохраняют связь с физическим реестром Research 17. Эти изображения являются источниками проектных рассуждений, а не измерениями, трассами реализации или самостоятельно проверенными научными диаграммами.

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

2. Методика и граница доказательств

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

Принятый срез закрытого смыслового реестра содержит беспробельное разбиение пяти исходных документов на 232 сегмента, 212 смысловых единиц, 67 физических строк изображений и 77 вхождений ссылок на изображения в контексте. Детерминированные проверки фиксируют эти знаменатели, покрытие локаторов, уникальность идентификаторов, допустимые типы доказательств и ссылки между таблицами. Короткие trace-идентификаторы в рукописи связывают опорные утверждения о дизайне с просмотренными единицами и локаторами источников. Это след дизайна, а не научная поддержка, результат эксперимента или разрешение на публикацию.

Аудит физического корпуса и смысловой реестр являются свидетельствами воспроизводимости исследовательского процесса, а не свидетельствами того, что предлагаемая архитектура работает. Внешние стандарты и статьи задают поверхность сравнения. Результаты, сообщённые авторами современных препринтов, остаются сообщениями авторов, пока их не воспроизвели независимо. Внутреннее развёртывание Arcanada не используется как результат.

Из этой границы следуют два вывода. Во-первых, предложение можно критиковать по определениям, инвариантам, контрпримерам и сравнению с существующими системами до появления реализации. Во-вторых, правдоподобие архитектуры не закрывает эмпирические вопросы. Поэтому программа оценки в разделе 10 является частью научного предложения, а её эксперименты остаются невыполненными.

3. Связанные работы и отказ от чрезмерных заявлений

3.1. Контракты для автономного выполнения

Agent Contracts объединяют спецификации входа и выхода, ресурсные ограничения, временные границы, критерии успеха, семантику жизненного цикла и сохранение делегируемого бюджета [1]. Agent Behavioral Contracts определяют предусловия, инварианты, управление, восстановление и вероятностное выполнение [2]. ToolGate поддерживает явное символьное состояние и использует контракты в стиле Хоара для допуска вызова и фиксации результата инструмента [3]. Синтез поведения робота на основе контракта извлекает навыки, операторы и шаблоны до генерации и проверки исполнимого поведения [4]. Эти работы исключают широкое утверждение, будто формальных или исполняемых контрактов для агентов не существует.

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

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

Исследования контекстного обучения показывают, что получение локальной спецификации может быть отдельной осью отказа, не совпадающей с извлечением содержания, и изучают индукцию частных контрактов спецификации [5]. Работы об agent skills рассматривают переносимые процедурные пакеты, постепенную загрузку, интеграцию с MCP, приобретение, безопасность и управление жизненным циклом [6]. Поэтому статья не объявляет новыми индукцию спецификации, переносимые навыки, постепенное раскрытие контекста, версионируемые репозитории или управление навыками. Здесь Skill — один из типов артефакта среди нескольких, и его включение в контракт должно быть обосновано обязательствами задачи и совместимостью с выбранными версиями других типов.

3.3. Смысловые сервисы, происхождение и валидация

OWL-S разделяет профиль сервиса, модель процесса и grounding. Grounding сопоставляет абстрактное описание сервиса с протоколом, сообщениями, сериализацией, транспортом и адресацией [7]. Это близкий прецедент разделения смыслового описания и конкретной реализации. Поэтому разделение контракта и привязки здесь следует оценивать как специализацию для композиции агентной задачи, а не выдавать за первую абстрактно-конкретную границу сервиса.

PROV-O представляет интероперабельное происхождение через Entity, Activity и Agent и включает отношения derivation, revision, invalidation, usage, generation и responsibility [8]. Реализация Knowledge Contract должна сопоставлять события происхождения с PROV-O, а не заново изобретать provenance. SHACL проверяет графы данных RDF относительно графов форм и выдаёт результаты валидации [9]. Графовое хранилище артефактов может использовать SHACL или должно точно объяснить, зачем ему другой язык ограничений.

3.4. Протоколы и обнаружение возможностей

Model Context Protocol стандартизирует соединения, через которые host, client и server передают ресурсы, промпты, инструменты и согласованные возможности [10]. A2A определяет обнаружение агентов, Agent Cards, навыки, задачи, сообщения, артефакты, привязки, аутентификацию и проверку возможностей [11]. Эти протоколы могут переносить или открывать привязки, но сами по себе не решают, какие смыслы задачи и версии артефактов следует собрать. Meaning Management предлагается выше транспортного выбора. Он может привязаться к CLI, API, MCP, A2A или человеческой процедуре, если они выполняют одни и те же обязательства; семантическое равенство разных механизмов ещё нужно проверить.

4. Определения

Операционный смысл

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

Управляемый артефакт

Управляемый артефакт — неизменяемая версионируемая сущность со стабильной логической идентичностью, идентичностью содержимого, типом, объявленными отношениями, происхождением, состоянием доказательств и состоянием жизненного цикла. Кандидатами могут быть Role, Skill, Blueprint, Constraint, SuccessCriterion, Policy и CapabilityDescription. Набор расширяем; типы не считаются взаимно сводимыми.

Репозиторный снимок

В момент наблюдения t снимок репозитория S_t — конечное множество версий артефактов, типизированных отношений и событий жизненного цикла. У логического артефакта может быть несколько версий, но контракт ссылается на точные идентификаторы содержимого.

Knowledge Contract

Knowledge Contract K — неизменяемая, содержательно адресуемая спецификация выполнения для одной ревизии задачи. Она связывает нормализованную задачу, выбранные версии артефактов, ограничения, обязательства успеха, требования к доказательствам и происхождение сборки. Контракт может ссылаться на отдельно версионируемую привязку рантайма. Он не может получить другую версию артефакта, не став новым контрактом.

Привязка рантайма

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

Текущая авторизация

Auth_t(K, B) — внешнее предикатное условие, зависящее от времени и проверяемое в момент выполнения. Отзыв credential, политики, инструмента, модели или согласования может сделать старый контракт неисполнимым, не изменяя его байты. Неизменяемость не означает постоянство разрешения.

5. Формальная модель

Пусть T — множество типов артефактов. Версия артефакта задаётся кортежем:

a = (i, τ, v, h, P, R, X, E, L)

Здесь i — логическая идентичность, τ ∈ T — тип, v — метка версии, h — криптографическая идентичность содержимого, P — множество предоставляемых предикатов, R — множество требуемых предикатов, X — множество исключений, E — запись доказательств и происхождения, а L — состояние жизненного цикла. Метка версии помогает человеку упорядочивать записи; h является неизменяемым якорем содержимого.

Для ревизии задачи q и снимка репозитория S_t резолвер задаётся композицией:

R(q, S_t, t) =
    Bind_t ∘ Assemble ∘ Select ∘ Validate ∘ Propose(q, S_t)

Фазы имеют разные обязательства.

1. Propose. Создаёт полный набор кандидатов с происхождением поиска и запроса. Кандидат ещё не является принятым доказательством.
2. Validate. Отклоняет недоступные, отозванные, некорректные, неподдерживаемые, несовместимые версии и версии с недостаточными доказательствами по явным правилам.
3. Select. Выбирает совместимое покрывающее множество с объявленным детерминированным порядком или возвращает неоднозначность. Смысловая генерация может быть стохастической; принятую сборку нельзя называть детерминированной, если не закреплены снимок кандидатов, предикаты, оценка, правила разрешения ничьей и реализация.
4. Assemble. Строит неизменяемую спецификацию задачи и вычисляет её идентичность содержимого. Отсутствующие обязательные классы и неразрешённые конфликты являются терминальными типизированными отказами, а не поводом для молчаливого отката.
5. Bind. Сопоставляет обязательства с конкретным рантаймом только после проверки текущих возможностей и авторизации. Отказ привязки не изменяет уже собранный контракт.

Для выбранного множества артефактов A^* определим:

Provides(A*) = ⋃ P_a
Requires(A*) = ⋃ R_a
Excludes(A*) = ⋃ X_a

Минимальное условие совместимости содержит две части:

Requires(A*) ⊆ Provides(A*) ∪ Provides(q)
Excludes(A*) ∩ Provides(A*) = ∅

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

Собранный контракт задаётся так:

K = (q, A*, C, O, G, Π)

Здесь C — нормализованный набор ограничений, O — обязательства по успеху и доказательствам, G — ссылки на управление, применённое при сборке, а Π — пакет происхождения. Идентификатор контракта — дайджест канонической сериализации этих полей. B хранится отдельно: несколько конкретных механизмов могут проверяться на одном абстрактном контракте, а привязка может быть отозвана без переписывания контракта.

5.1. Валидность и исполнимость

Валидность контракта и его текущая исполнимость разделены:

Executable_t(K, B) =
    Valid(K) ∧ Satisfies(B, K) ∧ Auth_t(K, B)

Valid требует целостности идентичности содержимого, полного набора обязательств, совместимых версий артефактов, достаточного происхождения и успешной сборки по объявленным правилам. Satisfies требует, чтобы привязка покрывала возможности, ресурсы, окружение и интерфейс доказательств контракта. Auth_t может меняться независимо.

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

5.2. Повторный запуск и эквивалентность

Побайтово одинаковые контракты не гарантируют одинаковых результатов от стохастической модели или меняющегося окружения. Нужно различать:

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

Утверждение о воспроизводимости должно называть установленный уровень. В этой рабочей версии ни один уровень эмпирически не установлен.

6. Жизненный цикл и архитектура

Meaning Management находится над конкретным выполнением. Слой владеет идентичностью артефактов, выбором, совместимостью, сборкой и обязательствами по доказательствам. Обвязка выполнения отвечает за планирование, вызовы моделей, процессы и инструменты, а также за сырую телеметрию рантайма. Политика проходит через оба слоя: сборка записывает использованные ссылки на управление, а выполнение проверяет текущую авторизацию.

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

Три исходные схемы выше делают декомпозицию видимой: отдельная схема показывает резолвер, отдельная — различие основного жизненного цикла и расширения пробела, ещё одна — более широкую архитектуру Meaning Management. Формальная модель статьи, а не рисунки, задаёт заявленную семантику.

7. Синтетический рабочий пример

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

• Role, описывающая осторожного исследовательского аналитика;
• Skill, описывающий проверку утверждений по первичным источникам;
• Blueprint со стадиями ingest, classify, verify, draft и review;
• ограничения, запрещающие секреты, внешнюю отправку, неподдержанные утверждения и неограниченное включение источников;
• SuccessCriteria, требующие ссылок от утверждений к источникам, раздела ограничений и чтения закрытого результата.

Propose возвращает несколько версий, в том числе новый Skill для подготовки текста, которому нужен публичный инструмент поиска, и старый Skill для автономной работы без сети. Validate отклоняет Blueprint без требуемого интерфейса проверки цитат и отмечает привязку публичного инструмента как неразрешённую для одного класса источников. Select выбирает совместимый набор только при покрытии каждого требования и однозначном порядке. Assemble фиксирует точные дайджесты артефактов, нормализованные ограничения, свидетельства успеха и происхождение. Bind сопоставляет публичные ссылки с разрешённым браузером только для чтения, а закрытые заметки — с локальным путём чтения; операцию публикации сопоставить нельзя, потому что такой авторизации нет.

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

8. Обязательства соответствия и недопустимые состояния

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

1. Неустановленная идентичность. У выбранного артефакта нет стабильной идентичности содержимого или загруженные байты ей не соответствуют.
2. Неполное замыкание. Требование или обязательный класс артефакта не имеет принятого поставщика и явного решения по пробелу.
3. Несовместимое замыкание. Выбранные provides, requires, excludes или ограничения версий конфликтуют.
4. Неоднозначный выбор. Два допустимых множества сравнялись без объявленного стабильного правила решения.
5. Устаревшее полномочие. Сборка завершилась, но текущая политика, credential или согласование человека не разрешает привязку.
6. Разрыв происхождения. Для утверждения, отношения, результата поиска или перехода жизненного цикла отсутствует требуемый источник или событие полномочия.
7. Ретроспективная мутация. Принятый артефакт или контракт изменился под существующей идентичностью вместо создания наследующей версии.
8. Самоавторизованный пробел. Сгенерированный кандидат принят или выполнен только потому, что та же попытка его предложила.
9. Смешение границ. Транспортная способность принимается за доказательство полноты смысла, или смысловой выбор принимается за текущее разрешение на выполнение.
10. Отмывание доказательств. Отсутствующий эксперимент, кандидатная цитата или утверждение источника переименовываются в проверенный результат.

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

9. Угрозы и режимы отказа

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

Слой выполнения всё равно обязан применять обычную изоляцию, минимальные полномочия, проверку входов, ограничение ресурсов, отделение секретов и наблюдаемую обработку ошибок. Адресование по содержимому обнаруживает подмену байтов, но не ложную семантику. Ревью обнаруживает часть смысловых дефектов, но вводит вопросы идентичности и независимости ревьюера. Формальная совместимость может отвергнуть объявленные конфликты, но не вывести каждое взаимодействие реального мира. Текущая авторизация может остановить известную опасную привязку, но оказаться устаревшей или недоступной. Это взаимодополняющие меры, а не взаимозаменяемые гарантии.

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

У дизайна есть и риски отказа в обслуживании. Большой граф артефактов может сделать генерацию кандидатов или решение о совместимости дорогими. Циклические требования, диапазоны версий и множество эквивалентных кандидатов способны создать комбинаторный поиск. Практическому резолверу нужны объявленные границы, детерминированный отказ при усечении вместо молчаливого пропуска и объяснения неполного поиска. Ни один результат о сложности или масштабе здесь не заявляется.

10. Программа оценки

Следующие исследования являются целями для пререгистрации, а не выполненными экспериментами.

10.1. Сквозное сравнение

Нужно использовать один набор задач, версии моделей, инструменты, снимок данных и ресурсные ограничения в условиях «только промпт», «промпт плюс поиск», существующая память/инструменты агента и Knowledge Contract. Основные исходы должны включать успех задачи, нарушения жёсткой политики, полноту доказательств, разброс повторного запуска, нагрузку на исправление человеком, задержку, число токенов и стоимость. Протокол должен различать отказ сборки, отказ привязки, отказ выполнения и отказ оценки.

10.2. Абляции артефактов и резолвера

По одному удаляются или искажаются Role, Skill, Blueprint, Constraint, SuccessCriterion и сведения о привязке. Измеряется, сообщает ли резолвер ожидаемый пробел, выбирает ли недопустимую замену или создаёт внешне полный, но поведенчески недостаточный контракт. Детерминированный выбор при фиксированном снимке кандидатов сравнивается со стохастической генерацией кандидатов.

10.3. Повтор и эволюция

Сначала собирается контракт, затем развивается один репозиторий артефактов, после чего старый контракт повторяется со старым и новым окружением привязки. Проверяется, сохраняется ли идентичность содержимого, блокирует ли отзыв опасное выполнение, объясняет ли контракт-наследник изменившиеся зависимости и выявляет ли критерий эквивалентности результата вариативность среды вместо того, чтобы называть каждое различие недетерминизмом.

10.4. Совместимость и объяснение

Создаются совместимые, неоднозначные, противоречивые, циклические графы и графы с конфликтом версий. Измеряются корректность решателя, минимальное покрытие, стабильность решения ничьей, качество объяснения конфликта и производительность при росте графа и числа кандидатов.

10.5. Состязательное управление

В корпус добавляются вредоносные артефакты, поддельные доказательства, устаревшие политики, обходы согласования, отравленные результаты поиска и подмены возможностей. Требуются решения с отказом по умолчанию и аудируемой цепочкой происхождения. Успешная защита в синтетическом fixture не доказывает безопасность в производстве; она проверяет только названный механизм против названной угрозы.

10.6. Независимость транспорта

Один закреплённый абстрактный контракт по возможности выполняется через семантически эквивалентные привязки CLI, API, MCP и A2A. Эквивалентность результата определяется заранее, а ошибки адаптера измеряются отдельно. Только после этого можно обсуждать практическую независимость контракта от механизма выполнения.

11. Ограничения

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

Дизайн возник в истории одной частной экосистемы. Формализация рассчитана на обобщение, но таксономия артефактов и приоритеты отказов могут отражать этот контекст. Обзор литературы охватывает известные близкие источники, но не является систематическим обзором. У предлагаемой комбинации могут быть предшественники в системах рабочих процессов, планировании, движках политик, цепочках поставки программного обеспечения, case-based reasoning, алгебре процессов, компиляции знаний и контрактном проектировании. Поэтому широкое заявление о новизне не обосновано.

Несколько определений остаются неполными. Эскиз provides/requires/excludes не фиксирует временные ограничения, количественные ресурсы, вероятностное выполнение, порядок, подтипы, семантику диапазонов версий и минимальные объяснения. Двойная роль Capability как переиспользуемого описания и конкретной привязки требует опыта реализации. Рекурсивной декомпозиции нужны инвариант сохранения родителя и правило остановки. Атрибуция эволюции остаётся сложной: наблюдаемый отказ может исходить от задачи, контракта, артефакта, привязки, окружения, модели или оценщика.

Закрытый корпус исследования не может быть выпущен этой публикационной версией, а права на исходный текст и рисунки ещё не оформлены. Эта статья сохраняет выбранные схемы в разделах, к которым они относятся; права, приватность, атрибуция и метаданные требуют отдельной проверки перед любой публичной научной публикацией. Совместимость исходников с arXiv не проверялась, и использование LaTeX в частном пакете не означает подготовку или подачу заявки.

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

Meaning Management предлагается как граница жизненного цикла, которая превращает развивающиеся неоднородные смысловые артефакты в одну неизменяемую спецификацию задачи и при этом оставляет конкретную привязку и текущую авторизацию явными. Knowledge Contract — снимок выполнения, произведённый этим жизненным циклом; это не утверждение, что контракты, навыки, provenance, смысловые сервисы или агентные протоколы являются новыми.

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

Приложение A. Иллюстративная схема контракта

Следующая схема объясняет объект, но не является замороженным стандартом обмена. Все ссылки обозначают точные идентификаторы содержимого; многоточия показывают опущенные поля, а не необязательную валидацию.

knowledge_contract:
  schema_version: 0
  task:
    logical_id: task-example
    revision_digest: sha256:...
  artifacts:
    - logical_id: cautious-research-role
      type: Role
      version: 3
      content_digest: sha256:...
      evidence_state: reviewed
  constraints:
    - no_public_dispatch
    - no_unsupported_claims
  success_obligations:
    - claim_to_primary_source_coverage
    - limitation_section_present
  governance_refs:
    - policy_digest: sha256:...
  provenance_bundle: sha256:...
  contract_digest: sha256:...

runtime_binding:
  contract_digest: sha256:...
  model_identity: exact-runtime-id
  tools: [...]
  environment_digest: sha256:...
  authorization_evidence: current-event-id

Приложение B. Псевдокод резолвера

resolve(task, snapshot, now):
    candidates, proposal_evidence = propose(task, snapshot)
    valid, rejections = validate(
        candidates, task, snapshot, now)
    if uncovered_requirement(valid, task):
        return GAP(uncovered, proposal_evidence, rejections)

    solutions = compatible_covers(valid, task)
    if solutions is empty:
        return CONFLICT(explain(valid, task))
    if not unique_under_declared_order(solutions):
        return AMBIGUOUS(explain_tie(solutions))

    selected = select(solutions)
    contract = assemble(task, selected, proposal_evidence)
    assert digest(contract) == contract.contract_digest

    binding = bind(contract, current_capabilities(now))
    if binding is absent:
        return UNBOUND(contract.contract_digest)
    if not currently_authorized(contract, binding, now):
        return UNAUTHORIZED(
            contract.contract_digest, binding.digest)
    return READY(contract, binding)

Сгенерированный кандидат не вставляется в множество valid во время той же резолюции, если он не прошёл независимо разрешённый жизненный цикл артефакта.

Приложение C. Эволюция артефакта и контракта

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

Приложение D. Замыкание и вид соответствия

Приложение E. Рубрика классов доказательств

Приложение F. Минимальная запись эксперимента

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

Литература

1. Q. Ye, J. Tan. Agent Contracts: A Formal Framework for Resource-Bounded Autonomous AI Systems. arXiv:2601.08815, 2026. Источник.
2. V. P. Bhardwaj. Agent Behavioral Contracts: Formal Specification and Runtime Enforcement for Reliable Autonomous AI Agents. arXiv:2602.22302, 2026. Источник.
3. Y. Liu et al. ToolGate: Contract-Grounded and Verified Tool Execution for LLMs. Findings of ACL 2026, pp. 9653–9684. Источник.
4. J. Salfity, R. B. Anderson, M. Pryor. Contract-Grounded Behavior Tree Synthesis via Coding Agents. arXiv:2607.12220, 2026. Источник.
5. J. Zhong et al. Agentic Context Learning with Self-Discovered Specification. arXiv:2607.09794, 2026. Источник.
6. R. Xu, Y. Yan. Agent Skills for Large Language Models: Architecture, Acquisition, Security, and the Path Forward. arXiv:2602.12430, 2026. Источник.
7. OWL Services Coalition. OWL-S: Semantic Markup for Web Services. W3C Member Submission, 2004. Источник.
8. T. Lebo, S. Sahoo, D. McGuinness. PROV-O: The PROV Ontology. W3C Recommendation, 2013. Источник.
9. World Wide Web Consortium. Shapes Constraint Language (SHACL). W3C Recommendation, 2017. Источник.
10. Model Context Protocol Project. Model Context Protocol Specification, 2025-06-18 Revision. 2025. Источник.
11. A2A Protocol Project. A2A Protocol Specification, Version 1.0. 2026. Источник.

Материал для вычитки. Нужна проверка терминологии, авторского голоса, полноты разделов, корректности внутренних trace-локаторов и решения о том, какие исходные схемы можно будет выпускать публично после отдельной проверки прав.