{
  "version": "2026-10-07.academy-reading-site-1",
  "entries": [
    {
      "module": "Академия DiCE",
      "title": "Академия DiCE",
      "label": "Об Академии",
      "url": "index.html#home",
      "text": "Академия DiCE соединяет теоретическое понимание и инженерную практику. Участник рассматривает цифровой двойник как часть управления: вместе с данными, алгоритмами, правилами, обратной связью и человеческой ответственностью.\n\nПодготовительные занятия проходят 16–28 октября, конференция «Интегрированные цифровые двойники 2026» — 29–30 октября в Санкт-Петербурге, в «Цифергаузе». Организаторы конференции — ПАО «Газпром нефть» и Цифровой центр инжиниринга. В обеих частях можно выбрать собственный рабочий вопрос и пройти от понимания к его предметному разбору."
    },
    {
      "module": "Академия DiCE",
      "title": "Оглавление Академии DiCE",
      "label": "Разделы сайта",
      "url": "index.html#paths",
      "text": "Академия собрана в три последовательных раздела. Программа показывает подготовительные события и два дня конференции. Теория объединяет вводные карты, подготовительные лекции, содержательные выступления и инженерный метод. Практика начинается с общего обзора и вводной, затем идут пять блоков: киберобъект, организация как код, нормативный контур, «Совет 2045» и взаимодействие организаций.\n\nНажмите на название раздела или нужного стенда, чтобы перейти к его началу. Стрелки просмотра продолжают единый маршрут. В PDF все слайды идут подряд, а пояснения находятся в отдельном блоке и связаны со своими слайдами. Номер практического блока задаёт порядок раскрытия материала; календарный порядок мероприятий показан в программе."
    },
    {
      "module": "Академия DiCE",
      "title": "Один рабочий вопрос проходит три шага",
      "label": "Теория и практика",
      "url": "index.html#learning",
      "text": "Участник начинает со своего рабочего вопроса, осваивает язык и принципы, пробует модель или действие в учебном случае и формулирует следующий шаг собственной работы. Опыт возвращается к исходному вопросу и уточняет его. Схема показывает путь участника через теорию и предметную практику.\n\nТеория помогает сформулировать понятия и основания. Практика позволяет наблюдать действие модели и его последствия. Выбор ветви следует на следующем экране; календарный порядок занятий раскрывается отдельно в программе."
    },
    {
      "module": "Программа",
      "title": "От первого вопроса к совместному действию",
      "label": "Как устроен маршрут",
      "url": "programme-site.html#start",
      "text": "Программа Академии начинается до конференции: подготовительные события 16–28 октября дают язык, метод и первый опыт. На конференции 29 октября связываются объект, организация и основания решения. 30 октября рассматриваются агент, пересборка работы, кооперация и роль человека.\n\nВыберите вопрос из своей работы. Предварительные события помогают освоить язык и метод. На конференции этот вопрос можно разобрать через объект, организацию, нормативное основание, агента и совместную работу. Все часы указаны по Москве. Конференция 29–30 октября проходит в Санкт-Петербурге, в «Цифергаузе»."
    },
    {
      "module": "Программа",
      "title": "До конференции: соберите язык и первый опыт",
      "label": "16–28 октября · подготовка",
      "url": "programme-site.html#preparation",
      "text": "16 октября: лекция и тестовая игра «Совет 2045», СПбПУ, 4 часа. 17 октября: экскурсия в Новой Голландии 12:00–13:30. 20 октября: онлайн-лекция по кибернетике 13:00–14:00. 22 октября: офлайн-погружение «Организация как код». 23 октября: офлайн-сессия «Методология дизрапта». 26 октября: онлайн-лекция «Динамический стандарт между организациями» 13:00–14:00. 27 октября: онлайн-лекция «От нормы к проверяемому решению» 13:00–14:00. 28 октября: онлайн-вебинар «Человеко-машинная организация» 13:00–14:00.\n\nПереходы открывают содержание темы. У смешанных событий отдельно доступны теория и практика. Все часы — МСК."
    },
    {
      "module": "Программа",
      "title": "29 октября: соединяем объект, организацию и норму",
      "label": "29 октября · первый день",
      "url": "programme-site.html#day1",
      "text": "Регистрация — 08:30–09:00. 09:00–10:30: пленарный разбор «Как меняется система управления?». 10:30–12:00: секция «Объект» и «Киберобъект». 12:20–14:00: «Организация как код» и двойники информационных систем. 15:00–17:00: «Семантика и доверие» и смарт-стандарт 4 уровня. 17:20–18:20: лаборатория первого дня. 18:40–19:40: нетворкинг и демонстрации.\n\nПерерывы: 12:00–12:20 и 17:00–17:20. Обед: 14:00–15:00. 18:20–18:40 — переходная фиксация результатов. МСК. Схема показывает порядок блоков, а вертикальные расстояния не являются шкалой длительности."
    },
    {
      "module": "Программа",
      "title": "30 октября: от работы агента к решению человека",
      "label": "30 октября · второй день",
      "url": "programme-site.html#day2",
      "text": "ИИ-навигация — 08:30–09:00. 09:00–10:30: пленарный разбор «В управляемой среде появляется агент». 10:30–12:10: «ИИ-агенты» и конструирование. 12:30–14:30: «Экосистема» и взаимодействие организаций. 15:30–17:30: смысловой блок о человеко-машинной команде и затем «Совет 2045» — 60 + 60 минут. 17:50–19:00: финальная сборка. 19:00–19:15: закрытие.\n\nПерерывы: 12:10–12:30 и 17:30–17:50. Обед: 14:30–15:30. Нетворкинг после закрытия — 19:15–20:15. Все часы МСК. Игровой номер 4 не задаёт порядок: он следует после практического блока 5."
    },
    {
      "module": "Теоретическая часть",
      "title": "Шесть вопросов связывают теорию и практику",
      "label": "Карта теоретических тем",
      "url": "theory-site.html#start",
      "text": "Теоретическая ветвь объединяет две линии. Первая — лекции и погружения перед конференцией. Вторая — два открывающих разбора и шесть секционных тем 29–30 октября. Одна тема получает общий экран принципа, чтобы содержание лекции и секции не дублировалось.\n\nПервый день движется от объекта через организацию к основаниям решения. Второй — от появления агента через пересборку работы и кооперацию к человеческому участию. Отдельные переходы ведут к соответствующим практическим блокам. Историческое происхождение инженерного метода раскрыто отдельным экраном экскурсии."
    },
    {
      "module": "Теоретическая часть",
      "title": "Граница объекта выводит решение на уровень организации",
      "label": "Границы объекта",
      "url": "theory-site.html#scales",
      "text": "Вход первого дня разбирает одну ситуацию: цифровой двойник прогнозирует рост риска отказа, а технологический процесс ещё удерживается в допустимом режиме. Продолжение работы, снижение нагрузки и обслуживание затрагивают разные ресурсы и владельцев.\n\nЧетыре содержательные позиции рассматривают применимость модели, промышленную надёжность, баланс ресурсов и организационное управление. Результат разбора — граница между локальным технологическим действием и решением организации. Эта рамка ведёт к трём темам дня: объекту, организации и семантическому основанию."
    },
    {
      "module": "Теоретическая часть",
      "title": "Модель участвует в управлении в трёх разных ролях",
      "label": "Объект и обратная связь",
      "url": "theory-site.html#object",
      "text": "Лекция по кибернетике вводит цель, состояние, сигнал, решение, действие, обратную связь и пересчёт. Локальные контуры должны согласовываться с уровнем координации; общий результат зависит от выбранных целей.\n\nСекция об объекте сравнивает три роли модели: подготовить рекомендацию человеку, поддерживать режим в заданных пределах, адаптировать стратегию к изменению условий. Организационный выбор между безопасностью, выпуском и затратами использует эти результаты и собственных владельцев решения.\n\nПодготовка: 20 октября, онлайн-лекция 13:00–14:00. Секция конференции: 29 октября, 10:30–12:00. Практический переход — теплоузел, программный ПЛК и двойник в «Киберобъекте»."
    },
    {
      "module": "Теоретическая часть",
      "title": "Совместимость и исполнение сходятся в контракте действия",
      "label": "Организация и договор",
      "url": "theory-site.html#organization",
      "text": "Подготовительное погружение показывает организацию как связное описание продуктов, требований, процессов, ролей и информационных систем. Двойник ИС описывает её функции и связи; он позволяет включать существующие системы в общий контур.\n\nСекция сравнивает два пути: сначала установить совместимость объектов и данных либо действовать через контролируемую границу доступа к функциям. Итоговая конструкция связывает смысл, роль, полномочие, исполнение и доказательство. Оба подхода обсуждаются на одном управленческом событии.\n\nПодготовка: 22 октября, офлайн-погружение. Секция: 29 октября, 12:20–14:00. Практика раскрыта в «Организации как код»."
    },
    {
      "module": "Теоретическая часть",
      "title": "Проверяемость сохраняет источник и причины решения",
      "label": "Норма и доказательство",
      "url": "theory-site.html#norms",
      "text": "Лекция объясняет три опоры решения: источник, применимость и доказательство. Источник связан с конкретной версией; применимость — с объектом и его состоянием; результат — с необходимыми свидетельствами и владельцем решения.\n\nСекция сравнивает свободное поручение и семантический контракт на одном исходном случае. Участники прослеживают причины ответа и рассматривают изменение нормы, состояния объекта или доказательства. Так раскрывается механизм доверия к основанию, а подробная сборка нормативного атома остаётся в практическом блоке.\n\nПодготовка: 27 октября, онлайн-лекция 13:00–14:00. Секция: 29 октября, 15:00–17:00. Практика — смарт-стандарт 4 уровня."
    },
    {
      "module": "Теоретическая часть",
      "title": "Агент входит в среду с целями, процессами и ответственностью",
      "label": "Агент в организации",
      "url": "theory-site.html#agency",
      "text": "Вход второго дня продолжает среду, собранную в первом: объект, организацию и основания решений. В эту среду входит агент, способный анализировать, предлагать, координировать и выполнять ограниченную работу.\n\nЧетыре содержательные позиции — возможности агента, включение в корпоративные процессы, профессиональное решение при высокой цене ошибки и изменение интеллектуальной роли человека. Они раскрывают одну ситуацию, в которой предложение агента меняет ход работы и затрагивает полномочия и последствия.\n\nПленарный разбор: 30 октября, 09:00–10:30. Далее программа переходит к пересборке работы, межорганизационной кооперации и человеко-машинной команде."
    },
    {
      "module": "Теоретическая часть",
      "title": "Дизрапт пересобирает способ получения результата",
      "label": "Пересборка процесса",
      "url": "theory-site.html#agents",
      "text": "Подготовительная сессия вводит метод дизрапта на материале управления рисками: агент помогает собрать основания и подготовить анализ, а экспертная работа сосредоточена на решениях.\n\nСекция переносит метод на задачу, инженерный процесс и управление. Сравниваются оцифровка существующей операции и новый контур, начинающийся с намерения, ресурсов, правил и ролей. Изменение условий возвращает к пересборке следующей работы.\n\nПодготовка: 23 октября, офлайн-сессия «Методология дизрапта». Конференционный блок: 30 октября, 10:30–12:10, «ИИ-агенты» и конструирование."
    },
    {
      "module": "Теоретическая часть",
      "title": "Кооперация агентов опирается на видимые договорённости",
      "label": "Правила между компаниями",
      "url": "theory-site.html#ecosystem",
      "text": "Лекция вводит динамический стандарт между организациями. Его технический слой описывает передаваемые данные и процедуры; договорный слой — приёмку, оплату, ответственность и изменения. Участники связывают возможности и интересы через явные условия.\n\nМатериалы секции раскрывают агентную кооперацию на примере совместного путешествия: предложения отдельных сервисов собираются вокруг общей цели группы. AI-Trip даёт логику кооперации, материалы ПроКСи — контрактный слой условий, версий и событий. Изменение цены, доступности или цели приводит к пересогласованию. Экономически значимое решение сохраняет владельца.\n\nПодготовка: 26 октября, онлайн-лекция 13:00–14:00. Секция «Экосистема»: 30 октября, 12:30–14:30. Текущая практика S05 раскрывает тот же уровень взаимодействия на промышленном случае расходомеров; она сохраняет собственный сюжет и роли."
    },
    {
      "module": "Теоретическая часть",
      "title": "Человеческое участие включает понимание, влияние и пересмотр",
      "label": "Человек в команде",
      "url": "theory-site.html#human",
      "text": "Подготовительные лекции и смысловой блок рассматривают место человека рядом с цифровыми двойниками, ИИ-агентами и роботами. Интеллектуальная работа и физическое действие могут делегироваться, а человеческое участие включает понимание целей и последствий, собственный выбор и возможность влиять на ход работы.\n\nПроверка и пересмотр решения связываются с ответственностью. В игре «Совет 2045» эти принципы переводятся в модель ролей и совместной деятельности; подробный ход игры раскрыт в практическом блоке 4.\n\nПодготовка: лекция и тестовая игра 16 октября, вебинар 28 октября 13:00–14:00. Конференция: 30 октября, 15:30–17:30; смысловой блок 60 минут последовательно переходит в игру 60 минут."
    },
    {
      "module": "Теоретическая часть",
      "title": "Инженерный метод связывает модель с пересмотром",
      "label": "Инженерный метод связывает модель с пересмотром",
      "url": "theory-site.html#method",
      "text": "Экскурсия 17 октября, 12:00–13:30, связывает четыре сцены инженерного метода: модель, испытание, координацию на расстоянии и пересмотр расчёта по реальности. Участник получает карту метода для следующих модулей.\n\nАвторский маршрут раскрывает преемственность инженерного метода через разные инструменты и ведёт к лекции о кибернетике."
    },
    {
      "module": "Практическая часть",
      "title": "Практическая часть Академии DiCE",
      "label": "Пять практических блоков",
      "url": "practice-site.html#home",
      "text": "Пять практических блоков сохраняют текущие схемы, сценарии и адресные раскрытия. Вводная «От модели к действию» объясняет общий метод, карту блоков и идентичность общего предметного примера. Теоретические основания и календарь открываются отдельно."
    },
    {
      "module": "От модели к действию",
      "title": "От модели — к обоснованному действию",
      "label": "Основание действия",
      "url": "overview-site.html#start",
      "text": "Цель практики — научиться превращать вывод модели в разрешённое, проверяемое и ответственное действие. Для этого сохраняем всю связь: модель → рекомендация → решение → полномочие → действие → доказательство → пересмотр. Выбор варианта, право выполнения и фактический результат — разные вещи. Рекомендация сама по себе не даёт права действовать.\n\nОбщий ритм занятия встроен в эту же схему: поставить вопрос о конкретном объекте, выполнить выбранное задание, проверить наблюдаемый результат и разобрать отклонение. Затем участник намечает применение в своей инженерной или управленческой работе. Ожидаемая польза — увидеть связь, попробовать её в опыте и перенести способ рассуждения в собственную задачу.\n\nРамка взята из прежней концепции Академии и совместима с постановкой встречи 2 октября. Это цель обучения и предложенная структура рассказа, а не отчёт о проведённых занятиях."
    },
    {
      "module": "От модели к действию",
      "title": "Пять блоков складываются в общую практику",
      "label": "Пять практических блоков",
      "url": "overview-site.html#stands",
      "text": "Киберобъект: проследить связь измерений, модели и управляющего режима в теплоузле с радиатором и вентилятором. Целевой контур объединяет физическую часть «Взлёта», программный ПЛК Северстали и цифровой двойник Дмитрия. Ожидаемые материалы — модель узла, наблюдения опыта и связанный пример документа. Подробности сборки двойника, документации и сравнения стратегий находятся в первой части.\n\nОрганизация как код: связать описания настроенных ИС с процессами, данными и правилами действия. Во второй части отдельно раскрыты обновляемые договорённости, динамика нагрузки и проект опыта с агентом в АРМ метролога.\n\nНормативный контур: найти требование, установить его применимость и связать действие с необходимыми доказательствами. Третья часть готовит основания работы сертифицирующей стороны; она не заменяет цифровой паспорт отдельного прибора.\n\nВзаимодействие организаций: пройти случай с ролями, договорённостями, событиями и решениями сторон. Подробная пятая часть показывает сертификацию, паспорт, поставку, входной контроль, возврат, изменение сертификата и проект. Ротация трёх ролей раскрыта там же.\n\nСтрелки показывают передачу материала в замысле программы, а не наличие выполненных интеграций. Связь стендов 1 и 5 через общий прибор требует выбора экземпляра и согласования данных. Текущая карта содержит пять блоков: четыре практических стенда и Disrupt-игру «Совет 2045» под номером 4. Номера не задают календарный порядок; расписание и подготовительные форматы показаны отдельно в календаре. Именованные выходы — ожидаемые артефакты; форма их фиксации и критерии согласуются для опыта.\n\nСовет 2045: команда проектирует совместную работу людей и машин, проверяет её кризисом и выбирает первые изменения сегодня. Опыт стендов может стать материалом решений Совета, а вопросы игры — гипотезами следующих опытов. Пунктир к игре означает предложенную связку, конкретные вводы согласуются со сценарием и автором."
    },
    {
      "module": "От модели к действию",
      "title": "Идентичность прибора удерживает сквозную историю",
      "label": "Сквозная история прибора",
      "url": "overview-site.html#thread",
      "text": "Общая история держится на идентичности конкретного экземпляра. Метка помогает открыть его паспорт; паспорт связывает сведения об изделии с сертификатом в его области, учётными записями и местом в проекте. Сертификат серии и паспорт экземпляра имеют разные роли, поэтому схема показывает отношения между ними, а не обязательный порядок выдачи документов.\n\nЗапись ERP, серийный номер, метка и позиция цифровой модели могут иметь разные идентификаторы. Их нужно сопоставить с сохранением владельца и основания связи. Это помогает проследить поставку, результат контроля, приёмку или возврат и найти связанные изделия при изменении статуса сертификата. Подробности этих сценариев относятся к стенду 5.\n\nДля перехода между тепловым примером стенда 1 и историей прибора стенда 5 общий объект ещё нужно выбрать. Пунктир сохраняет эту границу: тепловая физика и учёт отгрузки нефти не объявлены одним уже подключённым объектом. Карта показывает цель проектирования сквозного учебного примера, а не подтверждённую интеграцию."
    },
    {
      "module": "Киберобъект",
      "title": "DiCE связывает теплоузел, программный ПЛК и двойник",
      "label": "Теплоузел и цифровой контур",
      "url": "s01-cyber-object-site.html#start",
      "text": "В целевом стенде соединяются физический теплоузел, автоматика на программном ПЛК и цифровой двойник. Платформа DiCE обеспечивает модель, расчёт и интерфейс. ПЛК исполняет алгоритм, получает полевые сигналы и передаёт команды нагревателю и насосу через модули ввода-вывода. Измерения возвращают фактическое состояние в контроллер и модель.\n\nТепловой узел содержит нагревательный контур, циркуляционный насос, радиатор и вентилятор. Вентилятор меняет теплосъём радиатора и воспроизводит изменение внешних условий для учебного опыта. Упреждающий расчёт задаёт режим до изменения нагрузки; обычная автоматика реагирует на текущее состояние.\n\nКонтроллер находится вне трубного контура. Толстые серые стрелки обозначают циркуляцию теплоносителя, серый пунктир — данные, винные стрелки — управляющие воздействия. Уставки температуры подачи и скорости насоса сохраняются из тепловой постановки M05. Подробный маршрут полевых сигналов раскрыт отдельно. Схема показывает функциональные связи целевого стенда, а не монтажную электрическую схему."
    },
    {
      "module": "Киберобъект",
      "title": "Одна модель связывает оборудование, управление и документы",
      "label": "Одна модель · три результата",
      "url": "s01-cyber-object-site.html#assembly",
      "text": "Схема, спецификация и параметры оборудования задают состав физического узла. Из этих элементов собирается цифровая модель: состав, связи и поведение. Она служит общим основанием управления и выбранного фрагмента документации. Двойник связывает данные, расчёт режима и отклик оборудования.\n\nМонтажно-сборочная схема и спецификация конкретных моделей комплектующих нужны для физической сборки. Это входные документы оборудования. Другой документ — учебный фрагмент, который формируется из модели двойника по заданному образцу. Принцип «сначала двойник, затем его документ» относится к этому выходу.\n\nСвязь прослеживается от элемента оборудования через параметр цифровой модели к позиции документа. Образец задаёт формат и правила заполнения. Информационная модель состава и модель поведения процесса выполняют разные, связанные функции."
    },
    {
      "module": "Киберобъект",
      "title": "BlueTraktor делает модель и данные наглядными",
      "label": "Интерфейс BlueTraktor",
      "url": "s01-cyber-object-site.html#blue",
      "text": "Пример экрана HTS-001 показывает информационную модель теплового узла и привязанные параметры. BlueTraktor — программный компонент платформы DiCE. Модель поведения процесса обеспечивает расчёт, HMI — наблюдение и разбор режима.\n\nВ целевом контуре параметры оборудования связываются с полевыми сигналами. Экран даёт общую картину узла, его состояния и выбранного режима; исполнение команд проходит через программный ПЛК и физические модули ввода-вывода."
    },
    {
      "module": "Киберобъект",
      "title": "Один опыт связывает стратегию, исполнение и результат",
      "label": "Опыт с теплоузлом",
      "url": "s01-cyber-object-site.html#practice",
      "text": "Учебный опыт задаёт одно изменение теплосъёма: вентилятор усиливает теплоотдачу радиатора. При управлении по факту автоматика реагирует на текущее изменение состояния; при управлении по прогнозу двойник заранее рассчитывает режим. Оба подхода относятся к одному физическому узлу и одному сценарию нагрузки.\n\nВыбор стратегии и способ исполнения — разные части опыта. В целевой автоматизированной сборке режим исполняет программный ПЛК. Совместимый учебный вариант из прежнего обсуждения — человек действует по рекомендации двойника. Он позволяет раскрыть границы делегирования и роль оператора.\n\nСравниваются исходные условия, команды, температура, энергия и расхождение прогноза с фактом. Дополнительные эпизоды «что если», обновление входов и расхождение модели используют тот же контур. Численный эффект определяется результатами опыта. Вентилятор воспроизводит возмущение; внешний сценарий прогноза задаётся отдельно."
    },
    {
      "module": "Киберобъект",
      "title": "Три участника соединяют физику, автоматику и двойник",
      "label": "Роли участников",
      "url": "s01-cyber-object-site.html#result",
      "text": "Целевой стенд объединяет три предметные части и три вклада участников. «Взлёт» отвечает за физический теплоузел и полевое оборудование. Северсталь, представленная Иваном Ярцевым, предоставляет программный ПЛК как основу автоматизации. Дмитрий создаёт цифровой двойник и алгоритм управления.\n\nФизическая часть включает нагреватель, насос, радиатор, вентилятор и измерительные сигналы. Программный ПЛК исполняет алгоритм и обменивается с модулями ввода-вывода. Цифровой двойник использует состав узла, параметры и внешние условия для расчёта режима; HMI показывает состояние и результат.\n\nЭти части соединяются в киберобъект через общий маршрут «измерение → расчёт → команда → физический отклик». Учебные выходы — связанная модель узла, выбранный документ и наблюдения опыта — раскрываются на соответствующих страницах. Связь с другими стендами Академии строится через общий прибор, его идентичность и предметные данные."
    },
    {
      "module": "Киберобъект",
      "title": "Программный ПЛК связывает двойник с полевыми сигналами",
      "label": "Программный ПЛК связывает двойник с полевыми сигналами",
      "url": "s01-cyber-object-site.html#questions",
      "text": "Цифровой двойник задаёт целевой режим. Программный ПЛК исполняет алгоритм автоматизации и передаёт команды оборудованию через физические модули ввода-вывода. Полевые измерения и состояния возвращаются в ПЛК и цифровую модель. Программный контроллер и физический ввод-вывод — отдельные элементы одной системы.\n\nСигнал связан с конкретным объектом, параметром и единицей; команда — с адресом воздействия и пределами. В цифровом обмене каждый сигнал передаётся через свой топик или подтопик. Время и состояние помогают соотнести рассчитанный режим с фактическим откликом. Аналоговые и дискретные сигналы включают измерения температуры и давления и управление исполнительными устройствами.\n\nАлгоритм управления описывается в ST. Прогнозная модель, алгоритм ПЛК и модули I/O выполняют разные функции: рассчитать режим, исполнить логику и связать программное исполнение с полем."
    },
    {
      "module": "Организация как код",
      "title": "Организация как код: двойники систем + процессы",
      "label": "Зачем нужен стенд",
      "url": "s02-organization-as-code-site.html#start",
      "text": "Задача «внести сведения о приборе» кажется простой. В учётной системе он называется «прибор», у технических специалистов фигурирует как «КИП», то есть контрольно-измерительный прибор. Человек может связать эти записи благодаря своему опыту. Агенту нужно явно указать, какой объект имеется в виду, где лежат нужные сведения и какое действие разрешено. На стенде «Организация как код» проверяем, как такое описание помогает агенту выполнить задачу.\n\nДля руководителя это возможность увидеть, от чего зависит совместная работа систем. Инженер сможет разобрать отдельную операцию: какие знания понадобились агенту, что он сделал и какая запись появилась в результате. Модель объединяет описания конкретных систем и процессов между ними.\n\nВ первую часть модели входят цифровые двойники информационных систем (ИС), настроенных под организацию. Здесь двойник описывает данные, справочники, доступные операции и бизнес-логику в машиночитаемом виде. Один программный продукт в двух компаниях может иметь разные настройки. Чтобы выбрать поле или выполнить операцию, агенту нужно знать устройство именно той системы, с которой он работает.\n\nВторая часть модели описывает процессы: какое событие запускает работу, что нужно проверить, кто вправе действовать и какой результат должен появиться. Последовательность «событие → проверка → действие» связывает устройство системы с рабочей задачей. В описании также задают роли, разрешения, запреты и требования, на основании которых выполняют операцию.\n\nЧтобы связать записи об одном объекте, нужны идентификатор и основание этой связи. По похожим словам можно ошибочно объединить разные приборы. Согласованный смысл данных при разных названиях и справочниках называют единой семантикой организации.\n\nПо этой модели агент должен находить объект, выбирать операцию и сверять её с правилами. На стенде проверяем и его выбор, и фактическую запись в системе. Для запрещённых действий нужно отдельно проверить, срабатывает ли техническое ограничение: одного текста запрета в описании недостаточно."
    },
    {
      "module": "Организация как код",
      "title": "Две динамики дополняют архитектуру",
      "label": "Изменения и нагрузка",
      "url": "s02-organization-as-code-site.html#model",
      "text": "Информационные системы меняются: в них появляются новые поля, справочники и операции. Одновременно меняется нагрузка на них. Поэтому на стенде разбираем два вопроса: как сохранить согласованность систем после изменений и как спланировать их работу при общей нагрузке.\n\nКогда одна система меняется, другие системы и агенты продолжают пользоваться её данными. Нужно проверить, кто зависит от прежнего описания, что теперь означает запись и как выполнить согласованную задачу. Правила такого взаимодействия составляют договор системы с её окружением. В нём описано, что система предоставляет, как этим пользоваться и какие ограничения действуют.\n\nТакой обновляемый договор называем динамическим стандартом. Каждая система развивается под свои задачи, а участники проверяют затронутые связи и согласуют новую версию описания. «Договор v2» на схеме обозначает такую следующую версию.\n\nТеперь допустим, что пять процессов одновременно требуют одну и ту же вычислительную мощность. Все входы, выходы и связи описаны правильно, но ресурсов на одновременное выполнение не хватает. Какой процесс получит приоритет? Что задержится и какова будет цена задержки? Чтобы ответить, нужна модель поведения системы во времени.\n\nЕё используют для планирования и симуляции: сравнивают варианты распределения ресурсов, проверяют гипотезы о нагрузке, ищут слабые места архитектуры. Договоры помогают согласовать смысл данных и допустимые операции, а модель нагрузки позволяет оценить, как и когда удастся выполнить работу. Изменение правил может повлиять на допустимые действия; изменение нагрузки может потребовать другого порядка выполнения."
    },
    {
      "module": "Организация как код",
      "title": "Меняем модель — наблюдаем действие агента",
      "label": "Три прогона с агентом",
      "url": "s02-organization-as-code-site.html#practice",
      "text": "Агент получает одну команду: «внести сведения о приборе». В сценарии используется АРМ метролога, автоматизированное рабочее место для учёта приборов и сведений о поверках. Участник сравнивает, как агент выполняет эту задачу без согласованного описания системы, с ним и после его изменения.\n\nСначала ведущий объясняет, какой прибор выбран, какую запись нужно получить и почему она допустима. Каждый прогон начинается с одинакового исходного состояния учебной системы. Команду и входные сведения сохраняем; меняем только описание, доступное агенту.\n\nВ первом прогоне агент получает задачу без согласованной модели бизнес-логики. Наблюдаем, как он выбирает объект, операцию и поле. Он может сделать правильную запись, ошибиться или не суметь продолжить. Разбираем фактический исход: что агент смог понять из команды и каких сведений ему не хватило.\n\nВо втором прогоне подключаем описание объектов, связей, операций и правил системы. Повторяем задачу и сверяем результат с ожидаемой записью: тот ли объект изменён, в то ли поле попали данные, что сохранилось после выполнения. Ожидаем, что модель поможет агенту действовать точнее. Проверять это нужно в самой системе, поскольку убедительный ответ агента ещё не подтверждает результат операции.\n\nВ третьем прогоне намеренно меняем логику описания. Другой вариант этого же опыта: изменить саму систему, оставив агенту устаревшее описание. Повторяем задачу, находим расхождение между моделью и фактической работой системы, исправляем описание и запускаем проверку снова.\n\nДля разбора сохраняем цепочку «версия описания → выбранное действие и его основание → фактическая запись». По ней участник прослеживает, как описание повлияло на результат и что именно пришлось исправить. Ошибка без модели и успех с моделью остаются ожиданиями, которые нужно проверить. Если опыт дал другой результат, разбираем его.\n\nРазбор включает и полномочия агента. Для разрешённой операции проверяем полученную запись; для запрещённой проверяем, сработало ли ограничение и понятно ли основание отказа. Все действия выполняются в учебной среде. Участник видит, как описание данных, порядка работы и полномочий влияет на выбор агента и результат."
    },
    {
      "module": "Организация как код",
      "title": "Один принцип связывает разные масштабы",
      "label": "Между организациями",
      "url": "s02-organization-as-code-site.html#result",
      "text": "На стенде 2 мы связываем системы и процессы внутри одной компании. Когда к работе подключается другая компания, сторонам нужно договориться о смысле передаваемых сведений, своих обязательствах и событиях, на которые они будут реагировать. Этот переход раскрывает стенд 5.\n\nВ его сценарии участвуют изготовитель приборов, сертифицирующая сторона и покупатель, собирающий технологическую установку. Каждый ведёт свои записи. Изготовитель связывает паспорт изделия с сертификатом. Покупатель получает прибор, проводит входной контроль и записывает результат. Сертифицирующая сторона может изменить статус сертификата; об этом должны узнать остальные участники.\n\nЕсли сведения о приборе и результате контроля хранятся в разных системах покупателя, сначала их нужно связать внутри его организации. Затем результат проверки становится основанием для приёмки, учебной отметки об оплате или требования возврата и замены. При отзыве сертификата событие у сертифицирующей стороны должно быть связано с записями о конкретных изделиях у изготовителя и покупателя.\n\nДоговорённости сторон охватывают как обязательства, так и технические вопросы: какой объект передаётся, как он обозначен, какие сведения нужны для проверки и какие события меняют состояние процесса. Динамический стандарт описывает эти согласованные правила и порядок их изменения.\n\nМодель отдельной организации со стенда 2 становится частью взаимодействия нескольких организаций на стенде 5. Там подробно разбираются сценарии паспорта, сертификата, контроля, возврата и расчёта. Линии на карте показывают отношения между участниками; порядок операций раскрывается в самих сценариях."
    },
    {
      "module": "Организация как код",
      "title": "Как проходит показ и чему учится участник",
      "label": "Ход показа и результат",
      "url": "s02-organization-as-code-site.html#questions",
      "text": "Показ начинается с задачи о приборе. Ведущий объясняет, где находятся исходные сведения и какую запись нужно получить. Участник разбирает, почему для этой операции нужны описание системы, связи между данными и правила доступа.\n\nЗатем участник проходит три прогона с агентом. Он наблюдает за выбором объекта, операции и поля, сравнивает записи, меняет описание и проверяет результат повторного запуска. При разборе разрешённого и запрещённого действия становится видно, где проходят границы полномочий. Основанием для вывода служит сохранённая запись или зафиксированный отказ.\n\nВо второй части показа внимание переходит к общей нагрузке. Несколько процессов используют одни и те же ресурсы, и участник сравнивает варианты их распределения с помощью динамической модели. Графики и показатели сопровождают конкретный вопрос: какой процесс получает приоритет, что задерживается и какие последствия имеет это решение. Планирование и симуляция помогают связать поведение информационной системы с рабочей задачей.\n\nВедущий просит участника объяснить результат своими словами: какое описание использовал агент, почему операция допустима и где видно её выполнение. Для модели нагрузки нужно объяснить выбранный приоритет и его последствия.\n\nВ конце участник переносит тот же способ разбора на процесс своей организации. Он называет участвующие системы, связывает записи об одном объекте, определяет допустимые действия и способ проверки результата. Если система или правила меняются, эту связь проверяют заново. Следующий стенд расширяет задачу: согласовать работу изготовителя, сертифицирующей стороны и покупателя."
    },
    {
      "module": "Смарт-стандарт 4 уровня",
      "title": "Смысл нормы сохраняется в связной модели",
      "label": "От источника к нормативному атому",
      "url": "s03-smart-standard-site.html#start",
      "text": "Стенд показывает, как выбранные требования технического регулирования становятся связанным машиночитаемым основанием действий в сертификационной сцене. Начинаем с источника и его редакции, сохраняем целостное положение, затем выделяем нормативный атом с одним эффектом. Атомизация — смысловая работа, а не произвольное деление на абзацы. Нормативный атом и применимое требование имеют разные роли: требование сохраняет ссылки на соответствующие атомы и их источник.\n\nВ выбранном фрагменте задаём объект и условия применимости, необходимое действие, критерий доказательства, способ проверки, инженерный статус и владельца следующего решения. Перед опытом нужно выбрать конкретное изделие, документы и редакции, область применения и компетентную роль. Эти параметры в текущей постановке ещё требуют согласования.\n\n«Смарт-стандарт 4 уровня» — название целевого подхода этой части. Схема и один учебный фрагмент не устанавливают достижение формального уровня на всём нормативном контуре."
    },
    {
      "module": "Смарт-стандарт 4 уровня",
      "title": "Три прогона проверяют условие и источник",
      "label": "Три проверки с агентом",
      "url": "s03-smart-standard-site.html#practice",
      "text": "Проект упражнения начинается с одного выбранного требования, одного изделия и одной рабочей задачи. Сначала участник сопоставляет объяснение агента, действие, необходимые доказательства и источник. Затем меняет одно семантическое условие и смотрит, что изменилось в применимости, проверке, выводе и основании ответа. Изменение условия не обязано приводить к отрицательному результату: вывод определяется самим требованием и данными.\n\nДополнительный прогон проверяет связь с источником. Если нужную редакцию или основание нельзя подтвердить, в опыте фиксируют неопределённость и вопрос для уточнения. Работа по неподтверждённому основанию не должна скрываться под видом успешной проверки. После каждого сравнения восстанавливаем исходную модель; условие и редакцию одновременно не меняем.\n\nСтатусы PASS, FAIL, UNKNOWN и BLOCKED описывают инженерную проверку. Решение о выпуске сертификата принимает компетентная сторона в пределах своих полномочий. Механизм остановки, роль для эскалации, интерфейс агента и наблюдаемые записи нужно определить и проверить при подготовке учебной среды. Три прогона описывают ожидаемый учебный сценарий. Выход опыта — карта основания с источником, версией, условием, действием, доказательством, результатом проверки и ответственной ролью."
    },
    {
      "module": "Смарт-стандарт 4 уровня",
      "title": "Основания проверки передаются компетентной стороне",
      "label": "Основание решения",
      "url": "s03-smart-standard-site.html#result",
      "text": "Нормативный фрагмент и результаты инженерной проверки образуют основания для решения компетентной стороны. Инженерный PASS не превращается автоматически в юридическое решение или право на выпуск документа. Полномочия и область решения проверяются отдельно. Если решения о выпуске нет, в учебной сцене показываем ожидание или уточнение оснований, а не сформированный сертификат. Учебная сцена ограничена передачей оснований и решением о выпуске документа.\n\nВ постановке стенда 5 сертифицирующая сторона формирует моделируемый цифровой сертификат, который затем используется при связи с индивидуальными паспортами. Сертификат серии и паспорт конкретного изделия сохраняют разные роли; связь допустима только в выбранной области сертификата. Полная процедура сертификации сознательно остаётся за пределами этой сцены.\n\nДля подготовки показа нужно согласовать нормативную область и редакции, изделие и вид сертификации, шаблон сертификата, данные для проверки, роль с точными полномочиями и способ фиксации решения. Перед показом нужно подтвердить участие сертифицирующей стороны, её полномочия и операции интеграции для выбранного примера.\n\nНа стенд 5 передаём выбранный нормативный контур и воспроизводимый пример его применения. Детали паспортов, серийных изделий, событий статуса и взаимодействия организаций раскрываются там."
    },
    {
      "module": "Совет 2045",
      "title": "Совет 2045 проектирует совместную работу людей и машин",
      "label": "Замысел игры",
      "url": "s04-council-2045-site.html#start",
      "text": "В условной организации 2045 года люди, ИИ-агенты, цифровые двойники и роботы работают вместе. Команда становится её Советом и предлагает собственное устройство совместной деятельности: ради какого результата оно создаётся, что сохраняет человек и как связаны участники.\n\nАвторский каркас игры — построить модель, столкнуть её с изменёнными обстоятельствами, проверить роли и полномочия, пересмотреть решения и вернуться к первым изменениям сегодня. Важен не перечень функций каждой технологии, а то, как участники влияют друг на друга и сохраняется ли возможность человека действовать осмысленно.\n\nМатериалы Академии содержат авторскую программу HumanTech Lab и Александры Сапуновой; DiCE обозначен провайдером и участником фасилитации. Конкретные ведущие, участие сторон и готовность прогона подтверждаются отдельно. Календарь различает подготовительную игру и конференционный формат; номер 4 обозначает место в текущей карте практики, а не календарный порядок."
    },
    {
      "module": "Совет 2045",
      "title": "Совет задаёт роли и границы делегирования",
      "label": "Роли и делегирование",
      "url": "s04-council-2045-site.html#model",
      "text": "Совет начинает с одной совместной задачи и желаемого результата. Затем задаёт роли, связи, делегирование интеллектуальных задач агентам и физических действий роботам, использование двойников, принятие решений, проверку результатов и ответственность.\n\nВозможности технологии не определяют её право действовать. Нужно описать, что поручено участнику, в каких пределах он действует, как проверяется его результат и кто может остановить или пересмотреть ход работы. На схеме показаны типы участников и вопросы модели, а не готовая матрица полномочий для любой организации.\n\nЧеловеческое участие включает понимание ситуации, оценку целей и последствий, собственный выбор и возможность влиять на происходящее. Оно не сводится к бесконечной ручной перепроверке системы. Команда ищет устройство, в котором совместная работа даёт понятный результат и сохраняет осмысленное участие человека."
    },
    {
      "module": "Совет 2045",
      "title": "Кризис возвращает модель на проверку",
      "label": "Кризисная проверка",
      "url": "s04-council-2045-site.html#crisis",
      "text": "Кризисная проверка меняет обстоятельства и показывает, достаточно ли ясны роли, полномочия и ответственность. Команда разбирает, кто замечает проблему, может ли остановить или пересмотреть действие системы и сохраняет ли человек возможность влиять на происходящее. Изменения модели должны иметь объяснимые основания.\n\nВерхние четыре входа — предложение для связи Академии. Ошибка прогноза из киберобъекта позволяет обсуждать выбор стратегии и право остановки. Изменённая рамка агента — делегирование и пределы действий. Потерянная связь с редакцией нормативного источника — основания проверки и решения. Отзыв сертификата — оповещение, область события и ответственность сторон.\n\nНеверный прогноз и отзыв сертификата уже названы в контексте Академии как возможный мост; два других входа являются редакционными кандидатами. Эти примеры не объявлены утверждёнными правилами «Совета 2045». Автор и фасилитаторы выбирают конкретную задачу, ввод, исходные данные, порядок обсуждения и способ фиксации пересмотра."
    },
    {
      "module": "Совет 2045",
      "title": "Из игры выходит модель команды и первый шаг сегодня",
      "label": "Первый шаг после игры",
      "url": "s04-council-2045-site.html#transfer",
      "text": "Итоговый артефакт авторской программы — рабочая модель человеко-машинной команды: распределение ролей, пределы делегирования, порядок принятия/проверки/пересмотра решений, ответственность и предложения первых изменений. В исходной программе этот выход назван HumanMachineTeam2045Model.\n\nПрактическая форма первого изменения предлагается как три поля: кто берёт следующий шаг, что можно проверить в работе и по какому наблюдению станет виден результат. Конкретный шаблон и выбор действия согласуются для прогона. Игра не назначает реальных исполнителей и не предоставляет системе production-полномочия.\n\nНаблюдения других стендов могут стать материалом этого изменения, а вопросы Совета — гипотезами следующего опыта с объектом, организацией, нормативным основанием или взаимодействием сторон. Такой учебный цикл является предлагаемой связкой. В студенческой линии игра также помогает описать образ инженера будущего: что он понимает, чему учится, что передаёт системе и за что отвечает."
    },
    {
      "module": "Взаимодействие организаций",
      "title": "Три организации связаны двумя договорами",
      "label": "Организации и договоры",
      "url": "s05-agent-interaction-site.html#start",
      "text": "Смарт-стенд соединяет три деловые роли: сертифицирующую сторону, изготовителя и покупателя, собирающего технологическую установку. В сценарии эти роли названы «Русский регистр», «Взлёт» и ОЙЛТИМ. Участие сторон, их точные полномочия и готовность конкретных функций подтверждаются при подготовке.\n\nДва договора имеют разные входы и результаты. Сертификационный связывает нормативное основание, область сертификата и выпуск изделий. Поставочный задаёт предмет, параметры, передачу, приёмку, расчёт и обязательства при расхождении. К договорным обязательствам добавляются технические условия: поля, форматы, ссылки и допустимые операции обмена. Конкретные состояния договоров выбираются для сцены.\n\nНормативный контур раскрывается на стенде 3, внутреннее описание организации и двойников её ИС — на стенде 2, а общие условия и события между организациями — здесь. Эти периметры связаны, но у них разные владельцы и задачи. У каждой организации сохраняются собственные данные, агент, возможности, запреты и ответственность."
    },
    {
      "module": "Взаимодействие организаций",
      "title": "Два экземпляра сохраняют свою цифровую историю",
      "label": "История двух экземпляров",
      "url": "s05-agent-interaction-site.html#identity",
      "text": "Сертифицирующая сторона формирует моделируемый цифровой сертификат по выбранному шаблону и требованиям. Его издатель, область изделий, реквизиты и текущий статус должны быть объяснимы. Полная процедура сертификации рассматривается отдельно; выпуск и изменение статуса требуют полномочий конкретной роли.\n\nИзготовитель с агентом заполняет индивидуальный паспорт каждого из двух расходомеров, связывает его с сертификатом в нужной области и через BIMAR привязывает к физической метке. Серийный экземпляр, номенклатурный код, паспорт и запись ИС сохраняют разные идентификаторы; между ними нужен проверяемый способ сопоставления. Способ маркировки, подпись/источник доверия, схема данных и место хранения выбираются для показа.\n\nПокупатель сканирует один прибор и получает именно его паспорт, связанный статус сертификата и условия поставки. Это вход следующей проверки. Сканирование не доказывает отсутствие физического дефекта и не завершает приёмку. У двух приборов заранее согласуется демонстрационный дефект, но участнику не сообщают, какой экземпляр неисправен. Дальше один и тот же паспорт сопровождает контроль, движение, новые события и место в проекте."
    },
    {
      "module": "Взаимодействие организаций",
      "title": "Три проверки задают ветвь поставки",
      "label": "Проверки и ветви поставки",
      "url": "s05-agent-interaction-site.html#control",
      "text": "Контролёр ОЙЛТИМ сканирует метку в BIMAR и проводит три самостоятельные проверки: относится ли действующий сертификат к паспорту, соответствует ли прибор заказанному типу и параметрам, нет ли физического дефекта по чек-листу. Пример расхождения типа — заказан датчик давления, а доставлен расходомер. Действующий сертификат не отменяет физический дефект. Осмотр выполняет участник, а доказательство может включать фотографию и описание.\n\nЕсли контроль пройден и приёмка подтверждена уполномоченной ролью, согласованная сцена сохраняет хозяйственную запись ERP и событие/статус расчёта в контрактном контуре. Точные права и очередность учёта и расчёта нужно согласовать; демонстрация использует моделируемый платёж, без утверждения о выполненном банковском переводе.\n\nПри подтверждённом браке прибор помещают в изолятор, сохраняют причину и доказательства, запускают предусмотренный договором порядок возврата или замены и извещают изготовителя. При физической передаче на возврат складовщик сканирует тот же экземпляр; появляется отдельное событие «отгружен на возврат». Оно не подтверждает получение изготовителем, завершённую замену или закрытие обязательства. Спор, подтверждение поставщиком, сроки и повторный контроль замены требуют своих условий.\n\nПунктирная ветвь «прочее» — предлагаемое место разбора недостаточных данных и иных несоответствий. Неясный результат не подменяется успешной приёмкой или доказанным дефектом. Простые сверки выполняет код; временное использование агента вместо неготовой сверки возможно только как обозначенный режим показа."
    },
    {
      "module": "Взаимодействие организаций",
      "title": "Место прибора и статус сертификата учитываются отдельно",
      "label": "Установка и сертификат",
      "url": "s05-agent-interaction-site.html#installed",
      "text": "Принятый прибор связывают с проектом и 3D-позицией технологического блока в BIMAR ОЙЛТИМ. Паспорт сохраняет связь с конкретным экземпляром. Отдельно указывается фактическое состояние: прибор на складе, ему назначено плановое место или монтаж подтверждён. Цифровая позиция не доказывает физическую установку. Информационная модель сборки состоит из связанных моделей её компонентов.\n\nПозднее сертифицирующая сторона может инициировать учебное событие изменения статуса сертификата. Для него заранее задают область, временную границу и набор затронутых паспортов. Контрактный контур передаёт сигнал покупателю и изготовителю, а дальнейший порядок определяется согласованными условиями. Не следует автоматически переносить событие на все исторические изделия. Последствия для уже установленных приборов и конкретный порядок замены нужно определить отдельно.\n\nBlueTraktor относится прежде всего к киберобъекту: он показывает модель, измерения, расчёты и HMI физического узла. BIMAR поддерживает паспорт, метку, контроль и проект; CLBS и ПроКСи — хозяйственные записи и события сторон. Для связи со стендом 1 нужен общий прибор и сопоставление «ID экземпляра ↔ паспорт ↔ объект модели». Прямой обмен и готовая интеграция между этими контурами не утверждаются."
    },
    {
      "module": "Взаимодействие организаций",
      "title": "Каждая система и каждый исполнитель имеют свою роль",
      "label": "Системы и исполнители",
      "url": "s05-agent-interaction-site.html#architecture",
      "text": "Внутри каждой организации агент опирается на описание конкретной ИС: сущности, операции, смысл данных, возможности, запреты и правила обращения к роли, которая принимает решение. CLBS/ERP поддерживает хозяйственную модель, договоры, заказ и приборные записи. BIMAR у изготовителя связывает паспорт и метку, у покупателя — сканирование, чек-лист, доказательства и позицию проекта. ПроКСи предоставляет согласуемый контрактный и прикладной контур общих условий и событий.\n\nЛогические периметры организаций и физическая топология платформы — разные сведения. Из этой схемы не следует, что нужны три одинаковые физические установки. Топологию, доступы, ресурсы, эксплуатацию и восстановление проверяют на выбранной среде. Данные и идентификаторы сохраняют своих владельцев; организация получает собственный доступ к общим событиям и обновляет свою ИС по согласованной операции.\n\nКод выполняет вычислимые сверки, формат и простые обмены. Агент интерпретирует описание и связывает нетривиальный контекст, используя разрешённые инструменты. Человек проводит физический осмотр, принимает полномочное решение и разбирает неопределённость. Наличие инструмента или инженерный PASS не создают полномочия.\n\nДля CLBS нужны модель/справочники, список доступных операций, полные args и ответы, ограниченная роль адаптера, управление Ticket и ошибками, примеры запросов и восстановление. Известный PDF показывает интеграцию с 1С, но не специфицирует все операции этого стенда. Для BIMAR нужно уточнить продукт, версию, владельца данных и интерфейсы паспортов, контроля и проекта. Для ПроКСи — модели двух контрактов, методы, схемы, права, ошибки, профиль идентичности, эксплуатация и воспроизводимые события. Заявленный поставщиком стек раскрыт отдельно; готовое развёртывание и интерфейсы конкретной сцены не подтверждены. Агентная инфраструктура и доступ к моделям — отдельный пакет команды стенда."
    },
    {
      "module": "Взаимодействие организаций",
      "title": "Три предметных пакета собирают учебный случай",
      "label": "Предметные пакеты",
      "url": "s05-agent-interaction-site.html#handoffs",
      "text": "Пакет изготовителя: два различимых расходомера и контролируемый демонстрационный дефект, шаблон и пример паспорта, поля и серийные ID, параметры связи с сертификатом, способ маркировки и действия передачи. Данные адресуются BIMAR, CLBS, команде агента и нормативной стороне. Проверяемое проявление — сканирование каждого экземпляра открывает именно его паспорт с нужными связями.\n\nПакет сертифицирующей стороны: конкретные требования и редакции, изделия и область сертификата, шаблон, способ выпуска и хранения, событие изменения статуса, его охват и последствия, точные роли и право изменения/решения. Ограниченный пример согласуется с нормативной командой; он не утверждает полноту нормативного контура.\n\nПакет покупателя: предмет и параметры заказа, обязательства при расхождении, чек-лист физического контроля и доказательства, операции приёмки/изоляции/возврата и их подтверждения, 3D-модель установки, позиция и фактическое местонахождение. Участник должен объяснить, почему прибор принят или изолирован и где он находится.\n\nКаждый пакет включает подготовленные примеры, открытые вопросы, технического контакта и представителя для совместной проверки. Это предлагаемое разбиение подготовки, а не новое назначение ресурсов или подтверждение участия. Общий прогон проверяет конкретную передачу между сторонами; готовность одной компоненты не утверждает готовность всего случая."
    },
    {
      "module": "Взаимодействие организаций",
      "title": "Прогон подтверждает результат каждой сцены",
      "label": "Результат каждой сцены",
      "url": "s05-agent-interaction-site.html#readiness",
      "text": "DiCE собирает сценарий, роли, стартовые состояния станций, инструкции и восстановление. Для агентной работы нужны описание ИС, действия/запреты, узкие инструменты и доступ к моделям. Для интеграции — согласованные схемы входов/ответов, права, ошибки, ID, наблюдение событий и подтверждение действий. Инфраструктура ИИ, технические пакеты и предметный пример должны соединиться в одном воспроизводимом прогоне.\n\nПервый связанный срез проходит сертификат, паспорта двух приборов, метки, три проверки и наблюдаемый исход приёмки или изоляции. Затем проверяют возврат, изменение сертификата, место в проекте и технически отрицательный запрос. Этот порядок помогает найти разрывы, не сокращая объём предусмотренных сцен.\n\nВ отрицательной технической сцене заранее выбирают нарушение согласованной формы данных: поле, тип или обязательную ссылку. Сохраняют причину отказа, исправляют форму и повторяют тот же случай. Выбранный проверяемый отказ не заменяет предметный дефект. Полный контрольный список сохранён в адресном раскрытии.\n\nУспех транспорта, создание заявки, результат обработки и бизнес-событие фиксируются раздельно. Неизвестность, повтор, конфликт и восстановление требуют своих правил; отправка сообщения не доказывает выполнение операции. До прогона нужно согласовать ID и маркировку, область сертификата, последствия отзыва, два контракта, доступные методы, права подтверждения, отрицательные варианты, сброс и тайминг. Для каждой функции предъявляют наблюдение выбранной сцены и её ещё не реализованную часть. Подтверждение участия партнёра и готовность его функции — отдельные сведения."
    },
    {
      "module": "Взаимодействие организаций",
      "title": "Три группы проходят все деловые роли",
      "label": "Ротация деловых ролей",
      "url": "s05-agent-interaction-site.html#rotation",
      "text": "Каждая из трёх групп проходит сертифицирующую сторону, изготовителя и покупателя. На первой станции участник заполняет данные сертификата и может инициировать заданное изменение его статуса. На второй — формирует паспорт с агентом и связывает физическую метку. На третьей — сканирует, проводит физический контроль, фиксирует отклонение, принимает или изолирует, оформляет возврат и находит прибор в проекте.\n\nПорядок рассказа может начинаться с сертификации, но параллельный старт групп не обязан повторять эту хронологию. Для каждой станции нужны подготовленные входы, понятный режим сброса, доступы и полномочия участников. Численность групп, длительность, инструкторы и восстановление согласуются отдельно. Три станции — роли внутри стенда 5, а не стенды 1–3.\n\nПрактика одновременно исследует механизм межорганизационного взаимодействия и вовлекает участника через собственное действие. В результате он сохраняет след одного случая и объяснение решений с разных позиций. Возможные измерения — ручные переходы между ИС, время, полнота следа и выявленные несоответствия. Эффективность и численное преимущество требуют собственного сравнения; они заранее не заявлены."
    },
    {
      "module": "Взаимодействие организаций",
      "title": "Объекты и состояния сохраняют разные идентичности",
      "label": "Объекты и состояния сохраняют разные идентичности",
      "url": "s05-agent-interaction-site.html#app-data",
      "text": "Один прибор проходит несколько независимых осей состояния. Сертификат может изменить статус после приёмки; прибор может быть на складе или в изоляторе, а позиция в проекте — пока только плановой. ID номенклатуры и MDM-заявки не равен серийному ID. Для схемы нужны явные владельцы записей и правила связей.\n\nПрибор и метка. Владелец / связь: Экземпляр ↔ его паспорт. Что различать: Серийный экземпляр и код номенклатуры.\n\nПаспорт. Владелец / связь: Изготовитель; сертификат, проект и события. Что различать: Индивидуальный документ и сертификат серии.\n\nСертификат. Владелец / связь: Издатель, область, дата/номер и статус. Что различать: Применимость, действие и отзыв.\n\nДоговор и событие. Владелец / связь: Стороны, условия, версия и результат операции. Что различать: Сертификация и поставка.\n\nПроверка / движение. Владелец / связь: Контролёр, причина, доказательство и место. Что различать: Контроль, изолятор, отгрузка, склад/монтаж.\n\nУчёт / расчёт. Владелец / связь: Хозяйственная запись и статус расчёта. Что различать: Принятая заявка, обработка, бизнес-событие."
    },
    {
      "module": "Взаимодействие организаций",
      "title": "CLBS API: авторизация, вызов и состояние обработки",
      "label": "CLBS API: авторизация, вызов и состояние обработки",
      "url": "s05-agent-interaction-site.html#app-clbs",
      "text": "Login выдаёт временный Ticket. ExecuteEx принимает CalcId, args и ticket. Справочники и пакет заказов описаны в спецификации интеграции CLBS с 1С. Подключение требует базового адреса API, полных схем параметров и ответов выбранных операций. Тип RequestId зависит от системы. Чтение и запись классифицируются по смыслу операции; секреты и Ticket обрабатывает клиент адаптера."
    },
    {
      "module": "Взаимодействие организаций",
      "title": "Адаптер CLBS ограничивает инструменты агента",
      "label": "Адаптер CLBS ограничивает инструменты агента",
      "url": "s05-agent-interaction-site.html#app-clbs-tools",
      "text": "Клиент CLBS выполняет авторизацию, сериализацию, вызов и обработку ошибок. Адаптер предоставляет ограниченный набор инструментов чтения и записи, соответствующих задачам стенда. Для каждого инструмента задаются вход, права, типизированные ошибки и наблюдаемый результат. Расчёты из спецификации интеграции с 1С служат основой подключения; операции паспорта, сертификата, контроля, учёта и расчёта требуют отдельных спецификаций."
    },
    {
      "module": "Взаимодействие организаций",
      "title": "Стек ПроКСи: прикладной и инфраструктурный уровни",
      "label": "Стек ПроКСи: прикладной и инфраструктурный уровни",
      "url": "s05-agent-interaction-site.html#app-proksi",
      "text": "Базовый стек включает Linux, криптографический слой и реестр на основе форка Fabric 2.5.10. Прикладной уровень использует Контрактиум и методы ПроКСи. Идентичность и обмен опираются на DID, VC, VP и профиль ANP с ГОСТ/VDR. Для подключения стенда фиксируются конкретные форматы, права и прикладные методы. Цифровые подтверждения и сертификат соответствия продукции связываются отдельной моделью данных."
    },
    {
      "module": "Взаимодействие организаций",
      "title": "Интеграция различает запрос, запись и результат действия",
      "label": "Интеграция различает запрос, запись и результат действия",
      "url": "s05-agent-interaction-site.html#app-integration",
      "text": "Каждый интерфейс должен возвращать понятный результат с владельцем ID. Успешное обращение может лишь означать принятие запроса. Отдельно надо наблюдать запись и завершение бизнес-операции. Для повторов и неопределённого результата заранее задаются правила проверки состояния и восстановления. Криптографическое подтверждение и сертификат соответствия продукции сохраняют разные функции.\n\nИС ↔ адаптер. Вход и результат: Схема операции; типизированный ответ. Что подтвердить: Права, ошибки, ID и состояние обработки.\n\nАгент ↔ прикладной слой. Вход и результат: Разрешённое деловое действие. Что подтвердить: Границы действия и способ подтверждения.\n\nКонтракт ↔ стороны. Вход и результат: Событие и связанное обновление своей ИС. Что подтвердить: Кто читает, пишет и согласует результат.\n\nПовтор / неизвестность. Вход и результат: Тот же случай, запрос или событие. Что подтвердить: Корреляция, повторяемость и восстановление."
    },
    {
      "module": "Взаимодействие организаций",
      "title": "Матрица прав задаётся для конкретных действий",
      "label": "Матрица прав задаётся для конкретных действий",
      "url": "s05-agent-interaction-site.html#app-authority",
      "text": "Право выполнения определяется для конкретной операции: выпуска сертификата, публикации паспорта, приёмки, возврата или расчёта. Инструменты агента и контрактный обработчик используют выданную роль с ограничениями чтения и записи. Решения, требующие компетенции человека, передаются соответствующему участнику. Владелец системы подтверждает права доступа, владелец операции — допустимый результат.\n\nВыпуск / отзыв сертификата. Роль в сцене: Участник «Русского регистра». Что согласовать: Область, основания и право изменения.\n\nПаспорт / метка. Роль в сцене: «Взлёт» и разрешённые инструменты. Что согласовать: Владельца данных, публикацию и обновление.\n\nКонтроль / приёмка. Роль в сцене: Контролёр ОЙЛТИМ. Что согласовать: Осмотр, доказательство и полномочие принять.\n\nВозврат / расчёт. Роль в сцене: Покупатель, изготовитель, контракт. Что согласовать: Подтверждения, спор и завершение.\n\nДоступ агента. Роль в сцене: Выданная роль и внутренняя рамка. Что согласовать: Чтение, запись, запреты и эскалацию."
    },
    {
      "module": "Взаимодействие организаций",
      "title": "Полный прогон покрывает положительные и отрицательные сцены",
      "label": "Полный прогон покрывает положительные и отрицательные сцены",
      "url": "s05-agent-interaction-site.html#app-tests",
      "text": "Ведомость служит основой сценарного теста. В одном проходе нельзя засчитать возврат только по отправке или оплату только по успешному запросу. Если часть сцены имитируется, это отмечается рядом с наблюдением. Полный перечень охватывает от сертификата до проекта и отрицательных вариантов, сохраняя различие введённых данных и физического осмотра.\n\nСертификат → паспорт → метка. Проверяемый след: Издатель, область и идентичность экземпляра. Признак завершения: Связаны все три объекта.\n\nТри проверки и приёмка. Проверяемый след: Разные результаты; учёт и моделируемый расчёт. Признак завершения: Приёмка, учёт, статус расчёта.\n\nБрак и возврат. Проверяемый след: Доказательство, изолятор, уведомление и отгрузка. Признак завершения: Есть событие отгрузки.\n\nИзменение сертификата. Проверяемый след: Заданные затронутые паспорта и сигнал. Признак завершения: Есть сигнал у выбранных приборов.\n\nПроект и место. Проверяемый след: Связь экземпляра с позицией; склад/монтаж. Признак завершения: Позиция и состояние размещения.\n\nНеверный формат. Проверяемый след: Причина отказа и повтор исправленной формы. Признак завершения: Отказ и исправленный повтор."
    }
  ]
}