审查页面写着 finality，记录里却只有 proposal。遇到这种情况，第一步不是把“最终性”当成结论，而是倒着找证据：这个区块是否只是由委员会成员参与提议？如果答案是“是”，它还停在第一层，不能替代后面的验证与批准。

第二层要看 validation。资料要求独立验证候选区块与交易，重点不是页面上有没有一个漂亮的状态词，而是验证对象是否真的覆盖区块和其中的交易。若只有提议记录，没有独立验证的依据，证据链仍然断在中间。

第三层才是 ratification，也就是是否达到批准条件。达到条件后，区块才获得确定性最终性；在正常运行语境里，用户不应把它理解成还要依赖面向用户的重组。这个顺序很重要：proposal 是“有人提出”，validation 是“有人独立检查”，ratification 才是“满足条件并完成批准”。

因此，判断 @Dusk 的共识状态时，可以用三问替代一句口号：提议者是谁？验证覆盖什么？批准条件是否满足？$DUSK 是网络原生代币，但不能替最终性证据回答问题。#dusk

检查时还要记录“缺哪一层”，而不是只记录“未通过”。这种写法能把状态词还原为一条可追踪的证据路径，也能防止把正常运行下的最终性说明误读成对所有异常场景的承诺。

别把三个英文词当成三个独立卖点。真正需要留痕的是从 proposal 到 validation 的对象是否连续，validation 到 ratification 的条件是否明确。只有这条链闭合，finality 才是可复核的结果，而不是界面上的装饰。