От каталога моделей к рабочему измерению

Опыт DatsTeam и пилот Behind Software / DevTeam.Games

Опубликовано 21 сентября 2026 года. Работа выполнена 20–21 сентября. Статус: отчёт о реализации и ограничениях пилота, не нормативная спецификация Vercy и не подтверждение промышленного внедрения в DatsTeam.

Главный результат: измерение должно управлять не только составом моделей, но и применимостью процессов, источниками назначений ролей и правилами начала работы человека с ИИ. Мы собрали закрытый каркас DT, реализовали локальный планировщик рабочих действий и проверили связку на существующей AISMM DevTeam.Games в отдельном измерении Behind Software.

Публикуется архитектурный опыт. Закрытые репозитории остаются закрытыми; персональные реестры, исходные корпоративные документы, клиентские данные и учётные данные в этот отчёт не включены.

1. С чего началась задача

DatsTeam — сервисная компания, работающая с ИТ-инфраструктурой клиентов. Первоначальный запрос был практическим: создать измерение DT, развернуть реестр, запросить недостающие мета-модели, принять спецификации и установить их в закрытых репозиториях. Затем проверить, как сотрудник добавит собственную существующую модель и начнёт работать с корпоративными знаниями через ИИ.

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

Измерение DT и потенциальные измерения клиентов могут быть связаны проекциями. Сервисный провайдер может подготовить клиентское измерение до участия клиента, но это не означает автоматического согласия клиента или состоявшейся передачи владения. Передача должна отдельно фиксировать принятие, полномочия и отзыв прежнего делегирования. Этот сценарий описан; реальные клиентские измерения в данном пилоте не разворачивались.

2. Владение и мастер-данные

Мы разделили владельца спецификации, владельца измерения, ответственного за данные, администратора хранения и мастер-систему. Они могут различаться.

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

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

3. Что развернули для DT

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

Два запроса к Vercy прошли путь от pending до опубликованных решений. Запрос не обязательно означает создание новой спецификации: подходящие существующие модели переиспользуются. В DT установлены четыре закреплённые спецификации:

• Ownership / Stewardship;
• Projection / Disclosure Policy;
• Dependency / Impact;
• Managed IT Service Graph — версия 0.1.0-research.1, со статусом reviewable-draft и тремя обязательными зависимостями.

Локальный реестр после установки и обработки временных записей использует состояние refactored; это не отдельный статус публикации каталога Vercy. Установка спецификаций также не означает подключения рабочих данных: Jira и CMDB не подключены, данные клиентов не импортированы, исполняемые контракты фактов для этих пакетов ещё не активированы.

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

4. От одной ссылки к двум разным процессам

Изначальная идея была простой: сотруднику отправляют репозиторий, он передаёт его своему ИИ и начинает работу. Мы разделили этот сценарий на онбординг и обычную сессию.

Онбординг: проверить личность и приглашение, зарегистрировать участие, показать обязательные правила, получить действительное принятие человеком, назначить роли и области полномочий. Предложить постоянное подключение через ссылку в локальном AGENTS.md. Агент не принимает правила за человека, а открывшаяся ссылка не считается согласием.

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

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

Наличие AGENTS.md не запускает ИИ при входе в ОС. Его чтение обеспечивает конкретная среда агента; корпоративный launcher должен отдельно запускать рабочую сессию. Ссылка сохраняется в выбранном локальном файле в пределах поручения пользователя, без молчаливого изменения глобальных инструкций.

5. Доступ к хранилищу и рабочая роль

Ключевое уточнение: интерес представляет не только возможность прочитать репозиторий, а роль человека при работе с моделью. Технический доступ обычно обеспечивается GitLab, GitHub или другим хранилищем. Рабочая роль определяет, какие действия человек вправе выполнять в определённой ситуации с определённой информацией.

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

Формула решения выглядит так:

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

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

6. Как использовали процессы AISMM

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

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

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

В DT реализованы ограниченные профили по C-4/C-2 и S5–S7, а не весь канон процессов. Демонстрация показывает одного синтетического участника с разными ролями в двух моделях. В реальной конфигурации DT продуктовые AISMM и их процессы не активированы: корпоративная среда была недоступна для подключения.

7. Почему реальный пилот перенесли в Behind Software

Для проверки на доступной существующей модели выбран личный проект DevTeam.Games. Его организационным контекстом является Behind Software, поэтому создано отдельное закрытое измерение в GitLab, рядом с AISMM. Оно не смешивается с DT и не заменяет модель сайта behind.software.

Существующий Product Landscape Behind Software Group переиспользован как источник связей. В графе отмечены PLMM и пять AISMM; активирован только DevTeam.Games. Остальные модели обнаружены, но не получили процессы и роли автоматически. Продуктовое содержимое не копировалось в измерение.

Для DevTeam.Games добавлен явный контракт связи с измерением и запись назначений в организационном слое b11. Владелец получил пилотные роли владельца модели, аналитика и владельца зоны, со сроком пересмотра через 30 дней. Это первоначальное подключение владельца по его поручению, а не фиктивное принятие сотрудником правил.

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

8. Что проверено и что не доказано

Результат планировщика всегда advisoryOnly. Файл с evidenceRef не является подписанным разрешением. Исполнитель обязан повторно проверять полномочия перед записью в мастер-систему. V3 подтверждает проверяемую структуру, но не достоверность фактов, действительность полномочий или безопасность произвольного действия.

9. Как должна выглядеть следующая рабочая сессия

После аутентификации и загрузки актуальных назначений агент может сказать: «Вы работаете аналитиком в модели A и владельцем зоны в модели B. Доступны исследование источников и рассмотрение находок. Вот подтверждённые задания из подключённых очередей; для этого решения нужен другой проверяющий». Если очереди нет, он сообщает об этом, а не придумывает план дня.

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

Практический вывод: развёртывание измерения завершается не появлением каталога. Нужна проверяемая связь «человек → роль и область → принятый процесс → ситуация и информация → действие → мастер-система», при сохранении владения данными и независимости клиентских контекстов.

Материалы и происхождение

• Vercy: точка входа агента, процессы, границы соответствия.
• Managed IT Service Graph: опубликованная спецификация.
• DT Dimension — закрытый репозиторий; отчёт опирается на ревизию 6161739.
• Behind Software Dimension — закрытый репозиторий; проверенная ревизия feef9bb.
• DevTeam.Games AISMM — закрытый репозиторий; интеграция 2ac063d, последующая фиксация ad9314c.

Закрытые ссылки являются указателями для уполномоченных участников, а не публичным доступом к исходным данным. Источник истории — рабочая сессия развёртывания и проверенные артефакты пилота. Будущие механизмы явно отделены от выполненного.