A ten-step procedure for deciding whether, and how, the KV-state control plane of Chapter 3 โ SELECT, PLACE, MOVE โ applies to your own system, using only what this package has actually established, in the order the questions need to be asked.
Chapter 3 replaced a single conflated eviction decision with a control plane spanning two orthogonal hierarchies โ an information hierarchy (agent state โ context-region summaries โ candidate regions โ KV blocks โ token-level KV) and a physical hierarchy (HBM โ host/CXL DRAM โ NVMe/remote) โ resolved through three joint stages: SELECT, PLACE, MOVE. That architecture is mostly proposed, not validated; Chapter 3, ยง3.3 is explicit about which pieces have evidence and which do not. This chapter turns that same honesty into a procedure. It is not a checklist for adopting a tiering system โ it is a checklist for deciding, stage by stage, whether the control plane's assumptions hold for your workload, and for knowing exactly which of your conclusions rest on this package's evidence versus your own measurement.
Before evaluating any part of the control plane, check whether your workload's KV footprint can exceed fast-tier (HBM) capacity at all. If it can't, none of SELECT, PLACE, or MOVE has anything to do yet โ you don't have the problem this package's architecture exists to solve.
The capacity-crossover arithmetic from Chapters 2 and 5 is the filter. For Llama-3 70B-class GQA models, KV cache costs approximately 320 KiB per token, and the crossover point โ where a single sequence's KV cache exceeds the size of the model's own weights โ lands at roughly 427,000 tokens of context. If your realistic sequence lengths and concurrency stay well under the point where aggregate KV demand exceeds your fast-tier budget, look elsewhere first โ batching, model-weight quantization, request scheduling โ before reaching for a control-plane architecture at all.
If capacity is binding, classify the workload: dense-attention, sparse-attention, prefix-reuse-heavy, agentic/tool-using, or some mix. This classification determines which signal type in Chapter 3's taxonomy โ past-only (recency, frequency, EMA-style decayed scores) versus predictive (agent/tool-call state, tool-return timing, prefix identity, attention signals) โ is likely to matter for your SELECT stage.
Agentic and tool-using workloads are exactly where predictive signals have shown the largest measured external gains: per Chapter 10, CacheWise-class systems using agent/tool-derived predictive signals report 2โ2.6x fewer evictions and up to 3.5x completion-time improvement over past-only baselines. If your workload is agentic, predictive signals are the more promising direction to prototype for SELECT, even though this package itself has not tested them โ see Step Five.
Quantify the decode-phase cost of reading resident KV. This is not a hypothetical โ Chapter 4's two-term fit methodology measures KV bandwidth as a real, separately-attributable cost component of decode, distinct from weight bandwidth. Apply that same fitting approach to your own model and hardware to see how much of your decode-phase bandwidth is actually KV traffic versus weight traffic. If KV bandwidth is a small fraction of the total, the control plane's MOVE stage has less to gain from being optimized aggressively; if it's a large fraction, movement cost (Step Seven) and hiding movement (Step Eight) become high-leverage.
This is the SELECT stage of Chapter 3's architecture, and it is explicitly unvalidated in this package โ no simulation or hardware result here tests whether relevance/candidate filtering, ahead of any tier-placement decision, actually reduces the working set that PLACE and MOVE must handle. Chapter 3, ยง3.3 lists SELECT plainly as a proposed design with no result behind it.
The closest external evidence that this direction is viable comes from Chapter 10's survey of PNM-KV, which performs selection before recall and reports a 21.9x figure of its own (their number, not this package's โ it has not been reproduced here). Treat it as a signal that selection-before-movement is a live and plausible technique in the field, not as a validated property of this package's own architecture. If you build SELECT, budget it as new engineering and new measurement, not as inherited evidence.
A narrower version of Step Four: can SELECT use predictive signals โ agent state, tool-call timing, prefix identity โ rather than only past-access signals, per the taxonomy in Chapter 3, ยง3.4? Again, this package has not tested predictive signals; its one strong empirical result (Step Six, below) is built entirely on a past-only, recency/frequency-style score replayed against traces, not live agent state.
CacheWise is again the relevant external evidence, and again it is external: it demonstrates predictive signals working for agentic workloads elsewhere, not here. If your workload is agentic (Step Two), this is the direction most worth a small, isolated prototype before committing to any larger SELECT design โ but go in expecting to generate your own evidence, not to confirm ours.
This is the PLACE decision, and it is the one piece of Chapter 3's architecture with actual simulated evidence behind it in this package: the persistent-metadata result from Chapter 7, showing that policy state surviving a tier eviction โ rather than being discarded and rebuilt from scratch โ improves hit rate by +34.15 points for LFU and +24.85 points for EMA (ฮฑ=0.01) under a 32 GiB HBM budget. It is simulated and provisional, not measured on real hardware, but it is this package's strongest result, and Chapter 3, ยง3.3 confirms it is the only row in the architecture's evidence table marked "has evidence."
It is also the cheapest of all ten steps to check yourself: it's a protocol-level question about whether metadata persistence helps, answerable in software simulation against your own access traces before touching any tiering hardware at all. If you take one concrete, well-evidenced action from this chapter, make it replicating this experiment against your own workload.
Once PLACE has decided what belongs off the fast tier, MOVE has to actually transfer it, and the cost of that transfer is Chapter 5's analytical tier-fetch/regenerate cost model โ an order-of-magnitude estimate, not a measurement on real CXL hardware. Do not treat the bandwidth and latency ranges used in that model as ground truth for your deployment; they are modeling assumptions this package has not validated against a physical CXL fabric. Measuring your own tier-ingress bandwidth and per-transfer latency is a prerequisite before any MOVE design decision, not an optional follow-up.
This is the other half of MOVE, and it is where the payoff of a working control plane looks largest โ when it works. Chapters 7 and 11 report that under an idealized-overlap model, recompute avoidance becomes more than 99% of total stall, meaning that when a fetch or transfer can be scheduled behind ongoing compute rather than sitting on the critical path, the residual cost of movement nearly disappears. That is an idealized figure, not a hardware measurement, but it is a strong argument for treating MOVE scheduling โ not just MOVE bandwidth โ as a first-class design target: hiding a slow transfer well can matter more than making the transfer itself faster.
A tier doesn't have to hold full-precision KV. It could hold compressed or quantized KV, or โ per the information hierarchy in Chapter 3 โ a context-region summary rather than token-level KV at all. Both options are open questions in this package. Chapter 4 notes explicitly that fp8 KV compression was not measured; no throughput, accuracy, or bandwidth number exists here for it. And the summary-representation idea is a structural feature of Chapter 3's information hierarchy, not a tested mechanism โ nothing in this package builds or measures a context-region summary as an actual stored artifact. Both are legitimate design directions and both require your own prototyping before you can size their benefit.
Finally, decide whether a given piece of the control plane belongs in the runtime, in the device/controller, or in a shared control plane spanning both. Chapter 9 lays out the GPU/controller integration design space this question sits inside. Chapter 3, ยง3.5 offers one narrow, already-adopted design note within that larger space โ host owns policy, device owns mechanism โ describing specifically who executes the residency-persistence operation inside PLACE and MOVE. That note answers Step Ten for one sub-mechanism; it does not answer it for SELECT, for predictive-signal processing, or for movement scheduling, all of which remain open placement questions of their own.
Set against all ten steps, three currently rest on evidence generated inside this package: Step One's capacity-crossover arithmetic, Step Three's measured decode-phase KV bandwidth split, and Step Six's simulated residency-persistence result. All three are either directly measured or grounded in a repeatable measurement methodology, and all three are cheap to re-run against your own numbers before committing further engineering.
The remaining six โ selection (Step Four), prediction (Step Five), movement cost (Step Seven), hiding movement (Step Eight), representation (Step Nine), and mechanism placement (Step Ten) โ remain open design work. Some have promising external evidence (CacheWise for prediction, PNM-KV for selection); some have only analytical or idealized models (movement cost, hiding movement); one is untested in any form here (representation). Be explicit with yourself about that ratio: seven of ten steps in this procedure are open, not validated, and the honest reading of this package is that the control plane's architecture (Chapter 3) is a coherent design with one solidly evidenced load-bearing piece, not a finished, measured system. Use this chapter to decide what to build, not what to assume already works.