審査ページには「finality（最終性）」と書いてあるのに、記録には「proposal（提案）」しかない。こういう場合、最初の一手は「最終性」を結論として扱うことではなく、証拠を逆順に探ることです。このブロックは、委員会メンバーだけが関与して提案された段階で止まっていないでしょうか？答えが「はい」なら、まだ第一層であって、後続の検証と承認に置き換わるものではありません。

第二層を見るのは validation（検証）です。資料では、候補ブロックとトランザクションが独立して検証されていることが求められています。大事なのは、ページに立派なステータス語があるかどうかではなく、検証対象が本当にブロックとその中のトランザクションをカバーしているかどうかです。提案記録だけで独立検証の根拠がなければ、証拠チェーンは中途で断たれたままです。

第三層が ratification（追認・承認）です。つまり、承認条件を満たしているかどうか。条件を満たした後に初めて、ブロックは確定的な最終性を得ます。通常の運用の文脈では、ユーザーがそれをユーザー向けのリコンポーズに依存して「まだ確定していない」もののように理解すべきではありません。この順序が重要です。proposal は「誰かが提案した」、validation は「誰かが独立してチェックした」、ratification は「条件を満たして承認を完了した」です。

したがって、@Dusk のコンセンサス状態を判断するときは、スローガン一句を代わりに三問で置き換えられます。提案者は誰？検証は何をカバーしている？承認条件は満たされている？$DUSK はネットワークネイティブのトークンですが、最終性の証拠としての問いに答える材料にはなりません。#dusk

検査では「どの層が欠けているか」を記録し、「通らなかった」という一点だけを記録しないでください。この書き方は、ステータス語を、追跡可能な証拠のパスに復元できるだけでなく、通常運用での最終性説明を、あらゆる例外シナリオに対する約束と誤読してしまうことも防げます。

この3つの英単語を、3つの独立したセールスポイントとして扱わないでください。本当に残すべき痕跡は、proposal から validation へと対象が連続しているかどうか、そして validation から ratification へと条件が明確かどうかです。このチェーンが閉じている場合にのみ、finality は再検証可能な結果になります。インターフェース上の飾りではありません。