diff --git a/fifa17-recon/docs/CARD_SYSTEM.md b/fifa17-recon/docs/CARD_SYSTEM.md
index 49c4cd8..57b39af 100644
--- a/fifa17-recon/docs/CARD_SYSTEM.md
+++ b/fifa17-recon/docs/CARD_SYSTEM.md
@@ -139,3 +139,58 @@ and validates A. No such tool exists yet.
 - `fifadrive.sh` (screen capture) + `vgamepad.py` (virtual pad) for headless
   drive/observe — note keyboard XTEST does NOT reach FIFA; the gamepad is unverified
   in-game.
+
+---
+
+## REFUTED 2026-08-04: the CardsDb map is NOT empty offline
+
+This document has claimed since it was written that "**Offline that map is EMPTY**, so
+every lookup misses and a default blank record is emitted -> generic card", and that
+the view-model reads every rendered field from the resolved record and "NEVER from our
+item JSON". A live pack open falsifies both halves.
+
+### The observation
+
+One bronze pack, five cards. Two rendered as real players with names, club badges and
+national flags. Three rendered as blanks: rating 50, position RWB, every attribute 1,
+no name. Nothing in our pool has rating 50, position RWB or all-ones attributes, so the
+blank is the client's default record, exactly as this document describes.
+
+The two that resolved match OUR ITEM JSON field for field:
+
+| we sent | screen showed |
+|---|---|
+| `(232517, 62, RB, nation 36, league 19, team 175, [72,44,58,60,62,61])` | SILVA, 62 RB, Wolfsburg badge, Norway flag, 72 PAC / 44 SHO / 58 PAS / 60 DRI / 62 DEF / 61 PHY |
+| `(235066, 60, GK, nation 34, league 31, team 48, [62,63,33,61,17,62])` | NOWAK, 60 GK, 62/61, 63/17, 33/62 |
+
+Those attribute numbers were invented by hand. They cannot have come from a database.
+
+### What this means
+
+- The map HAS entries offline. Some asset ids resolve.
+- Rating, position, nation, league, team and the six attributes come from **our item
+  JSON** for a card that resolves.
+- Name, club badge and national flag come from the **client's own data**, keyed by
+  assetId.
+- When the assetId is NOT in the client's data, the whole card collapses to the blank
+  default, which is why a bad id looks like a rendering failure rather than a lookup
+  failure.
+
+### The consequence, which is much cheaper than what this document proposed
+
+The recommended plan here was to populate the client's map by driving its insert, hand
+building a red-black tree node, or patching the resolve miss-path, all of which write
+to a live process. **None of that is needed to get real cards.** The rule is simply:
+
+> Use asset ids that exist in the client's database. Valid id gives a real card.
+> Invalid id gives the blank.
+
+`fut_cards.py` currently carries 18 verified ids and 61 structural placeholders, and
+the placeholders are what produce the blanks. Two of them (232517, 235066) happen to be
+real, which is why the pack was a mix. The remaining work is therefore a DATA problem,
+getting the real id list out of `dbdata.dll`, and not a code-injection problem.
+
+`TODO/CONFIRM`: whether a resolved card's rating truly comes from our JSON or whether
+the client's record happens to agree. The attributes settle it (they were invented) but
+rating specifically has not been isolated. Send a deliberately wrong rating for a known
+good id and look.