The ledger said 763 assets. The platforms said about 400.

A developer's audit of a multi-platform AI asset ledger found that only about 400 of 763 recorded assets were real, revealing three distinct failure modes: ghosts, misses, and false positives. The developer, building the pre-launch control plane untactit, emphasizes that read-back audits—re-reading platforms and diffing IDs—are essential to prevent silent data corruption.

A sync ledger fails silently. Ours said 763 assets. When we stopped trusting it and counted by hand — opening 21 AI platforms in browser tabs, calling each platform's own API from the page context, comparing ID by ID — roughly 400 of those were real. This is the audit log of that gap. The numbers are from one working account, measured on 2026-08-18. Nothing here is hypothetical. The database held every asset collected from the platforms a working account actually uses — conversations, projects, skills, instruction files, memories — across Claude, ChatGPT, Gemini, Grok, Perplexity, Kimi, Qwen and fourteen others. 763 rows total. The verification method matters more than the tool: fetch with credentials: 'include' , paginating to exhaustion.A count that matches can still be two different lists. Only the ID diff tells you what is actually there. The 363-row gap was not one bug. It was three independent failure modes, each of which produces a database that looks healthy. | Failure mode | What happens | Confirmed rows | |---|---|---| Ghosts | Deleted on the platform, still alive in the DB | at least 173 | Misses | Exists on the platform, never made it into the DB | at least 63 | False positives | Platform-provided defaults counted as user assets | at least 109 | Note the shape of the problem: ghosts and false positives inflate the ledger, misses deflate it. They partially cancel. A total count is the one metric guaranteed to hide all three. A page-size limit became a count. One platform's skill list showed 100 in the DB. The user had installed 4. The other 96 were the platform's public catalog — shown to every user — and the number 100 was simply the API's page-size cap, recorded as if it were a fact about the account. Example strings became memories. A memory collector stored 2 items for a platform where the user had 8 real saved memories. It had missed all 8 — and stored two lines of the settings page's placeholder text "e.g. ..." as if they were user data. On the dashboard, this cell looked like one of the working ones. Files that were never there. 42 instruction rows pointed at local rule directories that did not exist on the machine at all. Nothing had been deleted; the source path had simply never existed on this host. The collector wrote 42 rows anyway. Every one of these rows was written by a run that reported success. That is the actual lesson: The fix is not a better collector. It is a read-back audit as a first-class operation: after any sync, re-read the platform and diff IDs in both directions, and treat "platform-provided default" as a category your matcher must know about. Run it on a schedule, not once. If you run agents across several tools, try the count yourself. Pick one platform, list what your ledger thinks is there, then page through the platform's own API to the end. The first diff usually takes ten minutes and is rarely empty. This audit is part of building untactit, a control plane for the skills, rules, and memory AI agents run on — currently pre-launch. The read-back verification described here is the product lesson: deployment without re-reading the target is how ledgers rot.