docs: add Tier 7 to the roadmap after an external review

[tonytonycoder11]

An external review raised a set of items against Kmemo. This triages them into a new Tier 7 (M19 to M23) and records, next to each declined item, the reason it was declined, so the same suggestions do not have to be re-litigated later.

The filter is deliberately narrow: an item earns a milestone only if it answers something a team actually hits once the cache is on a request path. Nothing here is added for completeness.

Accepted

Milestone	Why it earns a place
M19 · Exact-match fast path and conversation-aware keys	Every getOrPut embeds, a network call, even when the prompt is byte for byte one already cached. An identical prompt in the same scope is the same question, so the fast path needs no guards at all and adds no false-hit risk by construction rather than by measurement. Embedding, not search, dominates what a lookup costs.
M20 · Shadow mode	ThresholdCalibrator needs a labelled set, so the honest answer to "what threshold should I use?" is currently "measure it, on data you first have to build". That step, not the cache, is what stops teams putting a semantic cache in front of production traffic.
M21 · Invalidation beyond TTL	A TTL is a guess about when knowledge might go stale; it is not a way to act on knowing that it just did.
M22 · CachePolicy	kmemo-slf4j redacts prompts in logs, but the cache stores prompts and responses verbatim. For a regulated adopter the first question is whether they can prove a class of data never got persisted.
M23 · The comparative benchmark	The central claim, that Kmemo rejects near misses other caches serve, has never been measured against another cache, only against this project's own corpus.

Three judgement calls worth surfacing, because they changed the suggestion rather than accepting it:

• M19 also makes conversation keying explicit. kmemo-langchain4j already keys on the whole conversation, but core getOrPut has no notion of a turn. A caller who caches turn five of a dialogue on its text alone serves a confident wrong answer, which is precisely the failure this library exists to prevent, arrived at through the key rather than the threshold, where no guard can see it. scope is already the primitive; what is missing is the documented pattern and a helper.
• M21 documents the pattern that already works first. Version the scope (pricing-v3.2 to pricing-v3.3) and clear the old one: no new API, atomic cutover, and for many teams the entire answer. Tags and predicate deletes come only where that is too coarse, because that is a seam change touching CacheStore, the TCK and all four adapters.
• M23 deliberately excludes cross-runtime latency against GPTCache. A JVM versus Python wall-clock figure compares runtimes while appearing to compare caches, and publishing it would undercut the honesty the rest of the corpus work rests on. Only precision, recall, F1 and false-hit rate on identical inputs. Latency and throughput stay in kmemo-benchmarks, across Kmemo's own configurations.

Declined, with reasons recorded in the roadmap

• Provider prompt caching as a third layer. It happens inside the provider's API. There is no seam for Kmemo to own, and presenting it as a Kmemo layer would take credit for a saving the library does not produce.
• Reversible PII redaction. Reversible means the mapping is stored, which relocates the sensitive data rather than removing it: a weaker posture than not caching the entry (M22), sold as a stronger one.
• Distributed propagation of the negative cache. It is deliberately local and only ever reuses a vector, never suppressing a search, which is exactly why it cannot manufacture a false hit. Making it coherent and distributed would add a coherence problem to defend that property, in exchange for saving embedding calls.
• A shipped event-bus module. CacheListener already is that seam; bridging it to a broker is a few lines in the application, where the broker dependency belongs. Ships as a recipe.
• Distributed cache-warming locks. A warm() race wastes embedding calls at startup; it corrupts nothing.

In M18, a cross-encoder reranker is declined as duplicating the Verifier seam while putting an ML dependency next to a core with one dependency. Quantization is accepted, but only with exact rescoring of the survivors, so the precision loss lands on which candidates are considered and never on the accept or reject decision itself: the same discipline the HNSW store already follows. PCA is declined for the reason rescoring cannot fix.

Scope

Documentation only: ROADMAP.md and the README Roadmap section. No code, no CHANGELOG.md entry, since nothing shipped. Checked against ROADMAP-CONVENTIONS.md: no ✅ without a version, tier and milestone headings conform, and the README carries the Shipped / Next / Later labels the standard calls for.

M17 gains the on-device rationale that makes the KMP migration worth its cost. It is the same migration as Kdrant's M25 on the same toolchain, and both now say so. The companion change is NaCode-Studios/Kdrant.