Стенд 5. Цифровое взаимодействие организаций и агент с ограниченным мандатом

ЛАБОРАТОРНАЯ РАБОТА · СТЕНД 5

Цифровое взаимодействие организаций и агент с ограниченным мандатом

Методические указания по выполнению лабораторной работы

Три станции: изготовитель приборов, сертифицирующая организация, покупатель и комплектатор технологического блока.

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

Основной источник: транскрипт рабочей встречи «ПроКСи и стенд агентной экономики» от 19 октября 2026 года, продолжительность записи 01:24:30.

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

DiCE · 22 октября 2026 года

Содержание и порядок работы с методичкой

Как читать документ

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

Основная программа: паспорта и метки двух приборов; сертификат и его связи; агентный деловой и защитный опыты на станции 2; входной контроль; уведомление о дефекте; связь принятого компонента с паспортом блока.

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

1. Назначение, цель и задачи работы

1.1. Назначение стенда

Стенд показывает цифровую экосистему из трёх самостоятельных организаций. Каждая организация выполняет собственные действия и получает нужную ей часть сведений через общий контур смарт-контрактов. На физическом примере двух приборов прослеживается связь «изделие — паспорт — сертификат — событие поставки — результат контроля — состав технологического блока».

В исходном обсуждении роли названы «Взлёт», «Русский регистр» и ОЙЛТИМ. На встрече 19 октября для учебного показа предложены условные обозначения: изготовитель, сертифицирующая организация, покупатель / комплектатор. Названия компаний в источниках не заменяют подтверждение их участия или юридических полномочий.

1.2. Цель работы

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

1.3. Задачи участника

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

• Наблюдать публикацию сведений и появление результатов на другой станции.

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

• Сравнить штатный запуск агента с запуском при изменённом условии мандата; отдельно различить предупреждение и запрет.

• Провести входной контроль: соответствие заказу, сведения о сертификате, физический осмотр.

• Передать сообщение о несоответствии изготовителю и связать принятый прибор с паспортом блока.

1.4. Ожидаемый результат

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

Основание: [Т19], 00:00:00–00:05:26; 00:25:14–00:33:36; 01:05:58–01:09:19.

2. Краткие теоретические сведения

2.1. Что именно исследуется

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

2.2. Разделение ответственности

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

Основание: [Т19], 00:06:37–00:20:36; 00:44:50–00:45:39; 00:50:06–01:09:19.

3. Состав стенда

3.1. Основные части

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

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

Станция 3 — покупатель / комплектатор. Рабочее место сканирования, входного контроля, фиксации результата и создания связи компонента с паспортом технологического блока.

Общая платформа. Контур идентификации, общих записей, согласованных функций и событий. По транскрипту используется решение ПроКСи. Число серверов, узлов реестра и их фактическое размещение не определены.

Основание: [Т19], 00:25:14–00:26:57; 00:32:17–00:35:56; 00:46:01–00:48:30.

3.2. Оборудование и программные части

3.3. Границы состава

В более ранних материалах DTconf дополнительно описаны CLBS / ERP, договорные записи и связи с другими стендами. На встрече 19 октября основное взаимодействие разбирается между BIMAR и платформой ПроКСи. Отдельная ERP не объявляется обязательным установленным компонентом этой лабораторной.

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

Основание: [Т19], 00:03:13–00:05:26; 00:08:26–00:09:30; 00:23:35–00:24:44; 00:39:19–00:44:24.

4. Объекты данных и прослеживаемость

Что нужно установить по каждому экземпляру

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

На станции изготовителя видна связь «паспорта → сертификат», на станции сертифицирующей организации — обратный перечень «сертификат → паспорта». У покупателя добавляется связь «паспорт блока → паспорт принятого прибора». Сертификат прибора и возможный сертификат всего блока — разные документы.

Основание: [Т19], 00:07:17–00:12:27; 00:28:45–00:31:46; 00:43:50–00:44:06; 00:46:01–00:48:30.

5. Общая последовательность взаимодействия

Условия связи эпизодов

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

В BIMAR покупателя данные могут обновляться постоянно через согласованный обмен. На встрече специально уточнено: сканирование открывает карточку, а не обязательно запускает единичный запрос на платформу. В отчёте указывается фактически реализованный способ и время обновления.

Основание: [Т19], 00:32:17–00:34:55; 00:47:35–00:48:30.

6. Подготовка, исходные данные и безопасность

6.1. Подготовка участника

1. Прочитать разделы 1–5, найти на схемах свой текущий участок работы.

2. Объяснить различия между прибором, паспортом, сертификатом и записью события.

3. Получить номер учебного прогона, роль и форму журнала. A / B в схемах — условные обозначения, не выданные серийные номера.

4. Проверить вместе с ведущим вход в учебные интерфейсы. Секреты и токены не копировать в отчёт, чат агента или снимки экрана.

5. Зафиксировать, какие действия выполняются участником, какие показывает инструктор, а какие недоступны.

6.2. Комплект исходных данных

• Два прибора с различимыми метками и согласованными индивидуальными паспортами.

• Образец сертификата с реквизитами, областью и статусом; разрешение на использование в учебном показе.

• Условия заказа: какой тип и параметры должны поступить покупателю.

• Согласованный чек-лист входного контроля и один способ имитации дефекта.

• Учебный паспорт технологического блока и определённое место выбранного компонента в его составе.

• Доступная спецификация платформы, соответствия полей BIMAR, контакты технических ответственных.

• Для станции 2 — исходный документ карточки, мандат, разрешённая операция и один контролируемо изменяемый параметр запуска.

6.3. Правила безопасной работы

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

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

Основание сценарных входов: [Т19], 00:23:35–00:24:44; 00:37:05–00:44:24; 00:49:33–00:49:57; 01:09:47–01:12:29. Правила безопасной организации опыта сформулированы для этой методички.

7. Организация занятия и ротация групп

7.1. Режим проведения

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

Три станции работают как части одной истории. Номер станции 2 не означает, что сертификат выпускается после изготовления. Ведущий согласует моменты появления сертификата, публикации паспортов, физической передачи прибора и возврата результата контроля.

7.2. Повторные круги

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

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

Основание: [Т19], 00:25:14–00:26:57; 01:09:24–01:09:36; 01:10:43–01:12:29. Схема распределения групп — методическое предложение.

8. Станция 1. Изготовитель приборов

8.1. Цель, входы и результат

Цель: выпустить цифровые паспорта двух различных экземпляров, связать их с метками и сертификатом, наблюдать последующее сообщение покупателя.

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

Результат: каждый прибор открывает собственный паспорт, на платформе видны две отдельные записи, а связь с общим сертификатом наблюдается с обеих сторон.

8.2. Порядок выполнения

1. Установить экземпляры. Сверить модели и заводские номера с выданными исходниками. Записать обозначения двух приборов в форму 1. Не присваивать один ID двум экземплярам.

2. Создать паспорта в BIMAR. Использовать шаблон паспорта прибора из приложения Д. В подготовленном интерфейсе заполнить согласованные поля каждого паспорта. Если обязательного значения нет, отметить разрыв и запросить исходник; не заполнять поле по догадке.

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

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

5. Наблюдать сертификат. Если нужного сертификата пока нет, зафиксировать отсутствие доступной связи. После сигнала станции 2 повторить чтение и проверить издателя, область и относящиеся экземпляры. Связь устанавливается только доступной согласованной функцией, а не произвольной записью агента.

6. Сверить обратную видимость. Попросить станцию 2 показать два паспорта в области сертификата. Совпасть должны конкретные экземпляры, а не только название модели.

Основание: [Т19], 00:20:47–00:24:44; 00:26:57–00:33:36.

8.3. Передача прибора и обратное сообщение

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

8. Получить результат контроля. Дождаться согласованного события от покупателя. Открыть запись, проверить ID прибора, результат, причину и связанную ссылку на фотографию, если она включена в показ.

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

10. Проследить второй экземпляр. Для положительной ветви использовать второй прибор с его собственным паспортом. Если возврат или замена показываются, отдельно отметить фактически выполненные шаги. Уведомление о браке не равно завершённой замене.

8.4. Контроль результата станции

Вопросы на станции

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

Основание: [Т19], 00:35:56–00:44:24; 00:47:35–00:48:30. Контрольные формы — методическая развёртка.

9. Станция 2. Сертификат и агентное взаимодействие

9.1. Смысл станции

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

• Деловой сценарий: получить исходные сведения, заполнить карточку, выполнить разрешённую запись и найти паспорта в области сертификата.

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

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

Основание: [Т19], 01:00:00–01:06:18; 01:06:27–01:09:19.

9.2. Деловой опыт: агент выполняет поручение

1. Открыть исходные документы. Открыть сертификат [СК] и шаблон приложения Е. Найти номер, издателя, изготовителя, область и срок по источнику. Не переносить учебную запись в реальные реестры.

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

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

4. Проверить подготовленную карточку. Сравнить сведения с исходником; расхождения ТУ и дат разобрать по приложению Е. Полный формуляр и названия полей задаются согласованной схемой платформы. Отдельный интерфейс подготовки заранее не предполагается.

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

6. Повторно прочитать результат. Открыть карточку на платформе и сравнить с исходными сведениями. Сообщение агента «готово» не заменяет чтение записи.

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

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

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

Основание: [Т19], 01:01:44–01:03:54; 01:05:58–01:06:18. Тексты поручений и контроль шагов — методическое оформление.

9.3. Защитный опыт: мандат и изменение запуска

Что сравнивается

В демонстрации ПроКСи описывались идентификатор агента, выданный владельцем мандат, настройки AGENTS.md, доступные инструменты и параметры запуска. На примере изменения seed с 42 на 7 показывался конфликт запуска с мандатом. Эти числа — пример из записи, а не обязательные настройки данной лабораторной.

Порядок выполнения

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

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

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

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

5. Повторить ту же разрешённую операцию. Сравнить идентичность, результат проверки конфигурации, реакцию допуска и состояние целевого объекта. Записать, что именно отклонено: идентификация, допуск к функции или сама операция.

6. Подтвердить отсутствие защищённого эффекта. При отказе повторно прочитать объект и убедиться, что действие не выполнено. Одна надпись «отказ» без проверки результата недостаточна.

7. Восстановить согласованное состояние. Вернуть утверждённый запуск либо получить новое разрешение предусмотренным способом. Повторный штатный опыт выполнять только после подтверждения ведущего.

Основание: [Т19], 00:13:52–00:20:36; 01:06:27–01:09:19. Проверка результата и восстановление — требования методики проведения опыта.

9.4. Предупреждение, отказ и дополнительные эпизоды

Две разные реакции платформы

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

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

9.5. Отзыв сертификата — отдельный опыт

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

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

Что не является обязательным опытом

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

Основание: [Т19], 00:11:16–00:12:27; 00:51:16–00:52:32; 00:55:02–00:56:12; 01:04:01–01:09:19.

10. Станция 3. Покупатель и комплектатор

10.1. Цель, входы и результаты

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

Входы: физический прибор и метка; индивидуальный паспорт; сведения сертификата; условия заказа; согласованный чек-лист; BIMAR покупателя; канал обмена с платформой; паспорт технологического блока.

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

Основание: [Т19], 00:03:49–00:05:15; 00:33:36–00:44:24; 00:46:01–00:48:30.

10.2. Получение и входной контроль

1. Принять физический экземпляр для осмотра. Зафиксировать его поступление на станцию, не называя это автоматически положительной приёмкой. Сверить с передачей, отмеченной станцией 1.

2. Сканировать метку в BIMAR. Открыть карточку и убедиться, что она относится именно к полученному экземпляру. Проверить соответствия метки, заводского номера и платформенного ID.

3. Проверить актуальность данных. Указать, откуда BIMAR получил паспорт и статус: постоянное обновление, настроенный запрос или иной реально подготовленный путь. На встрече описан постоянно обновляемый набор данных; само сканирование только открывает нужный элемент.

4. Сопоставить с заказом. Проверить тип, модель и согласованные параметры. В обсуждении приводился пример расхождения «заказан датчик давления, получен расходомер». Это иллюстрация, а не назначенные параметры нашего заказа.

5. Проверить сертификат. Найти издателя, область и статус; установить, относится ли он к этому прибору. Не считать наличие файла достаточным подтверждением нужной области. Если источник статуса недоступен, записать неизвестность, а не «действует».

6. Провести физический осмотр. Человек выполняет пункты выданного чек-листа, отмечает результат и, при учебном дефекте, фиксирует причину. Конкретный чек-лист должны выбрать участники подготовки; универсальный перечень технических неисправностей здесь не выдумывается.

7. Разделить основания решения. В журнале отдельно отметить соответствие заказу, сведения сертификата и физический осмотр. Лишь после этого ответственный оформляет результат контроля.

При неясном результате

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

Основание: [Т19], 00:04:25–00:05:15; 00:34:22–00:38:20; 00:41:19–00:42:22.

10.3. Отрицательная ветвь: дефект и уведомление

8. Зарегистрировать учебное несоответствие. В BIMAR записать результат «контроль не пройден» или соответствующее фактическое значение настроенной системы. Указать конкретный ID, причину, дату наблюдения и исполнителя в доступных полях. Названия статусов не объявляются стандартом API.

9. Зафиксировать фотографию. Сделать предусмотренный учебным сценарием снимок. Дефект не создаётся повреждением прибора. Связать снимок с тем же экземпляром и результатом контроля.

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

11. Передать ссылку на фотографию. Файл может оставаться в хранилище BIMAR, а в связанном сообщении передаётся его URL. Это согласованный на встрече способ показа; не следует утверждать, что фотография целиком хранится в блокчейне.

12. Проверить получение изготовителем. На станции 1 открыть сообщение с тем же ID, причиной и ссылкой. Если не виден результат на стороне получателя, отметить незавершённый обмен.

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

Контрольный результат

У покупателя сохранён результат осмотра; на платформе доступно согласованное событие; изготовитель видит причину и относящееся доказательство. ID не меняется незаметно при переходе между системами.

Основание: [Т19], 00:35:56–00:44:24; [К05], сцены S05.C06–C07 — совместимое описание возвратной ветви. Последовательность чтения результата — методическое требование.

10.4. Положительная ветвь: прибор в составе блока

14. Провести контроль второго экземпляра. Использовать его собственные метку и паспорт. Не превращать отрицательный результат первого прибора в положительный путём замены номера внутри прежней записи.

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

16. Открыть паспорт технологического блока. Показать изготовителя / комплектатора, идентификацию и согласованный состав сведений. Конкретная модель, номер и реальная комплектация блока задаются исходником, а не выбираются по догадке.

17. Связать компонент со сборкой. Использовать шаблон templates/block-passport-template.md и карточку связи компонента из приложения Г; данные прибора сверить по приложению Д. Включить паспорт принятого прибора в паспорт блока доступной подготовленной операцией. Если используется 3D-модель, отдельно различить проектную позицию и факт монтажа. Исходный промышленный паспорт — образец структуры документа, а не подтверждение наличия всего газового блока на учебном стенде.

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

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

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

Метрологический учёт. Обсуждался запуск процесса со стенда 2. Этот эпизод не заменяет агентный опыт на станции 2 самого стенда 5. В рабочей заметке DTconf регистрация опознанного поступившего СИ отделена от исправности и приёмки. При включении этой связки дефект не должен автоматически запрещать регистрацию; правила учёта подтверждаются отдельно.

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

Основание: [Т19], 00:05:15; 00:09:41–00:11:09; 00:46:01–00:49:57; 00:52:34–00:56:50; [СУ].

11. Согласованный сквозной прогон

11.1. Карта контрольных событий

11.2. Работа ведущего

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

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

11.3. Если шаг не готов

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

Основание последовательности: [Т19], 00:25:14–00:49:57; 01:05:58–01:12:29. Координация и фиксация режима — методическое предложение.

12. Отчёт и формы регистрации результатов

12.1. Состав отчёта группы

1. Наименование работы, дата, состав группы, роли и идентификатор учебного прогона.

2. Цель и короткое описание состава стенда с собственной схемой либо ссылкой на рисунок 1.

3. Соответствия меток, паспортов и системных идентификаторов двух экземпляров.

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

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

6. Сравнение дефектной и положительной ветвей; цепочка от паспорта блока к сертификату компонента.

7. Вывод, ответы на контрольные вопросы и список невыполненных / смоделированных эпизодов.

Форма 1. Идентификация объектов

Форма 2. Универсальная строка наблюдения

Прогон / станция / шаг: ______. Объект и ID: ______. Кто действует и от чьего имени: ______. Исходное состояние: ______. Операция: ______. Ожидаемая реакция: ______. Фактическая реакция: ______. Повторное чтение и доказательство: ______. Открытый вопрос: ______.

12.2. Формы наблюдения агента и входного контроля

Форма 3. Агентный опыт станции 2

Форма 4. Три проверки покупателя

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

13. Анализ результатов и критерии выполнения

13.1. Что сравнить

• Между станциями: открываются ли одни и те же экземпляры; какую информацию одна сторона получила от другой; где потребовался ручной перенос.

• До и после появления сертификата: что изменилось в связях паспортов и в доступности сведений.

• В агентном опыте: изменилось ли только одно условие; одинаков ли предмет операции; кто обеспечил запрет; осталось ли состояние объекта неизменным после отказа.

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

• Между заявлением и наблюдением: что видно в рабочем интерфейсе и что лишь описано словами; подтверждена ли запись в распределённом реестре отдельно от записи в прикладном сервисе.

13.2. Критерии завершения основной программы

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

13.3. Контрольные вопросы

1. Какие три организации представлены станциями и какие данные каждая из них создаёт?

2. Чем физический экземпляр отличается от модели, цифрового паспорта и сертификата серии?

3. Как показать связь «многие к одному» у изготовителя и «один ко многим» у сертифицирующей стороны?

4. Что наблюдается, когда паспорт уже создан, а нужного сертификата ещё нет?

5. Почему сканирование метки само по себе не доказывает проведение входного контроля и не обязательно запускает запрос на платформу?

6. Какие три самостоятельных основания проверяет покупатель? Как фиксируется неустановленный результат?

7. Что передаётся изготовителю при дефекте и где может храниться сама фотография?

8. Чем агентный деловой опыт на станции 2 отличается от обычного запрограммированного обмена BIMAR и платформы?

9. Кто выдаёт мандат и какие действия агент не вправе выводить из одного лишь текста поручения?

10. Как отличить проверку идентичности агента от проверки права на конкретную операцию?

11. Что должно остаться неизменным, если действие было отклонено? Как это проверить?

12. Чем предупреждение о параметре запуска отличается от запрета действия? Когда опыт блокировки нельзя считать проведённым?

13. Почему хеш настроек или верная подпись не доказывают автоматически всю фактическую конфигурацию среды и правильность вывода агента?

14. Может ли паспорт быть подлинным при отозванном сертификате? Делает ли действующий сертификат прибор физически исправным?

15. Как проследить принятый прибор из паспорта технологического блока? Чем эта связь отличается от доказательства нормативной допустимости применения?

16. Какие функции были реально выполнены в вашем прогоне, какие имитировались и что осталось неподготовленным?

Итоговое задание для защиты

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

Перед завершением

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

Приложение А. Подготовка ведущего и открытые параметры

Ограничение готовности по записи 19 октября

В конце встречи сообщается, что код для DID написан, но не запущен и требует испытаний / синхронизации; обсуждаются ограничения gRPC и замечания по безопасности; выбирается способ связи с реестром; ставится вопрос о достаточности OpenAPI для интеграторов. Эти сведения относятся к моменту встречи, а не доказывают состояние на день занятия.

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

Основание: [Т19], 01:09:47–01:12:29; 01:16:38–01:23:14.

Приложение Б. Источники и границы переноса

Основной источник

[Т19] «ПроКСи и стенд агентной экономики — транскрипт встречи», запись от 19.10.2026, 01:24:30. В комплекте сохранён исходный TXT без изменения. В нём заявлена сверка двух распознаваний, но не полная ручная проверка на слух. Имена по номерам спикеров не устанавливались.

Дополняющие материалы DTconf

[К05] dice-academy-context-2026-10-02/context.md, карточки S05, S05.ARCH, S05.ROLES, S05.C01–C10. Историческая основа: два прибора, два договора, возврат, отзыв и место компонента в проекте.

[П05] dice-academy-decks-2026-10-02/smart-stand-onboarding.json и interaction-review-2026-10-06.md. Исходник презентации и описание её структуры, не доказательство работающей установки.

[СУ] dice-academy-context-2026-10-02/scenario-si-s02-s03-s05-2026-10-08.md. Использована локальная рабочая редакция: регистрация опознанного поступившего СИ отделена от приёмки, исправности и поверки.

[Н35] stand3-inti-certificate-traceability-2026-10-13/architecture-s03-s05-normative-smart-contract-2026-10-13.md. Отдельный проект нормативного основания и сертификации блока; не внедрённая замена приборного сценария этой работы.

Все пути этого списка относительны operations/conferences/integrated-digital-twins-2026/artifacts/. При расхождении о программе стенда приоритет отдаётся итоговой постановке встречи 19 октября; исторические уточнения сохраняются только с обозначением своего статуса.

Приложение В. Методическая основа и сведения об издании

Примеры методических указаний, просмотренные в сети

[М1] Мельник Г. И., Тинина Е. В. «Методические указания по выполнению лабораторных работ по физике». Рязанский институт (филиал) Московского политехнического университета, 2019. Использованы разделы 4–6, 8–9: состав установки, теория, подготовка, порядок эксперимента, оформление и защита отчёта. Правила физической лаборатории и расчёта погрешностей сюда не перенесены. Первоисточник М1.

[М2] Уральский политехнический колледж — Межрегиональный центр компетенций. «Методические рекомендации к разработке методических указаний по проведению лабораторных работ и практических занятий». Год издания в просмотренном тексте не установлен. Использованы раздел о структуре текста работы и приложение 4: цель, оснащение, задания, методика, отчёт и оценка. Первоисточник М2.

Интернет-источники использованы для структуры учебного документа, а не для описания возможностей BIMAR, ПроКСи или готовности нашего стенда. Ссылки и сведения о фактическом доступе сохранены в methodology-references.md и source-manifest.json комплекта.

Статус собственных добавлений

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

Открыты: интерфейсы и команды; фактические приборы стенда и исходник второго экземпляра; применимость полученных документов; матрица прав; подтверждение запуска; политика предупреждения / отказа; реестр, длительности, сброс и готовность прогона. Источники паспортов и сертификата получены — приложения Г–Е; их наличие не закрывает разрывы ТУ, дат и индивидуальной применимости.

Состав комплекта

Методичка и три отдельных шаблона — паспорт блока, паспорт прибора и цифровой сертификат — в Markdown и PDF; шесть схем PNG / SVG; исходный сертификат; разбор источников и карта проверок. Цифровой сертификат дополнен учебной JSON-заготовкой. Все формы пусты до выполнения занятия.

Подготовлено: DiCE, 22.10.2026. Основание сценария: встреча 19.10.2026. Назначение: инструкция участнику и ведущему, не акт испытаний и не эксплуатационный паспорт установленного стенда.

Приложение Г. Шаблон паспорта технологического блока

Г.1. Источник и назначение

[ПБ] Предоставленный пользователем паспорт блока подготовки топливного газа с вертикальным сепаратором БПТГ-0,9-1,6, заводской № 22828. Файл «Паспорт Зав. № 22828.pdf», 69 страниц; источник — облачная папка по ссылке пользователя. Оригинал сохранён без изменения в sources/block-passport-22828-original.pdf; подробный разбор — source-analysis-block-passport-22828.md.

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

Г.2. Файлы для заполнения

Шаблон охватывает разделы 1–16: общие данные и характеристики, аппараты и компоненты, трубы и сварку, арматуру, КИП и А, комплектность, консервацию, упаковку, приёмку, гарантии, движение, работу, обслуживание, контроль, поверку, хранение, рекламации, ремонт, утилизацию и приложения.

Широкие таблицы труб и сварки развёрнуты в карточки одной позиции; повторные пустые листы сокращены до образца. Это учебная адаптация, не факсимиле и не утверждённый эксплуатационный документ. Наличие шаблона не подтверждает наличие всех приложений: отдельные облачные папки и файлы не скачивались.

Приложение Г. Применение на станции 3

Г.3. Порядок заполнения

1. Ведущий выдаёт копию шаблона и разрешённые исходные данные учебной сборки. Фактический паспорт промышленного блока сохраняется как пример, а не перезаписывается.

2. Группа заполняет титульные реквизиты и применимые поля общих данных. Неизвестное помечает «не предоставлено», неприменимое — «не применяется» с основанием.

3. В составе отдельно фиксируются два индивидуальных прибора. Ссылка на один сертификат не объединяет их паспорта и заводские номера.

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

5. В доступном интерфейсе выполняется подготовленная операция связи «паспорт блока → паспорт прибора». Идентификаторы и результат переносятся в учебную карточку и отчёт.

6. При отсутствии функции сохраняется заполненная учебная форма с отметкой «операция не выполнена»; сквозной результат не подменяется ручной записью.

Г.4. Карточка связи компонента — учебное дополнение

Форма — собственное дополнение к лабораторной работе, а не исходная заводская таблица и не контракт API. Её полная версия находится в конце шаблона. Для второго прибора нужна отдельная карточка.

Приложение Д. Шаблон паспорта прибора

Д.1. Исходный документ

[ПИ] Предоставленный пользователем файл «Паспорт ЭРСВ-440ЛВ.docx»: расходомер-счётчик электромагнитный «ВЗЛЕТ ЭР», модификация Лайт М; исполнение ЭРСВ-440ЛВ, DN 150, заводской № 2208748. В разделе приёмки указана дата 22.02.2023. Это сведения из документа одного экземпляра, не результат осмотра приборов стенда.

Оригинал сохранён без изменения в sources/instrument-passport-ersv-440lv-original.docx; разбор — source-analysis-instrument-passport-ersv-440lv.md. Наличие двух одинаковых вложений не подтверждает наличие паспортов двух разных приборов.

Д.2. Файлы и состав шаблона

Форма содержит идентификацию, технические характеристики, таблицу DN / Qнаиб, метрологические исполнения, комплектность, приёмку, обе группы калибровочных коэффициентов, поверку, гарантию и отметки работ. Проверка заполнения и цифровая карточка — отдельные авторские учебные дополнения.

Приложение Д. Работа с паспортом прибора

Д.3. На станции 1

1. Для каждого физического экземпляра создать отдельную копию шаблона и сверить исполнение, DN, заводской номер и метку с его исходником. Полученный паспорт относится только к № 2208748; данные второго прибора не выдумывать.

2. Заполнить согласованные поля из источника; неизвестное отметить «не предоставлено». Таблица семейства не является перечнем физических приборов стенда. Штрихкод, заводской номер, регистрационный номер типа СИ и ID цифрового паспорта — разные реквизиты.

3. Подготовить цифровую карточку из раздела 10 шаблона. Перенести в BIMAR только предусмотренные схемой поля; выполнить разрешённую публикацию и повторно прочитать запись. Заполнение Word или Markdown само по себе не является записью в платформу.

4. Связь с сертификатом проверить отдельно. Упомянутая в паспорте сертификация СМК изготовителя не заменяет сертификат продукции из задания станции 2.

Д.4. На станции 3

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

Неоднозначность источника: у диапазона III обе границы напечатаны как 100%·Qнаиб. Не исправлять по догадке. Отметка «ПОВЕРКА ВЫПОЛНЕНА» не даёт отсутствующей даты; дата приёмки не заменяет дату первичной поверки. Не объявлять поверку действующей без отдельного подтверждения.

Приложение Е. Цифровой сертификат соответствия

Е.1. Полученный источник и границы

[СК] Предоставленный пользователем одностраничный сертификат на расходомер-счётчик электромагнитный «Взлет ЭР Лайт М», серийный выпуск. В документе указана система добровольной сертификации «ИЦ МеТриКа», орган — ООО «Испытательный Центр Метрика», изготовитель и получатель — АО «Взлет».

Оригинал: sources/instrument-certificate-2024-original.pdf. Посекционный разбор и визуальная транскрипция: source-analysis-instrument-certificate-2024.md. Полномочия издателя, подлинность, отзыв, QR и электронная подпись независимо не проверены.

Е.2. Файлы цифрового шаблона

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

Приложение Е. Заполнение и работа станции 2

Е.3. Последовательность

1. Создать копию пустого шаблона. Перенести реквизиты со скана; для номера и кодов отметить неразличимые кириллические / латинские символы. Не подменять неизвестное правдоподобным значением.

2. Сохранить ссылку и SHA-256 исходника. Разделить сведения документа и цифровые поля. Хеш PDF не является подписью издателя или подтверждением запуска агента.

3. Отдельно проверить принадлежность каждого прибора к области. Для данного набора документов есть неразрешённые расхождения — таблица ниже. Не менять исходники ради положительного ответа.

4. В деловом опыте агент готовит карточку, показывает неизвестные поля, получает предусмотренное подтверждение и вызывает только доступную разрешённую операцию. После записи участник повторно читает результат.

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

6. Защитный опыт выполнить по разделу 9.3; зафиксировать предупреждение либо отказ и фактическое состояние объекта. Состояние документа, карточки и допуска агента не объединять.

Е.4. Что нужно уточнить до утверждения связи

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