Паспорт физического процесса
Что должно переноситься из одного сценария в другой?
Пакет процесса переносит цель вместе с моделью, ограничениями и способом проверки результата. Список устройств и текст запроса дополняют этот контракт, но сами по себе не определяют поведение в новой комнате.
Повторно использовать нужно не только код правила. Вместе с ним нужны описание измерений, допустимые действия, условия модели, способ проверки результата и поведение при нехватке данных. Мы соберём это в паспорт физического процесса.
Так освещение кабинета станет не набором скрытых настроек, а проверяемым пакетом. При переносе в другую комнату система сможет запросить новое размещение датчика и проверку влияния лампы вместо слепого копирования старых коэффициентов.
Предлагаемый формат Process Package#
Назовём переносимое описание пакетом процесса. Это собственный контракт Koobique, пока не стандарт и не готовая библиотека. Его читаемая часть объясняет смысл; машинная часть содержит типизированные поля, допустимые значения и ссылки на артефакты. Ниже — состав, который нужен уже для освещения.
| Часть | Пример кабинета |
|---|---|
| Объект и цель | Рабочая поверхность; согласованный диапазон света при присутствии |
| Входы | Освещённость, оценка присутствия, здоровье каналов, ручной режим |
| Исполнители | Конкретная лампа через конкретное реле; только ON/OFF |
| Модель | Вклад лампы и остаточная неопределённость; версия размещения |
| Ограничения | Минимальная пауза между переключениями, срок команды, права владельца |
| Проверка | Выход подтвердил состояние; свет изменился в ожидаемом направлении |
| Отказ | Неизвестное присутствие не трактуется как пустота; политика света согласована |
| Ресурсы | Максимальный размер состояния, время вычисления, квота истории |
| Доказательства | Тестовые эпизоды, условия допуска, известные слабые режимы |
Связывание с реальной комнатой#
Установщик пакета ищет подходящие возможности, но не связывает их автоматически по похожим названиям. Пользователь указывает физический объект и подтверждает нагрузку; тест определяет наблюдаемый эффект. Если лампа умеет только включаться и выключаться, параметр «яркость 37%» не становится доступным действием.
У пакета есть два результата проверки: структурная совместимость и эксплуатационный допуск. Первая означает, что типы и интерфейсы сходятся. Второй — что выбранная сборка проверена для данного сценария. Нельзя заменить второй результат успешной проверкой JSON Schema.
Жизненный цикл#
Предлагаемые состояния: черновик, связан с ресурсами, наблюдает, проверен на записи, ограниченно управляет, действует в подтверждённой области, приостановлен. Переходы журналируются. Подписанный пакет от автора всё равно не получает автоматически право управлять помещением владельца.
Обновление пакета сравнивает не только версию кода, но и область полномочий. Добавление нового исполнительного устройства, увеличение диапазона или смена политики отказа требует отдельного разрешения. Исправление текста подсказки не должно проходить тот же тяжёлый путь.
Ресурс «влияние на среду»#
Две программы могут одновременно хотеть управлять одним реле. Поэтому пакет запрашивает право на действие через арбитр. Приоритет определяется политикой пользователя и устройством, а не тем, какая модель прислала более высокий confidence.
У одной цели тоже могут быть несколько исполнителей. Освещение комнаты и экрана конфликтуют с экономией энергии; вентиляция конфликтует с шумом. Пакет объявляет целевые величины и цену компромисса, а жёсткие ограничения остаются отдельно. Человек должен понимать, что оптимизируется, а не обнаруживать это по неожиданному поведению системы.
Как добавлять новые алгоритмы#
В первой версии пакет — декларативные данные и ссылка на встроенный Rust-алгоритм. Затем можно допустить изолированный вычислительный модуль. Ему выдаются только объявленные входы, бюджет и интерфейс предложений. Доступ к сокетам устройств или файловой системе станции не возникает из самого факта установки.
Пример переноса в другую комнату#
Пакет освещения знает, что ему нужен измеритель света на рабочей поверхности, оценка присутствия и двоичный исполнитель. В новом кабинете эти типы нашлись — структурная проверка пройдена. Но старая лампа давала в точке датчика один вклад, а новая расположена иначе. Эксплуатационный допуск ещё не получен.
Пользователь подтверждает назначение реле и размещение сенсора. Система сначала наблюдает, затем в разрешённом опыте оценивает влияние лампы и проверяет его на отдельных эпизодах. До этого она использует согласованный простой режим. При переносе сохраняется архитектура пакета, но не необоснованная уверенность в старых коэффициентах.
Пакет процесса в первом экземпляре#
В E0 пакет — статическая проверяемая конфигурация и имя встроенного Rust-автомата. Не требуются магазин модулей, произвольный планировщик, граф распределённого исполнения или нейросеть. При этом сохраняются цель, входы, ограничения, условия допуска и проверка результата; они нужны и для одной лампы, чтобы следующий экземпляр не зависел от памяти автора.
Для PIR-only пакет не может заявить requires=presence_boolean и получить право автоматического ухода. Он требует конкретный observability_profile и запись допуска на выбранное размещение. При замене радара, перемещении сенсора или восстановлении старого пакета прежний допуск не возобновляется автоматически. Это проверяется до выдачи исполнительных полномочий.