Предположим, сервис заказов должен принимать предоставленное вызывающим кодом правило, которое решает, отправить заказ или задержать для проверки. Передадим ему явные входные данные, например сумму заказа и результат проверки личности. Пусть правило возвращает данные решения с выбранным действием и причиной. Хост сможет рассмотреть результат, прежде чем выбрать выполняемую операцию.
В этой гипотетической интеграции возвращённое решение об отправке не устанавливает, что заказ отправлен. Хост может отвергнуть неизвестное действие, применить дополнительную проверку полномочий или обновить другой заказ. Запись входа и возвращённых данных помогает локализовать спорное решение. Для установления фактического действия нужно отдельно наблюдать хост.
Вычислитель важен не меньше интерфейса правила. В Lispex 1.21 вычисление исходного кода по умолчанию выполняет доверенный код внутри процесса. Это разумный выбор, если предоставленному коду доверяют и ограниченное выполнение не требуется. Такая схема не даёт ресурсных гарантий для произвольного кода вызывающей стороны.
Native embed и embed full являются разными ограниченными вычислителями, использующими WASM без импортов и новые экземпляры для запусков. Ресурсное утверждение должно называть вычислитель и профиль, обеспечивающие гарантию. Подготовку и вычисление также нужно учитывать отдельно в рамках выбранного профиля. Ограничение только на вычисление не описывает всю работу подготовки.
Для этого сервиса я бы записывал вместе вычислитель, профиль, явный вход и возвращённое решение, а наблюдаемое действие хоста связывал с ними отдельно. Тогда расчёт правила остаётся доступным для проверки, но его результат не принимается за доказательство исполнения.