初回案内・オンボーディング催促・機能の有効化バッジのように「その人は既にこの状態に到達したか」を判定する箇所で、有効期限や失効フラグを持つ資格情報（アクセストークン、リフレッシュトークン、セッション、一時的な許可レコード）の"有効なもの"の存在を条件にすると、判定が時間とともに巻き戻る。到達済みの人にしばらく後で案内が再表示され、催促として最も不快な形（もう知っている人への繰り返し）になる。

判断基準

• 判定したい対象が「今この瞬間その資格が使えるか」なら有効性で判定してよい。「過去に一度でも成立したか」なら、失効・期限切れを問わない発行履歴の存在で判定する。この2つを混同しない。
• 発行履歴で判定する場合は、その記録が消えないことを先に確認する。古い行を消す定期削除やTTLがあるなら履歴として使えないので、到達時刻を利用者レコードに1カラム持たせる方式に切り替える。
• 資格情報の寿命が長い（数十日〜数ヶ月）ことは根拠にならない。寿命が長いほど不具合が出るのが遅く、リリース直後のテストでは絶対に踏めないため、発覚が最悪のタイミングになる。

併存する紛らわしい判定軸

同じ画面で「到達済みか」を判定するとき、次の3つは別物として区別する。

• 資格が今有効か（＝操作できるか）
• 過去に一度でも成立したか（＝案内が要るか）
• その機能を使った成果物が何件あるか（＝習熟しているか）

成果物の件数を「到達済み」の代理にするのも誤りになりやすい。前提条件は満たしたが成果物をまだ作っていない層に、済んだはずの設定手順を繰り返し出してしまう。

判定元の取り違えを防ぐ

複数の認証・認可系統が同居するシステムでは、「どのテーブルがどの経路で書かれるか」を書き込み箇所から確認してから判定に使う。一般ログインの資格情報と、外部連携用の資格情報が別系統なのに、名前が似ているために取り違えると、全員が到達済み（または全員が未到達）に見える判定になる。書き込みコードの参照箇所を実際に数えるのが最も速い確認方法。

検証方法

失効済みかつ期限切れのレコードを1件だけ用意した状態で判定を呼び、到達済みと返ることを実データで確認する。ユニットテストのモックでは、この"失効していても真"という性質が意図どおりかを表現しきれないことが多く、実データでの1回の確認が最も確実に効く。逆に、まだ一度も到達していない利用者で未到達と返ることも同時に確認して、判定元の取り違えを検出する。