同期台帳がサイレントに失敗し、実際には稼働中のアカウントで約400件しか存在しないにもかかわらず、763件のアセットを報告しました。手動での検証により、プラットフォームのUIとAPIを検査することで、この不一致が明らかになりました。台帳の不正確さは、3つの異なる障害モードに起因していました。「ゴースト」は、プラットフォームから削除されたがデータベースにまだ存在していたアセットを表し、少なくとも173行を占めていました。「ミス」は、プラットフォームにアセットが存在したがデータベースに記録されなかった場合に発生し、合計で少なくとも63行でした。「偽陽性」は、プラットフォームのデフォルトが誤ってユーザーのアセットとしてカウントされたもので、少なくとも109行を占めていました。これら3つのモードは互いに部分的に相殺し合い、合計カウントを誤解を招く指標にしていました。エラーの具体的な例としては、プラットフォームのスキルリストが、ユーザーの実際のスキル4件ではなく、ページサイズ制限のために100件を誤って報告したことが挙げられます。別の例では、設定ページのプレースホルダーテキストがユーザーのメモリとして保存され、実際のメモリは見逃されていました。さらに、42件の命令行が、マシン上の存在しないローカルディレクトリを指していました。重要な教訓は、同期が成功したという報告は、データの正確性を保証するものではないということです。ページネーションの問題により、リスト呼び出しが早期に停止したためアセットが見逃され、もっともらしい数字が油断を生みました。提案されている解決策は、より優れたコレクターではなく、すべての同期後に必須の読み戻し監査です。このプロセスには、プラットフォームを再読み込みし、双方向のID差分を実行することが含まれます。プラットフォームによって提供されるデフォルトは、明示的に特定され、処理される必要があります。このプロアクティブな検証は、スケジュールで実行され、台帳の劣化を防ぐために不可欠です。著者は、この読み戻し検証がコア製品の教訓であるコントロールプレーン「untactit」を開発しています。