Последняя проверка перед действием
Что проверяется за мгновение до выхода на устройство?
Модель формирует предложение, которое проходит независимую проверку. Устройство применяет собственные ограничения, а результат действия сопоставляется с физическими наблюдениями.
План мог быть правильным секунду назад. Затем человек нажал кнопку, датчик устарел или управление перешло другой станции. Поэтому разрешение проверяется не только при составлении плана, но и перед исполнением.
Этот последний рубеж не является ещё одним голосованием AI. Он проверяет формальные условия: владельца ресурса, эпоху, срок, версию состояния и пределы команды. А после отправки следит, какой уровень результата действительно получен.
Три уровня допуска#
Права отвечают, кто может воздействовать на объект и в каком диапазоне. Политика процесса проверяет свежесть, режим, ручной приоритет и допустимость плана. Локальная защита устройства удерживает выход в предусмотренных границах даже без связи. Это разные механизмы; успешная аутентификация не заменяет ни один из двух последних.
Контракт предложения#
Предлагаем объект ActionProposal: уникальный ID, объект и действие, аргументы, инициатор, версия прав, снимок состояния, срок действия, предусловия и ожидаемый эффект. Он не содержит секретов устройства и не может указать произвольный сетевой адрес вместо зарегистрированного ресурса.
Валидатор проверяет типы и единицы; арбитр — конфликт владельцев и ручного режима; исполнитель — актуальность условий и возможность доставки. Проверки с числами выполняются точно в коде. Валидация схемы — первый барьер, не полная безопасность.
Гонка между планом и кнопкой#
В 10:00:00 модель предлагает ON. В 10:00:01 человек нажимает OFF. В 10:00:02 план готов к отправке. Если проверить ручной режим только до вычисления, старый план отменит волю пользователя.
Разводим три независимых величины: controller_fence связывает назначение станции с её ключом; output_revision меняется при установке выхода; manual_revision меняется при ручном намерении, даже если электрический уровень не изменился. Все локальные версии дополнены boot_id. Ручной режим — отдельное состояние, а не только число. Сверка новой версии после связи не даёт автоматизации права отменить действующий ручной запрет.
Доставка, повтор и неизвестный исход#
Используем семантику KQIP из глав 21–22: ID команды, дедупликация, срок действия, подтверждения и отдельный результат. Команда «установить ON» легче переносит повтор, чем «переключить». Но идемпотентность значения не делает любой физический процесс безрисковым: повторная подача питания может иметь особенности конкретной нагрузки.
Если подтверждение потеряно, исход может быть неизвестным. Сначала читаем состояние и проверяем наблюдения. Для неидемпотентной операции автоматический повтор запрещается или требует специальной процедуры. Нельзя объявить её невыполненной только из-за тайм-аута связи.
Пять записей о намерении и результате#
| Запись | Что она утверждает |
|---|---|
| CommandIntent / ACCEPTED | Core транзакционно сохранил намерение и outbox |
| DeliveryAttempt / DISPATCHED | Началась попытка отправки; RECEIVED требует ответа MCU |
| ExecutionResult / APPLIED | MCU сообщает результат с boot_id и ревизиями |
| OutputSnapshot | Последний известный выход по версии, независимо от ACK |
| EffectEvidence / GoalEvaluation | Наблюдение эффекта и оценка цели в названном интервале |
Ток лампы помогает обнаружить обрыв, но не заменяет световой контроль. Рост света может быть вызван окном; при неоднозначности результат «эффект совместим с ожиданием» честнее абсолютного утверждения причинности.
Независимость защиты#
Проверка ограничений не спрашивает ту же модель, правильно ли она решила. В E0 это небольшой Rust-модуль Core; его независимость логическая, не аппаратная: panic или OOM могут остановить весь процесс. Последний локальный рубеж — прошивка с собственным владельцем выхода; физическое снятие питания остаётся отдельным средством. Для опасных нагрузок потребуются независимые схемы и профиль риска, отсутствующие у учебной лампы. Модуль проверки остаётся малым и тестируется отдельно от предсказателя; для решения ему не требуется завершение GPU-задачи или AI-worker. Это требование к реализации не устраняет общие отказы процесса: проверяется поведение при зависании worker, исчерпании ресурсов и остановке Core.
Последствия ошибочного предложения ограничиваются проверяемыми условиями исполнения. Для каждого действия указаны ресурс, владелец, срок, пределы и способ наблюдения результата.
Ни распознавание речи, ни модель мира не получают прямой доступ к GPIO, SSH или ключам. Между предложением и выходом стоит независимый исполнитель с повторной проверкой условий. После команды отдельно фиксируются подтверждение выхода и достижение физической цели.
Разные счётчики защищают от разных устареваний#
ID команды отвечает на вопрос «это тот же запрос или новый?». Версия выхода — «менялось ли состояние после снимка?». Controller fence — «это ещё действующий хозяин инсталляции?». Локальная ревизия ручного действия — «не нажал ли человек кнопку после плана?». Эти поля связаны, но один общий счётчик не обязан надёжно заменять все четыре.
Конкретное двоичное представление следует закрепить в спецификации. На устройстве проверяется та часть предусловий, которая доступна локально; на станции — права, контекст и план. Во время разрыва связи кнопка меняет локальную ревизию. После соединения сначала согласуется текущее состояние, а не отправляется накопленная очередь старых желаний.
Приоритеты и атомарная граница действия#
| Приоритет | Что означает |
|---|---|
| 1. Аппаратная защита / физическое снятие питания | Не блокируется manual hold и AI |
| 2. Локальные ограничения MCU | Недопустимый режим, новая boot, срок и межблокировки |
| 3. Подтверждённое ручное намерение | Обычная автоматика не отменяет его |
| 4. Разрешённая автоматизация | Только свежие данные, допущенный профиль, текущие версии |
| 5. Исследовательский кандидат | По умолчанию только предложение |
Guard внутри Core уменьшает доверие к модели, но разделяет с Core память и отказ процесса. Поэтому инструкции узла не сводятся к «сервер уже проверил». MCU проверяет собственные boot, revision, срок и режим непосредственно в владельце выхода. Граница доверия остаётся: авторизованный, но скомпрометированный Core может лгать о пользовательской причине. E0 не заявляет защиту от всех действий такого контроллера; для более опасного применения нужны отдельные локальные полномочия и независимое оборудование.
Внешний настенный выключатель либо снятие питания лампы фиксируются как возможное вмешательство. APPLIED GPIO при отсутствии света не становится ложным успехом. Система не должна бесконечно щёлкать реле, пытаясь «исправить» физически разорванную цепь: лимит повторных попыток и уведомление входят в профиль.
Модель не выдаёт себе допуск#
Исполнитель получает не только предлагаемое действие, но и ссылку на исходный снимок, версию модели и область, для которой проверено её поведение. Core выводит права из своей текущей записи владельца и пакета процесса; поля ответа worker не создают эти права. Затем проверяются свежесть, состояние ручного режима, действительность привязки модели к размещению и допустимость воздействия. На MCU повторяются boot, fence, срок, ревизии и локальные ограничения.
У допуска есть область: конкретный объект, набор действий, диапазон, версия и условия измерения. Замена весов, калибровки, нормализации или размещения может вывести исполнение за эту область. До повторной проверки сохраняется согласованный базовый режим либо остановка автоматических действий по политике нагрузки. Ручная кнопка и независимая аппаратная защита не ждут, пока модель объяснит результат.
Отдельная приёмочная история связывает все уровни: worker получает снимок, человек нажимает OFF, затем приходит позднее предложение. Сохраняется исходная привязка запроса; обновление snapshot не превращает старый ответ в новое намерение. Исполнитель отказывает по изменённым условиям, фиксирует причину и сохраняет текущий выход. Это уже предусмотренный архитектурой принцип, который нужно подтвердить реализацией каждого клиентского пути, включая голос.