The paper's token-cap analysis is positioned as a diagnostic tool, not a new compression method. Starting from the observation that fixed-$k$ retrieval does not imply fixed token budgets, the paper applies a hard token cap on top of an already-selected candidate set and measures how performance moves. Because the underlying selection is held fixed across compared systems, the analysis isolates two specific factors: (i) ordering — which retrieved items survive the cap and in what rank, and (ii) serialization — how the surviving items are concatenated into the LLM input. The contribution is therefore an audit of how prerequisite-graph-aware retrieval interacts with a length budget under strict parity, rather than a new length-aware compressor in the style of knapsack-based selection or prompt compression.