Clarify E8 key is an added lookup layer, not a footprint reduction: the full embedding is retained in every mode and never discarded

README.md

@@ -64,10 +64,16 @@ library README's own benchmark table for the real, mode-by-mode picture (includi
 this mechanism scores 0% on real asymmetric RAG).
 
 > **Compression basis:** 1 address byte per 8-dim block × 128 blocks = 128 bytes for a
-> 1024-dim embedding, vs 4,096 bytes for float32 = 32x. This applies to E8 key storage only;
-> see [LatticeMemory](https://github.com/sangmorg1-debug/latticememory) for hybrid mode,
-> which also stores a dense (Int8/float32) fallback index for asymmetric retrieval — that
-> fallback, not the E8 key, is what actually serves paraphrase/RAG queries today.
+> 1024-dim embedding, vs 4,096 bytes for float32 = 32x. This describes the *added* E8 key
+> structure's size, not a reduction in what's stored — LatticeMemory retains a full-precision
+> embedding for every document permanently (used for exact-hit scoring), in every mode,
+> whether or not a dense fallback is configured; there's no path to discard it once a document
+> is keyed. The E8 key is an O(1) hash-bucket lookup layer added on top of the retained
+> embedding, not a replacement for it — it buys lookup **speed** for exact/near-exact hits, not
+> smaller total memory. See [LatticeMemory's README](https://github.com/sangmorg1-debug/latticememory#readme)
+> for the full breakdown, including hybrid mode's separate dense (Int8/float32) fallback index
+> for asymmetric retrieval — that fallback, not the E8 key, is what actually serves
+> paraphrase/RAG queries today.
 
 ## Usage