# Контракт глубокого исследования каждой мета-модели Версия задания: 2.1, 21 сентября 2026. Контракт принят для этой исследовательской программы. Проверки выполняются и фиксируются отдельно для каждого результата. Контракт не объявляет уже выполненными исследования или проверки. Каждая индивидуальная карточка в `research-briefs/` применяется вместе с этим контрактом. Карточка задаёт предметную границу, собственные вопросы, инварианты, ошибочный пример и сквозной сценарий. Исследователь вправе обоснованно разделить контур, объединить задания, переиспользовать опубликованную модель или отказаться от нового пакета. Такое решение должно сохранить все покрываемые потребности и crosswalk. ## 1. Что именно исследуется Единица реестра - управляемая область исследования мета-модели с проверяемым результатом. Она не равна одной сущности, таблице, папке, namespace или репозиторию. Перечень `candidate_types` - рабочий словарь для проверки границ, а не утверждение, что каждый термин станет самостоятельной мета-моделью. Для каждого кандидата заполнить таблицу: определение; самостоятельная идентичность; отличие от соседей; lifecycle; владелец фактов; источник; права; независимая применимость; выбранная форма. Формы результата: reuse, profile/extend, bundle/layer, shared contract/facet, new subject model, landscape, adapter, local binding, deferred. Не использовать механическое голосование «четыре из шести»: один разрушенный допустимый сценарий может потребовать разделения даже без большинства признаков. Разделять три графа: экземпляры и их отношения; зависимости спецификаций; состав поставки. Циклы бизнес-связей могут быть допустимы, циклы наследования и безусловной композиции - отдельный предмет проверки. Взаимные ссылки объектов сами по себе не требуют циклических package imports. ## 2. Источники и конкурирующие подходы Для каждого контура сопоставить не менее трёх подходов: релевантный первичный стандарт/онтологию, объектную практику действующей системы или открытого проекта, альтернативную предметную школу. Если для узкой темы доступно меньше, записать ограничение и компенсирующие кейсы; не выдумывать источники ради количества. В карточке приведены начальные источники и направления сравнения. На каждый принятый тезис: URL/документ, редакция, дата чтения, точный раздел, краткий тезис, значение для границы, принято/отклонено/неопределённо. Платный непрочитанный стандарт не цитировать как доказанную норму. Ссылка на HR Open, ISO, ITIL, ArchiMate, SPDX или NIST не означает соответствие, сертификацию или буквальный crosswalk. Проверить лицензию на заимствуемые схемы и классификаторы. Метки свидетельств: **observed** - проверено непосредственно в названном источнике; **source-asserted** - утверждение автора документа; **inference** - наш вывод; **proposal** - проектное решение; **unverified** - ещё не проверено. Анализ ИИ реальной организации даёт требования и гипотезы; он не является нашей проверкой её действующих систем. ## 3. Вопросы, на которые модель должна отвечать Начать с трёх предметных вопросов карточки и добавить следующие двенадцать. Итого исходный минимум - 15 вопросов, но качество покрытия важнее счёта. 1. Что является данным объектом, а что лишь записью, ролью, наблюдением или носителем? 2. Что сохраняет идентичность при переименовании, переносе и смене владельца? 3. Какие события создают новый объект, split, merge или правопреемника? 4. Какие факты прямые, вычисляемые, утверждаемые и оспоренные? 5. Кто владеет смыслом и кто вправе изменять каждый вид факта? 6. Какая система является master на уровне поля/отношения и периода? 7. Что было действительно на дату и что было известно на дату получения сведений? 8. Какие состояния, переходы, условия, эффекты и полномочия специфичны предмету? 9. Какие связи обязательны, каковы кратности и ограничения удаления? 10. Что может увидеть конкретная роль, цель обработки и внешний Universe? 11. Какова минимальная полезная конфигурация и какие расширения необязательны? 12. Как выявить недостаток контекста, предложить вопрос/артефакт и проверить действие агента? Каждому вопросу присвоить ID, связать с Finding → Question → Artifact → допустимым Action. Ответ без фактов должен быть `unknown/insufficient-context` с перечнем недостающих сведений. Не достраивать неизвестное догадкой. ## 4. Семантическая спецификация Представить границу мета-модели и Bundle → Layer → Objects. В каждом слое описать цель, вопросы, артефакты, источники, связи, правила качества и допустимые действия. Не копировать весь доменный мир внутрь каждого bundle. Для каждого канонического типа подготовить: - стабильный идентификатор, критерии тождества, aliases и внешние bindings; - поля: имя, определение, тип, единица/схема значений, nullability, кратность, обязательность, вычисляемость, mastership, sensitivity; - отношения: source/target types, inverse при необходимости, кратности по обе стороны, qualifiers, действительность во времени, constraints; - lifecycle: состояния и переходы с actor, guard, effect, evidence, правилами отмены/коррекции и идемпотентности; - минимум восемь проверяемых инвариантов, включая три предметных из карточки и ограничения identity, времени, mastership, disclosure, версий; - таблицу спорных определений: выбранный смысл, альтернативы, цена ошибочного объединения, допустимые профили. Глобальные ограничения для включения в соответствующие схемы: схема ≠ ревизия объекта ≠ состояние; неизвестное ≠ ноль; ID квалифицирован схемой/issuer; источник и effective time факта видимы; равный по authority конфликт не перезаписывается молча; relationship не доказывает identity; назначение роли не доказывает исполнение действия; metadata секрета не содержит его значение. ## 5. Whole-object, источники и проекции Для **каждого** экспортируемого типа заполнить пять граней: identity-class; direct-properties; recognition-observation; capabilities-behaviour-actions; context-evidence. Для каждой выбрать required, optional, not-applicable с причиной либо delegated с точной моделью и версией. Нельзя одной общей таблицей пометить все типы «покрыты» без проверки. Абстрактному договору не навязываются масса и габариты. Матрица фактов: fact/relationship → semantic owner → authoritative system → writer → reader/purpose → valid time → provenance → conflict policy → retention. HRIS, ERP, CRM, Git, CMDB, BI - кандидаты мастер-систем, а не заранее подтверждённые источники конкретной организации. Одна Projection описывает один канонический Meta-Object. Составной dashboard/context pack собирает допустимые проекции либо является видом явно смоделированного агрегата. Агрегат должен иметь идентичность, границу, владельца, правила расчёта и раскрытия. Проекция не создаёт новый master и не даёт права раскрывать исходные сведения. Обезличивание и агрегация проверяются на конкретном сценарии, не считаются автоматической гарантией. ## 6. Сопоставление с существующим Vercy Для каждого кандидата v1 и текущего WM/vr-ID прочитать целевую спецификацию, AGENTS, registry metadata, dependencies, examples, validators и publication holds. Одинаковое название - повод сравнить, а не exactMatch. Заполнить old ID → current ID → version → runtime status/installable → research assurance → смысловое отношение (exact/narrower/broader/overlap/unrelated) → действие (reuse/profile/extend/new/defer/manual migration) → потери → доказательство. Проверить старые world-model IDs из обоих приложений отдельно. Существующие разные Person, Employment, Membership и Assignment нельзя слить только потому, что их исследуют в одной карточке. Для ПО и ландшафта: отдельная матрица WM-SFT-001, AISMM runtime 3.1.0, заявленный README 3.2.0, PLMM runtime 0.1.0-legacy и текущий draft репозитория. Найти immutable refs и выполнить semantic diff; до этого совместимость не установлена. Статус runtime не переносится на новый предлагаемый пакет. ## 7. Испытания и доказательства Подготовить синтетические fixtures минимум для трёх применимых профилей: малый бизнес без обязательной HR/ERP, сложная матричная или международная организация, профиль предмета (hardware, AI, B2C, сервис и т. п.). Неприменимый профиль исключить с причиной. Для SoftwareProduct обязательны SaaS, OSS library, on-prem, container и firmware-as-software; физическая прошивка связана с активом только когда рассматривается факт установки. Минимальный набор: положительные примеры; ошибочный пример карточки; дополнительные semantic-negative cases; историческая коррекция; повторный импорт; конфликт mastership; проверка прав; round-trip выбранного binding; upgrade/downgrade или явный отказ при потере смысла. На первом исследовательском проходе целиться в десять отрицательных случаев. Узкий контракт может иметь меньше при доказанном покрытии всех независимых ограничений. Не вся семантика проверяется JSON Schema. Разнести syntactic validation, graph constraints, policy evaluation и экспертное решение. Валидатор должен отклонять именно запрещённые состояния; законный профиль Employee, например, допустим как роль/представление над Person+Employment, если он не создаёт вторую личность. Нельзя запрещать слово вместо ошибки смысла. Для performance: объектив, evidence, assessment, calibration и appeal имеют отдельные объекты/события; спорное отрицательное утверждение не становится свойством человека. Проверить доступ, исправление, смену работодателя, сравнимость шкал и рассмотрение человеком. Количество коммитов/тикетов само по себе не доказывает продуктивность. Для SLO допустимый объект оценки определяется услугой, journey или системой, а не ограничивается одним instance. ## 8. Пакет результатов одного исследования 1. `research.md` - источники, альтернативы, спорные определения и решение о границе. 2. `boundary-decision.md` - reuse/extend/new/decompose/defer, owner и обоснование каждого типа. 3. `model-spec.md` - полный Bundle/Layer/Objects и маршруты вопросов. 4. `schema/` - схемы типов и квалифицированных отношений. 5. `lifecycle/` - переходы, authority, guards и эффекты. 6. `whole-object-coverage.yaml` - пять граней на каждый тип с обоснованной делегацией. 7. `mastership-and-rights.yaml` - владельцы фактов, источники, проекции и disclosure. 8. `crosswalk.json` - проверенные сопоставления и решения по каждому предшественнику. 9. `composition.yaml` - только выбранные зависимости, типы edges и точные версии. 10. `bindings/` - обезличенный контракт адаптера и синтетические примеры; реальные локальные bindings остаются у владельца. 11. `fixtures/` и `validation/` - positive/negative сценарии, исполняемые проверки и воспроизводимый отчёт. 12. `agent-guide.md` - что читать, что спросить при пробеле, что можно предложить и какие действия требуют полномочий. 13. `migration.md` - изменения смысла, upgrade, rollback и ручные решения. 14. `publication-manifest.draft` - registry role, ID proposal, immutable ref, version, digest и отдельно semantic fingerprint; не подставлять фиктивные значения. 15. `review.md` - предметный и архитектурный review, unresolved holds, принятые ограничения, решение ответственного. ## 9. Стадии готовности и выходные условия **Research scoped**: есть индивидуальное задание и источники. Именно на этой стадии находится текущий реестр. **Research accepted**: граница обоснована альтернативами и кейсами; crosswalk проверен; каждый тип имеет владельца; предметный и архитектурный review проведены. Объём дальнейшей реализации определён, но код/спецификация ещё могут отсутствовать. **Implementation validated**: спецификация, схемы, coverage, lifecycle, policy и fixtures согласованы; проверки выполнены; миграция воспроизводима; нет скрытой потери identity/time/authority. **Publication candidate**: immutable refs и hashes вычислены, зависимости разрешены, manifest соответствует актуальным требованиям Vercy, лицензии проверены, организационные instance-данные отсутствуют, блокирующие holds закрыты. Для исследовательского draft разрешён иной статус только если действующий процесс Vercy явно это допускает; такой статус не называется канонической готовностью. **Published**: публикация выполнена разрешённым процессом, запись прочитана обратно, runtime status/version/digest совпали. **Installation tested**: отдельно доказана установка в синтетическую Universe и разрешение выбранных моделей. Публикация сама по себе не доказывает эксплуатационную пригодность. Следующий этап следует начинать с W0 и нескольких сквозных моделей W1. W1-W3 - очереди по зависимости и применимости, не календарные обещания. Не ждать реализации всей библиотеки, чтобы проверить минимальную работающую сборку.