A sync ledger failed silently, reporting 763 assets when only around 400 were actually real for a working account. Manual verification revealed this discrepancy by inspecting platform UIs and APIs. The ledger's inaccuracies stemmed from three distinct failure modes. "Ghosts" represented assets deleted from the platform but still present in the database, accounting for at least 173 rows. "Misses" occurred when assets existed on the platform but were never recorded in the database, totaling at least 63 rows. "False positives" involved platform defaults being incorrectly counted as user assets, contributing at least 109 rows.These three modes partially canceled each other out, making the total count a misleading metric. Specific examples of errors included a platform skill list incorrectly reporting 100 items due to a page-size limit, instead of the user's 4 actual skills. Another instance involved placeholder text from a settings page being stored as user memories, while real memories were missed. Furthermore, 42 instruction rows pointed to non-existent local directories on the machine. The key lesson is that a successful sync report provides no assurance of data accuracy. Pagination issues caused missing assets because list calls stopped prematurely, and plausible-looking numbers fostered complacency.The proposed solution is not a better collector, but a mandatory read-back audit after every sync. This process involves re-reading the platform and performing a bidirectional ID diff. Platform-provided defaults must be explicitly identified and handled. This proactive verification, run on a schedule, is crucial for preventing ledgers from decaying. The author is developing a control plane called untactit, where this read-back verification is a core product lesson.