操作说明字段
每项设备操作都应提供以下说明：参数字段
parameters 中的每个参数应分别说明：
参数约束既用于编译和仿真，也必须在设备动作前再次校验。参数之间存在关系时，还应说明跨字段约束，例如“总加液量不得超过目标容器剩余容量”“转速越高时允许的最大持续时间越短”。
调用时的操作字段
返回时的操作字段
填写示例
以加液操作为例，操作说明可以声明：操作标识为add_liquid；参数包括来源容器标识和加液体积；体积类型为数值、单位为毫升、允许范围为 0.05–0.8 mL；完成条件为设备确认液体已经加入且实际体积得到核验。调用时可以填写来源容器 source-01 和体积 0.5 mL。完成后的操作结果可以填写状态 succeeded、实际体积 0.498 mL、诊断为空。
以设定温度操作为例，可以声明目标温度、升温速率和稳定时间三个参数。目标温度可限制为 20–120 °C，升温速率可限制为 0.1–10 °C/min。完成后返回实际稳定温度、达到稳定状态的时间以及超调量；如果温度未在规定时间内进入允许偏差，则状态填写 failed，诊断说明超时和实际温度。
强制规则
定义和检查一项动作的流程见动作契约伪代码，可运行实现见 GitCode 示例源码。- 操作参数必须声明类型、含义以及适用的范围、枚举或格式约束；
- 调用前必须同时校验对象状态、操作参数和系统条件；
- 返回结果必须反映设备实际执行情况，不得把计划参数直接当作实际结果；
- 失败、取消或结果未知时，不得报告预期成功状态；
- FSP 不规定操作在 HTTP、CLI、MCP、RPC 或 SDK 中的具体名称与路径。
怎样判断操作成功
每项操作必须写清“做到什么才算成功”：用completion_scope 指定完成范围，并列出完成条件、可以采用哪些测量或检查、允许多大误差、需要持续多久或何时超时。
返回 succeeded 只表示这些条件已满足。例如，“温度设定值已写入”不能说明样品已经达到目标温度。
这些范围不构成自动继承关系。每个操作独立规定必需证据；例如离心周期结束可能还要求转子停止，温度设定值回读不能证明样品已经恒温。
用于判断完成的记录放在
operation.completion_evidence 中。每条至少写清记录编号、来源、设备、相关任务和容器、测量字段、值、适用单位、观察时间、有效期，以及是不是模拟结果。
对应字段为 evidence_id、source、device_id、适用的 task_id / container_id、field、value、单位、observed_at、有效期和 simulated。来源可以是设备硬件 hardware、外部传感器 external_sensor、人工检查 human 或计算推导 derived。人工检查和计算推导只有在操作定义明确允许时，才能用于判断对应条件。
0.005 mL；这个数字只是示例，不是实际设备精度。
basis_revision 记录动作前的目标容器版本，服务端要检查它是否属于原任务，不能把它当成动作后的版本。本例没有读取设备设置值，所以不填 adopted_settings。完整响应还要包含对象和系统两部分。
程序没报错、HTTP 返回成功、命令行正常退出、设备回复 ACK、等待时间到了，都不一定表示设备动作已经完成。模型生成的“已完成”也不能作为依据。
缺少所需证据时，按实际情况返回 running、waiting_confirmation 或 unknown。不同证据互相矛盾时，要说明冲突，并暂停依赖该结果的后续动作。
仿真结果必须标记 simulated: true 并存入隔离状态，不能更新真实对象。effects 表达计划预测；只有已确认事实可以更新物理状态。失败、取消或未知时也必须保存部分实际变化。
让程序能够检查这些规则
参数定义必须写清哪些必填、默认值是什么、能否为空、数组长度，以及多个参数之间的关系。preconditions、effects 和 completion_conditions 应使用固定的规则编号和程序能检查的参数。文字解释可以保留，但安全检查不能只靠一句“条件合适时执行”。requires、provides、invalidates 可以帮助规划程序安排步骤，但必须说明哪些状态还要在执行时实际读取。
契约固有范围与部署限制分别校验。单位换算、坐标系、工具参考点、校准版本和允许误差须在相关操作定义中明确；分辨率或小数位数不能替代准确度与测量不确定度。