先判断这一行是在观察还是在改变状态
阅读区块链智慧城市方案时，可以先暂时遮住宣传图中的链标识，只看每条业务记录的动词。W3C的SSN文档把Observation用于描述按程序估计或计算属性值的活动，把Actuation用于描述借助执行器改变世界状态的活动。二者分别关注获得什么信息、实施什么变化，不是同一种事情。
例如，一份假设的照明维护清单写着“读取灯具附近的亮度”和“调整灯具输出”，前者记录观测，后者涉及动作。它们可能发生在同一设备附近，却不能都简写成“灯具已处理”。这里仅用清单帮助读懂方案，不提供真实城市设施控制参数，也不代表已有城市采用本文流程。
操作请求不能直接放进完成记录那一列
本文建议将维护工单拆成请求、执行反馈和后续观测三类记录：请求写希望做什么，反馈写执行端报告了什么，观测写之后取得什么读数。它们是为阅读清单提出的整理栏位，并非SSN规定的三个标准状态。特别要注意，一条名为动作完成的日志，仍要看其内容由谁生成、描述的是哪个环节。
假设工单甲只有调整请求和接收确认，工单乙另有执行反馈与后续亮度记录。读者可以指出乙提供了更多核查材料，但不能仅凭多出两行就保证现场效果正常。若执行反馈缺失，应保留该缺口；若后续观测与预期不同，应记录差异，不把发出请求的时间改写成验收完成时间。
把链外数据进入合约的环节单独画出来
以太坊官方预言机文档说明，合约默认不能直接取得区块链外的信息，需要相关机制将外部资料提供给合约；文档同时强调正确性和可用性等问题。因此，照明读数进入链上记录之前，还有采集、传送和提供数据的环节需要解释，不能只画一个传感器连向区块的箭头便视为说明完整。
审阅方案时可以逐项问：这行数据取自哪个记录，谁负责提供，缺失时页面怎样显示，多个报告不一致时由什么规则处理？这些问题属于本文的阅读检查单，不代表某个预言机产品已经满足要求。链上留痕也不应被标成设备实际动作的替代证据；两者需要有可核对的关联说明。
最终看板应让未完成和未取得都可见
作为一个可复核的展示设计，可以保留工单编号、观测对象、请求记录位置、执行反馈位置、后续观测位置和链上记录位置。没有材料的格子写明未取得，而不是统一显示绿色成功。若只有教学数据，栏目标题就不要写成实时城市运行数据；若只展示局部设施，也不要外推为整座城市的运行状态。
读完方案后，试着让另一位读者只凭这些材料回答：观察到了什么、准备改变什么、报告做了什么、后来又观察到什么？四个问题能被分别回答，才便于继续讨论数据是否需要上链、采用何种保存方式。区块链是待评价的组成部分，不是让这四类记录自动变成同一份事实的标签。