一份报告写着“验证通过”，阅读者还需要知道它验证了什么。文件能打开、计算能重跑、设备能工作，是不同的判断。把检查对象写清楚，团队才能决定是否加工样件、继续试验或扩大使用范围。
先检查软件与模型
参数化模型生成后，可以回读导出文件，核对几何、尺寸和装配关系。控制程序可以在固定配置下重跑，观察输入、状态和输出。这些检查要使用独立的判断依据，保留版本及失败项。
软件测试仍有明确范围。MOTRA中的日志回放用于阅读已记录的过程，固定配置重执行用于复现软件行为，几何检查用于核对模型。它们不能替代厂商 PLC 联调、真实设备试验或安全认证。
再问计算覆盖什么
计算结果支持的是一组假设下的判断。输入条件、求解设置、训练与验证数据需要可查。一个模型预测过某种工况，并不说明它在其他温度、速度或材料批次下同样成立。
PhysicsX 的滑翔机文章记录了设计、制造与试飞，也说明模型计算的是纵向稳定性，横向稳定性尚待探索。我们从中借鉴的做法是，将模型覆盖的性质和实物遇到的问题分别交代。
超出范围时，可以增加计算或试验，重新确定适用条件。稳定性也应如此描述：在什么条件下重复运行，出现过什么异常，还有哪些边界没测。
测量需要自己的条件
光子器件可以帮助理解这一层次。试验计划被正确执行以后，还要核对器件编号、仪器校准、扫描范围、原始曲线和拟合方法。仅凭一张平滑曲线，无法判断器件是否满足设计要求。
Axiomatic AI 的 AxMeasure 页面将试验规划、仪器操作与参数分析放在同一流程里，并明确网页演示未连接仪器。演示可以解释操作方式，现场测量才会产生相应物理证据。两种内容各有用途，页面应当清楚标识。
这也是我们讨论光子测量等新任务的起点：先确认已有仪器、数据与专业人员，再决定软件应该接入哪一段。当前不能把这种方向写成 GOPROMP 已完成的器件验证。
流程通过，还要看执行
实验室自动化中，计划可能通过结构校验，但样品、耗材和仪器状态仍会影响运行。Automata 的 LINQ 文档明确区分工作流校验与成功执行；依赖关系和配置正确，只支持相应层次的结论。
因此交付报告应分别列出：软件检查、计算比较、物理试验，以及暂未完成的项目。每项附输入版本、条件、结果和异常。实物测试需由具备条件的实验团队实施，我们根据合作范围构建软件、组织计算并整理记录。
失败也需要说明发生在哪一层。修复后重跑受影响的检查，再用新的证据更新结论。这样，下一位使用者才知道哪些结果可以采用，哪些条件改变后必须重新确认。